The rapid growth in use of mobile devices demands that libraries accommodate information presentation on smartphones and other small screens. Usability should be the focus for every stage of design, ideally following the conventions and best practices promulgated by the World Wide Web Consortium and codified by major manufacturers such as Apple, Android and Blackberry. A mobile device is not simply a reduced-size desktop; its minimal real estate requires different design choices and compromises that affect reading, navigation and entering text. Testing and evaluating the mobile interface design and function require attention to the hardware, operating system and browser. Ideally testing should be performed on multiple hardware configurations and by a wide variety of users. Emulators, simulators and lab testing can be useful but should not replace usability evaluation by real people in real life situations.

mobile applications 
smartphones
usability
screen design
human computer interaction
information architecture 
evaluation

Bulletin, October/November 2011


Mobile Usability

by Jeff Wisniewski

It’s a mobile world. Over the past several years there has been an impressive increase in the number of mobile devices, particularly smartphones and tablets, and mobile Internet use has skyrocketed accordingly. Libraries are aware of these trends and are making forays into the mobile landscape with apps and mobile sites. Libraries need to be mobile, but need to be mobile in the right way, in a way that’s accessible, appropriate and user friendly. Most libraries have experience with desktop usability, but what about usability in the mobile context? 

Before discussing usability in a mobile context, we need to clarify what exactly is “mobile”? A tablet, for example, is indeed mobile, but it has a screen that in some cases bests the size of some notebooks and netbooks. Is a smartphone that has a laptop dock, complete with keyboard and full size screen, mobile? A reasonable approach would be to categorize devices as either large screen or small screen. For the purposes of this discussion, the context is usability for the small screen.

Designing For Usability
The best way to ensure a usable mobile product is to design it well, with usability in mind through the entire process. Fortunately, there’s a lot of guidance available in the form of both platform-specific user interaction guidelines, as well as more general mobile usability guidelines from the World Wide Web Consortium. Apple, Android, Blackberry and other mobile OS makers make detailed user interface guidelines available that answer many of the questions a small screen designer might have.

Whether a user is physically on the move or stationary, immersed in the device or working in a state of constant partial attention, the simple reality is that interacting with the small screen poses challenges that working with larger screens does not. 

It goes without saying that mobile is not simply a minified version of the desktop. There are substantive differences that strongly influence the design and function of mobile that set it apart from the desktop environment. 

There’s less real estate to work with, so an important consideration is that of distilling your site content and services to their essence. Indeed, there is discussion about a mobile first design philosophy, which advocates designing your site first for mobile, then for the desktop, as opposed to the way it usually happens. The point is to get designers and developers thinking about and aware of which information and services they offer are core and which are ancillary. 

It is, for example, safe to say that most small screen users will neither need nor want to read the ins and outs of your full circulation policy. They will, however, most certainly want to be able to quickly look up a book title, see if the library is open or send you a question via text or instant messaging. 

Top-level choices should be relatively few. Again, think of what is mission critical. A slim and deep architecture makes sense. For example, instead of a single page or panel listing all of your branches, the days of the week and their hours of operation, a better approach is to chunk this information down through several screens. 

The New York Public Library does a great job here, by having the user first choose “visit a library,” then on the next screen choose location (borough), then branch on the next screen, then get the hours listing. They also get bonus points for offering a “today’s hours are...” statement. It’s more clicks than we’d perhaps use in a desktop environment, but in a mobile context it makes good sense. There are fewer top-level choices. 

Because of the small screen and the ergonomics of holding the device, buttons and other actionable areas are somewhat oversized with more real estate per choice and designed with a drill-down architecture that makes both the choosing and the selecting mindless and easy to execute. If we do as Steve Krug implores us and design desktop sites that don’t make the user have to think, perhaps we can say that in the mobile context we don’t want users to have to think or have to look too closely or to even have to scroll. If a user can get lost in a mobile site or app then something is wrong.

Entering text on small screen devices is another challenge, so minimizing the need to do it improves the overall usability of the site or app. In some cases, for instance, where login is required, it’s unavoidable, but in general the need for text input should be limited. In addition, as is usually the case in the desktop environment, it pays to be conventional. The user interface guidelines put out by manufacturers like Apple exist to codify and promote best practices or conventions. That’s not to say that there’s no room for innovation or uniqueness, but in general adhering to user interface guidelines is good practice. 

Testing and Evaluating
Most of us have experience with testing desktop site usability, and many of the same tools and techniques are useful in the mobile environment as well. 

What to test? Functional and interaction (task) testing are equally important. Because of the massive variation in both mobile hardware (for example, keyboard or touch screen or scroll ball? portrait or landscape orientation?) and operating system (Blackberry OS, various versions of Android, iOS) as well as browser if we’re talking about a mobile site (Opera, Fennec, Safari, Dolphin and so forth), functional testing takes on heightened importance. Test your app or mobile site on as many of these platforms with as many different hardware configurations as possible. Have friends and colleagues test, too. Initial testing for a mobile site can be done using a User Agent Switcher add-on for Firefox (https://addons.mozilla.org/en-US/firefox/addon/59/); this add-on enables your desktop browser to identify itself as a mobile browser, to help with testing and debugging. In addition, there are a number of mobile browser and platform emulators and simulators that can be useful adjuncts to, but not substitutes for, testing on actual devices. Web-based services like DeviceAnwhere (www.deviceanywhere.com/mobile-application-testing-web.html) and BrowserCam (www.browsercam.com/) offer mobile emulation and testing and can also be useful tools in your mobile usability toolbox.

Interaction or task testing is also important, and, as in the desktop environment, this testing can and should begin before the site or app is even built. Paper prototypes work great here. A wireframe, built and tested on the desktop, can provide some useful insight as well. Once you have a working prototype, though, how do you test it?

Testing
There are two leading approaches to testing: testing in a controlled environment, like a usability lab, and testing in the wild, that is, going out and finding real users where they are and testing on the spot. The usability literature is not clear about which approach is better. Testing in the lab introduces some artificial stability that can affect results. Someone testing in a lab is not, as they might be in the real world, doing three things at once ̶ walking down the street, trying, for example, to see if the library is open. On the other hand, testing in the wild can be a hit or miss affair, and while the context is more real, finding an appropriately representative sample of users and devices can be a challenge to say the least. 

Lab testing probably makes the most sense. In the desktop world, despite its limitation, it has proven to be useful and reliable. Testing in the lab can be as low tech or as high tech as you want it to be. Some mobile usability lab environments use sleds, which are cradles to keep the device stationary, and cameras to record interactions for analysis. Some use cameras and no sleds, and some use neither cameras nor sleds. While the desire to have good quality video to analyze is reasonable, fixing a device to a surface is an added layer of artificiality in what is already a fairly constructed environment. A combination of observation and the “think aloud” protocol, where users are encouraged to verbalize what they’re doing and why, can provide a great deal of insight and lead to a far more usable product in the end. That it’s both cheap and easy is icing on the cake.

Whether we’re building for the desktop, small screen mobile or large screen mobile, usability needs to be present from the conceptual stage straight through to deployment and after implementation. Build well, test and retest, and continuously improve to ensure a mobile web experience that both satisfies and delights users.


Jeff Wisniewski is web services librarian at the Hillman Library, University of Pittsburgh. He can be reached at jeffw<at>pitt.edu.