In order to be true to the open source philosophy, City of Malmö now makes its open source builds of the intranet available on GitHub.

The dashboard on our intranet, running on Rails.

You need an intranet dashboard? Why not try ours, built in Rails! Does our assets approach sound interesting? Download it and look for yourself! You want to reuse some of our mediawiki and wordpress end user design ideas? It is all there to use! All we ask is that you in turn also share the great things you build.*

City of Malmö at GitHub

Using open source has a lot of positive effects. Some examples of what we have seen in my organization:

• Software quality. The open source things we have done on the intranet keep running, day by day. The cost of maintenance is minimal.
• Simple customization. It is easy to tweak the open source software to suit our needs, and the code is adhering to open standards. This has for example made it possible to build a responsive intranet the way we want it.
• No vendor lock-in. Since open source software does not require an initial choice of and costly purchase of platform, we can introduce new functions and intranet sections by trying it out in a small scale and then scale up if we like the results. We can also follow our Best of Breed-philosophy.
• Speedy development and quick results. Open source is ideal when you want to have iterative development and avoid big projects. Open source also means plenty of cost free community developed choices when adding functionality. No need to wait for the vendor to prioritize your needs.

Some background on open source:

• 10 Reasons Open Source Is Good for Business – PCWorld
• Benefits Of Open Source Code – OSS Watch
• Open Source Case for Business – Open Source Initiative
• Five Pros and Five Cons of Open Source Software – CIO Insight
• Advantages And Disadvantages Of Open Source – CloudTweaks
• Open Source (Almost) Everything

* The things we have created is released under the AGPL license. Basically this means you have to open source your own releases of our forked builds.

The dashboard on our intranet, version 1.2.

Left column: 1) Theme box for Community and culture content. 2) Status updates from your friends.

Middle column: 1) News box, with news from your department, your job role, from the organization and important IT news, all in one single time feed. If a news piece have comments, you can see this. If you want to see more than five items, you can click “show more”. 2) Discussions box, with blog posts and forum discussions based on your department and job role. If a blog piece have comments, you can see this (see item #1 in the screen shot). If you want to see more than five items, you can click “show more”. 3) Your own box, customize it with any rss feed you like. If you want to see more than five items, you can click “show more”. In all of these boxes you can also add more feeds to follow.

Right column: 1) People search box. 2) Tools and systems links based on your department and job role. 3) Tasks menu based on your department and job role. In the two last boxes you can also add more tools, systems and tasks.

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 decreases the load time for the end user since the majority of stylesheet and Javascript code will be cached in the browser instead of being fetch from each application.
• 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.

A blog page on our intranet, running on WordPress.

A news page on our intranet, running on another WordPress server.

The dashboard on our intranet, running on Rails.

A wiki page on our intranet, running on Mediawiki.

The news pages on the intranet provide the employees with info about changes that affect the working day, they speak about what is important right now. In my blog post A new take on intranet news I wrote about the changes we made in 2012, when we introduced comments on the news pages. Now you will read about iteration #2, some nine months later.

In the January design change we increased the focus on the news story and reduced some noise on the news page.

The new news page.

The old news page.

The new news page in a smartphone.

Main task—to tell you about changes
The main task of a news page is to tell you about changes in the organization that are important for you to know in your working day. This task remains after the design change.

For this reason, the greatest focus on the news page are the header and preamble, both in the old and new design. Directly under this, we have the text body. Further down the page there is the comment field.

A page that differ from other pages
News pages differ from other pages. News pages have an expiration date that is often just one or two weeks from the creation date. After this, the event the news page talks about has occurred—and the page stops being relevant.

Basic pages on the other hand often describe something that is “always true” in the organization and therefore have a very long lifecycle. The page about how vacation works in City of Malmö has changed maybe three times in ten years, since the rules for this normally do not change in the organization. The page about vacation is not a news page. (But a change on the page might warrant a news item.)

News pages are characterized by constant change and should be sorted according to creation date, newest on top, to give good support.

For this and other reasons we create news in WordPress. This tool, originally for blogs, is excellent for newest on top sorting. Wordpress is also excellent for handling comments on posts, the ability to comment on a news item is a natural companion to news. The possibility to easily batch remove old news also speaks for WordPress as the news creation tool no 1. We have no news older than 11 months on our intranet—because when they become one year old they start to destroy the search engine quality.

The January design change
The big change on the news pages is that the right column is greatly shortened compared to the September iteration. It used to have more than 30 links (5 more news blurbs based on categories for the news item on the page, 4 help links, 10 latest comments, 12 archive months), but now it only has five “further reading” links. These five blurbs are community-wide “Our ​​municipal news”, relevant for everyone.

The right column links were introduced in September and this was an improvement—the news page originally was a dead end. But we have realized that 30 is too much—a bit less is more. The old solution of news blurbs based on the categories of the current news item had a tendency to send people to other news posts that was not relevant.

Categories and tags have moved to below the news item. We also have less focus on the author, and have moved it further down as well.

The comment section has the same width as the news body, in the old version we had an unnecessary jump to the left when the comments began.

The Like button has been removed. It was not used to any great extent. We will evaluate whether we should have some kind of Like button for news in the future and if another graphic design for this might work better.

The news pages has a footer where we have gathered help, navigation to all categories and labels, news archive, etc. All this content is secondary compared to the actual news item.

And of course the new news pages are also responsive, so they fit beautifully in a smartphone.

Benefits we get
Thanks to the January adjustments in the News section, we use the news page more effectively. Look at the examples above—it is the same content on both pages, but the page in the new design is 25 percent shorter. Also, the need to get the news pages into the smartphone gave us more of a “Mobile first” approach in the desktop version with greater focus on the most important content.

We have fewer secondary things exposed directly on the page, and this, together with moving the author, categories and labels downwards, makes the page less “noisy”. We get a greater focus on the news content – just what the page is for!

This allows Komin to give the employees better support and make them more effective in their work—the goal of the intranet.

Since last time I’ve been promoted to communication channels manager. I have a team of four and our mission is to manage and develop City of Malmös big communication channels: external web, City of Malmös citizen paper (11 issues/year), intranet, and staff magazine (also 11 issues/year). On top of this we will also develop City of Malmös mobile presence. This will be a fun challenge!

One thing we have delivered in Januari is a new look for the intranet and more responsive web design. I will let the screen shots speak for themselves! All 24 in a zip file below, and then some teasers in the blog post.

Today our intrant is RWD in more than half of the tools we use to generate it (WordPress, Mediawiki, Ruby). Still to get RWD are the oldest static pages with left hand navigation, and our forum section (IPboard, or maby we will use the Drupal forum). Hopefully an upgrade of our CMS Sitevision will make some of it RWD after the summer break.

24 screen shots from City of Malmös intranet

Dashboard 1200px.

Dashboard 320px.

News page 1200px.

News page 230px.

Wiki main page 1200px.

Wiki main page 320px.

See all 24 screen shots from City of Malmös intranet

A while ago I heard an Intranet Manager saying “I have no clue about what our IT developers do”. While this is ok at low level coding activities (you do not have to know html language), it is NOT ok on a higher conceptual level. In my opinion you must understand what they do, how they are implementing your new intranet features, how this technically relates to the existing intranet and how they are solving your problems.

Only then can you decide on the right development activities for your intranet and have an opinion about the best solution. If you do not have the knowledge you are at the mercy of your developers. And while this is not necessarily bad (most IT developers are not evil), your intranet has a much greater chance of success if you (who have overall responsibility) have a basic understanding of IT, integrations, platform choices etcetera. Because you are the one, maybe the only one, who have the potential to see the intranet’s every need, no matter which area it falls in. Technology choices are not made in isolation from everything else, they affect the “softer” parts of the solution and therefore you have to take an active part in this.

An example: We are applying responsive web design on the Intranet. I am a comms officer, but if I do not understand the basics about html, what a CSS is, why we have this on a separate asset server, how the design break points are controlled by media queries and so on, we would never get a good solution. Not because my developer lack the skills on his own (actually he is brilliant and I am really fortunate to have him!) but because without knowledge I would order the wrong things and require suboptimal solutions.

Of course this also applies to more areas, e.g. HR, comms, business development and core operations—the more you know about all this the better intranet manager you will be.

So, if you, intranet manager, have a background as a communications officer, prioritise learning about IT and other areas related to your intranet!

How to start? Easy—ask your developer the first “stupid” questions about how things really work. Soon you will ask smarter questions. Always strive to know about more than you know today. Never act as if some things on your intranet is not your responsibility, or someone else’s work. Because it is in fact your job, if you want to control just how great intranet you will deliver.

What kind of solution should you go for?
There are three possibilities for going mobile:

1. a native app,
2. a HTML5 “app”,
3. a responsive version of the web/intranet you already have.

City of Malmö has the last five years tried all three. Here are our findings.

