In one of our recent active discussions on the new Print Software section, a WhatTheyThink reader asked “in your support for mobile do you recommend looking for just the sites being "responsive" or applications to be "native" or just plain "compatible", i.e. no Flash?” After my third paragraph response to this question I decided this warranted a full length feature article to describe and comment on the varying degrees of mobile support in web software.

“Now is the time for the medium of the web to outgrow its origins in the printed page. Not to abandon so much wisdom and experience, but to also chart its own course, where appropriate.” – John Allsopp, A Dao of Web Design April 2000.

We all know that mobile access to the internet is exploding; smartphones were boldly predicted to out-ship the combined global market of laptop, desktop, and notebook computers by 2012. They did so in the last quarter of 2010. Mobile is important, but how important is it to printers using web software for web-to-print and Print MIS? A very popular cloud based web-to-print platform confided in us that 40% of their access today is through mobile browsers. Mobile support is needed now. Another printer showed us an RFP from his top customer where the web-to-print solution was going to be used exclusively by their global sales team via company issued iPads. We have been in several large printing plants where a significant portion of the Print MIS input (not just shop floor data collection) is being done on mobile devices.

“Mobile support is critical for print software now; every print software vendor should be incrementally advancing their support for mobile in virtually every release moving forward.” – Jennifer Matt, WhatTheyThink.

So how do you assess the mobile support of your print software? It’s not a simple check box, the support of mobile is on a wide spectrum; ranging from it simply doesn’t work on mobile to it elegantly adapts to the screen you’re on and gives you the optimal user experience.

What Makes Mobile Different?

The most obvious difference with mobile devices vs. computers is the dramatic decrease in screen real estate. The initial versions of smartphones typically had a 320-480 pixel screen resolution; this represents an 80% decrease in real estate from a typical computer browser. You simply can’t build a cluttered mobile experience, there isn’t room. Mobile devices are taken everywhere, you can’t assume a steady connection because mobile users are moving between networks, and you better assume only partial attention; “one eyeball and one thumb” as described by Luke Wroblewski in this book Mobile First.

Mobile Compatible (it’s not broken, kind of…)

The original question that spurred this article on asked “or just plain "compatible", i.e. no Flash?” wondering if your product/site can load on a mobile device without errors, is that enough? Certain technologies, e.g. Adobe Flash are not compatible with most mobile devices (including iOS and Android). So if Flash, Java or Silverlight is crucial your site it will not work on mobile.

If your site loads then you could say its mobile compatible - let’s call mobile compatible “not broken, but not ideal”. We’ve all browsed to a site on our mobile device that loads with no understanding of your screen size, they are OK for finding out an address or phone number but you really can’t do anything else on them without a lot of zooming and scrolling.

“Mobile support is critical for print software now; every print software vendor should be advancing their support for mobile in virtually every release moving forward.” – Jennifer Matt, WhatTheyThink

This is a very low bar and should only be where you start the process of mobile support. The transition from Flash to HTML5 (the mobile compatible alternative) is underway, don’t freak out if components of a solution are still in Flash, it should not be a total deal breaker unless you know that your customer base is dominated by mobile devices. At this time Flash is more feature rich than HTML5 so the transition can sometimes be painful, with critical functionality being lost in the transition. For more complex user interactions having a desktop version that still runs Flash is acceptable – the software just needs to load a HTML5 alternative when it detects a mobile browser.

Mobile Web Experience – Separate Sites

In the early days of smartphones there was a wave of website redesigns which made a separate site which sat next to the desktop site specifically made for smartphones (sometimes they were even iPhone specific). This made for a better user experience but also a headache for the web developers. You now have to program and design two different websites. The folly of this style of design came back to roost when the iPad came out and the mobile sites all looked pretty awful on the larger, but still ‘mobile’ device. This approach is not preferred and costs more in the long run as maintaining the two designs adds up.

Mobile Web Experience – Responsive Design

Responsive Design dictates that as the screen changes size the web page should change its layout. You can see a good example of this style of web site at http://www.bostonglobe.com/. Load it on your computer and then narrow and widen the browser window from phone width to your full screen width. What you will see is that the layout goes from one column to two columns to three columns, the headlines get bigger, the section selector turns into a traditional set of header links, etc. 

Back in April of 2000, John Allsopp wrote a brilliant article, A Dao of Web Design that essentially advised web designers to change their thinking and predicted where we are today with responsive design. Allsopp suggested that a web designer’s objective should be to “…make pages which are adaptable.” This quote reveals that Allsopp saw what was coming back in 2000, “perhaps now it remains an aspiration, with browsers so broken, and many of the devices through which we will access the web in their infancy, or not yet born.”

Ethan Marcotte, coined the term Responsive Web Design (RWD) in May 2010, he describes it as “…a design that can adapt to the constraints of the browser window or device that renders it, creating a design that almost responds to the user’s needs.” This is of course ideal, one design that works on all devices.

Responsive Design, when done well, can get expensive. Responsive makes it elegant on a range of screen sizes from phones to tablets to PCs. Elegant is the key word. Kind of like a magical always good fitting suit or dress; not like sweatpants. This is quite forward thinking because your site will work well even as phones and tablets get bigger and smaller.

“… Starting with the desktop design may be an increasingly backward way of thinking about a web product.” – Luke Wroblewski, Mobile First, A Book Apart.

Responsive Design or a Separate Site can be done in steps. If you have an existing web site and you browse it on your tablet you may find that there are just a couple of places that it doesn’t work well. Now do the same on your phone and you may find another couple of troublesome spots. Rather than doing a site wide redesign you could just target those specific pages with either responsive design or an alternate version of the page for smaller screens. For existing sites this can be an economical way to get rid of pain, which is confined to parts of your site’s mobile experience without the burden of a long and expensive redesign.

Native Mobile App

Developing a native application has a number of advantages. Users spend more time with native apps then they do with mobile websites. You have access to the full capabilities of the device with a mobile app (background processes, app or in-app sales, access to core features like address book, SMS, audio inputs, etc.). The downsides are, mostly, schedule and budget. A native application is more time consuming to develop. So the budget is much larger and the schedule will be much longer. In addition you will need to make an app for each of the different devices types. You can easily spend an order of magnitude more money to develop the same functionality as a web site.

“My goal was initially just to make a mobile companion, but I become convinced it was possible to create a version of Facebook that was actually better than the website.” – Joe Hewitt, former lead developer of Facebook’s iPhone application.

Native or not is a choice that is dictated by how often and what the user needs to accomplish (and the aforementioned budget and time). If this is an occasional use then a website will work great. If your project is an interface that production people are using all day via a tablet than a native application is absolutely the way to do.

Mobile First

Google Chairman Eric Schmidt advises: “The simple guideline is whatever you are doing—do mobile first.”

Mobile First is a rallying cry for the change in web development practices. It posits that when developing a new web interface you should make a basic version of it work well with smartphone browsers. Then begin add features for a richer experience on tablets and PCs. i.e. build it simple and grow it rather than build it complex and then dumb it down for mobile.

Where retrofitting existing web interfaces to be responsive can be expensive, going Mobile First can actually reduce costs since it keeps pages simple. 

Once you understand that mobile support is an evolutionary process, there is no such thing as
“done” with mobile support because it keeps moving; you can now ask intelligent questions of your print software providers. Where are they on their mobile support roadmap? What is their plan to continue to make their product “adapt” to the use no matter what the browser, device, or connection?