Customizing Your SharePoint Site? Read These 10 Concepts/Gotchas First
June 21st, 2008 | Posted in SharePoint |
Preface: I wrote this post after spending a month digging deeply into SharePoint, attempting to customize and brand the site as well as migrate all my help content to it. If you’re totally unfamiliar with SharePoint, this post will not get you up to speed. But for those embarking on a SharePoint customization challenge, most likely you’re already familiar with SharePoint. Reading these ten concepts and gotchas will help you avoid some of the pitfalls I encountered when customizing my site.
Note: When I say “SharePoint,” I’m really referring to MOSS 2007. But SharePoint actually has two components — a free one that’s available on any Windows server, called Windows SharePoint Services. And an additional layer that gives you more functionality, called Microsoft Office SharePoint Server 2007, which isn’t free. When I use the term “SharePoint,” I’m referring to the latter version, the un-free one.
1. A good SharePoint site is one that doesn’t look like a SharePoint site.
SharePoint provides push-button site publishing, so creating a site takes literally 3 seconds. But all the sites look the same. Having an out-of-the-box SharePoint theme, just like everyone else, makes you look like a novice, on par with the completely untechnical depts who can barely operate SharePoint, much less customize it.
Here’s what the default theme looks like.
More importantly, SharePoint has a lot of negative baggage. All those poorly organized, neglected, outdated SharePoint sites immediately come to the user’s mind. Do you want your SharePoint site mixed in with this negative baggage? No. You want your site to gather respect from your users. A little awe. Not a sigh and an “oh, another pathetic SharePoint site” response.
Customizing your Sharepoint site should definitely be in the plans. But before you run forward, make sure you actually can run. SharePoint has three basic levels of rights access: server admin, site collection admin, and site admin. If you only have site admin rights, you’re at the mercy of your site collection admin as far as customizations go. If you have site collection rights, you have a lot more customization power. And if you’re a server admin, you can do almost anything (and probably break everyone’s site in the process).
If you’re only a site admin, stop here. You can’t customize much of anything. Sure, SharePoint allows you to pick about a dozen different incredibly ugly themes, but they all shout SharePoint. If you’re a site collection admin or server admin, keep reading. There are additional themes that don’t look anything like a SharePoint site, but they’re hidden away.
To view these alternative, hidden themes, which look nothing like regular SharePoint sites, you have to activate the Office SharePoint Server Publishing Infrastructure feature at the site collection level. See the following image.
(You can click any image to see the full size at a crisper resolution.)
After you activate the publishing feature at the site collection level, you can then activate the publishing feature at the site level. Once activated, you have a whole new world of customization features available to you. You’ll also notice that the Site Actions menu has about three times as many options on it.
With the publishing features activated, go to your settings, and under the Look and Feel column, click the Master Page link (this link only appears after you activate the publishing features). Select a new master page, such as Blueband.master, my favorite. See the following image.
Here you can also select inheritance properties for master pages and stylesheets. In other words, you can determine whether the subsites inherit the Blueband.master theme from the parent site. And you can select the CSS file your site uses (choose Band.css).
Note: I’m not sure that the Blueband.master is a “theme,” rather than just a different master file. But it seems like a new theme to me. In contrast, the default “themes” available at the site level, such as Vintage, are really just color variations.
2. Without SharePoint Designer, you can do nothing. With SharePoint Designer, you can do nothing.
If you don’t have SharePoint Designer, you can do very little in customizing your site. That said, SharePoint Designer isn’t very useful. It provides a box of tools in the upper-right, as if you could just insert buttons and controls to modify your site. But the toolbox requires advanced knowledge.
SharePoint Designer is only useful in that it gives you access to the stylesheets and allows you to make minor edits to some of the pages. Beyond that, you need to be a SharePoint programmer to really modify the page. The page’s code is not basic HTML or XML. Additionally, much of it is heavily nested in tables.
3. Like the Borg, all content pages render through Default.master or another master file.
SharePoint’s files are all incestuously interconnected. If you’ve seen the Borg, from an episode of Star Trek, it works the same way. The Borg is a collection of individual people that are all controlled through a central person. In SharePoint, that central person is the master file. If you’re using your default theme, it’s the Default.master file. If you’ve selected Blueband, then Blueband.master is your master file.
When you create a page (by going to Site Actions > Create a Page), you’re not creating a page that exists independent of the master. The content page renders through the master, or uses the master to render.
You access the master by going to _catalogs > Masterpage > Blueband.master in SharePoint Designer (at the site collection level). The master has numerous content placeholders, which you see when you open the master in SharePoint Designer. These content placeholders also exist on the content pages that render through the master.
If you delete a content placeholder on the master, it breaks all the pages that use the master to render. So be sure you leave content placeholders alone.
What if you don’t want one of those content placeholders? Well, you can actually delete it. When you open a content page, you’ll see an error message prompting you to find the content placeholder you deleted. Just delete the placeholder from the content page as well and it’ll work.
4. When you edit the master, the core.css file unghosts.
An interesting thing about SharePoint is how it hides the stylesheets. Core.css is the main stylesheet that styles the default.master (and subsequently every other page). But core.css exists at the server level, not the site collection level. It’s only when you start editing the master file that the core.css file “unghosts” and copies down to your site collection level.
To unghost the core.css file, put your cursor somewhere on the master page and change the font through the CSS panel on the left. After saving your changes, you might see core.css suddenly appear as a new tab. It is then permanently available in the _styles folder of your site.
Notice I said “might.” Actually, if you’re using Blueband.master, there are at least two main CSS files that style the page: core.css and band.css. If you edit the wrong part of the master page, band.css might appear instead of core.css. At any rate, I don’t think band.css unghosts from the server in the same way that core.css does, although to be honest I’m not sure. In my setup, core.css unghosts at the site level, while band.css is available at the site collection level.
Regardless of how you accomplish it, changing the styles through the core.css file and the band.css file is key to customizing your SharePoint site.
5. You can’t see the image directory that the core.css stylesheet refers to.
As if the confusion over stylesheets wasn’t enough, images are also problematic. First, there are two sets of images: images that belong to the blueband.master file and images referenced in core.css. The blueband.master images are available in the site collection level under Style Library > en-us > Images. If you open that folder up in Windows Explorer, you can quickly drag those images to your desktop and start modifying them in Photoshop.
But where are the images referenced by core.css? Remember that the core.css file originally exists on the server and is only copied down to the site collection level after you start modifying your master file. Well, the images don’t come along for the ride. If you want to change an image referenced in the core.css file, you have to download the image from your site (by right-clicking and downloading the image or by noting the file name and path in the core.css stylesheet and then inserting it in your web address so you can view and then download the image).
After you download the image, you can’t upload it to your server image directory unless you have access to the server, and even if you did, it might change that image for all other SharePoint sites on that server.
So you upload the image to a picture library on your site. Then replace the original URL in the core.css stylesheet with the new URL.
Now, you may think that by deleting, overriding, or completely annihilating the images in either Blueband’s image location or uploading new images to replace core.css you would actually be successful in replacing the previous image. Nope. Though they appear live and published to you, until you check in and publish your images and files, others can’t see your changes. If you can sign into the site as another user (somewhat tricky if it’s all the logins are automatically synchronized with Active Directory), you can see what others see. At that point, you’ll know if you’ve checked in and published your images properly.
Here’s the interface where you must publish your images. (Note: If Approve is also an option, do that too.)
You can shoot yourself in the foot by removing the versioning settings of the document library where your images are stored. If you edit the library’s settings and choose no versioning, you don’t have an option to publish the images, and I believe they never show. I know that I spent a while pulling my hair out before I figured out what was wrong.
6. If you edit the Summary View and change the item limit, it breaks the code and you have to generate a new site to figure out the code to fix it.
Do you think I’ve hit on some unintuitive processes for web design? Wait until you read this one. There’s a nasty bug in SharePoint that actually breaks the code if you make a certain modification to a blog site. Open up the category view of a blog, and then edit that category view.
Change the item limit for the default summary view of that category. Bam, it just broke some code. When you click a category now, only one item in the category shows, rather than all posts of that category.
The details aren’t something I want to delve into here. But basically to fix the problem, you have to open the category page in SharePoint Designer and replace some code with the same code from a working site.
Open the category.aspx page in SharePoint Designer. Select the Split view, and then select the Posts web part in the Design view. Then in the Code view, look for listxmlview and replace that entire part with code from a new SharePoint category.aspx page (using the same selection).
I’m not kidding about this. You might not want to make too many modifications to the default category views if you’re using a blog site.
7. If you modify a theme, switch back to the default, and then return to your modified theme, all modifications are gone.
There’s something else you should know about modifying themes. When I first started modifying a theme, I started modifying one of the pre-built themes you can choose without slipping into the Publishing features. I switched to Vintage, modified a bunch of files for an hour or two, and then switched it back to the Default theme because I realized modifying Vintage would take me all day due to the massive number of images and the inability to actually access them in mass.
When I switched back to Vintage, I discovered, in an unpleasant way, that all my changes were gone. It seems that each time you select one of these themes, SharePoint copies down the theme’s files anew from the server, overwriting any changes you made to the theme.
After that, I decided not to switch back and forth between themes, so I can’t say that the same is true for master pages like Blueband. Still, you might want to back up your modifications before switching around those master files/themes.
8. To configure the search to see just blog posts, you have to enter a code that does not exist anywhere on the Internet or help file.
The way I set up my SharePoint site, I chose a blog site and created about a dozen views of the blog posts. Views define specific ways of looking at the same information. For example, one view may include only certain categories, another view may include only the post titles, and so on.
When I searched for a file using SharePoint’s search box, the search results showed all of my view pages first before the actual blog post files. As a result, the search was worthless until the second or third page of results.
Fortunately, SharePoint does allow you to configure the search at the site collection level. You can set a scope with a specific search rule, and then modify the search web part to use that scope. I wanted the scope to return only blog posts, and not any view pages. To do this, you need to enter a certain contentclass code into the scope at the site collection level. This content class does not exist anywhere online that I’ve been able to find. Here it is:
contentclass = STS_ListItem_Posts
The following image shows where you enter that contentclass.
You may also want to restrict the results to a specific folder, such as http://yourdomain.org/blog/lists/posts. Once you set up this scope, the results are much better.
One thing I could never figure out is how to configure the best bets search. Supposedly, SharePoint allows you to enter synonyms for searches and then specify the results. For example, let’s say you use the term “meetings” in your help, but your users also use the term “agenda.” You can create a best bet so that when users search for agenda, the search results show URLs you’ve selected. But I was never able to get this feature working.
9. You can’t control the look and feel of the admin side of things.
You may have spent weeks creating a beautiful interface for your users. But there’s one ugly truth that will scare away anyone with collaborative purposes: the admin side of SharePoint can’t be skinned (at least not without some tricky programming).
As long as users aren’t creating posts, or editing wiki pages, or doing anything on the admin side, they won’t know that the admin side still shows the default SharePoint style. But if they do need to go into the admin view, the experience can be jarring, as they go back and forth between themes.
You can’t create a seamless experience with your new SharePoint site. You can only customize the clothes, not the body, so to speak. Here’s what the Blueband master looks like as users view your SharePoint site.
And here’s what the same site looks like when you enter the admin side of it.
Nothing at all like the external interface. By now many of you reading this may be thinking, I’m never touching SharePoint. SharePoint is such a kludge of an application; no way I’m ever using that. Here’s one more little surprise for you.
10. Site metrics don’t tell you what post anyone has viewed.
Admittedly, one appeal of using SharePoint when it’s integrated with Active Directory is to see not only the names of your visitors, but the posts they viewed. However, if you’re using a blog site, get ready for some disappointment: you can’t actually see which posts visitors viewed. The metrics entice you with informative looking color graphs, but when you start trying to piece together the information, it’s missing a component: the actual post name.
This is because I was using a blog site, and the pages I wanted to track were the posts. Surprisingly, posts are actually stored in a database somewhere, unlike wiki pages or other content pages.
The same metrics problem isn’t true if you have a site with a lot of pages. Still, it proved somewhat unclimactic for me. I even attached some hit tracker code onto the post template, but it didn’t propagate to the individual posts.
Conclusion
With all these quirks, it’s hard to see why SharePoint is so popular. I suspect it’s popular because none of these serious flaws are apparent until you try to customize your site, and 99% of the time people leave the sites as is.
Even despite these quirks, if you’re company uses SharePoint, you may be stuck with it. Once you get these concepts down, however, SharePoint is a workable solution as a file repository, a website, and a corporate blog. SharePoint does provide a ton of collaborative features with almost no custom coding. Few other platforms can make the same claim.
Follow-up note: A couple of months later, after fully migrating my help content to SharePoint, I decided the platform had too many disadvantages for help authoring (for example, you can’t export your content into different formats). I now use SharePoint only as a file repository and landing page for my help content.
Related Posts
- My Compromise with SharePoint — What Works and What Doesn’t
- Are Newsletters Dead?
- Corporate Blogging
- Creating your own RSS Feed
- SharePoint Wikis: Both Liberating and Frustrating
Tags: customization, Microsoft, SharePoint, usability, Web Design
Podcast in iTunes
Follow me on Twitter












