Asha UX checklist

The items described below are the most important UX issues to consider when designing an application for Nokia Asha. Many of the 'checks' are solved automatically when using ready-made components from LCDUI or LWUIT, but they remain an issue for custom components.

No focus - use direct touch paradigm only

  • No visible focus on screen (1).
  • No double tap to open an item.
  • Single tap triggers the action (2, 3).
  • Content follows finger, e.g. a drag gesture moves a list.

Visual feedback - indicate all touch down events

  • React to people's gestures.
  • Indicate the touch down event - not the touch release (1, 2).
  • Actions are triggered immediately after touch release - not on touch down (3).
  • Touch down feedback is easily forgotten for custom UI elements.
  • If the application behaves in a different way, people may perceive the application as broken.

Make touch areas large enough - obey the minimum touch area

Minimum touch areas:
  • UI element optimised for finger: 7x7 mm², i.e. 37x37 pixels².
  • UI element optimised for thumb: 9x9 mm², i.e. 47x47 pixels².
  • Gap between elements (margin): 1mm, i.e. 5 pixels.
Please note:
  • Pixel size is 190,5 x 190,5 µm².
  • People tend to press a bit lower than the actual center of the item.
  • People on the move operate the device with one hand and with thumb.

Place basic view elements where expected - use basic gestures as expected

  • Status bar contains important phone status information, like battery strength or SIM card usage (1).
  • Header contains the view title (1, 2).
  • Category bar is located at the bottom of the view (1).
  • If there is no category bar, the highest priority Command will be shown as a textual button at the bottom (2).
  • If Options menu is available, an indicator is shown (2).
  • Options menu opens with a swipe from the bottom (2).
  • Notification panel opens with a swipe from the top (3).
  • The app closes with a swipe from the left or right edge of the screen.

Back stepping is done via the hardware key - and only via the hardware key

  • Must have:
    • On main level of the application, pressing the hardware Back key exits the application.
    • On sub-levels of the app, pressing the HW Back key leads to upper hierarchy level.
  • Not allowed:
    • Software Back button on the screen.
  • Exceptions for games:
    • During game play, pressing the HW Back key can open the game's play-pause menu, if the menu contains a command which leads to upper hierarchy level.
    • In rare cases, the software Back key can be used if it is necessary to understand the game logic; however, HW Back key must work consistently, e.g. both open the game's play-pause menu.
Why not use a softkey on screen for back stepping?
  • User can get confused whether the phone will always provide the on-screen navigation method or not.
  • By removing all on-screen back buttons, the applications will help the user to get accustomed to always using the back key as means to go to the previous state (when on sub-levels) or exit the application (when on app main level).

Do not combine tabs and actions in category bar

  • Category Bar uses either tabs or actions.
    • Tabs (1):
      • Up to 4 tabs possible.
      • Navigate between parallel views.
      • Should disappear when drilling down.
      • Highlights the current tab.
    • Actions (2, 3):
      • Up to 4 actions possible.
      • Affect the entire view, not a single item inside the view.
      • Highlight only on touch down (3).
  • Use cases for tabs and actions are very different.
  • Visually, the only difference between tabs and actions is the highlight.
  • If using Category Bar, do not add additional tab bars or action bars into the view.

No radio button indicators for exclusive choice or check box icons for multi-selection

  • Do not use radio button indicators (1).
  • Do not use check box icons (2).
  • Single selection or multiple selection of items will be indicated with highlight (1, 2).
  • People will know out of the context if the list allows single selection only or if multiple items can be selected.
  • Allowed exception: Check box icon (3).
    • Can be used for a "switch" UI component (on - off states).
    • Must work for left-to-right (LTR) and right-to-left (RTL) languages.
    • Is placed on the right for LTR languages and left for RTL languages.
  • Allowed exception for games: for a game specific UIs it is feasible to use:
    • Check box icon to indicate that one or multiple items are selected.
    • Radio buttons to indicate that one item out of many is selected.

View related actions are in Options menu - item related actions are in the long-press menu

  • Options list (left image):
    • Contains commands that apply to the entire view.
    • The most frequently used command should get highest priority.
    • Help and About:
      • Add at least to Options menu in the main view.
      • Recommended to add to all other views' Options menus.
      • Required About content is listed in Java Verified Unified Testing Criteria.
  • Long-press menu (aka context menu, right image):
    • Contains item specific actions only.
    • First time users might not realise the existence of long-press gesture.
      • Consider the long-press menu as hidden.
      • Long-press menu items are only shortcuts.
      • Repeat long-press list items in the next view either as action in the category bar or as item in the Options menu.
  • Allowed exception for games: if the game UI benefits:
    • Options menu can be reached via a menu.
    • In this case it is not necessary to reserve the "bottom swipe" gesture for options menu.

Use consistent labels, expressions and commands - make sure things are readable

  • Use initial Caps for:
    • Button labels.
    • List items.
    • Header labels.
  • Be consistent with terms in your app.
    • List items should match headers when drilling down (1, 2, 3).
    • Use identical terms, e.g. in alerts and help settings.
  • Use a short application name (max 8-9 characters) to avoid truncation in the app menu (1).
  • Ensure readability.
    • Font size is at least 14 pt (or larger).
    • Use phone's standard font.
  • If using your own font:
    • Pack it into your app.
    • Ensure it renders correctly on all the phones.
    • Ensure it is readable also in non-optimal conditions, such as direct sunlight.

Use correct icon sizes - optimise your icon for Nokia Asha

Your square-shaped icon will be:
  • Shown on Fastlane.
  • Cropped automatically for launcher icon.

Icon Bounding box Icon size Focal zone
Fastlane icon 50 x 50 px² 50 x 50 px² 30 x 30 px²
Launcher icon (shown in Home view) 44 x 44 px² 42 x 42 px² 30 x 30 px²
Category Bar icon (aka Toolbar icon) 22 x 22 px² 20 x 18 px² -
List icon 30 x 30 px² 22 x 22 px² -
Button icon 34 x 34 px² 22 x 22 px² -

Does your application require text input - if not, clean the Options menu

  • In some cases, in Canvas "show text keyboard" is added automatically to the Options menu.
  • If your app does not require text input, check that the command is removed from the Options menu.

Last updated 29 January 2014

Back to top