1. Native app
This is the original way of getting into the smartphone, started by Apple and their App store. Basically you build a program that users can install on their iOS/Android/other OS device, and this program delivers some kind of experience (in this discussion preferably some version of the intranet).

City of Malmö has developed a native iPhone app for citizens. Go to the iPhone app store and search for “Malmö stad” for a first hand look.

City of Malmös native app.

In this app we offer the user:

• News from City of Malmö,
• Places (libraries, playgrounds for kids, baths, bicycle pumps and some other physical objects we think citizens want to find),
• Art map (showing the places of public art, e.g. statues, and some info about the art items),
• Report an error (e.g. a pothole, a broken street lamp, unlawful graffiti).

Good services, I think. The error report service can also access the camera in your smartphone and you can take a picture of the pothole. When you send a report City of Malmö also gets a geolocation tag, so we can see where you were when you reported the error.

While this seems like a good solution, there are some drawbacks:

• Creating mobile content and services this way does not improve the desktop web malmo.se at all. Every integration in a native app is custom made for the app and not reusable on the standard web/intranet. For example, on malmo.se we do not have the Places service.
• The user has to go to an app store and download the app before getting started.
• The tool generating the app is not our ordinary CMS. In most cases a native app is hard coded, which means you as an intranet manager do not have any direct control over content and features. Upgrading, altering and adjusting content is difficult and often requires external consultants.
• A native app also needs a separate server, which means higher costs for running the web/smartphone presence every year.
• And—maybe the biggest problem with a native app—you actually have to build and support several apps, at least one for every smartphone OS. Or skip support for small OS ecosystems? Tablets also add to the complexity. Or should tablets use the desktop intranet? Decisions, decisions.

Your future if you choose to go for an native app.

We have found that the native app is an expensive and isolated solution, not helping the broader digital presence. The evolving landscape of smartphones/tablets also makes this life increasingly difficult. A native app might be the right solution for a specific single task, but we do not recommend going for a native app when delivering a broader experience or a whole web/intranet.

2. HTML5 “app”
With the HTML5 approach you use the smartphone web browser as the “app” and build ordinary web pages on templates custom made for smartphone screen sizes.

City of Malmö has also tried this, surf to malmo.se/touch for a first hand look.

In this HTML5 solution we offer the user:

• News from City of Malmö,
• Things to do (e.g. events, lectures, popular tourist attractions),
• Available jobs in the municipal organization,
• Social service chat for youths,
• A link to http://www.malmo.se.

Also good features in this solution, but different ones than in the native app. And while you can also find all four services on malmo.se, they are placed at different places, some several clicks away from the home page.

At best, a solution like this uses the same CMS and server as the ordinary web/intranet. If so, services you deliver through the smartphone can also fairly easy be reused on the desktop web/intranet. However, in some CMS tools it is difficult to make a whole different set of templates. Maybe you need a completely different database/tree structure and depending on your CMS license model you might have to pay for the CMS again (another web = another bill). Therefore some organizations run their HTML5 smartphone presence on a lightweight CMS, e.g. WordPress, or hardcode everything. malmo.se/touch is hardcoded.

• Creating mobile content and services this way might improve the desktop web/intranet, if you use the same CMS and it is easy to reuse integrations. But if you build on another platform the HTML5 “app” will be an isolated island, just as the native app approach is.
• If the CMS tool is not the ordinary web/intranet CMS you probably have less control over content and features. Upgrading, altering and adjusting content can be difficult and may require external consultants.
• The HTML5 solution might need a separate server, which means higher costs for running the web/smartphone presence every year.
• The user have to surf to another address, e.g. http://mobile.%5Bwebname%5D.com, before getting started.
• With the HTML5 solution you can have one build for all the smartphones, if you make sure the templates work for several different screen sizes. Media queries in the CSS (a part of Responsive Web Design) enables you to make custom design solutions for different screen sizes—absolutely necessary for making sure the HTML5 “app” also delivers a good user experience in tablets.

Your future if you choose to go for an HTML5 “app”.

We think that the HTML5 approach is much better then building a native app, and can be a good start if you feel you are “trapped” in your desktop intranet (an old intranet with bad content or if your CMS can not generate/use RWD). If you do not want the smartphone presence to be a completely different object (operatively and developmentally) you should plan for some kind of future merging of the HTML5 solution and the desktop intranet. Maybe the smartphone solution is the first version of the next intranet? Start in the smartphone but plan for upscaling the app to desktop sizes. A true mobile first approach! (Btw, you really should have the bible on this: Mobile First, by Luke Wroblewski.)

