Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
✇MS Technology Talk

Building Custom SharePoint Solutions to Meet Your Business Needs

SharePoint is a powerful platform for building custom solutions that meet the unique needs of your business. One way to extend SharePoint’s functionality is by creating custom web parts. A web part is a modular component that can be added to a SharePoint page to display information or perform a specific function. In this blog post, we’ll explore how to create custom web parts in SharePoint to build custom solutions for your business needs.

Planning Your Custom Web Part

Before you begin building your custom web part, it’s important to plan out the requirements and functionality you need. This includes identifying the data sources, user interface, and any other features that you want your web part to include. Some questions you may want to consider during the planning phase include:

  • What data sources will your web part use?
  • How will users interact with your web part?
  • Will your web part require any custom logic or functionality?

Creating Your Custom Web Part Using Out-of-the-Box Features

SharePoint provides several out-of-the-box web parts that you can use as a starting point for your custom web part. These web parts include the Content Editor, Image Viewer, and Script Editor web parts, among others. You can customize these web parts by modifying their properties or adding your own code. To create your custom web part using out-of-the-box features, follow these steps:

  • Navigate to the page where you want to add your web part and click the Edit button.
  • Click the Insert tab on the ribbon and select the web part you want to modify.
  • Modify the properties of the web part or add your own code using the Script Editor web part.

Creating Your Custom Web Part Using PowerApps

PowerApps is a low-code platform that allows you to create custom web parts without writing code. With PowerApps, you can create custom forms, dashboards, and other components that can be added to a SharePoint page. To create your custom web part using PowerApps, follow these steps:

  • Navigate to the PowerApps portal and create a new canvas app.
  • Design your app by adding screens, forms, and other components.
  • Publish your app to SharePoint by selecting the PowerApps option on the Insert tab in the SharePoint ribbon.

Creating Your Custom Web Part Using SPFx

The SharePoint Framework (SPFx) is a modern development framework that allows you to build custom web parts using modern web technologies such as React, Angular, and TypeScript. With SPFx, you can create powerful, dynamic web parts that can be added to any SharePoint page. To create your custom web part using SPFx, follow these steps:

  1. Install the necessary tools and dependencies for SPFx development.
  2. Create a new SPFx web part project using the Yeoman generator.
  3. Develop your web part by adding components, styling, and logic.
  4. Deploy your web part to SharePoint by packaging it as a SharePoint solution and uploading it to the SharePoint app catalog.

Creating custom web parts in SharePoint can be a powerful way to extend SharePoint’s functionality and build custom solutions for your business needs. Whether you use out-of-the-box features, PowerApps, or SPFx, you have the flexibility and power to create web parts that are tailored to your organization’s unique requirements. By planning out your requirements and following best practices for development, you can create web parts that deliver real value to your organization.

The post Building Custom SharePoint Solutions to Meet Your Business Needs appeared first on MS Technology Talk.

✇More SharePoint

Collapsible Current Navigation in SharePoint...and my new job

Big news in the beginning of this week. No, I'm not back to school :) I recently accepted a new job as an internal SharePoin employee for a company which is not yet an enterprise, but not a startup either. It will be very different than all of my past experience at service providers and consultancy engagements, but I am excited as it's a very innovative organization and we met when it's just about time for some SharePoint(ing).

Now to the point... one of my first tasks is to create the organization's navigation structure for an Intranet portal. We will use Managed Navigation after an evaluation and demos of all the possible methods. I will do this on SharePoint Online for the example, but the method is the same for SharePoint 2013 as well.

The decision to use Managed Navigation is not the scope of this post, a very good comparison by Microsoft is published here, which evaluates performance, needs and in fact all pros and cons.

One of the main requirements is for the Current Navigation to become collapsible, imagine a Windows Explorer style...like the following example. Now, if you have users that will be switching from file shares to SharePoint, that type of navigation might come handy. I personally don't really like the fact that it does go very big when you expand a lot of nodes, but there's a solution for that.

If the SharePoint site structure becomes deeply nested e.g. Site Collection -> Site -> Site -> Site ... this will also be a pain to navigate in, and most users would most likely prefer the Search option (I got this feedback after conducting a few user interviews and demoing this type of navigation).



