UX Magazine

Defining and Informing the Complex Field of User Experience (UX)
Article No. 701 July 21, 2011

UX Concerns Across Mobile Platforms

Whether you’re developing applications for one specific mobile platform, or targeting multiple mobile operating systems, it is a good idea to become familiar with the established general user expectations for each device. This article discusses the importance of adhering to user expectations through these constructs, and describes some circumstances when deviation may be appropriate.

Desktop User Expectations

When working within a full desktop environment, the user has room to spread multiple applications across the desktop simultaneously. Application developers have the freedom to allow window functions such as minimizing, resizing, repositioning, generation of multiple windows, and so forth. These applications can also be tightly integrated into the operating system by associating specific file types, tapping into specific OS constructs like the Windows Taskbar, or notification tray, and request updates independent of any application store.

Desktop Experience: Windows vs. Mac

Before mobile was a real consideration for most people, there was always the concern for an adherence to certain user control paradigms when developing for specific operating systems. The most obvious of these differences, to most users, have to do with differences in the Mac OSX and Windows application controls.

Quite a big deal was made of these differences when Adobe released their cross-platform AIR runtime. AIR allows developers to build desktop applications which can run on Windows, OSX, and even Linux. This fact caused a stir among platform-specific UI purists (especially those familiar with the Apple Human Interface Guidelines) as application interface controls could take on a variety of forms due to the open nature of Flash UI design. There was a great fear that applications built using Adobe AIR on Windows could then be used on OSX and ruin the integrity of the unified Apple experience.

I’m a proponent of the idea that any experience, if done well, does not necessarily need to conform strictly to any specific guidelines. Though useful when considering the user experience, to dismiss anything which deviates from that restrictive path is probably not the most open way to approach new ideas.

How Mobile UX is Different

The mobile user experience is radically different than that of the traditional desktop, by necessity. Users generally have very small screens and therefore not a lot of room to work with. As a result, excepting Android Widgets, applications take up the entire screen. The user’s full attention is directed toward the running application with few distractions. A phone call could come in, or a notification may pop up, but most of the time, as a mobile application developer, you are guaranteed a captive audience.

Screen Paradigm

The fact that an application will fill the entire screen during the entire duration of an interaction is the single most important consideration for mobile UX. It frames any other decision that is to be made about the overall UI and flow of the application. Depending upon the platform, this may mean that while an application is active, additional applications have been dismissed to the background or closed entirely. The user is always focused upon one screen at a time, and methods for navigating these screens are often dependent upon whichever operating system is in play.

Unique Hardware

The most obvious difference between various mobile platforms is their differing hardware. Android devices have four buttons along the bottom or side, which include a home key, dedicated back button, dedicated options menu button, and search. The iPhone has one button. Tablet OS devices such as the BlackBerry PlayBook have a unique bezel through which a variety of gestures can be used, moving beyond simple button presses.

Gestures

On a desktop or laptop computer, the user generally interacts with the application by use of a mouse or some other traditional pointing device. With a mobile phone or tablet device, support for touch completely derails the concept of a single, clicking arrow, substituting fingertips, gestures, and sensors for the simple mouse pointer. This fact alone reshapes the entire interactive landscape when considering UX with these devices.

Addressing Concerns Across Platforms

I will discuss some of the more obvious differences between three major players in the mobile market at this time: Google Android, Apple iOS, and the BlackBerry Tablet OS.

One major difference across all three platforms is how option menus are handled. For iOS, there is normally a button within the application that allows the user to access application-specific menus. This is quite different on Android, as there is a dedicated menu button built into the device that can be programmed to reveal application options, normally via a menu at the bottom of the screen. With Tablet OS, a swipe from the top bezel will pull down or dismiss a set of menu options defined for any given application.

As a result, each of the platforms has an entirely different way of handling the same problem. Users on each platform expect to be able to access similar features in each app in similar ways, consistent with that specific platform. There is room for overlap, of course. The baseline is the iOS model you can simply render a menu button within the application UI of the other two platforms. However, this is not ideal on Android or Tablet OS and could alienate users of those specific platforms.

Also of concern is the styling of certain UI controls. A list control on Android often looks quite different than the same control on iOS. We encounter the same problem with an alert or any other standard control element such as buttons, scrollbars, etc. This is where decisions around skinning come into play. While not entirely necessary, it will aid the UX if the controls on your application look as though they belong to that particular platform, making the application friendlier to their predetermined sensibilities.

Why Adhere to Existing Paradigms?

When users have become familiar with a specific platform, they will expect certain behaviors when interacting with that device. Deviating from an established expectation can cause confusion for the user and lead to a frustrating experience, or even to total abandonment of the application.

It’s important to remember the importance of a first impression. This is as true for applications as it is for people. If you lose someone right off the bat because you force him into unexpected methods of interacting with the application, it will be difficult to win that user back, even with an update that fixes the issue.

