Five Mistakes to Avoid in Creating User Interfaces for Mobile Devices

Altoros Systems, Inc. October 15, 2008

Handbook and Tips: Five Mistakes to Avoid in Creating

User Interfaces for Mobile Devices

Abstract:

When creating a mobile user interface, developers inevitably face a number of

challenges. Most of them are caused by the difference in developing user interfaces for

mobile and desktop applications. This white paper will explain how to create an effective

user interface for mobile devices and avoid the most common mistakes.

By Michael Fedotov, Alex Khizhnyak,

Renat Khasanshyn

Five Mistakes to Avoid in Creating User Interfaces for Mobile Devices

of 12

Altoros Systems, Inc.

Table of Contents

1. Executive Summary 3

2. Mistake #1: Poor Data Structuring and Ineffective Usage of Space 3

3. Mistake #2: Ineffective Navigation 6

4. Mistake #3: No Screen Resolution Optimization 8

5. Mistake #4: Overloading Mobile Hardware Resources 10

6. Mistake #5: Ignoring the Specific Technical Features of Mobile Devices 10

7. Short Summary 11

8. About the Authors 12


of 12


1. Executive Summary

Every mobile application developer inevitably faces a number of serious challenges. Most

challenges are caused by the drastic difference between developing user interfaces (UI) for

mobile and for desktop applications, which is why even experience with one does not guarantee

avoiding mistakes with another. The main factors that influence these challenges are the natural

limits of mobile hardware resources, smaller screen resolutions, and so on. Typically, mistakes

that developers make when creating mobile UIs are of the kind that is a lot easier to prevent

than to fix post factum, since in practice ‘fixing’ them means rewriting certain fragments of the

interface entirely.

This white paper identifies the five mistakes most commonly made by mobile UI developers.

The research was created as the result of trial and error during several years of mobile

application development at Altoros Systems, a global service provider specializing in mobile

development for software companies and interactive agencies. This white paper will explain how

to avoid the most common mistakes, and how to ultimately create an effective user interface.

2. Mistake #1: Poor Data Structuring and Ineffective Usage of Space

Creating effective user interfaces is only one half of a

developer’s work. In fact, it is the most crucial part of the work

that has to be carried out before development proper, in the

stage of business analysis and designing the UI. Remember

that poor user interface design can hardly be compensated for

by developer effort.

2.1 Control positions and names

Data fields and other controls should be thoughtfully

structured; their positions on the screen have to be defined at this early stage, so as to avoid

difficulties in the process of development. Texts and captions also have to be well thought out,

aspiring to as much brevity as possible. For example, Full Name is preferable to User Full Name

because it is shorter and, therefore, saves considerable screen space.

Also, think about acronyms that could be used instead of full words, but remember to keep them

intuitive.

2.2 Using icons

Using intuitive icons is another good way to save screen space. Not only is an icon smaller than

a text inscription, it can also be more informative, as long as it is really intuitive (and achieving

“Poor user

interface design

can hardly be

compensated for by

developer effort.”


of 12


that requires effort). Icons should be implemented in several sizes (16x16, 32x32, 48x48,

64x64) and two color modes (16 colors and 16-bit color) to ensure that they look sharp on all

screens. The small size of icons, however, is not a reason to cram the screen with them. Per-

screen quantity regulations (see below) apply to icons just as much as any other controls.

2.3 Grouping items into tabs

Grouping controls into tabs is also something to think over carefully. Grouping should have clear

and logical criteria, so that users have no problem finding what they are looking for, and do not

find themselves in the disconcerting position of having to repeatedly fill in consecutive fields that

have little or no relationship between with one another (putting a University Major field right after

a First Name field, for example).

Figure 2.1. Field distribution between tabs

Source: Altoros Systems, Inc.

For mobile devices, distributing controls between tabs adequately is especially important, as

controls distribution is the ultimate way out of the scarce screen space problem.

2.4 Using screen space efficiently

It is important to make use of the whole screen space. Literally,

you should try to use every pixel. This means no unnecessary

graphics, borders, etc. On the other hand, overloading the

screen with controls is also something to avoid. Not only does it

cause difficulties with the perception of the screen contents by

users, it also makes navigation inconvenient.

“Grouping related

menu items into

sub-menus can

help save space

considerably.”


of 12


2.5 Allowed numbers of controls and recommended sizes

Ten is considered the upper limit of controls that can be displayed on the screen at the same

time. If there are 11 or more controls, we recommend reducing the number of controls per

screen. It is a good idea to put no more than three controls in a row and a maximum of two

multiline blocks on a page. Typically you want to avoid putting scrollbars on data control groups.

If there are more than three tabs, using multi-tab navigation is recommended.

The name of a control that cannot have a label on it, such as an input field, should be put to the

left of the control and aligned right. We suggest that the distance between a control and its

name is 5 pixels.

2.6 Menus and sub-menus

Grouping related menu items into sub-menus can help save space considerably and create a

more convenient user interface. On the other hand, it is important to keep this within reasonable

limits: make sure your navigation does not get cumbersome due to numerous nested sub-

menus. We recommend that every menu contain no more than seven items. We suggest that

the height of every single item is 30 pixels.

Figure 2.2. Menus


2.7 Zoning

To achieve maximum efficiency of screen space usage, zoning is a good approach. Divide the

screen into several areas of fixed height and assign a specific function to each of them.

In one of our projects, for example, we zoned the screen (of 320x240 resolution) like this:


of 12


Figure 2.3. Zoning


All of the zones had fixed height.

We used Zone A for the Windows Navigation Panel.

Zone B was used to display the data control group.

The functioning of Zone C depended on the mode that was used:

In what we called the TabNavigation mode, Zone C was where tabs were displayed.

In the MultiTabNavigation mode, it displayed tabs and additional buttons.

In the ButtonNavigation mode, buttons were displayed in Zone C.

Finally, zone D was used for displaying application control buttons in different modes.

3. Mistake #2: Ineffective Navigation

There are three main means of navigation: using the

keyboard, stylus, or fingers.

One of the fundamental principles of building a mobile user

interface is to minimize switching. Ideally, a user should be

able to stick to just one method of navigation all the time.

Using a stylus is not recommended, since taking out the

stylus and putting it back, is not always convenient. Many

mobile devices do not have keyboards—on the other hand,

“There can be

nothing worse

about a UI than if it

causes a user to

make several

attempts to hit a

button.”


of 12


not all of them support touch navigation, either.

Thus, if your mobile application is not oriented to a specific group of devices or intended for

special usage that sets its own requirements to the user interface, it is a good idea to enable the

support of both keyboard and touch navigation. At the same time, a user should be able to stick

to one way of navigation without having to switch to another.

Just as crucial as that, is to make sure that the size of controls is adequate for touch navigation.

There can be nothing worse about a UI than if it causes a user to make several attempts to hit a

button. Research shows that on a 2" QVGA screen 29 pixels is the smallest height and width for

a button to be easy to hit. Also, never forget about the distance between controls: it should be

there to prevent mis-hits. Avoid creating large gaps, however: we recommend that spacing

between controls does not exceed 10 pixels.

If your application has a menu, the menu should be assigned to the right soft key. The left soft

key is typically for quick (common) actions, such as New. If a second menu is used, it can be

assigned to the left soft key.

Gesture navigation is a technology that any mobile application could benefit from, provided the

implementation is smart enough. Messages from gesture navigation should be processed on

the top level and forwarded using the cascade mode to lower levels (parent to child).

Figure 3.1. Night mode


Another thing that is worth considering, is implementing a night mode. Color perception is

greatly dependent on light conditions; when there is little light, the human eye perceives dim

colors better. In night mode, therefore, the gamma should be dimmer, which enables the user to

work comfortably during nighttime.


of 12


4. Mistake #3: No Screen Resolution Optimization

There are several standards of screen resolution for mobile devices. Usually, an application