Let's review the options to achieve the closest functionality in the SharePoint Current Navigation.
We assume we'll only have one site collection, which is nowadays common for small to medium sized organizations. Especially if you go the SharePoint Online route.

Option 1: Tree View

The way to enable this is simply going to Site Settings -> Tree View -> Enable Tree View.



The Tree View looks like this in a site collection (left) and respectively in a site (right):


Now, I'll share my view, based on experience around this functionality.

Pros:

- Sites are automatically added, no admin overhead
- OOB solution. No custom master page need, hence sticking to the Office 365 best practices.
- Displays lists and libraries in addition to the sites
- Easy to use, nice icons on the left, indicating the type of each node - that's all OOB again.

Cons:

- NOT security trimmed!
- Displays the Apps (add-ins) as well, no way to hide those. The regular user might not need them.
- Can take a large part of your screen and becomes unusable if you need too much scrolling
- Enabled per site level only, e.g. you need to save your site as a template and create new sites based on that if you need Tree View enabled by default
- NOT consistent accross sites. E.g. does not show the parent navigation when you're in subsites. 
- NO way to customize it OOB, needs custom CSS (not a big deal, you still don't need to modify the master page for that and the OOB view might suit you just fine in some scenarios.)


Option 2: Managed Navigation + custom CSS

The Managed Navigation requires some planning, manual work and a lot more maintenance then the Tree View. The way to enable it will be out of the scope of this post, but just don't forget to enable the Publishing feature on your sites before you switch to this navigation. It's a prerequisite. 

The way it looks in a very quick and simple demo is this:


But it's not collapsible by default!... Even though there are some articles online suggesting the use of fly-out menu I personally didn't feel it's good enough (e.g. a lot of levels will take a lot of space oon the right of the designated navigation menu control)

There's another solution which uses jQuery and provides the "accordion" feeling. But this will generally work if your items that you want to expand don't have a hyperlink. E.g. if in the above screenshot Operations doesn't point anywhere, then it would make sense to expand it with a click and see its children. But in our scenario the 1st level items would be links to actual sites...the solution still works... but in order to expand the children, you'd need to wait for the parent link to load. Not good, could be annoying for users and the link might point you to a site which doesn't inherit the same navigation. 

So... to just quickly review the Managed Navigation against Structured Navigation and the alternative Tree View option... read further.

Pros:

- Consistent across all sites if you inherit navigation in the subsites
- Very good for public sites or extranets, where you don't want it to definitely reflect your site structure.
- Better performance than the structured navigation
- More compact than the Tree View and very good looking when customized

Cons:

- Sites are not automatically added, it requires some maintenance
- Not security trimmed.
- Not collapsible OOB for use in Current Navigation. Needs custom CSS and potentially JavaScript.
- By default it's set to display only 2 levels of hierarchy - e.g. Projects site -> Project X subsite. If you want to display libraries and lists for example, or anything else... you need to touch the master page.

Now on the collapsing functionality... you can achieve that by using some simple css. Take the example a few lines below and save it somewhere on your SharePoint site. For the demo I've used a file, called sideNavBox.css and I've put it in the Style Library.

I got the original idea from Dércia Silva at broculus, but that solution seems to work well only for small navigation structures. I don't see it working with more than 2 levels and it requires you to click on a menu item (e.g. a site) to see its children.By default SharePoint will load the site if there's a valid link behind the navigation menu item. Not too good, you might have clicked on it by mistake, and you might not want to wait the load time (imagine it's a heavily customized site).  It also uses jQuery, while I think this functionality can be achieved by CSS only. 

So I decided to use the :hover pseudo selector instead of the .selected class to address the need for the click issue.

/* Do not show nested ul by default */
#sideNavBox .ms-core-listMenu-verticalBox ul ul {
 display: none; !important
}

/* Show nested ul on hover only */
#sideNavBox .ms-core-listMenu-verticalBox ul li:hover ul {
 display: block; !important
}


Now you need to refer your site to the custom CSS file. Go to Site Settings -> Master Page -> Alternate CSS URL (preferred solution): 



