More Customization on SharePoint, Good or Bad?

The way I see it, SharePoint is one of the products that vary quite a lot compared to other products that developers have to engage with. If we look at what SharePoint had in 2007 the improvements in 2010, it has built up lot of potentials to it. Comparing 2010 with 2013 version is another big ask. So will these customization we make affect a migration and performance after migration? The answer is YES. But this does not mean we should not customize SharePoint.

Why make customization?

SharePoint has its own limitations. It is not a platform tailor-made for every business. So we need to customize it. But there are some silly arguments that some clients do not like SharePoint to look the way it is by default. They need the breadcrumb removed, they need some other standard features hidden from the interface but they do not mind letting users access them direct via a URL. I think this does not make much sense. After customizing the client need some menu items added that are not frequently used. So why do not consider the SharePoint defaults the same way? Having a drop down menu will not ruin your site.

Another reason for a customization was the need to integrate a search functionality across a list. By default SharePoint list view webparts supports filtering and sorting. But this specific client was so hungry to do a quick search for like 200 list items. This is something can be found very easily through sort and filter. To cater this scenario in SharePoint 2010 we had to add some jQuery libraries and create a custom web part.

Impact on Customizing

Although customizing is recommended for SharePoint it has some impacts when come to the migration. Definitely the .NET Framework changes. So there can be some changes in the method APIs. Perhaps the classes we do refer can be moved into some other namespaces. These are not quite often but if you are unlucky to find one, you can spend hours searching for it.

It is always recommended to reduce the amount of code customization but this is not practical. If you have created workflows in SharePoint 2010, then you have to run workflows in 2010 mode even you migrated to SharePoint 2013. Else you will have to redo the workflows in SharePoint 2013 mode which is the recommended.

Use SharePoint Property values

Even when you are customizing, it is good to make things configurable. For example if you are connecting to a data source outside, you can store the connection string in a web application or property. Then this can be changed anytime. Also maintain virtual versions if possible and store the version as a property value so that can be configured whenever necessary.

Implement Design Patterns

Design patterns solve some common problems that can occur in solution design. Therefore try to make use of the design patterns in your code. This can make changes much easier and changing at one place may not have effect on another. Does not matter whether you use C#.NET or JavaScript, using design patterns will be useful.

In a summary, it is not stopping your selves from customizing but making only necessary customization that are necessary. Also whenever writing some code, make use of design pattern implementations so you can avoid common design problems.

This article was first published by Malin De Silva here>>

For more informative content on SharePoint customization and design why not check out this conference presentation ‘Give the SharePoint Designer a Chance!’. Download presentation now>>


Share this on...

Rate this Post: