An Into and Overview of Options for SharePoint User Interface Customization

Through mailing lists and newsgroups I see many issues and questions over and over again, and one in particular is “How do I customize my portal or WSS site?”.

This is a tough question.  I have been in those shoes staring at the sea of information and options trying to figure out how to do it.  I have been frustrated and I understand the pain that happens trying to figure it all out.  Yet after all that, it is still a difficult question to answer.  Customizing SharePoint is like riding a bike, it is very hard to tell someone how to do it, and that person really just has to try, fall down, try again, and they will figure it out.   There is not a step by step process out there for customizing a site.  Deciding what to do is dependent on many factors. Your skill set, your project requirements, your target audience, your timeline… the list of factors can go on and on depending on your unique situation.

I recently posted a long reply to a mailing list about options available and I wanted to add to it and post it on my site.  There are a lot of resources out there and opinions on how to do stuff, I am just throwing out there what I think and my personal experiences.

Options for updating the user interface (UI) for SharePoint:


  1. Alter the site definitions:
    Site definitions are the templates SharePoint pages are based on when they are created.  On the web server, there is a set of files that contain the HTML that make up the site’s UI. There are a lot of these files and unfortunately SharePoint 2003 doesn’t utilize any type of central code store for the HTML that formats the pages.  The HTML code is located on nearly every file, so making any changes can become a very time consuming venture.  Additionally with portal there are several site definitions that are used in one portal.   The Home page is one definition, the topics page is another definition, and the news page is yet another one.  So on and so forth.   I can’t list a specific number of files that you will have to edit, because it all depends on how many site definitions your portal uses.Personally, I have a deployed a huge portal using only use three site definitions (excluding My Site).  I find it is not necessary to use all the definitions and it just increases your workload.   For WSS, things become easier.  WSS only uses one site definition (STS) and you can create custom site definitions for use with WSS sites by just making a copy of the STS definition and making your changes to the copy.  The copy process has been documented here:
    Creating a Site Definition from an Existing Site DefinitionI think one of the confusion points is where do you go from here?  You have made your STS copy or figured out which portal definitions you need to edit, then what?  Well it comes down to going back to the basics.  You look at the code that runs the page, figure out where your changes need to happen and you make them.  You change the HTML, the JavaScript, the CSS, the whatever to make your UI requirements and changes happen.  There is not a special tool or application that can do it for you.  You basically just get your hands dirty and edit code. For maintenance, if you need to make updates to your site, you can go into the site definitions and make the changes and it will affect all pages based off that site definition. So it is a lot of work at the onset, but easier to maintain in the long run. ALWAYS make a backup of your files on the web server and store in a safe place.  You can either create custom site definitions or edit the existing ones, but editing the existing ones may take you out of supported mode if you ever have to call product support.  Keeping copies of the original files protects you from any possible mishaps where you corrupt the file beyond fixing or if you need to roll back original files to receive support from Microsoft. Additional Resources:
    List of the site definitions:
    UI Customization Resources:
    Customizing SharePoint Sites and Portals: Using Templates and Site Definitions (MSDN) 
  2. Use FrontPage to make your changes:
    FrontPage is the Microsoft touted tool of choice for SharePoint customizations and provides a friendly GUI for changing the design of a SharePoint page.  There are handy features that allow you to directly open a site in FrontPage from the browser, edit the site navigation, easily edit list and library pages and make theme creation (see below) easier.  The biggest issue with using FrontPage to make UI changes to any SharePoint site is that you open yourself up to possibly unghosting your pages.  When you unghost a page, you sever the ties that page has to its template (see site definitions) back on the web server and all changes now reside in the database.  This becomes particularly problematic when you need to do site updates and maintenance, as you will probably have to visit each page to make any changes.  On the flip side, for small sites that will not have an increase in size or usage, meaning you don’t think SharePoint will explode in your company and have 1000 WSS sites in 6 months, or for one-off sites that can warrant it, FrontPage can be a good option.  I don’t use it myself, but I understand and support it being used in the appropriate situations. Additional Resources:
    More info on ghosting:
    SharePoint Customization with FrontPage 2003 
  3. Brand your portal using images and CSS:
    You can really do a lot to a portal or WSS site by using some image replacement and CSS style rule changes.  You can very effectively brand a SharePoint site.  A limitation is that you have to work within the HTML code and style rules provided to you through the existing UI.  So you will keep the layout of elements on the screen, nav over to the left, header to the top. But if you are skilled in CSS, you can really accomplish a lot.  This is my preferred method. To start changes using this method, look at the layout of the interface and identify what can be changed. Any image can be altered, any color can be changed, and some areas can have images added as a background instead of a plain color.  Once you start doing this you can see where you can effectively brand a site.   Make a mockup of what you want the site to look like, one way to do this is to start with a screenshot of SharePoint and replace bits and pieces until you are satisfied with your branding mockup.  You can then start applying the changes piece by piece through images and CSS changes. You can directly edit the existing CSS files, specify your own CSS file, or add custom CSS code to any one page through a hidden content editor web part.   ALWAYS backup any original files if you do decide to edit the existing CSS. Additional Resources:
    Customizing SharePoint Sites and Portals: Style Sheet Class Reference Tables
    Cascading Style Sheet Guide for Windows SharePoint Services
    SharePoint Style Designer 
  4. Themes (WSS Only):
    Themes allow you to do what I listed above with image and CSS updates, and additionally allow you to package it up to deploy on a site by site basis. Themes are a way to transport or apply your UI changes, not a way to create them.  A theme is stored on the web server and contains custom images and styles.  When a theme is applied, it overrides the style rules in the default CSS files.  Themes have to be manually applied to each site, but are a great option if you have to brand numerous sites with different interfaces.  Additional Resources:
    Applying a Theme to a Site Created with Windows SharePoint Services
    Customizing Themes (MSDN)