3. Responsive Web Design
Responsive Web Design is the new way of getting into smartphones and tablets. The idea is to use one web site/intranet (the one you already have) for generating your presence in desktops/laptops, tablets and smartphones. This is done through CSS3 media queries and fluid proportion-based grids, and

As a result, users across a broad range of devices and browsers will have access to a single source of content, laid out so as to be easy to read and navigate with a minimum of resizing, panning, and scrolling.

http://en.wikipedia.org/wiki/Responsive_web_design

Right now we are applying RWD on the intranet. Thanks to our assets approach we can implement RWD in steps. (Masthead, CSS and some other items are located on a separate server, our different content generators subscribes to these assets. Content generators: our “old” CMS generate base content, we use WordPress for news and blogs, IPBoard for forum, Ruby for our dashboard.)

So how does this look? Since our intranet is not open for all I can not invite you to a first hand try-out. But below are some screen shots that show the same page in different sizes.

This page has almost the same content in all sizes because we believe basic employee needs are the same no matter what device you use. People, news, discussions, web feeds you want to keep an eye on and so on—all this is basic stuff we always have to deliver. But this does not mean it has to look exactly the same. Thanks to media queries we compress and adjust appearance and interaction. It is also possible to switch off some boxes and features, and switch on new ones with media queries.

• With RWD you build content and services once—and you get it in all devices.
• You get a consistent appearance in all devices.
• You have no double maintenance.
• This is a foolproof solution against new devices with different screen sizes and new operating systems.
• You have the same web address for everything.
• You need only one server and one generating system for everything.

Your future if you choose to go with RWD.

We at City of Malmö really like RWD and we think this is the future. This is the way to go if you think you already have a good intranet with the right content and services. You will have only one intranet to care for, found at the same address no matter what browser and device you use, and no one will ever ask the question why you can do some stuff in one device but not the other.  (Get this bible as well: Responsive Web Design, by Ethan Marcotte.)

Another rather elegant effect is that the desktop user can have the intranet on the screen in “one-column mode”. 320px on the screen—it can always be open!

“But what if the mobile user has different needs than the desktop user? RWD do not handle this.”
This question sometimes pop up. Here I think it is important to discuss what we mean when we say the mobile user. Is it about:

1. A person using a smartphone/tablet, or
2. A person away from his/her desk?

It can not be answer #1. Because I can sit by my desk and use my tablet or smartphone. And I can be away from my desk and still use my laptop. I do not suddenly get totally different needs just because I push away the keyboard on my desk and switch to the iPad or iPhone, still sitting in my chair. Therefore The mobile user is not equal to holding a smartphone/tablet.

In my opinion this means that we must deliver everything in every device! You can not determine user needs based on device, this is not a valid token, so to say. Yes, employees away from their desks might have different needs or might want to use specific services in a different way. But we will have to come up with another way of supporting this than building a smartphone intranet totally different than the desktop version.

This said, I want to remind you that the RWD intranet needs user testing across the whole line of devices. It requires some proper thinking to deliver more complex forms and pages on a mere 153k pixels (original iPhone screen size). Again, make use of the RWD possibilities to compress, adjust, switch off and turn on content. Who knows—maybe the work with the smartphone appearance automatically gives new ideas on how the desktop version can be better.

He was surprised, and I felt a bit awkward. Of course this is—as he rightly argued—an easy way to pave the way for other social activities on the intranet. I had already introduced a forum section and a blog section. Then why not comments on news? In a way, I had avoided the issue for almost two years. But James’ remark got me to address this.

Old news presentation.

Above is an old intranet news post on the intranet. As you can see we have the basics in place: header, preamble, body. The author can also include a picture, a file and an info box. I would say this is mandatory parts of a news page. As you can also see we have no interaction and almost no possibilities to read more things. This news post is a dead end.

I gave this some thought and made a wish list of new functionality. In addition to the basics, I thought it would be great if the user could:

• comment on the news
• give a thumbs up
• see who the author is
• have links to related news

I also had some back-end wishes:

• simplified production of news posts (fewer clicks to publish, shorter CMS training requirements before a producer makes his first news post)
• syndication!!! (our old solution for news meant silo storage, one for each department, and and that we had to make several identical pages for the news to appear in different places on the intranet)

Very early in the design phase: getting the parts of the news page in the right order.

