I love my day job
March 2010 - Posts - SharePoint Skater

SharePoint Skater

Custom control and client script aficionado, neck-deep in a simmering SharePoint stew.

March 2010 - Posts

A Quick Primer on SharePoint Customization

This one goes out to all the people who have been asked to change the way a SharePoint site looks.  Management wants to know how long it will take, and you can whip that out by tomorrow, right?  If you don't have time to prepare a treatise on what's involved, or if you just want to lend some extra weight to your case by quoting a blogger who was an MVP for seven years, then dive right in; this post is for you.


There are three main components of SharePoint visual customization:


1)       Theme – A theme encompasses all the standardized text formatting and coloring (borders, fonts, etc), including the background images of various sections. All told, there could be around 50 images involved, and a few hundred CSS (style) classes.  Installing a theme once it’s been created is no great feat.  Given the number of pieces, of course, creating a new theme could take anywhere from a day to a week… once decisions have been made about the desired appearance.

2)      Master Page – A master page provides the framework for page layout.  This includes all the top and side menus, where content shows up, et cetera.  Master pages have been around for a long time in ASP.NET (Microsoft’s web development platform), and they do require some .NET programming knowledge.  Beyond that, in SharePoint, there are a few dozen controls which the system expects find on a given page.  They’re not all used at once, but if they’re not there when they’re needed, chaos ensues.  Estimating a custom master page is difficult, as it depends on the level of customization.  I’ve been on projects where I was brought in simply to fix some problems and add a few finishing touches, and it took 2-3 weeks.  Master page customization requires a large amount of testing time to make sure that the HTML, JavaScript, CSS, and control placement all work well together.

3)      Individual page layout – Each page (ideally) uses a master page for its template, but within the content areas defined by the master page, web parts can be added, removed, and configured from within the browser.  The wireframe that Brent provided could most likely be completed simply by manipulating the content on the home page in this fashion, and we had allowed about a day of effort for the task.  If needed, further functionality can be provided by an experienced ASP.NET developer; custom forms are a common example.  This of course is a bit more in-depth than simple content manipulation and could take several days per page (or more; there’s really no way to quantify this without a set of requirements).


That’s basically it.  To recap:  Fonts and coloring are done with themes, and can take anywhere from a day to a week to create (not counting creative time); required technical skills include HTML, CSS, and image manipulation.  Templated layout is done with master pages, and generally requires a developer familiar with both ASP.NET and SharePoint in particular; it can have far-reaching consequences depending on the complexity of the changes, and could add weeks or months to a project.  Page layout can be as simple as content manipulation in the web browser, taking a few hours per page, or it can involve more detail, like custom forms, and can require programming expertise and significantly more development time.

Clunky workarounds that work: catching field changes in a SPD workflow (with no custom code)

Yes, you can do this with an Event Receiver.  You might be able to do it with a VS workflow, or possibly one of those fancy third-party tools... maybe not.  But if you're a SharePoint admin with nothing but SharePoint Designer and you need to determine if a field changed, here's how.


1) Create a new field of the same type as the field you want to track.  We'll use Person or Group, since that's what came up today when somebody asked me how to do this.  If our field is called, say, "AssignedTo", we'll create another one called "AssignedPast".

2) If you haven't already, build a workflow and attach it to your list.  Tell it to fire when something changes.

3) Create a step with the condition "If AssignedTo not equals Current Item: AssignedPast".

4) In the Actions portion of the step, take whatever action you like (I just wrote a message to the History Log, but you can send an email or whatever makes sense).

5) Just before ending this step, set AssignedPast equal to AssignedTo.  This will reset your change indicator for next time.

That's all.  Simple, and not all that elegant, but it gets the job done and you can hide the extra field so your users will be none the wiser.

More Posts