On 9th January, 2007, Apple officially launched the iPhone, and the world of user
interface design shifted. While tablet PCs had been around for a while, the iPhone was
the first device to give so many people a portable touchscreen, and people loved it. Just
over a year later, Google and the Open Handset Alliance announced Android which in
many ways is the direct competitor to iPhone.
What is it about touchscreen phones that we love? The answer is simple—feedback.
Touchscreens offer a way to directly manipulate on-screen objects, which in the past had
to be driven through a keyboard, mouse, joystick, or other input device. The touchscreen
model of direct manipulation has a large impact on the way we think about our user
interfaces as developers, and changes the expectations a user has for the application.
Touchscreen devices require us to stop thinking in terms of forms, and start thinking
about object-oriented user interfaces.
Android is used as the primary operating system for a rapidly expanding range of
consumer electronics, including:
• Smartphones
• Netbooks
• Tablets
• Some desktop systems
While all of these devices have different purposes and specifications, all of them run
Android. This is unlike many other operating environments which are almost always
have a special purpose. The services and the APIs they provide to developers generally
reflect their target hardware. Android on the other hand makes the assumption that a
single application may be required to run on many different types of devices, with very
different hardware capabilities and specifications, and makes it as easy as possible for
developers to handle the differences between these devices simply and elegantly.
New challenges
As Android and the touchscreen devices it powers become increasingly common, they
will bring a new set of challenges to user interface design and development:
• You generally don't have a mouse
• You may have more than one pointing device
• You often don't have a keyboard
• Any keyboard that does exist may be a software keyboard
• A software keyboard may consume some of your application's screenspace
The software keyboard reduces the amount of screen space available to your application,
and in much the same vein, if there is a hardware keyboard present it may or may not
always be exposed to the user. Therefore, not only are different Android devices
different, but they may also appear to change features while your application is running.
The rule of finger
Most Android devices have touchscreens (although this is not a requirement). The first
restriction placed on any touchscreen user interface is the size of the human forefinger,
which of course varies widely from one person to another. If a widget is too small on the
screen, it won't be clear what the user is trying to touch. You'll notice that most Android
widgets take up plenty of space, and have more than the normal amount of padding
around them. On a touchscreen device, you can't rely on pixel-perfect precision. You
need to make sure that when the user touches a widget, they make contact, and they don't
accidentally touch another widget.
The magic touch
Another impact touchscreens have on user interface design is that an application and all
the widgets that it uses must be entirely self-explanatory (even more than usual). Far too
often, we substitute good user interface planning and design with a roll-over or tooltip to
indicate a widget's function. On a touchscreen device, there is no mouse or pointing
device. The first interaction it has with the user is when they touch it, and they will
expect something to happen.
A touchy subject
Most Android devices have a touchscreen, but it's not a requirement.
The quality of a touchscreen also varies wildly from device to device.
The category of touchscreens and their capabilities will also vary from
one device to the next, depending on the intended use of the device and
often its intended market segment.
A smaller view on the world
Most Android devices are small, and as a result have smaller screens and generally fewer
pixels than a normal PC or laptop. This lack of size limits the size of the widgets.
Widgets must be big enough to touch safely, but we also need to pack as much
information onto the screen as possible. So don't give your users information that they
don't want, and also avoid asking them for information you don't need.
Classic user interface principals
Here are some core guidelines which every user interface should follow. These guidelines
are what will keep your users happy, and ensure your application is successful.
Throughout the rest of the book, we'll be walking through these guidelines with practical
examples of improvements that can be made to a user interface.
Consistency
This is the cornerstone of good user interface design. A button should look like a button.
Make sure that the layout of each screen has a relationship with every other screen in
your application. People often mistake this principle for "stick to the platform look and
feel". Look and feel is important, consistency mostly applies to the layout and overall
experience of the application, rather than the color scheme.
Recycling your interface
The easiest way to maintain a consistent user interface, is to recycle as much of it as
possible. At first glance, this suggestion looks merely like a "good object-oriented"
practice. However, a closer look will reveal ways to reuse graphical widgets in ways you
hadn't thought of. By changing the visibility of various widgets, or you can reuse an edit
screen to view list items of the intended type.
Simplicity
This is especially important in a phone-based application. Often, when a user encounters
a new application, it's because they are looking for something. They may not have the
time (or more often patience) to learn a new user interface. Make sure that your
application asks for as little as possible, and guides the user to the exact information they
want in as few steps as possible.
The Zen approach
Generally, when you are using a mobile device, your time is limited. You may also be
using an application in less-than-ideal circumstances (perhaps, in a train). The lesser
information a user needs to give an application, and the lesser they need to absorb from it,
the better. Stripping away options and information also leads to a shorter learning-curve.
Android's hidden menu
A very useful feature of Android is the hidden menu structure. The menu is only visible
when the user presses the "Menu" button, which would generally mean, they're looking
for something that isn't currently on the screen. Typically, a user shouldn't need to open a
menu. However, it's a good way of hiding advanced features until they are needed.
Feedback
Feedback is what makes a touchscreen device exciting. When you drag an object, it sticks
to your finger across the screen until you let go of it. When the users puts their finger on
your application, they expect some reaction. However, you don't want to get in their
way—instead of showing an error message when they touch a button, disable the button
until it's valid to use, or don't show it at all.
Location and navigation
When you're in a place you've never been to previously, it's easy to get disoriented, or
lost. The same is true for a piece of software. Just because the application makes sense to
you, the developer, it doesn't mean it seems logical to your user. Adding transition
animations, breadcrumbs, and progress gauges help the user to identify where in the
application they are, and what's happening.
The road to recovery
A common way to tell users that something is wrong on a desktop application, or on the
web is to open an error dialog. On a mobile device, people want smoother use of an
application. While in a normal application you may inform the user that they selected an
invalid option, in a mobile application, you generally want to make sure they can't select
that option in the first place. Also, don't make them scroll through huge lists of options.
Instead, allow them to filter through the list using an auto-complete or something similar.
When something goes wrong, be nice, and be helpful—don't tell the user, "I couldn't find
any flights for your search". Instead tell them, "There were no available flights for your
search, but if you're prepared to leave a day earlier, here is a list of the available flights".
Always make sure your user can take another step forward without having to go "Back"
(although the option to go backwards should always exist).
The Android way
The Android platform is in many ways similar to developing applications for the web.
There are many devices, made by many manufactures, with different capabilities and
specifications. Yet as a developer, you will want your users to have the most consistent
experience possible. Unlike a web browser, Android has built-in mechanisms for coping
with these differences, and even leveraging them.
We'll be looking at Android from the point of view of a user rather than having a purely
development-centric approach. We'll cover topics such as:
• What user interface elements Android provides
• How an Android application is assembled
• Different types of Android layouts
• Presenting various types of data to the user
• Customising of existing Android widgets
• Tricks and tools to keep user interfaces looking great
• Integration between applications
We're about to take a jump into building user interfaces for Android devices—all
Android devices, from the highest speed CPU to the smallest screen.
No comments:
Post a Comment