Summary: SharePoint web parts and lists can easily allow users to adapt SharePoint to changing business needs if customizations are designed and developed properly. Specific examples are provided in the second half of this blog.
I’ve been around the technology block a few times; I mean my first computer program was written on what really were just variations of Jacquard cards for a Burroughs 5500. The technologies underpinning the systems I help enterprises implement today are soooooooo much better and of course ever-changing.
In one important way though, they are not all that different. They are still being used to fill the same set of human needs today as they were then. The set isn’t really all that large either: measurement, communication, calculation, analysis, prediction, control, and presentation pretty much cover it. It’s been the same set of needs since long before Jacquard created his first process control card.
If you are a bit skeptical about anything I’ve said; good. My purpose is to get you thinking about change; unavoidable, ever-present change. As a school of Pre-Socratic Greek philosophers used to state, “You cannot step into the same river once”. That might be a bit extreme but it’s not that far off the mark.
How does all this relate to SharePoint? There is a tremendous amount of SharePoint development work taking place currently. Developers across the globe are writing code for web parts, for workflows, for navigation, for search, and for every other aspect of SharePoint that can be customized. That’s a good thing. That’s the power of SharePoint. It is an application platform. It can be customized to meet the specific needs of an organization and every organization has some needs that are unique.
Ever-present change will affect the products of all that development work, however, and in some cases workflows and web parts are going to have short lives relative to the business needs they must fulfill. Yet SharePoint has a native ability to accommodate change. It’s not alone in this ability, but it is nearly unparalleled in the ease with which it can do so. More importantly, if designed and developed properly, modifying SharePoint to accommodate change can be put in the hands of those who use SharePoint – people in the business and corporate support units in your organization. This can significantly reduce the need for a developer in the Information Technology department to modify tiny modules of code due to ever-changing business requirements.
This can only happen by design though.
Web part properties and SharePoint lists are the main ingredients in the secret sauce I’m talking about here. These two features can provide tremendous flexibility for SharePoint customizations and allow users to modify SharePoint’s behavior as needs change. Using these two features to accommodate change is one of the keys to durable SharePoint customization. It seems obvious enough, but it takes discipline and continuous attention to detail to ensure that this flexibility is provided throughout the entire SharePoint system and all the customizations that can benefit from it.
That said, you should also be aware that like most everything else, this comes at a cost. It is going to take more design and development effort to do this than it would to embed the values in the code or even to use a custom database, configuration files or other ways of storing configuration values. Should the list be kept in a top-level site or in the sub-site where they are used? Should a special content type be created to store the values? These are just two questions that apply in the SharePoint arena the don’t apply elsewhere. Looked at from a broader perspective though, each of these non-SharePoint approaches have their own costs as well. There are performance costs too that cannot be completely ignored. If designed properly and with the correct server provisioning and farm topology the performance costs becomes less and less significant though.
Using configuration repositories to control and modify the behavior of applications is nothing new. ASP.NET uses the web.config file (or files). There’s the Windows Registry and, for the nostalgic among you, recall ini files. Again, SharePoint is so much easier to use for this purpose though. Who would really suggest that business users be allowed to change registry values or web.config files? (Yes, of course a user-friendly UI can be developed to allow this, but we all know it’s not as simple as it sounds and even so, such interfaces would likely be application specific.)
Since you’re implementing SharePoint, then, why not use it as fully as you can:
- for the business uses you are targeting and
- as a repository for control values as well as.
Let’s look at just a few specifics.
I’ve written before about the following use of lists. The region around the four sides of SharePoint content pages are produced by something called a master page. It and its supporting files essentially control the navigation and the branding or look and feel of SharePoint pages. The SharePoint UI allows a site to use one and only one master page for all the content pages (known as layout pages) it contains. This means that if a few content pages in a site need to have different navigation or look and feel than the other pages (specialized pages of some sort), SharePoint native functionality falls short. A very few lines of code can be used to provide the customization necessary to overcome this limitation though. More importantly, if a list like that show here is used, newly created master pages or layout pages can be tied together simply by editing the list.
At PointBridge we are continuing to see a number of organizations expressing interest in Social Networking using SharePoint. In many cases there is a need to display more information than can be accommodated easily on the person.aspx page as it exists natively. Further, some organizations have requirements to display data that are located in many different repositories like Active Directory, an HRIS database, a Time Reporting system and so on. There are numerous ways to fulfill these requirements the details of which are not important here. What is important is looking at how a list can be used to help control how and where the data are displayed.
The grouping of employee data in the SharePoint User Profile database is controlled by the Section property. Every piece of data belongs to one and only one section. This limits the ability to provide multi-level grouping. You can create a section named Memberships, for example, but within that you cannot create subsections for say, Professional, Community or Philanthropic. This makes organized presentation of employee memberships difficult. Customization of SharePoint can address this.
Often, though, the organization of the data would be designed into the logic of the customization; the code itself. If modifications of the sections were necessary due to new business requirements, the customization code would need to be modified. The use of a list similar to that shown below can eliminate or greatly reduce this need. What’s more, additional columns can be used to control the page on which the data are displayed, the sequence on the page and so on.
Both of the previous examples use lists as inputs to customization code. List values can also be used to control values for web part properties. We’ll look at one example in this blog. If you are interested in another great example check out Matt’s blog: Make Life Easy for your Users.
One of the more common customizations written for SharePoint involves user roles. For example, the class, SPRoleDefinition can be wired up to SPWeb.AllRolesForCurrentUser to enumerate all the role memberships for a user. Web parts like that shown here, would often be designed to populate the dropdown by reading from the site roles (SPRoleDefinitionCollection roles=SPWeb.RoleDefinitions). This is dynamic but if a subset of the roles is to be displayed in the dropdown the problem becomes more complex and potentially requires recoding as new roles are created.
A list like that shown below can be used to populate the dropdown and as we’ve seen before insulates the web part from changing business requirements and places the responsibility for managing the list, and therefore the web part’s dropdown items, with the site owners rather than the IT department – a common good.
.
