I talk with a number of SharePoint customers and developers. Interestingly, some of the experiences are common no matter where you go. What is even more interesting is that every time I mention the same solution, their eyes light up!

In this article, I am going to talk about five things from an architect or management point of view that you wish you knew before you started your SharePoint project. In part two of this article I will follow up with five things, targeted specifically for the SharePoint developer.

One fine day, I put my customer hat on and decided to learn about “What is SharePoint?” I went to Microsoft.com/SharePoint to read Microsoft’s description of the product. At http://www.microsoft.com/sharepoint/prodinfo/what.mspx, I read the following:

Microsoft Office SharePoint Server 2007 is a new server program that is part of the 2007 Microsoft Office system. Your organization can use Office SharePoint Server 2007 to facilitate collaboration, provide content management features, implement business processes, and supply access to information that is essential to organizational goals and processes.

Brilliant. That helped me a lot. I am now thoroughly convinced that there is actually a department at Microsoft whose sole focus is to come up with boring product names and mind numbingly generic product definitions, like the above.

But collaboration and being productive, and meeting our organization’s goals (whatever they may be) is what everyone wants. Right? Of course! And thus SharePoint entered the organization and was installed. It empowered end users. They created lists and document libraries, even sites and sub-sites willy nilly. It made for such a beautiful honeymoon.

And like all honeymoons, it is short. Two blinks and you had three crying kids, a mortgage, and a recessionary job market.

Users found themselves a bit lost in the UI. They really didn’t want to share information, so they broke site permissions inheritance, locked out the administrator, and then forgot their password. You had a wild sprawl of SharePoint sites and the search indexer kept getting stuck. Users were not happy, and it was all the IT department’s fault. That’s you!

It didn’t have to be that way! You don’t have a time machine, but if you did, and for the sake of your next SharePoint project, I will share some tips to keep your life in a SharePoint project sane.

Customize Out of the-Box Roles

Please carefully observe the following complex mathematical equation:

Number_of_Users X User_Permissions =
 Your_Headache

It cannot get any simpler than that. Now, it is my view (and only my view), that the out-of-the-box permissions levels of Full control, design, contribute, etc., are way too sparse. What do I mean by sparse? They are either too liberal or they are too limiting. You might find it rather shocking, but even the out-of-the-box Approval workflow cannot be properly implemented with the out-of-the-box permissions.

Lucky for you, SharePoint 2007 allows a fine-grained permission level control. I describe this in detail in the following article on my Web site.

http://blah.winsmarts.com/2007-4-SharePoint_2007__Fine_grained_permission_control.aspx

Always study your requirements, and start out with a small set of users who have the fewest permissions possible. Gradually open the permissions and number of users, to keep a manageable level of headache.

Trim the UI

I’ve laid out the following items in order of complexity.

  • Light Bulb: A light bulb is rather simple. You flick a switch and 99.999% of the times it turns on.
  • Dog: You pet a dog, and it wags its tail. Sometimes it may bite.
  • SharePoint: More on this shortly.
  • Men: It’s not that flicking the light switch should turn the bulb on, but first we must question, is light truly what we need? Let’s call a meeting.
  • Women: Well, I’m a man, so I cannot understand them myself, much less explain them to you.

SharePoint, as you can see, is more complex than a dog, but less complex than a human. Isn’t that what most computer software is becoming anyway? You flick a switch, and the bulb will turn on-most of the time.

Customers still want to treat computer systems like light bulbs. They expect things to work, always, and they don’t have the patience to learn its idiosyncrasies. Thus the iPod is so successful.

The answer is, make your computer system simple. Don’t make users think in terms of “Lists.” Let them think in terms of the business problem they are trying to fix. Trim the UI to suit your project.

So, how exactly do you trim the UI?

Customize the default master page. Don’t show SharePoint stuff like “View all lists” to users who only have read only permission. It makes no sense to them.

Ensure that your architecture does not require users to ever view the application master page.

Trim the UI, and offer in-place editing of displayed text, as demonstrated in this article http://blah.winsmarts.com/2008-5-Use_SPRSS_to_offer_a_better_editing_experience.aspx.

Always Use Features

Let me dispel some myths. SharePoint is a platform, not a solution. After you have installed SharePoint is when most of the work begins. You don’t get out-of-the-box solutions to do exactly what you want. But the beauty of every Microsoft platform is its extensibility.

And yes, while it is tempting to point and click and create a working product for the end user, this behavior will only get you in trouble over the long run. This is primarily for two reasons:

  1. Such a procedure ignores the software development lifecycle. There is no QA of what you did on the production box.
  2. It sets crazy expectations in the minds of users. While you could set up a blog easily, you cannot setup a chat room easily. The user may not understand why, and the out-of-the-box blog might not be exactly what the user wanted.

Thus, like you should do with any other software project, understand the business requirements, create functional requirements, design, write a feature or features, package them up as a solution, version control them, and deploy them to production after QA with great care and love.

Site Definitions Are So 1980s

Seriously, if you think delivering a SharePoint project is the equivalent of writing a site definition, it’s time to get a haircut and step into the 90s.

The problem with site definitions is that they are very monolithic. Your intent was to create this cookie cutter with which you could create multiple cookies, all of which looked the same. In reality, when you delivered the first five sites, users then wanted a slight change to the five sites already created, and every subsequent site that would be created. And beyond that point, users want divergent paths. Sites 10-15 will have some characteristics similar to sites 15-20, and sites 1-10.

Now, if instead you had bunched together your functionality as features instead of site definitions, your life would have been so much easier. Features work better than site definitions because of the following reasons:

  1. They can be scoped to web, site, IIS website, and farm.
  2. They can be turned off or on, independent of other features. A site definition is either the whole enchilada or death by starvation.
  3. Features come with receivers. You can run code before and after they activate or deactivate. Site definitions do have site provision providers, but they are not as flexible.
  4. Features can be stapled to existing site definitions. Thus, out-of-the-box site definitions can be customized, without actually changing the physical files.
  5. Features are very well suited to a version 2.0 scenario. Let’s say you wrote a site definition, and now a version 2.0 is required. What do you do next? Write a new site definition, or a feature? A new site definition will not work. You will have to write a feature.

What I like to do is this: I start with the basic site definition and trim everything I can. I’ll then add some things I know I will need. For instance, I am a huge fan of URL rewriting, in-place editing, and better RSS capabilities, and I use these features as my base development site definition.

Now I wish there was a standard development site definition. There isn’t! But one day, in my spare (!?) time, I will create one and put it on CodePlex. If you are interested in helping, please contact me at www.winsmarts.com/contact.aspx.

Define Roles within Your Team

Within a software shop, you have some major roles. The infrastructure people and the application developer people are two major roles involved in any project.

SharePoint introduces some interesting challenges. Infrastructure people can do much of the solution delivery, and application developers can do a lot of configuration. This overlap of roles can create confusion.

Before you embark on any SharePoint project, define clear roles. I suggest these basic tenets:

  • Wean away from point and click configurations on the production environment, except during initial install, work done inside the central admin, SSP (Shared Service Provider), and provisioning new Web sites or site collections. All these exceptions fall in the hands of the infrastructure staff.
  • Always deliver new functionality using solutions. Application developers author these solutions on separate machines they have full control on.
  • New functionality is driven, and architected by, application developers. Its design and architecture is vetted by infrastructure.

Summary

I have written many articles, but never before have I written an article that was so important. If you are currently in the middle of a SharePoint 2007 project, I am sure you understand why the above tips are so important.

In my next article, I’ll talk about specific developer-related tips that if you knew, would have saved you a lot of time.