June 22nd, 2008 at 1:41 am
Wow, that was an extremely informative post
I failed to grasp the benefits for me / my audience, though.
So, I may have my MOSS look smooth and “un-novice”. How would my reader benefit from it?
avis last blog post..הבעיה עם הטיפול בגלעד שליט
June 22nd, 2008 at 6:56 am
There’s inherent value in creating an attractive web design for your content. Also, the ability to customize your site gives you more control over the usability of it. You can strip away the features that don’t matter, emphasize those that do, and brand it to match your application’s look and feel.
But you have a point. I didn’t focus this post on how this all benefits the user. Maybe I should emphasize that more. Overall, there is a lot of mental baggage that works against you when you present the user with a standard SharePoint template.
It’s kind of like the default WordPress template (Kubrick). Sure a different design doesn’t always benefit the user, but if I land on a Kubrick theme, I usually think oh, the user is new to blogging or doesn’t know how to change themes. The content is still what matters most, but being able to manipulate the theme to emphasize the content you want is a powerful ability.
June 23rd, 2008 at 6:05 am
[...] use Microsoft’s SharePoint at work and after reading Tom Johnson’s article in which he provides some tips for customizing it, I’m not sure I’d want to use it, although it would probably be better than not having anything at [...]
June 23rd, 2008 at 10:14 am
Well I can certainly see where you’re coming from. Trying to brand Sharepoint with no experience/training is like trying to drive a car without knowing that the pedals and steering wheel does.
This post doesn’t do much more than scare people that knows nothing about Sharepoint away from it. Those you are aiming to here when you say “But for those embarking on a SharePoint customization challenge, most likely you’re already familiar with SharePoint.” should know how to avoid most of the “problems” that you describe in this article.
Stay away from Sharepoint Designer and pack your branding solution into a feature. Of course that won’t solve your bugs and quirks that are not related to branding but it will get you a long way towards a nicely branded ghosted site.
Sharepoint is far from perfect, and has some issues, but it’s not so bad to work with once you get to know the ins and outs. And it offers great benefits for the users (publishing, approval workflows, document libraries, etc).
June 23rd, 2008 at 12:19 pm
Tom,
Thanks for the informative article. Would you please recommend a good book or two on MOSS 2007 for the beginning user?
June 23rd, 2008 at 11:02 pm
[...] and the blog to communicate information to users. So I’ve made a compromise. First, I customized the SharePoint site to look like a sharp looking website rather than a SharePoint site. The default help URL in my [...]
June 24th, 2008 at 5:28 am
[...] Customizing Your SharePoint Site? Read These 10 Concepts/Gotchas First [...]
June 24th, 2008 at 4:50 pm
[...] SharePoint. Free Whitepaper. Sponsored by: http://www.emc.com/ • Found on Ads by Google Customizing Your SharePoint Site? Read These 10 Concepts/Gotchas … But SharePoint actually has two components a free one thats available on any … If youre [...]
June 24th, 2008 at 8:08 pm
[...] Customizing Your SharePoint Site? Read These 10 Concepts/Gotchas First [...]
June 25th, 2008 at 8:18 am
First, I want to say: I feel your pain. Things that should be simple, aren’t, and the tools that should help, don’t. The post above has established this pretty well
Second, I want to say: the most important thing to know is when NOT to use SharePoint. It sounds like you were attempting to set up a WordPress-style blog, which is a very reasonable request. But, you were told to do it in SharePoint, which is less reasonable. Had it been me, I would have said “can’t we use some other technology? SharePoint blogs have minimal features and are best only when you take what’s out-of-the-box.” So for the record: even had we the skills to brand the blog effortlessly, we still would have had problems with analytics (like you mentioned) or uploading images easily (like you also mentioned). The best solution is not always a SharePoint solution, and again, I feel your pain sir–sometimes the client wants it “in SharePoint” regardless.
Third, I want to combat some of the misinformation above. I’d say that anyone reading this looking for SharePoint branding advice should leave now and visit http://www.heathersolomon.com/ - she does this full-time and knows how to work around ANY problem. Specifics:
* Themes and custom master pages are something you use only if you like exactly how they look. Think “10 second customization.” It’s not a starting point, it’s the destination.
#9- You can customize the administrative pages in SharePoint, though it’s much more difficult to do so. Requires “programming” or at least “deep knowledge of SharePoint.”
#5 - you can see the images directory, but it requires server access. SharePoint makes heavy use of URL rewriting and virtual directories, so again, if you have deep knowledge, this is accessible. And again, I feel your pain
If you’ve made it this far down through my comment, congrats, it’s been a long journey. If I can summarize:
1. Don’t use SharePoint for everything, try to weasel out of some “solutions”
2. Follow Heather Solomon’s advice and approach to branding SharePoint
3. Don’t use SharePoint blogs for anything more than the out-of-the-box experience. They’re great for what they do–just not everything.
Peters last blog post..SharePoint 14: Everything We Know
June 25th, 2008 at 8:23 am
I should clarify my point above:
Themes and the BUILT-IN master pages are destinations. By all means go out and customize your own master page; just don’t start with the BlueBand.master, use a minimal master page instead (and save yourself a headache).
Peters last blog post..SharePoint 14: Everything We Know
June 25th, 2008 at 1:35 pm
Peter, thanks for your comment. My first inclination was to use something like WordPress or Joomla, but both require PHP and MySQL — both of those technologies aren’t supported by my IT department, so I had to use an alternative.
One reason SharePoint appealed to me is the possibility of using it as an integrated authoring solution — providing both a blog and help content on the same site. The search covers both.
However, SharePoint’s problem is that it tries to be too many things to too many people. It’s a swiss army knife type of application. It’s blog feature is poor. It’s content authoring features are poor. But at least it has both.
Thanks for your notes on some of my points. Yes, I’ve heard Heather Solomon’s site recommended by various people. She has excellent information and I should have included the link somewhere. It just seemed to me that blowing away the entire master page and starting from the bare bones was a little more design work than I intended. (I’m not really sure if that’s what the minimal master involves, but I assume so.)
Using SharePoint has been an interesting exercise. I know there are a lot of ardent SharePoint supporters out there. All I can say is that SharePoint is a complicated beast one could spend a lifetime studying. Switching from Flare or RoboHelp to SharePoint to take advantage of the Web 2.0 capabilities doesn’t really work.
As you say, as an out-of-the-box tool, SharePoint does great. The problem is, when you have 1,000 out-of-the-box SharePoint sites, they lose appeal. One needs to have more customization and control for the web platform to be useful. But once you start down the path to serious customization, the jungle gets very dark.
Still, I have a decent looking site right now where I can host all my content.
June 25th, 2008 at 11:15 pm
“…the jungle gets very dark.” Ha! These words I’ll remember; that’s an awesome way of saying it. As I’m wrestling with SharePoint workflows presently, I fully feel your pain.
What amused me most about your post is how much it mirrored my first experience with building something in SharePoint–not the specifics, but generally: pain, frustration, lots of looking around and wondering “am I incompetent, or is there something wrong with the product?”
Anyway, this was interesting.
July 3rd, 2008 at 11:22 am
There are many issues with SharePoint that can be frustrating, but not all of your issues are as hopeless as you make them seem. Many resolutions are already built into SP.
Example:
To see the actual site usage details change ~/_layouts/SpUsageWeb.aspx to ~/_layouts/usageDetails.aspx in your address bar.
July 8th, 2008 at 3:19 pm
Jeremy!!!
Where did you get that tidbit of knowledge about the usage reports and others you claim to possess?!
July 8th, 2008 at 3:22 pm
I was wondering the same thing.
July 25th, 2008 at 2:48 pm
Timely post, although I am looking for a different angle of SharePoint enlightenment. We use SP for what I will blatantly call file storage. No one really knows how to use, they just dump files there. We have been crying out for organization, but run into the usual problem of “no time”. I’d love a class where you can use several day to focus on the topic. No time for that either. As it is, I just put 2 books on my bookshelf over at http://safari.oreilly.com:
Essential SharePoint 2007, 2nd Edition, by Jeff Webb, publisher: O’Reilly
Microsoft SharePoint 2007 For Dummies, publisher: John Wiley & Sons
There were a few other candidates that looked promising, but I didn’t have enough slots for them on my little 5-book bookshelf.
You see, I know how to use the basics. I am an admin on one of our sites. I don’t necessarily need to do .NET coding. I want to know the business angle and the best practice angle. What is the best way to do X, and why, or why do we even need to do X. Sometimes I have found specific answers to specific questions on various blogs and MS websites.
It looked this books were in that in-between area that I need. The Dummies was attractive because I thought I would get through it more quickly!
I would really like to understand how best to use the tool. We have it, why not make the best of it. I’ll need to use discipline to get myself through these books. With some major deadlines looming, that will be tricky!
Based on some talk at the STC conference in Philadelphia this year, I also begged the program committee for next year to get some good speakers who can talk about best practices for SharePoint. There are many technical communicators using it, for better or for worse, so I do believe there would be a good audience for that.
July 25th, 2008 at 7:45 pm
Karen, I’d highly recommend you check out the SharePoint Best Practices conference, which is happening soon in DC. There’s also a newly-released SharePoint Best Practices book written by (actual) experts.
Also I recommend you search on “SharePoint governance”–a busy topic–as it solves the problem of “SharePoint chaos”. Well, maybe not solves the problem, but at least IDENTIFIES it, if nothing else.
September 9th, 2008 at 3:46 pm
In reference to Item #2 - customization should be done by professionals who know the difference between C# and XSLT. There is absolutely no C# code in the SharePoint aspx pages. In fact, you must make a change to a web.config file to support having inline C# codeblocks (a bad practice.) You’re stating that SharePoint Designer is “useless”, but on what basis? On the basis that you have to learn how to use it?
This blog is no less ridiculous that someone blogging about the horrors of trying to perform an appendectomy with no formal schooling.
September 9th, 2008 at 8:52 pm
DotNetPro,
Thanks for your comment. Going behind the scenes in SharePoint is much less intuitive than going behind the scenes in other systems. I’m merely listing 10 concepts that were unfamiliar to me.
Re the appendectomy comment, you’re basically saying that people who want to customize their SharePoint site have to go to formal schooling? Seems a little extreme. You have to do the equivalent of going to medical school just to, for example, get rid of the Quick Launch bar and replace it with your own content?
September 10th, 2008 at 10:13 am
Actually, my statement made blogging - about the horrors of SharePoint customization by someone who doesn’t know how to customize it - analogous to someone blogging about the horrors of performing an appendectomy without knowing how to perform an appendectomy.
SharePoint Customization is very simple and powerful - you can do absolutely anything when it comes to customizing SharePoint. The learning curve is steep, but I challenge anyone to demonstrate how customizing any other portal software that does Web Content Management, Enterprise Content Management, Collaboration, and the myriad of other things SharePoint does is any simpler or more flexible than SharePoint.
September 10th, 2008 at 11:39 am
I keep getting email alerts so I can’t stay away from this comment thread
DotNetPro is being a little harsh. Yes Tom, your post had lots of inaccuracies, but I don’t blame you as much as I blame the “steep learning curve.” Your post represents everyone’s “first/second/third/hundredth SharePoint project” vibe very well.
As to simplicity, yes, there are worse Enterprise products (most of them)–but what about, you know, non-Enterprise products? At what point do you say “ah, forget it, I’m going back to static HTML pages.” Or more realistic–”ah, forget it, I’m going back to straight build-it-from-the-ground-up coding.” Maybe it’s just me.
If I could use the appendectomy metaphor, what Tom was trying to accomplish required a band-aid–an adhesive bandage, applied to the skin. What SharePoint required of him was to perform an appendectomy. DotNetPro, you’ve asserted that other Enterprise products are worse (which is true). But Tom just needed to apply a band-aid. Should it have been so hard?