Taking a short break from our normal topics of usability and user experience within games, this week i’ll be focusing on Intranets built with Microsoft Sharepoint.
This post is in response to Jakob Nielsen’s update on Sharepoint, entitled ‘Does Sharepoint Destroy Intranet Design?’. For the last year I’ve been working closely with Sharepoint, and want to wade in to this discussion.
Are intranets all the same?
Nielsen’s update argues for Sharepoint as an effective base for an intranet. Counter to the argument that the standard Sharepoint toolset doesn’t allow much flexibility when designing, he presents four different intranets, all based on Sharepoint, as evidence.
The evidence Nielsen supplies for this conclusion, that Sharepoint still allows intranet design, seems… dubious. For example, he lists the different top navigation categories as evidence that the sites design is different. I would hesitate to define the designing of an intranet to be entirely about information architecture (the categories chosen for top level navigation), and would suggest that the ability to design a flexible intranet goes much deeper than this.
Sharepoint isn’t perfect
Having worked closely with Sharepoint for the last year, it’s obvious that the usability problems within Sharepoint are more important than its ability to define navigation categories.
For example, this is how you’d upload an image from your hard drive onto the page you are editing.
- Click ‘edit page’. Wait for new page to load.
- Click in the area, and click on image button.
- New window comes up, click on ‘browse’.
- New window comes up, Only shows 8 images at a time – verify the image you want isn’t already uploaded (through lots of slow page refreshes).
- Decide to upload, click ‘upload’ (note that the directory you have been browsing is not the directory that it’ll upload too – instead it always uploads to the same directory. And has no tools to move the image to a new location, besides opening the directory in windows explorer to do it)
- New window comes up, click browse, find the file, click upload.
- Find the image in the thumbnail viewer (remember, only 8 images at a time) –
- Click ok on every box that’s opened
- Click on ‘check in’ to view page.
- Right click on a file, select ‘version history’.
- Right click on an invidual version
- Select ‘delete version’
- Accept confirmation box
- Refresh the page
- Go to 2
I often encounter files with hundreds of versions. This process takes hours.
So the solution to this is obvious and widely seen elsewhere (even in other areas of Sharepoint!). A row of tick boxes down the side of the list of versions, with ‘select all/none’ buttons. Then a ‘delete selected’ button. This would save hours on intranet maintenance, and seems like a massive oversight.
Although Nielsen’s argument that Sharepoint doesn’t prevent intranet customisation is legitimate, I feel Sharepoint has more pertinent usability issues that prevent it from being the perfect CMS to build an intranet upon.
Nielsen over-represents the amount of customisation possible – although you can change the navigation, and the pictures/layout, Microsoft impose definitive restrictions upon what can and cannot be done, often prevent usability issues from being fixed.
Instead, I suggest an open source CMS like Drupal would provide a better base for an intranet. By giving the administrator full control over the CMS’s inner workings, Drupal not only allows a wider range of customisation, and design to take place, but it also benefits from a plethora of user created modules which add almost any pre-generated functionality that can be imagined. As such, it not only allows the limited customisation that Sharepoint can, but gives the user the chance to fix usability problems through customisation, and extend the functionality in ways limited only by imagination.
Comparing Sharepoint with Drupal is a bit like comparing a fork lift with a ferarri… They both have 4 wheels but serve very different purposes.
Good point. I think I was trying to promote the benefits of open-source, and the plethora of user-created modules that you get with that (like wordpress’s plugins), as opposed to the benefits of Drupal specifically.
However, as you note, Drupal would find scaling to enterprise level difficult!