Mobile Design Principles
The author accepts that there are fundamental principles of design that can be applied to any channel, but that there are also channel-specific concerns that may change the degree to which principles come into play.
One example of a principle that is of unusually exaggerated importance to the mobile channel is "Fitts's Law," which suggests that the difficulty of acquiring a target has to do with the distance and size of the target - the further away, and the smaller it is, the more difficult it is to hit, due to the distance the user must travel (physically reach) and the degree to which precision of control decrease as the hands are moved further away from the body.
(EN: Fitts's law was codified in 1954, well before the age of mobile, and was often used in the design of industrial machinery. There's been some argument over whether it applies to digital media, where the distance of a monitor is fixed and only the size of the target varies, but other research has backed up that the smaller a button or link is, the more time it takes for the user to hit it.)
MOBILIZE, DON'T MINIATURIZE
The practice of porting applications designed for the desktop computer over to a mobile platform by simply "shrinking" the UI almost always results in a "suboptimal" experience. And while some seek to make development more efficient by creating a single code-base to serve both platforms, the results are a reduction of quality in both places. An application must be designed for its delivery device - and this does mean developing two separate applications with similar functionality for the two different platforms.
Ultimately, the success of an application depends on user adoption, not the efficiency of the development process. And as users adopt an accept software that serves genuine needs in an easy-to-use manner, it follows that the needs and ease of use are significantly different in different channels: people do not want or expect the mobile experience to perfectly match the desktop experience.
In effect, "mobilizing" an application effectively requires a blank-slate approach that revisits the purpose of the application, nor merely re-skins it for a smaller device, and considers the needs and capabilities of he user in the mobile channel. Not all features of a desktop application will be desirable. And from a technology perspective, it often requires a completely different architectural approach for the application to be efficient and serviceable in the mobile channel.
The source of many differences between desktop and mobile is the carry principle: the device will always be with the user, which itself precipitates a number of implications for the design of mobile applications: a small size, one-handed use, variable environments, etc. Some of these principles are considered at greater length.
The most obvious implication is a small device size: users do not lug about physically large devices, and the small size means a small screen and limited input capabilities. As such, most devices are designed to handle one task at a time, with limited (if any) application switching capabilities. Typically, a device will preserve state when a call or instant message comes in, but will not run multiple applications at once or multiple instances of the same application (such as multiple browser windows). However, it's also typical for there to be a lag when switching.
The small screen is also an inconvenience for reasons other than application switching: legibility of text of small sizes, and in varying lighting conditions, is a common problem. The time required to render screen content is considered more of a nuisance in mobile. There is the problem of maintaining context when scrolling of paging through content, and the small amount of text forces users to read word-for-word rather than scanning.
One-handed mobile operation is another factor. In some instances, a user will employ both hands, or even set the device on a surface to do so, but this is not something they particularly enjoy. Applications that provide the same benefits via one-handed mobile operation generally win out over those that fail to do the same. It's also suggested that one-handed means one digit - the user's thumb, which is a bit of a thick and clumsy appendage. A stylus approach is an improvement, but this is again two-handed operation (the user must hold the device in one hand and the stylus in the other)
It's also noted that mobile applications are used in an interrupted manner. A user may be distracted often and need to stop and continue. Or he may be using the application covertly, such as under the table in a meeting - in which case they may not be looking at the screen while performing actions.
Even the best of devices, in the best of situations, are clumsy when it comes to text entry. Users prefer to type very little, and there will frequently be errors and typos. The author mentions predictive text entry, but that has so far been a terrible failure in terms of both accuracy and ease of use (the feature meant to be helpful often is obtrusive). While portable keyboards are becoming more common, it's unlikely they will become a standard input mechanism for mobile because they require the user to stop work and place the device on a surface, which is anti-mobile. A general bit of advice is to reduce the need to do text entry whenever possible, but be careful that the solution isn't more inconvenient than the problem.
The current trend in mobile devices is multi-purpose: competition among device manufacturers is presently focused on the number of blades in their Swiss Army knife, and customers generally seem to be tolerant and even encouraging of this, and will accept some loss or inconvenience of functionality for the sake of not having to carry multiple devices. The "universal" set that all devices provide and all users want has not been settled, but is being experimented by device manufacturers in different markets. In some instances, devices are designed to eliminate features users don't want - for example, there are devices that specifically eliminate the telephone for users who just want to do text messaging.
For application developers, their application will unlikely be the primary function of a device, but adds capabilities to what is primarily a communication tool (a phone or game console or music player). It unrealistic to expect the user to regard your software as the most important thing on their device, nor will device manufacturers accommodate your application over the intended main function, so you must accept that you will be an "also" capability that is unobtrusive and doesn't get in the way of the main purpose.
Each device has its own UI, and there is not much commonality, generally because it is driven by a manufacturer who focuses on the main capability and is not concerned with being standard for "also" features. Even the look-and-feel of common elements differs among manufacturers. Also, the device design will be derived from its primary purpose. The web browser on a portable gaming console works much differently than the web browser on a portable phone.
There's also a bit on manufacturers' desire to "patent" certain technologies to create a preference for their particular device, which further balkanizes the user experience and makes it less likely for a common set of standards to evolve. There is also some attempt for manufacturers to exert control by means of restricting device capabilities - such as Apple's refusal to support Adobe Flash on its devices (ostensibly for security reasons, but pushing their own technologies such as QuickTime is likely a motivating factor).
But at the same time, manufacturers seem to gravitate to accommodate common practices that are derived from the design of one manufacturer. The example given is the Nokia options/back soft-key that is being adopted by other manufacturers because the users have learned to use it on Nokia phones and are likely to find their product less usable if they must learn a new key.
Mobile is used for small tasks that are frequently performed. Buying or selling a stock may be desirable, but rebalancing a portfolio of investments is unlikely to be something that is simple or done often enough for users to desire a mobile capability.
It's reiterated that the mobile device is considered to be personal - used by a single person rather than shared with others, and as closely guarded as a person's wallet or house keys. Certain security needs from the desktop world - such as the need to mask password fields, expire cookies quickly, or store personal information - are not relevant. You can more safely assume the device is personal and secure.
Users tend to customize their phones with external skins or cases, face plates, ring tones, wallpapers, etc. Some devices are moving to enable the user to set UI "themes" that dictate the visual appearance. This requires consideration in the design process: if an icon is black, it may disappear if the user sets the theme to be white text on a black background.
The "always connected" principle is fairly widespread, to the point that users often report feeling a sense of detachment when their device is not accessible, but neither should this be overestimated: the device is always at hand, though not always in hand, and the willingness of a user to give the device immediate attention varies.
Social acceptance of mobile phones varies. There are few places one can escape from mobile phone intrusion. While there are some locations where it's largely inacceptable to use a mobile device (a restaurant, theater, church, elevator, etc.), this stigma is attached almost exclusively to voice communication - text communication draws fewer objections.
Battery power is also a consideration. Power consumption is more acute for some devices/activities (video players and gaming), so users may choose limit their use of video-rich applications. The duration of charge has largely been addressed for most purposes, but there are still power-conserving conventions (such as dimming the screen after some period of activity) that must be considered. And in terms of "always connected," users generally disconnect to charge their devices - it's fairly common for a person to place their device on a charger any time they are at home (though for some, its' only when they are asleep).
Network connectivity also interferes with being "always on." Even within developed nations , there are still many dead zones, and physical barriers (being in an elevator, a basement, a tunnel, or "deep" inside a large building) still prevent network access. Worse than complete lack of access is temporary outage - a user who passes under a bridge or steps into an elevator may lose connectivity for a few seconds, which may interfere with connectivity (and even cause an application, such as a web browser, to display an error and then restart on the home page).
(EN: The author doesn't mention locations in which mobile usage is utterly forbidden, such as in an airport, a courtroom, or a secure facility. Neither does she mention the desire of certain parties to create mobile-free zones - while the practice of "jamming" signals by electronic means has been criminalized in some countries, there are others where jamming is supported or practiced by government, and I expect that the desire to intrusively address the problem may not be altogether gone.)
USER CONTEXT
Aside of the device, another important consideration is the user's physical environment. For a desktop computer, it's understood that the device is sued in an office environment (controlled conditions), and even a laptop computer is used in certain kinds of situations - the user goes to a specific place, unpacks the device, and uses it. Mobile is much more varied.
Ideally, a mobile device could "know" where it is being used and adjust accordingly - by some combination of GPS, light meter, and microphone, it could know whether it was indoors or out, in bright light or shade, in a noisy or quiet location. However, the devices simply are not yet that "smart."
In terms of application development, it's presently unheard of for an application to attempt to do the same. More likely, the designer makes some educated guesses about the typical user environment and designs his application according to where the user is expected to be at the time he uses it.
However, context is often used in a more functional way: to determine where the user is located, and what time it is in that location, to deliver information that is germane: a user in a city at noon could see restaurants near their location that are open for lunch. And this is becoming more of an expectation than a convenience.
HANDLING DEVICE PROLIFERATION
From the developer's perspective, device proliferation is concerned with the many different devices, either for multiple users or a single user who upgrades or changes his device, where devices are constantly changing and there is no standard platform or set of capabilities that is universally supported.
The author describes four basic approaches:
- Targeted Development - Seeks to develop an application for a specific device or set of devices, to the exclusion of all others. This minimizes the size of a market, but maximizes the value that can be delivered.
- Least Common Denominator - Selects a number of technologies supported on various devices, then eliminates development techniques that will only work on some of them, to arrive at a plan that should suit most devices
- Standards-Based - Adheres to a set of industry-specified standards, with the hope that all devices that support those standards will run the application
- Class-Based - Chooses a specific technology (e.g., Java) and the programming classes that are understood to be run on the targeted devices (EN: though "targeting" would probably still be LCD or standards based)
The author explores each of these approaches in a bit more detail:
Targeted Design
The targeted approach works well in an environment in which a small set of devices is used by the intended user base. The primary example an internal development team developing for users with company-issued mobile devices, where the devices are selected and upgraded by the company in an organized manner.
The chief benefit of this approach is the ability to do deep integration with the platform capabilities, which are well known, in order to provide broader functionality and a more predictable user experience. Meanwhile, the drawbacks are that the application has a limited lifespan (when the device changes or upgrades) and a small potential user-base.
Upgrades are a specific concern: being completely locked out of an application is less of a negative experience than have it seem to perform properly and then misbehave.
(EN: This is more common than the author seems to let on. There are a number of independent developers and studios who build applications that are exclusive to the iPhone, Blackberry, or Android phone. There's a large enough user base for them to be profitable, and having an "exclusive" application is a boon to the device manufacturer.)
Least Common Denominator
Building for the lowest common denominator has a precursor on the Internet itself. Since the very beginning, different manufacturers provided different capabilities, and the common practice has been for Web designers to select which versions of which browsers to support, and build to their common capabilities. In spite of this practice, and attempts by various groups to define the capabilities of "the Web," it has not been entirely successful, and compatibility of a site to popular browsers waxes and wanes.
In spite of its failure, there is an attempt to transport the same practice to the mobile platform, which is even more Balkanized than the Web. And while some "standards" are emerging, they are poorly supported and offer a very low level of capabilities when compared to the Web browsing experience, and the notion of graceful degradation is a complete disgrace.
The source of the problem is in each manufacturer's attempt to build a device that is tailored to the needs of various users. To do so requires the manufacturer to adopt a specific technology platform that provides the capabilities and features that best suit their target market's need - and to adopt a standard for the sake of compatibility would undermine their ability to focus their device in this manner.
(EN: I suspect this is subterfuge and the real motivation is not as innocent. There is merit to the argument that manufacturers purposefully make devices incompatible in order to force customer loyalty by setting up a situation where a user who wants to switch to a different phone must also abandon all his software and data. As such, they will accept a less appealing device for the sake of keeping their old files and applications. This is not unique to the mobile channel - switching between a Microsoft PC and an Apple Macintosh computer has long been effectively discouraged by the same means. I wouldn't entirely side with the type who suggest that evil intent is entirely to blame, but I don't think it should be dismissed as a factor.)
Developers are also keen on this approach because it is assumed that standards will be adopted from other channels, hence they can write one application for the desktop and merely port it over, with few changes, to the mobile environment. However, as has been stressed, this is a very bad practice. The content, features, and information architecture should be different, to suit the specific needs of the user in this channel.
5.3.3 Automatic Translation
As more back-end systems are going "open source", there is a trend for software developers of all walks to seek to exploit standards. A prime example of this is the use of XML for database design: rather than building an application to read a specific proprietary database format, most applications are adopting XML as a standard for data. This enables them to rapidly develop a stand-alone application, a browser-based Web interface, and even a mobile application that share (read/write) the same data source.
Another example is SGML, the GUI-design markup standards from which HTML was excerpted. The author of an application need not worry about how to render a "radio button" on the user's screen, but merely use a standard tag to indicate a radio button and the software on the local device would determine its actual appearance.
Naturally, the problem becomes that the rendering is not controlled and may not be predictable. That, in effect, one manufacturer's interpretation of what a "radio button" should look like may not be compatible with what the standard expected it to be, and the layout would break. Or if the manufacturer decided not to support this tag, any application that required a radio-button selection would be unusable.
These problems are much more pronounced on mobile devices than they ever were on the WWW. As such, developers cannot count on universal support of nominal standards, and the choice of standards-based development degenerates back into lowest common denominator, as the developer must select versions of the standards supported by specific devices.
Class-based Design
Class-based design takes the notion of automatic translation a step further, from the format and display of information to the functions available for writing code. In the simplest sense, class-based design attempts to develop a core programming language across all platforms, such that the developer can call a given class to perform a specific operation, on any of a number of devices.
The author goes into much detail, but the problems are similar: not all devices support the same functions in the same ways, and the developer must select a certain level of support required for his application as a lowest common denominator and design to suit. However, when it comes to programming functions, the restrictions that are placed on developers are far more hampering than mere cosmetic defects.
EMULATORS AND SIMULATORS
The author mentions that there are software applications that emulate or simulate the capabilities of a device, which enable developers to build and test code without having to load it onto an actual device.
Such applications should be approached "with great caution" for a number of reasons - which all boil down to one thing: they aren't accurate reflections of the real thing. Code that works in a simulator will not necessarily run the same way on the actual device. User behavior using a n emulator on a computer screen is significantly different than user behavior holding a device (and it cannot be done in a realistic environment).
As such, simulation can be useful in the coding process, as developers draft their code and test them on the fly - but system testing, unit testing, and user acceptance testing should be done on the actual device.
DETAILED DESIGN RECOMMENDATIONS
Discussions in this book are necessarily of a general nature. The author provides references and links to more detailed information in other sources, in four categories:
- Carriers Device Manufacturers - Likely the most detailed and reliable information comes from the manufacturers of devices and certain carriers (in some instances, a model of phone will be made for a specific carrier, and documentation and support provided by the carrier rather than the manufacturer)
- Platform Providers - Platform providers are the second most accurate source of information, though they are limited to being able to indicate how a given technology is supposed to work, not how it actually does work on a specific device. (EN: A good example of this is that PERL is a common language, but development techniques are different if you are developing PERL for a Windows computer)
- Standards Organizations - These organizations are often cooperative alliances among multiple manufacturers. Like platform providers, they are limited to indication how things should work, rather than how they do. It's also not uncommon for standards groups to attempt to pursue their own agenda and trying to define standards they wish companies to follow.
- Third-Party Guidance - In some instances, an independent third party will attempt to provide guidance. This may include a person who writes an independent manual, or even an informal group of developers sharing information to help one another along.