SharePoint 2010 has been gaining more and more traction lately in the portal space as well as the public website/web content management space. As such, organizations are trying to maximize their investment by enhancing their SharePoint-based sites with improved user experiences and custom functionality.
Simply put, the out-of-the-box SharePoint user experience is somewhat generic. It begs for a visual and functional face-lift in order to be used as an effective tool for digital marketing as a public-facing website. In some ways, one has to assume this was Microsoft’s intention. Knowing it is impossible to satisfy everyone’s specific needs with one “silver bullet” product, Microsoft built a platform with a bevy of integration points, documentation, and development tools so that organizations can build exactly what they need. These customizations range from integrating an existing line-of-business application to a complete user experience overhaul “making SharePoint not look like SharePoint.”
The underlying issue, however, is that many SharePoint sites are functional and even fully responsive according to screen size but have sacrificed features like web content management (WCM) that are inherent to SharePoint. Essentially the capabilities of SharePoint have been limited by using it simply as a host for custom web sites or applications rather than a platform to build upon. We sometimes refer to this as developing “on top of” versus “within” SharePoint.
Generally speaking, there are two high-level approaches to customizing SharePoint:
1. Customize existing out-of-the-box functionality to meet requirements.
2. Develop custom solutions to add additional functionality to the platform.
In our experience, one of the most difficult parts of SharePoint customization is determining the best approach for a particular requirement. Is the requirement straightforward enough that existing SharePoint components can be used? For example, can we use content types or an existing web part such as the Content Query Web Part? Or is the requirement unique enough to require a custom web part or an external database? Realistically, because of varying requirements, seldom is the result one approach or another. The customizations are more likely to be a hybrid of leveraging and configuring out-of-the-box functionality and then supplementing the out-of-the-box with the deployment of custom code.
Given this, there are several core principles and best practices that govern whether a certain requirement falls into one bucket or another, and how best to address these principles, which are worth mentioning here. Note that many of the best practices Northridge uses from a SharePoint user experience and branding perspective are the same as those used from a SharePoint custom development perspective.
1. Deploy customizations in a repeatable manner from one environment to another. It is in everyone’s best interest that there exists at least one other environment other than the production environment and local development environments that can be used as a staging environment to perform testing against. To maintain consistency as well as sanity, customizations should be maintained as features that are packaged in a WSP solution file so that they can be deployed on separate environments with minimum effort and maximum consistency. Customizations that may not be able to be packaged in a WSP solution should be scripted in a PowerShell script that can be run against a server.
2. Preserve standard SharePoint functionality whenever possible. It’s likely that a number of the desired customizations can be done by manipulating and configuring out-of-the-box functionality. The Publishing Framework in SharePoint 2010 provides excellent components such as content types, page layouts, lists and document libraries, and web parts that may already support your needs with just a few tweaks. SharePoint provides the most value when used as a platform to build upon and not a hindrance to replace with customizations.
3. Stay away from existing files in the 14 hive. In a standard SharePoint 2010 installation, the files are installed in a folder named “14″, since the official version number for SharePoint 2010 is actually version 14 (and SharePoint or MOSS 2007/WSS 3.0 is technically SharePoint 12, hence the files are in this version are in a folder named “12″). This “14″ folder has come to be known as the “14 hive” and when it comes to customization, the manipulation of any of the existing files in this folder can adversely affect the SharePoint installation involving patches or upgrades. Customizations from farm solutions that need to be deployed into the 14 hive should be deployed into new folders to prevent naming conflicts with existing files.
With over a decade of experience in the areas of business consulting, user experience, and collaboration technology, Northridge is a national leader in Microsoft SharePoint solutions and a dedicated Microsoft partner. Utilizing the SharePoint platform, Northridge creates user-centric experiences that integrate the appropriate visual, informational, and interactive design elements for target audiences.
Loading ...
