Three ways to bring your intranet into the smartphone

Did you just get the question from your senior manager about when all the employees can use the intranet on their smartphones and tablets? Do not panic. You can deliver sooner than you think. You just have to make a basic decision first.

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. Update: The Native app has been deprecated.

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.

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.companyname.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.

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.

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.