Another idea. (Wondering about the background? My kitchen table. )

Later in the design process. Wireframes.

In order to achieve all this we decided to move our news production from our CMS Sitevision (swedish java based CMS) to a WordPress installation. In 2010 we integrated a blog section on our intranet. The blog runs on WP and we felt this tool also could fill our news production needs.

New news presentation.

Today we show the news in a modern way. In addition to seeing the basic stuff the user also can “like” the news post and comment. It is also clear who made ​​the news post.

Like, comments and author.

And when you have read the news post the page offers a lot of possibilities for more reading.

No dead end!

All news posts in the organization are stored in the same WordPress archive. Because of this and the WP model of classifying posts with categories and tags we have really powerful syndication possibilities. We can assign more than one category and more than one tag to a post, and this way we can show a news post in several places but only produce one version. The news post above appears in five different places on the intranet! (On the main pages for the 3 business units “Street and Parks department”, “Culture department”, “City Planning Office”, on the main page “Our organization” and on the personalized dashboard for everyone, because this particular news post is deemed relevant for all employees.)

In WP, every category and every tag automatically get an RSS feed. We take these feeds and integrate them in key places on the intranet. This way we integrate news with other types of intranet content.

WPnews RSS integration on the start page of a business unit.

WPnews RSS integration on the start page of a job role.

Our new dashboard also shows the right feeds for every user based on department and job role. Back-end we import 50-60 different feeds from WPnews.

On my dashboard i can see relevant news feeds based on who I am.

Today we have used the new way to produce news for 5 months. How did this turn out? Pretty good, actually!

• June and September both saw approximately 260 news post each month—big and small news to inform the employees, give them work day support and make them more effective.
• A news producer today only need 30 min education compared to 4 hours in the old system.
• We no longer have to make new versions of the same news post for it to show in different departments and job role sections on the intranet.
• Comments and likes for a news post are still in the 0-10 range, but on the way up.

This winter we will evaluate with google analytics, surveys and study the user flows. I think we will see that because of our new take, intranet news now works better.

Our dashboard “Min sida” (My page) version 1.0. The dashboard has global intranet news items, local intranet news items from your own business unit, local news items from your own job role, intranet blog posts you want to follow, intranet forum posts you want to follow, RSS streams you want to follow (any rss from the internet), twitter hash tags you want to follow, Twitter persons you want to follow, Tools you need in your work day (based on who you are), people search (a very basic one).

Now we are in the process of upgrading to version 1.1. We believe in taking small but rapid steps, to start with a few features in the first version and then quickly move on with the development and launch a version 1.1, 1.2 and so on.

September 15 we plan to

• have online help icons on the page (expand help texts about what each box does and how to control them as a user)
• show how many comments a news piece/blog post has
• introduce end user controls for expanding a box in order to show more news/blog items than the preset 5/10
• improve the overall looks (today we think the page has too much text and to few pictures/graphic objects)
• create the possibility for the user to upload a picture of oneself, register his/her own status message and see colleagues statuses, se the wireframe mockup below

Top box is your own micro-bio-box where you can set your own status. Next box is where you add colleagues and see what they do.

Update August 16: And some dev screen shots:

Write mode – submit your status.

After you have set your status.

The status update function package will be the big thing in the 1.1 version and—hopefully—a crowd pleaser. But we do of course not build functions just for fun – work day status updates is an important first part of a brand new employee DB. More about this later this year.

After launch of the 1.1 version, the dashboard will become the standard start page of the intranet. (Until today the starting page has been “Vår kommun” (our municipality) an old top down solution from the 90s.) A revolution!

crafted to use Cascading Style Sheets 3 media queries, an extension of the @media rule, with fluid proportion-based grids, to adapt the layout to the viewing environment, and probably also use flexible images. As a result, users across a broad range of devices and browsers will have access to a single source of content, laid out so as to be easy to read and navigate with a minimum of resizing, panning, and scrolling.

Sounds like a thing an intranet could benefit from. While many organizations still has a single OS platform (City of Malmös computers run on Windows XP and Explorer 7) (Yes, I know its middle age, hopefully we will get at least W7 and Ex9 this autumn), smartphones, tablets and BYOD are on their way. In a year or two, I think a core operating system not adapted for a wide array of devices is facing major problems.

Therefore, we made sure our new intranet dashboard were built with RWD from the beginning. Launched May 25, this page adapt beautifully according to device.

Our dashboard was the first RWD test for us. This summer we will make the other parts of the intranet responsive as well.