You need a CMS for generating your intranet. Statistics says either you choose A) Sharepoint, or B) some other CMS platform that delivers in the same amplitude (you hope), but with a lower price tag and not so many implementation hours (you hope again). Either way, you end up in a long-term engagement and have to accept the choices and the development pace the platform supplier chooses.
If you are full of initiative and build your own additional functions on top of the product, you are usually “punished” when upgrading. More often than not, your own functions break down and have to be rebuilt.
But wait! I am here to tell you there is a third way for your intranet.
At City of Malmö we have a C) best of breed, open source approach. This means:
- No need to live with some mediocre modules and tools in the CMS platform.
- A more “modular” approach on the intranet and in each tool.
- Free access to great stuff thousands of open source developers have created, with a global and open ecosystem.
- No annual license fees.
Let me elaborate.
Using different products for different needs
Two years ago we needed a blog on the intranet. Our original CMS did not have a blog module. Therefore we looked at WordPress, globally recognized as the leading blog tool. Today our blog section runs on WordPress.
Last year we decided to produce intranet news in a completely different way. Read more about this here and here. For this we decided to use a second WordPress installation, since WPs categorization and tagging was exactly what we needed for our news maintenance.
Last year, we also introduced individual personalization on the intranet and built a dashboard in Ruby on Rails. RoR, often shortened to Rails, is an open source web application framework for the Ruby programming language and has a large, sharing developer community.
Last month we saw the need for a wiki section on the intranet. A quick market scan made it obvious Mediawiki is the most used wiki tool. If it is good enough for Wikipedia, it most probably fills our needs also. Therefore we use Mediawiki for our brand new wiki section.
Now we need to make our forum section responsive. We also feel that the back-end in IPBoard (our current forum product) is too complicated to use. Therefore we will use the forum section in Drupal, an open source content management framework.
The Best of Breed, open source philosophy
All choices above were made with a “Best of Breed” approach. The BoB philosophy: If we need a blog, why accept that it is not in the CMS platform or settle with mediocre functionality? Why not choose the tool that is considered the best on the market and solve the need this way?
Also, all choices above are open source. Open source means mature code, a lot of different plug ins/add ons, a huge, global, sharing developer community and available consultants in every country—the last one often a big problem when choosing a small cms. Open source also means no initial purchase cost and no annual license fees. Hence a lot more money for development.
A consistent user experience
So far, so good. But surely several different products generating the intranet must be living hell in terms of graphic front-end design? It must be impossible to get a consistency of appearance?
No. Because the graphic design is not generated in our products.
City of Malmö has a separate assets server. The assets contains a common base for the UI such as a masthead, footer, form styling, page layouts, styling for articles, widgets, and components. Every product accesses the assets server and uses the base to build the views and pages. Easily explained: the individual product contains the data (the text content, “the letters”), and the assets server provides information about how to style the data, e.g. “apply Georgia, 13px, black, with a green box behind”. This way the end user does not notice any difference between different generating tools.
Compare this with authentication. A modern system does not run its own user database. Instead, the system has an integration to the central employee catalogue in the organization, or have Single Sign On implemented. Thus the user has only one username and one password to keep track of, and each system does not have to reinvent the wheel. Placing the CSS, java scripts, web fonts and the masthead on a separate server is more of this “solve it once, use it many times”.
The intranet assets gives us several benefits:
- It gives all web applications a consistent UI for the user.
- Common changes are deployed in one place and the changes are reflected immediately in all web applications.
- It speeds up development.
A fairly obvious step to take, when you start to think about it. But still pretty genial. A big thank you to our long term consultant Mårten Thavenius who convinced us to choose this path!
A lot of positive effects
The Third Way Intranet has a lot of positive effects:
- Keeping the user experience and graphic design separate from the content generating tools makes it possible to have several different tools, each time using the best tool for the specific task at hand.
- Using open source speeds up the development and delivers results faster. It saves money and gives you plenty of cost free community developed choices when adding functionality.
- Several different tools also means you can actually “hot swap” sections on the intranet. If we want to change to a different blog tool, we can a) set up the new product, b) make it access the stuff on the assets server, c) export the blog database from WordPress and integrate it in the new product, d) and then redirect the users to the new blog section by changing the address in the masthead tab and on the other places we link to the blog. And the rest of the intranet had zero downtime! No laborious, ulcer-generating all-at-once platform migration needed.
- Last but not least, when you have the UX and graphic design on an assets server, third party developers/vendors can use it and add value (functions, services and integrations) to the intranet in a effective and simple way.