Microsoft’s latest release of SharePoint (SharePoint 2010) has been gaining more and more traction lately in the collaboration/portal space as well as the public website/ digital marketing space. As such, organizations are trying to maximize their investment by enhancing their SharePoint solution with custom functionality and improved user experience.
Let’s be frank, the out-of-the-box SharePoint user experience is rather generic and begs for a visual and functional face-lift to really drive user adoption on an intranet portal or to be used as an effective tool for digital marketing as a public-facing website. In some ways, one has to assume this was intentional on Microsoft’s part. Knowing they can’t satisfy everyone’s specific needs with one “silver bullet” product, they built a platform with a bevy of integration points, documentation, and development tools so that organizations can build what they specifically need. These customizations run the gamut, from integrating an existing line-of-business application such as a CRM to a complete user experience overhaul to “make SharePoint not look like SharePoint.”
The issue, however, lies in the fact that there are many SharePoint sites that are functional and even fully responsive according to screen size but that have sacrificed features like web content management (WCM) that SharePoint provides. In essence, the capabilities of SharePoint have been limited by using it as a host for custom web applications rather than a platform to build upon. We sometimes refer to this as developing “on top of” versus “within” SharePoint.
There are generally two high-level approaches to custom SharePoint development:
- Customize existing out-of-the-box functionality to meet requirements.
- Develop custom solutions to add additional functionality to the platform.
One of the most difficult parts of SharePoint customization is to determine on which side of the fence certain requirements fall into. Is the requirement straightforward enough that there are existing components that 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? In reality, because of varying requirements, the result will rarely be exclusively one approach or another. Rather, it’s much more likely that the customizations will 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 some essential core principles and best practices that govern whether a certain requirement falls into one bucket or another, and how best to address them, that are worth mentioning here. Note many of the best practices we use from a custom development perspective are the same from a user experience and branding perspective.
- Customizations should be able to be deployed in a repeatable manner from environment to environment. 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
- Maintain as much standard SharePoint functionality as possible. It’s likely that a number of the customizations that you’re looking to do 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 provide what you’re looking for with just a couple of tweaks. SharePoint should be treated as a platform to build upon and not a hindrance to replace with customizations
- Steer clear from the 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 when it comes to patches or upgrades. Customizations from farm solutions that need to be deployed into the 14 hive should be deployed into new folders to avoid any naming conflicts with existing files.
