The Device Agnostic Intranet

Are you, intranet manager, thinking about entering the mobile world by making an iOS app version of the intranet, with maybe five to ten often used tools and features? Then I beg you to reconsider, because in my opinion you do not take sufficient height for the future. Because pretty soon you need to be device agnostic.

The Old, Singular World
At City of Malmö we have a standard computer platform (W7, IE9). The only sanctioned tablet at the moment is Apples iPad. And the only smartphone that is possible to order is the iPhone. I think this—only one desktop OS platform, only one or a few smartphone choices, a single accepted tablet—is still the reality in many organizations.

Living with this, it would be tempting to think that the intranet should be built for exactly those devices. If we make sure the intranet is working on Windows 7 + Explorer 9, iOX + Safari, and looks good at 1200px, 1024px, 768px, 480px and 320px everyone will be happy. Let’s just build an Explorer desktop version and an iOS app, either a native iOS app store app or a web app, and then we would be done with it.

But this would be completely wrong approach. Why? Because a good, modern intranet is OS agnostic, browser agnostic and physical device agnostic!

Being OS and Browser Agnostic
Remember when some web pages only worked on IE6? There was a time when HTML standards was in its infancy, and Microsoft did not have a problem with breaking them in Explorer. Sometimes the effect was either your web page worked fine in Explorer or worked fine in the other web browsers, but not in both worlds at the same time. This is a thing of the past on the web, thanks to HTML5 and Explorer 9/10.

But inside companies some systems with web interfaces still require a special browser version. Our HR system officially only supports users with Windows and Explorer (although Mac and Safari usually works). Our finance system has some serious front-end design glitches when using some browsers other than Explorer, columns tend to move horizontally and the labels do not match. Not good when dealing with money.

This is not OK, of course. But big IT systems are sometimes closed worlds with proprietary interfaces from the 90s. Technical change is really hard, and often you are in the hands of the vendor. Change will come but takes time.

For an intranet, this does not have to be the case. If you are using a good CMS, it supports all the major browsers. If it don’t—change CMS! Now! City of Malmö have many intranet CMS tools because of our Best of Breed, Open Source philosophy, therefore we have a list of the browsers and OSs the intranet must support. Our goal is to make sure the intranet works and looks good on every HTML5 compatible browser. This is not necessary or demanded of the intranet team today, but some day, probably quite suddenly, the traditional “pro PC, no Macs” attitude we still have among a few systems owners in the organization will be over* and then we will be able to choose any computer we like, or bring our own private device. At that point the intranet have to be ready and usable, no matter what computer OS and browser you choose to use.

* To be fair: The central IT unit at City of Malmö is hard at work envisioning and delivering “the digital workplace” where OS and physical device are your own, free choices. Also, the policy is that from now on when buying new systems at City of Malmö, the web interface must be browser agnostic.

Being Physical Device Agnostic—an iOS App is Not The Solution
A web page should work on any browser—this is obvious. Today, no UX professional designs for Explorer only.

The same approach must be taken when designing for different physical devices. Even if City of Malmö only use iPads and iPhones today it would be wrong to design only for these mobile devices. Because there are other kinds of devices out there, still officially outside the organization but slowly seeping in. The increasing employee demand to use the computer/device of his/her own choice and the BYOD trend will in the end break the barriers. Then we have to support every device.

This is why it is wrong to develop a separate native intranet app or a separate intranet web app. None of these two solutions are device agnostic. A native app only works in iOS or in Android—not in both OSs at the same time. A web app is begging for trouble in the same way with different versions not matching and a never-ending double maintenance of the intranet.

For every separate mobile version you’re building and maintaining, a separate tablet version and TV version are right around the corner. […] No matter how many versions you support, if you’re using separate websites, you’re supporting too many. Drew Thomas; Why Responsive Web Design Has To Win Out

Sharing links from a native app or web app when the receiving user is at her desk using a desktop computer is almost impossible. Users quickly start questioning why some pages, tools and features are available just in one version and not in all. Search and statistics are other challenges when you fragment your intranet with a separate native intranet app or a separate intranet web app.

Lets face it: Native apps and web apps do not solve the whole need, in the end they contribute only to the intranet fragmentation. They might be a short-term solution for addressing an urgent need, but not the right long-term solution for your intranet presence in the organization.

Responsive Web Design as a Device Agnostic Solution
Enter Responsive Web Design as a solution for being physical device agnostic. With RWD you have one intranet that you tailor with breakpoints depending on screen width. You have one page on a subject that you display differently in different devices. With RWD you support every device with the same page source as long as the browser in the device supports HTML5 and CSS3 with media queries (all modern smartphone and tablet browsers do this).

Also, with RWD you can be truly device agnostic by not looking at the device’s screen sizes at all! What I’m talking about here is to stop thinking about the device based breakpoints and start thinking about the design based breakpoints. Here is a really good blog post about design based breakpoints. To summarize Stephen Greig, the author: it is wrong to make the RWD breakpoints based on the devices the organization has today, on devices that are currently popular. The breakpoints should not be at popular devices widths. The page should always look good, no matter what width the browser uses. Breakpoints should be inserted whenever they are needed in order to make the page look good.

Pull your browser window out and see when the design starts to break – that’s your first breakpoint. Use a media query, fix it up and repeat the process. Simple!

Don’t base your breakpoints on devices that are currently popular, base them on your design and where it requires adjustment.

In theory, we should forget everything we ever knew about currently popular devices when it comes to determining breakpoints […] Stephen Greig; Deciding What Responsive Breakpoints to use

Below a chart describing our breakpoints. As you can see the breakpoints occur at many different places and also individually depending on content type—we just insert them whenever we feel we need to change the design in order to make the individual page look good.

If you want to study the design choices we have made you can download a collection of screen shots in this blog post.

The Device Agnostic Intranet
Now, I will stop talking about OS, browser and physical device as separate parts, because in reality they are inseparable. Let us just call it “the device”, containing two parts software and one part hardware.

In order to make an intranet that is future proof, an intranet that works no matter what device the end-user chooses, you have to avoid building native apps or special web apps. You have to throw out the old inferior CMS. You have to walk the RWD way. Then you have the possibility to create the Device Agnostic Intranet. City of Malmö has started the journey. Have you?