Designing for User Experience, Power, and Performance on Tablets

This document is written from the perspective of an application designer and author. My goal is to provide the application designer and User Interface designer with suggestions and ideas to consider, along with guidelines for ways to deal with these issues. This is not a formal “must do” list of specifics for a destination OS, but a healthy dive into some of the hardware and software issues to deal with in the mobile market.

The design of User Input methods and processes needs to account for the hardware that the application is designed to run on. Given that we want our apps to run on a wide variety of hardware designs, these guidelines will help by giving you issues to consider when working out your User Interface and overall user experience. These are actual issues we have addressed in the last few years when working with application vendors to adapt their software to Intel hardware.

Hardware Realities

Understanding that the hardware we are using for mobile applications is different in many key ways will help us as we adapt existing software to the mobile platform.

First, a list of questions the application designer should answer as he formulates his User eXperience (UX). With these questions answered you’ll be able to better deal with the additional issues addressed below.

  1. Are you starting with an existing application and adapting it, or will you be designing your application from the ground up around a target device?
  2. Are you designing your app for a specific market? Tablet or Handset?
  3. Will you use the standard input methods as provided by the hardware, or will you adapt to include other new methods (swipe for example).
  4. Do you know what all of the supported sensors are for the destination hardware? When you know them, determine which you will support now, and in the future.
  5. Does the hardware support finger touch, stylus or both?
  6. Which language and tools will you use to develop your app? Verify that the sensors and methods you need are supported via those tools.


Once you gather the answers to the above questions you need to look at your UI and consider how it will adapt to a Tablet form factor. Due to the touch screen display, you should account for accidental actuation. While verifying choices can be a distraction, how will your users account for accidents such as “pocket dialing”? Make sure that the size of the selection target area is large enough for touch usage. Will the users be able to correctly select the desired item? 10mm is the recommended hit area for touch UI.

Here’s a list of issues to consider along with suggestions for handling those issues.

Issues and Recommendations

Less usable screen space than a desktop

  • Eliminate unnecessary UI components, use the full screen.
  • In some cases items, some elements such as dialogs may be restricted by the screen size.
  • Make close buttons, minimize buttons, and other static UI transparent, with the goal of giving yourself as much usable screen space as possible. Of course some of this can be different based on the destination OS you have in mind. Some of these issues are also out of the application’s control.
  • Avoid screen edges and corners, as selection areas, they are more difficult to select with fingers.
  • Make sure the users can access the UI on devices with different screen resolutions.
  • Anchor dialog boxes to the top and left, as opposed to the center of the form. This can be helpful as a way to adapt to varying screen sizes.

Dialogs don’t fit on the screen

  • Consider wider dialogs; design your interface to keep dialogs small.
  • Dialog boxes tend to be tall and narrow; design to take advantage of the wider screen.

Screen not large enough to present data

  • Use vertical scrolling with controls large enough to facilitate usage.
  • Vertical scrolling is preferred over horizontal scrolling in most cases.
  • Scrolling up, down, left, and right makes an application hard to use.

Interface needs additional input

  • Use hardware buttons for most desired functionality.
  • Whenever possible use the hardware provided for maximum benefit.

Accidental activation

  • Buttons need to be large enough for both finger and stylus input? Which will you be using?
  • Provide a way for users to back out of any accidentally selected option.

Additional navigation desired

  • Use on screen navigation controls. Make them large enough to use and select

Physical screen sizes and resolutions are different

  • Make sure your text is readable on an actual device
  • Be aware of the possible default resolutions. For example some commonly see screen sizes are 800x480 and 1024x600, with 800x600 and 1024x768 available through video scaling technology.
  • Most developer tools now support emulators. If you don’t have the actual device, run your UI using the emulator to verify that it’s useful and functional.

Some devices are optional (optical drives may not be present)

  • Don’t require an optical drive, use web install and other methods to work around this.
  • Learn about the available ways devices users can get your application and get into that market place. Learn about AppUp here http://www.appup.com

Right clicks and multi-button clicks are difficult

  • Avoid requiring difficult to accomplish clicks. Design to provide easy methods for common activities.
  • A right click might be easy on a mouse but is very difficult to manage on a tablet, and all but impossible on a handset.

