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.
