There is a bit of debate over whether you should or should not use SharePoint for an externally facing public website (on the Internet rather than an Intranet or private Extranet).
In this post I will outline a few of the things to consider about using SharePoint for a public facing website, but please note, this is just my opinion, and there may be some inaccuracies, and you may not agree with it, so please feel free to comment.
Some of the important considerations for SharePoint as a public website are:
- Content Management and Office Integration
- Versions, Licencing and Support
- Web Standards and Accessibility
- Coding and Development
- Security and Logins
But firstly who is already using SharePoint as an externally facing public website? There is a great site called WSSDemo that lists all of the externally facing public SharePoint sites on it, categorised by industry. Some Australian examples are WesternAustralia.com, AGL and MYOB and the government site of WA Dept of Premier and Cabinet. Interestingly, Microsoft’s own SharePoint site was recently released on SharePoint. A tip when looking at websites is, that if the URL has /Pages/ and the page is a type of .aspx then it is probably a SharePoint site.
Now onto those considerations…
Content Management and Office Integration
One of the main reasons for using SharePoint as an externally facing website is it’s excellent content management features. If you have SharePoint within the enterprise anyway then there is no duplication of training of staff to learn to update different systems for the Intranet and the website. The web content management features of SharePoint allow for the same content to appear on both the Intranet and Internet sites (avoiding duplication of information) and it has built in features for localisation and multilingual sites.
Also SharePoint works with your existing Microsoft Office implementations, allowing you to use the tools familiar to you to author and approve content on the site.
Versions, Licencing and Support
SharePoint MOSS 2007 comes in 2 flavours, Standard and Enterprise. To build an externally facing site, you need the Enterprise version PLUS you need the External Connector Licence. At over US$40k it is a hefty price tag and on top of all the other licencing you need it all adds up. (See the Bamboo Solutions SharePoint Price Calculator for more info).
Another thing that a lot of corporates need to know about is supportability. There are a lot of fantastic tools for SharePoint available on CodePlex, but as they are not officially supported by Microsoft this could be an issue for some companies. However, I think that for SharePoint you will need some of the CodePlex projects so companies may just have to compromise on this supportability issue a bit.
On top of all the licencing costs is the hardware. SharePoint can’t just be installed on a server you have lying around, or one that you have in use for another purpose. Plus then there is the SQL Servers, the Dev, Test and Production environments etc, and all of the other servers that may be required depending on the site size and load. As I know very little about the hardware requirements, I won’t delve into them, except to say that you need a SharePoint Architect to assess the current hardware in the organisation and plan out the full requirements for the new SharePoint installation.
Web Standards and Accessibility
This issue is not a SharePoint issue but one that any public website has to deal with. At the recent Remix event in Sydney, Tatham Oddie and Damian Edwards gave a great presentation about building web standards compliant websites with ASP 4.0. A lot of what they went through will be relevant to SharePoint also (plus it’s a very interesting presentation, which is well worth a look).
SharePoint is not fully accessible out of the box, and requires a bit of tweaking to get it to be more accessible. Thankfully Microsoft is aware of this issue and have partnered with HiSoftware to release the Accessibility Kit for SharePoint which is free with a valid SharePoint licence. This is a good article outlining the issues with the Accessibility features in SharePoint.
There is also the ARF framework that helps developers to build Accessible websites with SharePoint. It does change the way developers need to approach SharePoint but as they need to do that anyway the ARF helps with the process.
As with any website design, the more complex the design the more it costs. With SharePoint it is the more Master Pages and Page Layouts you have the more it will cost to design and build the site.
It is interesting that you can build a site in SharePoint that is not really SharePoint. Eg, one of the very first Australian sites to be an externally facing public SharePoint site is the WA Tourism Site. There is a really interesting talk by Jeremy Thake, one of the lead developers on the project talking about the development of the site (it’s quite long so I recommend watching the whole thing only if you are really interested. Part 1, Part 2). What I got most out of that talk is that the original WA Tourism Site is not 100% SharePoint, there is a lot of hand coded components to the site, just in a SharePoint framework. When you look at the newer WA Tourism regional sites (eg SouthWest and NorthWest , you can see that the design is a lot simpler, with one or two master pages, and only a few different page layouts (you will notice all the pages have a much more consistent look and feel).
There is a great article on Heather Solomon’s site explaining how all the SharePoint design components fit together. It’s an essential resource to at least understand some of the terminology of SharePoint.
So, you can do anything you want as far as design goes in SharePoint, but the more you do, the more it will cost. So stick to a simple design with one Master Page and a few Page Layouts and that will minimise the costs.
Coding and Development
This is one area where I know that I do not know enough about SharePoint… So this is my opinion only and it could all be factually wrong. But it just seems to me that SharePoint development is hard, and there is not a lot of Best Practices around for how to develop in SharePoint well. Now this is probably not specifically a SharePoint issue either, I’m sure any large Website, especially public facing, will have many issues about which is the best way to do things for them.
Thankfully there are some great resources starting to surface. The excellent SharePoint Dev Wiki is aiming to share best practices for SharePoint development, and anyone can contribute to the site.
Getting the SharePoint development environment set up well, having a good, documented process for development and deployment from Dev to Test to Prod servers and having a good dev team that works well together are essential for any successful SharePoint Project.
Some of the key people you need for a SharePoint development are:
- SharePoint Architect – works out the structure of the overall SharePoint site, the hosting requirements and even the hardware.
- SharePoint Administrator – (overlaps with the Architect). Makes sure all the SharePoint sites are installed, patched and up and running at all times.
- SharePoint Consultant – works with the business to understand the requirements, does the customistation and configuration of SharePoint to meet the business needs. Works with the developers to ensure the business requirements are met, and does testing and training of the SharePoint installation with the business.
- Designer – if not a specific SharePoint designer, needs to work with the developers to ensure that their design is translated into the correct CSS and themes by the developers.
- SharePoint developer – for any custom development required (eg Web Parts, Line of Business applications, Custom Themes etc)
Thinking that you can build a successful SharePoint project without all of these people is just heading for disaster. And thinking that a SharePoint Consutant and a SharePoint developer can be the same person is also a concern. A person that can talk to the business has a completely different mindset than a person who can cut code. To have those two very different approaches in the one person requires a very special kind of person – one who probably would be doing something more than building SharePoint sites.
Security and Logins
As with any Website, security is a major concern that needs to be addressed in the very early architecture discussions of the site.
For people just browsing the website on the Internet, this is called Anonymous access, however, with any SharePoint site, people are going to have to interact with it, usually by logging in. SharePoint can have domain logins where every user needs to be authenticated on your Active Directory (not desirable for an Externally facing site) or Forms Based Authentication. I know very little about either, so I’m not going to go into it. But here are some articles that may be of interest.
- SharePoint Security Concepts
- SharePoint Forms Based Authentication Site
- Links to some MSDN articles on FBA
There is a lot to understand about SharePoint security and it is a significant part of the overall SharePoint architecture discussion.
Again, SEO is not specifically related to SharePoint, but as with all things SharePoint there is some specifics about dealing with SharePoint that you need to know about. There is a whole site devoted to all things SharePoint and SEO called MOSSSEO.
In Summary, I don’t think SharePoint is any worse or better a platform than any other for building public facing websites. All public facing websites have to meet a number of requirements that make them much more difficult to deliver than a basic Intranet, so if you do already use SharePoint for the Intranet or are an exclusively Microsoft house, then SharePoint is definitely a candidate.