Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Testing mobile Web applications for usability and context

Key how-tos in testing mobile applications for usability and contest are covered, as well as differences between testing full-fidelity and mobile Web apps.

John Overbaugh
John Overbaugh
With more and more wireless devices with mobile functionality sold everyday, there's a great demand for qualified mobile web application testing strategists. In this article, we'll explore some of the differences between testing full-fidelity web applications and mobile web applications.

Two of the key differences in mobile application design are usability and context. Mobile devices are hand-held and generally require one-handed text entry, meaning they can't be significantly interactive. Additionally, their limited input functionality and screen capacity require a specific context for use. When testing a mobile application, it's important to keep this in mind. A key role of a tester is to advocate at project inception for good usability and appropriate context.

A real world example might help. Let's look, for instance, at a fictitious site , which I'll call My President's Speeches at the fictitious URL: www.mypresidentsspeeches.com . Let's say that this site is dedicated to publishing each speech made by the president of a fictitious country. The full-fidelity site would likely include video, audio, and print versions of speeches. It might post multiple speeches each day, and have a long archive for readers to browse.

Usability: Keep the device in mind

Now let's assume we (the engineering team) are tasked with building and testing a mobile sub-site for www.mypresidentsspeeches.com. Many first-time mobile sites actually just re-write their entire site in mobile-friendly XML, without changing layout, content, or design. As a tester, you must encourage your team to consider whether the site's usability will show well and interact well on a mobile device. It rarely does if it's just a port of an existing site.

A mobile sub-site of the speech repository would be poorly designed if all it did was serve up speeches in their entirety, with the same navigation and content. First of all, it's nearly impossible to navigate a full site with a small phone browser. There are simply too many links all over the page. Secondly, there are bandwidth constraints on mobile devices which prevent a good user experience if the site is "rich" -- full content, large images, etc. Finally, an entire speech is too much content to read on a little screen! A better site would serve up important quotes, in context, from recent speeches. This would keep downloads short and make the user's experience much more positive.

Another usability issue to advocate for is, of all things, the site's URL. Typing http://www.mypresidentsspeeches.com is a bit tedious on a handset. Several strategies exist for solving this issue, including:

  • Use a dot-mobi site: for instance, try prezspeech.mobi. Check out the .mobi domain for more information.
  • Use an m. extension, such as m.mypresidentsspeeches.com. Thay may not be much better, but it could still be helpful.
  • Try auto-recognizing a mobile device at the root of your server and redirecting to the mobile sub-site.

Each approach has advantages and disadvantages. For example, .mobi extensions are short, but are a new phenomenon and not often recognized by users. Adding m. to your site doesn't reduce the text input required for navigation; although it's preferable to using mobile.*. Finally, redirecting can have problems because it's difficult to detect all mobile browsers, and you may redirect in error.

Context: What is the user doing

Mobile content also needs to be considered in terms of context. If a user browses to our example site on their Smartphone, chances are that they're looking to keep up to date, and they're probably not looking for a specific speech or a speech on a specific topic. Given that context, the content on the mobile site might look more like a Facebook profile page. The default home page should provide a quick update; using, say, "What's the president doing today" or "Where is the president speaking today" approaches. Maybe have a link to quote of the day, speech of the day, and topic of the day—each of these links result in a few quotes being served up.

So your responsibility during the planning phase is to advocate for good site design. Work with the customer to advocate for mobility-driven design on the sub-site.

An excellent resource for mobile web design concepts is Cameron Moll's book on Mobile Web Design.. Follow the principles in this book, and your team will be able to deliver a mobile site which provides the usability and context which will keep users coming back in droves!

About the author: John Overbaugh has 15 years of experience in product and project IT, focusing on quality and defect prevention, working with Microsoft Corp. and other companies.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.