...or if for some reason you can't do the above, then as a last resort insert it in a custom Master Page directly by putting this line in the <head>. (change the path to your CSS). Please have in mind that custom Master Pages  in SharePoint Online should be used if no other customization option exist. The reason behind this is that you''ll end up not getting regular updates on master page functionalities released by Microsoft (they only deploy these to the oslo and seattle master pages).

If you're interested in the way Office 365 Sites branding is going forward, I recommend this great explanatory session by Vesa Juvonen. Then you can decide... to brand... or not to brand :) 

If you do decide to ignore the recommendations, here's the control you need to insert in your master page...

 <SharePoint:CssRegistration Name="Style%20Library/en-us/Themable/sideNavBox.css" runat="server" />

So, with the hovering trick and some more customizations I've added the nav menu looks like this. Currently I am hovering over the PMO link which is a site in a site collection (could be anything) and Project 1/2/3 are sites under PMO (again could be anything you add in the Managed Navigation through the term store management tool)

The extra styling is just for some similarity to the Tree View menu (the icon is a shameless steal from there)...  The "Edit Links" item is hidden and colors/sizes are slightly changed. Some cheeky icons added on the left to make it look more intuitive, too. Pretty  basic for the means of our example today:



Here's the additional CSS I applied:


/* Any style you want for the left-hand nav control*/
#sideNavBox {
background-color: #DBE8F3;
}

/* Making some room for the icons on the left */
.ms-core-sideNavBox-removeLeftMargin {
margin-left: 5px; !important
}

/* Insert the plus icon for the ul */
#sideNavBox  ul {
list-style-image: url('/Style%20Library/Images/Expand_01.gif'); !important
}

/* SP treeview expand icon for the nested ul */
#sideNavBox  ul li ul{
list-style-image: url('/_layouts/15/images/tvclosed.png'); !important
}


/* Hide the Edit Links button in the current nav */

.ms-listMenu-editLink {
 display: none; !important
}

And now to the levels... we have the requirement to display more than the two level of hierarchy on the screenshot above. Now if you get to this, and you definitely want to use Current Navigation (rather than Global Navigation) for this (regardless of the fact if you use Structured or Managed Nav in the background) then you need to edit your Master Page e.g. use a custom Master Page in SPO.

So, in a bit more details:

1. Create a blank master page
2. Open your seattle master page and copy all the code to the new one.
3. Go to the V4QuickLaunchMenu control.

       <SharePoint:AspMenu id="V4QuickLaunchMenu" runat="server" EnableViewState="false" DataSourceId="QuickLaunchSiteMap" UseSimpleRendering="true" Orientation="Vertical" StaticDisplayLevels="3" AdjustForShowStartingNode="true" MaximumDynamicDisplayLevels="0" SkipLinkText="" />

To properly achieve your goals, you might need a bit of clarifications on this above piece of code.

StaticDisplayLevels are the hierarchical items that will show in the navigation control. You would imagine that this solution will work like a charm and display the navigation representing the term store hierarchy. The problem is, if you increase that to 4, for example, you'll get this due to the lack of space in the OOB control. To visualize what I mean I've shown a small part of the term store managed navigation and the way it was represented after I've increased the StaticDisplayLevels.

So the expectation would be to see the same structure as on the left hand-side.
 ... but the reality is different: 

Let's look at the solution for this:

MaximumDynamicDisplayLevels are the hierarchical items that will show outside of the control.
Increasing that number will give you the items, but outside of the Quick Launch menu. Not too bad.
This functionality works OOB in the Global Navigation, so it's a good idea to consider that as well.


So... just a slight tuning here, in order to achieve the same styling as on the regular list items, I've had to apply the below CSS (not needed if you didn't use custom styling for this at all).

/* customize the dynamic ul */
#sideNavBox .ms-core-listMenu-verticalBox .dynamic {
 background-color: #DBE8F3; !important

}


That's it folks, hope you enjoy your new collapsible current navigation. If not, you can always switch to the Global Managed Navigation - it will collapse by default, it kind of uses the space on the screen in a more rational way and could be customized to the same extent. It's the user preference -horizontal or vertical menus... you could even go for the trendy mega menus in the Global Navigation (more suitable for public websites in my personal opinion anyway).
❌