developer would want to support as many devices with a compatible operation system as

possible, and to do so, the developer has to optimize their application for all standard screen

resolutions. It is advised that any mobile application supports these resolutions: 240x320,

320x240, 240x240, 320x320, 480x640, 640x480, and 480x480.

Unless the specifications of the project require something different, we recommend the creation

of layouts for QVGA screens that would be supported on VGA devices. A layout initially created

for a QVGA resolution should work on VGA resolutions; a layout initially created for a VGA

resolution is not guaranteed to work on QVGA resolutions.

When we used zoning (see chapter 2) for one of our applications that supported QVGA, zone B

was sized 240x240. If running on a device with a 240x240 px screen (and using zoning), zone C

was hidden in our applications, as well as the navigation panels. They opened and were

available for work upon clicking and holding.

Figure 4.1. Zoning in 240x240 resolution


For devices with high screen resolutions (such as 800x600 and higher), we recommend creating

a different user interface, based on the same design elements as the smaller version, but

making use of the large screen space such devices have to offer. High screen resolution means

more space to display information, which is a considerable advantage over smaller resolutions.

The number of controls that can be put on the screen increases, but in no way does this enable

a developer to overload the screen with controls. The number of controls is still limited for high

resolution screens; the limit is just different.


of 12


Figure 4.2. User interface design on a high-resolution screen


Control layouts should be anchored and resized/moved when the window is resized. That will

allow using one application for both QVGA and VGA-type resolutions.

Most UI-friendly applications support portrait, landscape, and square screen modes. This will

enable the application to run and will make it more convenient to use on mobile devices with

screens of all types.

If target devices are likely to be used in different orientations (landscape and portrait), it is wise

to consider implementing dynamic changing of the view. Surely there are some obstacles to it,

such as the necessity to rearrange the controls, treat scrollable elements, etc., but, if the

implementation is done carefully, it can be quite a clever stroke.


of 12


5. Mistake #4: Overloading Mobile Hardware Resources

The scantiness of hardware resources affects mobile application development considerably. In

fact, effective use of hardware resources becomes one of the primary goals of a developer.

This means that one should not get overenthusiastic about adding animations, rounded corners,

and other decorative features to the application. In fact, we recommend avoiding them

completely. Customers pay—first and foremost—for functionality and efficiency. The customer

can hardly consider an application effective if it does not run smoothly because it is packed with

visual effects. With the right approach, it is absolutely possible to create an efficient and nice

looking mobile application without resource-consuming visual effects.

Another example: there are no mobile devices whose screens

can display more than 65,536 colors. This means that storing

pictures with the color depth of 24 or 32 bit is pointless. All it

accomplishes is the consumption of more resources.

For a mobile application to run smoothly, it is important that the

balance between caching and calculating on request is

maintained. The former consumes RAM; the latter, CPU

resources—and in mobile devices both are quite limited. If

your mobile application is relatively resource-consuming, the

only way to optimize its performance is to find and maintain the

balance between CPU and RAM usage.

6. Mistake #5: Ignoring the Specific Technical Features of Mobile Devices

A mobile application developer has to keep in mind that different models of mobile devices, as

well as different versions of operating systems, have their own specific features. Ironically,

although the aim of a developer is to make his or her project as universal as possible, to

achieve that he or she has to keep in mind the peculiar features of the different systems the

application may be run on. More precisely, the developer must not just keep them in mind, but

optimize the product, so that the difference between models does not become a hassle to the

application functioning on any compatible device.

Internet connection. For example, a mobile application can connect to the Internet in a

variety of ways: via Wi-Fi, Bluetooth, GPRS, ActiveSync, etc. A mobile application

developer should provide for all of these, instead of implementing just one means of

connection.

Modal and modeless forms. Another thing to be aware of is that if a modeless window

of a mobile application loses focus to another window, there is no opportunity for the

user to retrieve it. Therefore, a mobile application absolutely should use modal forms for

the main application form, messages, and every form that has input controls, in order to

exclude the risk of focus being lost. An application can use modeless forms, however,

