“I need a publishing platform. Could I just use SharePoint or will I need some other CMS?”
If you were just asked the above question, I agree that it is fair to say that SharePoint is NOT a CMS… but it actually does not mean that Sharepoint cannot be used to manage and publish Web content! Microsoft’s knowledge management product or in simple terms - intranet solution has a complete set of publishing features, but it actually offers much more than. It could certainly be described as an enterprise collaboration platform with a variety of capabilities. At the same time, it is also a ready-to-use product and an application platform that you can transform into a tailor-made content management solution with a little customisation and development – an example of the latter would be a professional CMS solution. While there are many features for web publishing that SharePoint offers out of the box, it does actually have some specifics you should be aware of if, you plan to create a top-notch web publishing system.
How would you go about transforming Sharepoint to be a WCMS ?
When creating a new SharePoint site, you could select a template from the available template list. In order to add a basic publishing site, you can pick the Publishing Portal from the Publishing tab. Of course, you could also start with a Blank Site template and then, activate the SharePoint Server Publishing Infrastructure (at site collection level), to make use of the SharePoint Server Publishing (site level) features. Publishing features provide the Pages library, which is the place where all your articles will be stored (unlike basic web part pages, which are added directly under your site node). If you expect a large number of articles, storing all of them side by side may in due course, become for the lack of a better word -inconvenient. Fortunately, if you are using SharePoint 2010, you can create folders within Pages library (this was not possible in MOSS 2007). However, you cannot add a “child” article to your page, which is a common practice when using classic content management systems. I admit that people who have some experience with other web publishing systems may find it a little confusing at first. A typical CMS organizes the pages using a tree structure, allowing you to create effective information architecture in an easy and flexible way. And please note that SharePoint actually uses more complex structures to build the hierarchy - each site collection (which in most cases constitutes the single website) is a tree of sites, each of them which being a set of lists and libraries (including Pages)
With the above in mind, it seems sensible to structure your website by creating a few levels of sites that will reflect planned high-level information architecture, and at the same time define the global navigation (unless you intend to use some advanced navigation scheme). Each site’s landing page will likely serve as a hub page for the area represented by that site, and will reside in the site’s Pages library along with other articles of that section. In fact, each and every page published on your website will be stored in one of these Pages libraries. One of the direct repercussions here is that “Pages” name will appear in each article’s URL. Moreover, each page's URL name is suffixed with “.aspx”, and you end up with web addresses like http://my.website.com/News/Pages/some-article.aspx. Much to my dismay, there is no built-in feature providing user-friendly and/or SEO-friendly URLs. Fortunately, you can use IIS Url Rewrite Module to help you in reformatting the URLs to look like "http://my.website.com/news/some-article" (you may want to write a custom rewrite provider for best results). In case of a hub page, it would make sense to have "http://my.website.com/news" instead of "http://my.website.com/News/Pages/news.aspx".
The number of different types of pages you plan to have on your site is directly proportional to the amount of page layouts you need to prepare. Modern websites often allow editors to compose pages using modules. With a SharePoint page layout, you can define one or more web part zones where authors will be able to place web parts (that either present content or provide some functionality). While there are several web parts available out of a box in SharePoint, you will most likely need to have a number of custom developed options to meet all the requirements. Smart planning of layouts with web part zones will allow you to limit the number of required page types, by means of composition and reuse. More static sections of layouts can be assembled with regular .ascx web controls.
What about the CSS?
The vast majority of publishing website projects have significant branding needs. To meet these requirements, a custom master page with CSS stylesheets provided by front-end developers is often a must. While it is easy to style custom developed components, it is quite challenging to brand standard SharePoint front-end elements (there are lots of different UI pieces and CSS classes). Fortunately, you will use only some of these on your publishing pages’ layouts constituting your whole front-end. In most cases SharePoint back-end does not need to be branded as it will only be seen by content editors and administrators.
A publicly available website will require you to have anonymous access enabled. Unfortunately, the top bar part of the SharePoint ribbon is displayed for people that are not logged in as well. Most likely you will want to have some custom code added to hide it by default, and show it only to authenticated users. If you do this, remember to place a “log in” link somewhere on the site, or ask editors to access the back-end with a specific URL pointing to a special page that will force authentication (let's not forget Sharepoint does have some nifty security features).Once logged in, it often takes many mouse clicks for content authors to get to the right place to do their work. Usually there is a number of tasks that editors perform on a daily basis (e.g. creating a news article). You can make their job easier by identifying the most common actions, and creating an authoring dashboard page with quick links.
What's the verdict?
SharePoint is a nice choice for building a complementary set of sites, collaboration tools & applications running on a single platform. Creating a publishing website based on it is convenient when your organisation already uses the system (or plan to use it in future) - e.g. for hosting intranet site or document management purposes - the users and IT support team are already familiar with it, and there are potential savings on infrastructure, licensing and other costs of introducing a new system. However, creating a successful SharePoint website requires some thoughtful planning and proper implementation. When rolling out your first SharePoint site, remember it is quite easy to make a bad decision (due to the complexity of the platform) that could lead to some unpleasant consequences. The good news is that once you gain some experience, it will be much more easier to make the right architecture and design choices.
We're always looking for new faces to join the Cognifide family. Take a look at our available jobs.