Those are your main customization options.  I can’t dictate to anyone what they should or shouldn’t do because I don’t know your particular situation or site requirements.   There are a ton of resources out there (and more to come!) for each of these options.

Check out some of my additional resources:


11 thoughts on “An Into and Overview of Options for SharePoint User Interface Customization”

  1. Great post! I’m just finishing up a customization SOP for a client – it’s nearly 100 pages long and I’ve barely scratched the surface. SharePoint customization is definitely NOT for the faint of heart!

  2. Great psot Heather. I find too many clients get hung up on branding thier site based on guides all over the net. I prefer to guide them through the use of CSS and FrontPage. This apporach has proven to be an extremely effective means of acheiving a knowledge transfer to the client who can then be much more self sufficent.

  3. Thank you for this. I am currently branding my company’s site by building a custom theme just for it and this article helped a bunch.

  4. I am trying to change the colors of the drop-down menu highlight on our WSS site. I have identified the style (.ms-MenuUIItemTableHover), but the only way I can get the change to work is editing the main MENU.CSS in TEMPLATELAYOUTS1033STYLES, which then affects all the sites on the server – not what I want. I have tried adding the style in our sites theme (where I have successfully made many other changes), and even inline on the page itself and in a CEWP, but it always seems to get overridden by the defaut MENU.CSS. Everything I have read says the "local" or last settings should win, so I don’t know where else my custom styles should go.

  5. Chris-
    You can always set up a copy of the styles in a custom location and change IIS for that WSS site to point to the custom location. That way you can run different styles for each site, as long as it is setup in IIS.
    Another thing you can do is to use a theme. Add your CSS change to a theme.css file and apply the theme to your WSS site.

  6. Well, I do have a theme (where I have successfully made many other changes), but when I add a style name from the MENU.CSS (.ms-MenuUIItemTableHover), the values in my theme are not applied – it uses the values from the default MENU.CSS. So is MENU.CSS getting loaded/referenced after my custom theme? And why won’t adding the style "inline" on the page it self override it? (or is this only happening for me – can others override this specific style? (.ms-MenuUIItemTableHover)

    As for making a custom copy of the styles and pointing IIS at it, I can not find anything like that in my IIS Manager on the server, or in the SharePoint Central Administraton. Any pointers on where to get started would be helpful.

    Thanks for your assistance.

  7. Chris-
    If you have styles inline that are not working, then there is probably a crossed wire somewhere, such as you are editing a file but looking at a different one in the browser or something similar to that. One thing I like to do is change something that is horribly obvious, like making a font color or a background red. If that works you know you are in the right places and can go from there. Another thing is make sure you are listing and using any existing attributes in your new style rule. In order to override, you need to replace any attribute already set in addition to adding your own rules, otherwise the default styles will show through.

  8. I hope there is a forthcoming article with the same ideas but how to accomplish things using Moss and wss v.3

  9. Sorry if not the right place to post, but do you have any entries regarding the timing & sensitivity of SharePoint dropdown menus? We have a problem with our global navbar (horizontal tabs with dropdown sub-menus) being too sensitive. Also, the dropdown menus -once triggered- tend to linger too long before going away. How to adjust?We are optimizing for IE.

Comments are closed.