but either all these modeless forms have to be moved to the top when the main form is

“If a modeless

window loses focus

to another window,

there is no

opportunity for the

user to retrieve it.”


of 12


activated, or a form management subsystem should be implemented, in which all

modeless forms are children of the main form or its children.

Operating systems. Ideally, a mobile application for an operating system of a certain

version should work on all devices supporting this operating system, as long as the

application is not intended to be used on mobile

devices of a specific model.

Most popular mobile applications for Windows

support the following operating systems: Windows

Mobile 5.x, Windows Mobile 6.x, and Windows CE

5.x. Testing them on a wide range of devices is

recommended to ensure their maximum

workability on different types of mobile devices.

7. Short Summary

To recap, the five most typical mistakes that mobile application user interface developers

make are:

1) Not giving enough consideration to the structure of a user interface before actually

starting to develop it; creating a structure that is initially ineffective owing to unwise

space usage (putting too many controls on the screen or leaving too much empty

space) and poor logic in distributing controls between tabs.

2) Creating navigation that is inconvenient or ineffective (i.e. requires switching

between means of control, such as keyboard, stylus, and touch screen); making

controls too small or too closely spaced to each other to hit easily when using

finger navigation.

3) Ignoring the fact that a user might run the application on a device with a screen

resolution different than the one on the developer’s device, and, therefore, not

optimizing the application for different resolutions and orientations (portrait,

landscape, square screen mode); not implementing support for devices with big

resolutions.

4) Overusing the mobile devices’ hardware resources by not regulating the balance

between caching and calculating on-demand, implementing unnecessary design

elements, etc.

5) Not ensuring the application’s compatibility with the maximum number of mobile

devices possible; ignoring specific features of different devices.

Avoiding and fixing the foregoing mistakes can be a very hard thing to do, sometimes it is

practically unfeasible. Looking out for them, however, is imperative for every mobile application

developer who wants his or her UI to be truly user-friendly and convenient. Otherwise,

developers risk ending up with a user interface adopting poorly.

“One should not get

overenthusiastic about

adding animations,

rounded corners, and

other decorative

features.”


of 12


8. About the Authors

Michael Fedotov is Technology Evangelist at Altoros Systems, Inc. and has been working as a

freelance journalist for a number of IT-related periodicals since 2003, covering next to all

aspects of IT, and specifically software developments, in an abundance of articles. He has

taken part in several scientific conferences and provided service for many more participants

creating and holding their presentations. He also has experience working as an interpreter and

presently is studying Japanese.

Alex Khizhnyak is Chief Evangelist at Altoros Systems, Inc. and co-founder of the Belarus Java

User Group. Since 1998, he has gained experience as an author, editor, media specialist, event

manager, conference speaker, and blogger. So far, his educational background combines IT,

programming, economics, and journalism.

Renat Khasanshyn is the founder and CEO of Altoros Systems, Inc. Mr. Khasanshyn speaks

frequently at a wide range of events, and most recently was selected as a finalist for the 2007

Emerging Executive of the Year award by the Massachusetts Technology Leadership Council.

Prior to founding Altoros Systems, Mr. Khasanshyn was VP of Engineering for Tampa-based

insurance company, PriMed, Inc. Mr. Khasanshyn is a co-founder of the Belarus Java User

Group and studied Engineering at the Belarusian State Technical University.

Altoros Systems, Inc. is a global software delivery acceleration specialist that provides focused outsourced

software product engineering, independent Quality Assurance, and testing services to software

organizations and information-driven enterprises. Founded in 2001 and headquartered in Sunnyvale,

California, Altoros has representative offices in Western Massachusetts and Norway. It manages a

software development center in Eastern Europe out of its offices in Minsk, Belarus. For more information,

please visit www.altoros.com .

http://www.altoros.com/

Five Mistakes to Avoid in Creating User Interfaces for Mobile Devices

Technology

Transcript of Five Mistakes to Avoid in Creating User Interfaces for Mobile Devices