Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

SharePoint: 10 Things You Wish They Had Told You, Part 1 : Page 2

SharePoint customers and developers often experience common problems; these solutions can help.


advertisement
Customize the 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 permission levels of Full control, design, contribute, etc., are way too sparse, by which I mean either too liberal or 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 fine-grained permission-level control. You can find a detailed description in this related article, but briefly, always study your requirements, and start out with a small set of users who have the fewest possible permissions. Gradually open the permissions and the number of users, to keep the headache level manageable.

Trim the UI
To put what you're trying to do in context, 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 time 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 software's idiosyncrasies. That's why 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? Here are some ways:

  • 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.
  • Offer in-place editing of displayed text.
Always Use Features
Let me dispel some myths. SharePoint is a platform, not a solution. Most of the work begins after you have installed SharePoint. Out-of-the-box solutions rarely do exactly what you want. But the beauty of every Microsoft platform lies in its extensibility.

And yes, while it is tempting to point and click and create a working product for end users, such behavior will only get you into trouble in the long run, because:

  1. Simplistic procedures ignore the software development lifecycle. In other words, what you did on the production box never went through QA.
  2. Simplistic procedures create crazy expectations in users' minds. While you could set up a blog easily, you cannot set up a chat room easily. Users may not understand why, and the out-of-the-box blog might not be exactly what the user wanted.
Therefore, you must treat SharePoint sites just like you should any other software project: understand the business requirements, create functional requirements, design, write a feature or features, package them up as a solution, apply version control, 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 monolithic. The original intent was to create a cookie cutter with which you could create multiple cookies, all of which looked identical. In reality, immediately after you delivered the first five sites, the users each wanted a slight change. And shortly after that, users wanted divergent paths. Sites 10-15 will have only some characteristics similar to sites 15-20, and even fewer characteristics similar to sites 1-10.

If 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:

  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 well-suited to a version 2.0 scenario. Let's say you wrote a site definition, which now requires version 2.0. 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.
I like to 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.

I wish there were 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.

Define Roles within Your Team
A typical software shop has some major roles. For example, both infrastructure people and application developers have 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, but the overlap of roles can create confusion.

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

  • Wean yourself away from point-and-click configurations in the production environment, except: during the initial install, while working inside the central admin, with the SSP (Shared Service Provider), and when provisioning new Web sites or site collections. All these exceptions fall into the hands of the infrastructure staff.
  • Always deliver new functionality using solutions. Application developers should author these solutions on separate machines over which they have full control.
  • New functionality is driven, and architected by, application developers. Its design and architecture is vetted by infrastructure.
If you are currently in the middle of a SharePoint 2007 project, you probably understand why these tips are so important for architects or management. The next article in this series discusses five tips targeted toward developers tips that can also save a lot of time.



Sahil Malik Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant and trainer, and a well-rounded overweight geek. He has a passion for SharePoint 2007, data access, and application architecture. Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to be highly charged, fast moving, and highly interactive. Be sure to check out his blog.
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap
Thanks for your registration, follow us on our social networks to keep up-to-date