Connectivity concerns for Mobile applications

The nature of portable devices means there will be occasional disruptions in connectivity. Designing your software to account for these conditions will help your users have a better experience. Here are a few suggestions to consider as you plan for your mobile applications.

Here’s a list of issues to consider along with suggestions for handling those issues.

Issues and Recommendations

Unreliable Connection

  • Use subscription methods to maintain understanding of connection status. Most of the current OS’s provide this now.
  • Provide an Intelligent transition between on/offline and data management.
  • Provide On and Offline capability for you application.
  • Deliver an “always connected” experience by using store and forward architecture, working for seamless transitions.
  • What aspects of your app require a connection, are there ways to mitigate that?
  • Can you defer communication activities? (email send/receive when connected)

Online transition to offline workloads

  • Begin caching of information that will need to be synchronized upon reconnection.
  • An example can be Facebook* status updates. Cache these so the app comes up quickly. This helps the user feel the app is responsive as new updates trickle in.
  • Can you anticipate user needs and cache in advance?
  • How will you respond due to a connection failure during a data access or file transfer?

Offline transition to online

  • Detect new connection, synchronize data as previously prepared while offline.

Data loss during on/offline transition

  • Use secure methods of data transmission to maintain data integrity (avoid data-gram packets).
  • Maintain local cache until transmission verified to server system.

Server or web-service non-responsive

  • Treat as connection failure, maintain local cache and wait for working connection.

Synchronous Messaging

  • Use Asynchronous Messaging to avoid potential blocking issues.

Power and Performance optimizations

Mobile devices have characteristics that can make them very desirable for certain workloads. Understanding the limits of the devices can help you focus your work in ways that will give you the best return for the time you spend optimizing.

Understanding mobile users also helps in your application design. Mobile users expect performance and demand longer battery life. This is not just a hardware issue; we as application developers must be good power citizens. At a minimum, applications should be aware of the battery/power status. Application decisions effect power consumption on a platform level. When reading a file for example, read it all into cache, let the drive spin down.

Plan for and handle system messages. If you get a shut down, ignoring it may cause lost data. If the screen is going off displaying a message requiring a user response is futile. Handle Low power situations. For example if you have a fixed workload or something you know will take a certain amount of time (say playing a movie), check to see if there is enough battery life for that action and warn the user before starting. Nobody wants a CD burn to fail due to system shut down on low batteries.

Here are a few points to consider when looking at power and performance issues.

Issues and Recommendations

High CPU Utilization: with Fixed Workloads

  • Optimize performance so that the task is finished sooner and the CPU can step to lower power states.
  • Tune for performance first, then battery life for best results.
  • Turn off background processing.

High CPU Utilization: with Steady-State workloads

  • Optimize performance to allow the CPU to run at lower frequency for the duration of the workload.
  • Performance optimizations provide lower overall cpu utilization for increased battery life. Because the work can be done quicker, the cpu and other resources can go idle and be put to sleep sooner.

Heavy workloads (video playback for example)

  • Can feature quality be turned down? Consider using a lower resolution workload to match the output device.
  • Can feature quality be turned down? Lower but acceptable FPS, resolution etc.

Excessive use of Hard Drive

  • Reduce disk accesses by buffering data to let the drive spin down earlier and remain inactive longer.
  • This is both a power and a performance issue, and SSD’s help with both aspects.

Inefficient Spin-wait loops

  • Use subscription methods rather than polling which keeps the system unnecessarily busy.
  • Spin wait loops are very costly and need to be avoided.

Unoptimized Media Playback

  • Utilize Hardware media acceleration where possible.
  • Look into the hardware specifics and determine if the drivers you are using for H.264 playback for example are hardware optimized.

This list of issues and considerations can seem overwhelming, but there are many more you may run into given the specific features and desires of your application. These guidelines are something every Mobile application developer can incorporate into their work to help to deliver the best mobile applications possible.

Para obter informações mais completas sobre otimizações do compilador, consulte nosso aviso de otimização.