When to Deviate from Existing Paradigms

Adhering to known user conventions is the safest way to approach UX, but it may not always be the best. At times, it may be worth the risk of deviating from the norm, either due to the uniqueness of some application process, or because it better establishes a connection with your user in a tighter way than the standard paradigm allows.

An example of this is the Swype keyboard for Android. Through this virtual keyboard replacement, the user simply performs gestures across what appears to be a normal set of keys for inputting text. The application interprets the intention of the user through these gestures and lays out a series of words. This method of type input is completely different from the normal style of use of mobile keyboards, which requires the user to peck at each key on the screen to form words. Given its nonconformity with the established user experience, Swype should be a total failure, yet it has become hugely popular and has proven itself, for some users, to be more efficient than traditional methods.

Last Thoughts

The best advice to those coming to a new platform for application development is to learn what makes the device platform different from others and to take advantage of that. Only deviate from established norms when it benefits the user in some way by making interactions better than they would be otherwise. When creating an application that will be installed on multiple platforms, be aware of existing user interface paradigms and work with them for each system. Skinning your controls for each device, while not always necessary, will add a touch of polish and may go that extra little bit to win a user’s appreciation.

ABOUT THE AUTHOR(S)

User Profile

Joseph Labrecque is primarily employed by the University of Denver as a senior interactive software engineer specializing in the Adobe Flash Platform. He is also the proprietor of Fractured Vision Media, LLC; a digital media production company, technical consultancy, and distribution vehicle for his creative works. Joseph serves as an Adobe Education Leader and Adobe Community Professional.

Add new comment

Comments

22
18

Hmmm actually looking at this guy's website and his skillset I don't think he's actually qualified to talk about UX.....shame on you UXmag.

25
19

I agree with your comment about how with mobile applications, a users attention is different than with the general desktop navigation experience. I think it would be great to clarify that you don't necessarily have a "captive" audience as there is generally a lot of stuff going on when I am utilizing my mobile phone and applications, but that generally a user's intent is different when using mobile applications. As Susan Weinschenk points out in her article, often times when you are surfing the web or looking at your applications on your phone, you are very goal oriented and looking for specific, time sensitive material. I think this is what you mean by captive, as in, the focus is different than when you have users surfing the web on their ipads or laptops. Great article though. We are doing a lot of mobile development and your article is very helpful.

19
20

"I’m a proponent of the idea that any experience, if done well, does not necessarily need to conform strictly to any specific guidelines."

Hear, Hear!

However, assuming this is a Brand-related experience, aren't guidelines particularly necessary, for consistency's sake, when existing across various spaces (e.g. mediums, platforms)? And does following those guidelines become increasingly more importance when the experience needs to survive in a greater number of spaces?

Also, can common DNA be found across quality experiences? The thought being that since they've adhered to certain protocols (consciously or not) they end up well done and (hopefully) successful.

-TK

22
25

Jean                                           

Dmitry, I have to disagree with your comments above. I am also appalled with the brash approach of your comment. I don’t think that you would respond to an article in this way if you were not able to hide behind a computer. Your comment not only stifles constructive comments and contributions to this publication, but it also attacks an established professional and author trying to create dialogue and to make the user experience community more informed. I would hope that you would not verbally attack a person like this in person if you did not like or appreciate their work, but rather to ask thought provoking questions and try to understand where they are coming from. Behaving with quiet confidence will always beat berating with obvious insecurity. If you are an expert on this subject then I would suggest that you write your own article and have that published. Good article Joseph

18
22

Dmitry Nekrasovski           The article seems to consist primarily of generic platitudes. How many paragraphs are really needed to express the idea that you should conform to platform conventions unless you have good reasons for doing so? The one example used by the author (Swype) is totally inappropriate for the point he is trying to make. The whole point of an alternate-keyboard app is to deviate from established OS guidelines - if it conformed to them, it would match the experience provided by the device's default keyboard. I also take issue with the author's claim that the differences between the experience offered by native desktop applications vs. those based on Adobe Air are only of concern to "platform-specific UI purists". There are well-documented examples of users of applications based on Air and other cross-platform development frameworks expressing a preference for native-like experiences. Some examples can be found in Alex Payne's excellent post Shortchanging Your Business with User-Hostile Platforms.

It's unfortunate that the author, as a Flash/Air developer, is not familiar with the UX drawbacks of the cross-platform development approach. Finally, statements like "as a mobile application developer, you are guaranteed a captive audience" make it pretty clear that the author has very little familiarity with the topic he writes about. I'd strongly suggest that a bit of time spent observing actual people using mobile applications, as well as reading work from actual experts in mobile UX (e.g. Josh Clark on microtasking) would have made for a more informed perspective.