When porting app UIs from Android (2.3 or earlier) to Nokia Asha, you will find that the overall UI concepts can be quite easily mapped between the two platforms. However, it is important to realise that while the user interface designs and the components on both platforms may look similar, the UI styles have distinct characteristics that make the user experience different. For this reason, you may need to restructure the navigation model and reorganise the action items a little.
The most important step in any porting project is to become aware of the unique details that make the target platform different from the other platforms. The purpose of UI mapping is to ensure that there is a comfortable continuation of the user experience from the platform UI style to that of a third party app.
The five most important aspects of the UI to consider when porting are:
In addition, you should remember that even though Nokia Asha devices are small and powerful smartphones, the available memory / processing power may have an impact on the design of your app. As a rule, the amount of processing power should always guide your design decisions when porting apps. This applies to visual design in particular.
Each of the listed items will be described in more detail in the following sections where UI examples from a couple of apps demonstrate how Android UIs could be mapped to Nokia Asha UI components. Note that the depicted images differ from the actual ported apps, especially in the case of RLinks application. Some views and layouts are examples that have been specifically designed for this document.
Figure 1. Basic Android 2.x and Nokia Asha layouts
The interaction basics for Android 2.3 and earlier
The basic layout in Android 2.3 (and earlier) devices is very simple. Status bar shows global indicators (for example, time, battery level, and network strength indicator) grouped to the right, and pending notifications on the left. Parallel views can be placed into the tab bar on the top of the screen. All key actions are placed into the menu (opened with the HW key) or onto the content area. This is one of the key differences between the basic layouts. Note that the basic layout for Android has changed significantly after v3.0. For more information about the latest layouts, see Porting Android 3.X/4.X apps UIs to Nokia Asha.
The interaction basics for Nokia Asha
In Nokia Asha devices the status bar is automatically updated with different indicators for keeping people informed about the status of the phone. In case of dual SIM cards, both signal strengths are shown. Notifications appear as a separate overlay banner and after timeout in the notification panel. As with Android apps, the status bar in Nokia Asha can be hidden for a full screen experience in canvas apps, but as it contains relevant information for the user, this should be carefully considered.
In Nokia Asha, the application/view title is displayed in the header bar (with the first word capitalised). Note that there are no actions available in the header bar in Nokia Asha. The main content area in the middle of the screen is where the application content should be placed. The category bar area, located at the bottom of the screen, can be used to show parallel views or actions. Because of the HW Back key, there is no software back key in the category bar as opposed to Series 40 full touch devices.
In Nokia Asha, the user experience follows single tap interaction: a single tap on any object will select and activate the command. Basic touch gestures are aligned across Nokia devices: content follows finger movement when dragging or flicking. Most elements on the screen are touchable, but the status area and the scroll bar are only informative, not touchable. In full canvas mode, the full screen is touchable. Design is always optimised for one hand use.
In Android 2.3 (and earlier) devices, the swipe gesture can be used quite freely by the application. In Nokia Asha, the swipe gesture (both horisontal and vertical) is reserved for the platform:
For this reason any gestures that are used near the right or left edge of the screen in Nokia Asha should be carefully considered and tested as they can accidentally close the app. The flick gesture used for scrolling content (vertically or horizontally) can still be used normally without evoking the platform swipe features.
Figure 2. The swipe gesture use in Nokia Asha
Portrait and landscape screen orientations are supported in both Android and Nokia Asha devices. The normal screen orientation in Nokia Asha UI is portrait. The application developer needs to define if she wants the MIDlet to be locked to a one of the orientations or dynamically follow the device orientation.
In 2.3 (and earlier) Android devices, the HW keys are usually Back, Menu, Search and Home. Note that the Android 4.0 devices support a set of SW keys that replace the earlier HW keys: Back, Home and Recents. For more information, see Porting Android 3.X/4.X apps UIs to Nokia Asha. Nokia Asha devices have Volume keys, Lock/Power key and the Back key. Text input is handled with a virtual keyboard.
Size of touchable components
Android UI components are currently (in 4.0) laid out in a grid based on 48 dp (density-independent pixel) units. While porting your app, make sure you check the sizes of all touchable elements. The recommended minimum size of touchable components in Nokia Asha is 42 px (37 px + 5 px buffer around the component). If everything is custom designed in the 48 dp scheme in the Android app, you can transfer it directly to Nokia Asha, because the size difference is minimal.
In Android, many applications use tabs for navigating between parallel views. The same functionality is available for Nokia Asha devices, where the category bar can be used for parallel view navigation. Drill-down is used for hierarchical navigation.
Figure 3. Porting the Android tab navigation to Nokia Asha
The dashboard navigation style that uses a “cover page” as the application view is also popular in Android apps. Design-wise, the same user experience can be quite easily created for Nokia Asha apps with grid or list components.
Figure 4. Porting the Android Dashboard navigation to Nokia Asha
Figure 5. Porting the Android scrolling tabs navigation to Nokia Asha
Back navigation logic is one of the key characteristics of any platform UI style. All the major platforms have adopted unique ways of implementing this feature. The Android 2.3 (and earlier) devices, as well as the new Nokia Asha style, use a hardware Back key for navigation within an app and for exiting the app. This means that there is no back navigation button in the application views. This gives a bit more screen real estate for the actual content, as no extra space needed for displaying softkeys on screen. In Nokia Asha devices, the hardware back key works hierarchically. It always goes to the previous activity or to the previous screen. In the main screen of the application the Back key closes the application. Pressing and holding the Back key in any view will open a dialog from which the user can close the application. Read more on the behaviour of the Nokia Asha Back key in Nokia Asha Design Guidelines.
It is very important to implement back navigation that is in line with the platform style, as users using the platform apps have come to expect certain back behaviour and might get very confused if the behaviour within a third party app differs from the platform style
Figure 6. Backstepping in Android and Nokia Asha
In 2.3 (or earlier) Android devices, the common actions (meaning actions that are not related to a specific view item) can be placed onto the content area or in options menu that can be opened by pressing the hardware Menu key. From Android 3.0 onwards, the menu is replaced by the new action bar design. Items from the menu are presented in the action bar as a combination of on-screen action items and overflow options. For more information about the new Android UI style, see Porting Android 3.X/4.X apps UIs to Nokia Asha.
In Nokia Asha, when using commands, the highest priority command is shown as a toolbar button and the other commands are listed in the options menu. Alternatively, the category bar can be used to display anything from one key action to 4 key actions (given that the application does not use the category bar for navigating between parallel views).
Figure 7. Common actions in Android and in Nokia Asha
In both Android and Nokia Asha, the platform UI style supports context specific Options list for displaying the options that are related to a specific view item. These options are accessed by long pressing an item. In Android versions before 3.0, the context specific menu appears next to the selected view item. In Nokia Asha the long press launches a menu similar to the Options list.
Figure 8. Accessing the context specific actions in Android 2.3 and earlier and in Nokia Asha
This section covers some examples of components that are typically needed for porting cases.
|List view: A view that shows items in a vertically scrolling list.||
Figure 9. Basic Android list view
Android ListView displays a scrolling single column list by default. In the Rlinks application, a custom list element is used.
Figure 10. Custom list view in RLinks app
Figure 11. LCDUI list component
Figure 12. Custom list component in Rlinks app
For more information, see Lists and Grids in Nokia Asha Design Guidelines.
Figure 13. Custom list component in Music Explorer
Nokia Asha Lists support one row textual list items with an optional icon element.
Note: It is quite easy to create a custom list with multiple row list items if your application needs one.
|Options list: the method for accessing common actions||
The Options list is where you should place actions that have a global impact on the app, such as Search, Compose email, and Settings.In Android 2.3 (or earlier devices), users can reveal the options list panel by pressing the Menu button. In 3.0 and later Android apps, the common actions are placed in the action bar. For more information on the latest Android UI changes, see Porting Android 3.X/4.X apps UIs to Nokia Asha.
Figure 14. Nokia Asha options list
In Nokia Asha, the options list is conceptually very similar to the one used in the Android 2.3 (and earlier) apps. The menu is opened by swiping up from the bottom of the screen. As in Android, the options list contains actions that apply to the entire view. There is an indicator that shows when the options list is available. The menu is closed by tapping outside the list or by flicking the menu down. For more information, see Options list in Nokia Asha Design Guidelines.
|Context menu: the method for accessing item specific actions||
The Context menu used in Android 2.3 and earlier devices, is a floating menu that appears when the user performs a long-press on an element. It provides actions that affect the selected content.
Note: In Android 3.0 (and later) devices, the long press is reserved for the data selection mode. For more information, see Porting Android 3.X/4.X apps UIs to Nokia Asha.
Figure 15. Nokia Asha context menu
In Nokia Asha, the Context menu is also activated by long-pressing an item. The menu resembles the options list and slides up from the bottom of the screen. While the context menu is open, the content area background is dimmed. The object which the menu belongs to is highlighted under the dimming. A single tap action for an object should not be duplicated in its context menu. It’s recommended that the actions in the context menu are also made available in the next state down in the navigation hierarchy (for example, in the normal options list). For more information, see Context menu in Nokia Asha Design Guidelines.
|Tabs: navigation between parallel views||
Fixed Tab component is typically used for navigation between parallel views in Android applications. Fixed tabs can host maximum 4 tabs, displayed as icon and label in Android versions before 3.0 and with label only in Android 3.0 and higher.
Figure 16. Scrolling tabs in Android 2.X
Scrolling tabs can be used in the application navigation to display more than 3 tabs. The component itself is available in Android 3.0, but it has been in the support library for Android 2.X devices.
Figure 17. An alternative design for the RLinks app with the category bar
Figure 18. Category bar in Music Explorer
In Nokia Asha, the UI component corresponding to the Android tabs is category bar, placed at the bottom of the view in both orientations. The maximum number of categories is four.Categories depend on the level in the UI hierarchy, meaning that they disappear when user drills down in hierarchy. If you use the category bar for tabs, it must not contain actions. If the Android application to be ported uses scrolling tabs and has more than four tabs, the app navigation model should be changed from tabs to drill-down. Another option is to restructure the app so that only four categories/tabs remain. For more information, see Category bar in Nokia Asha Design Guidelines.
Figure 19. Form elements in Android 2.X
Android platform contains a number of ready-made form elements, including Edit Text, Checkbox, Radio Button and RadioGroup, DatePicker, Seek Bar, Toggle Button, and Button.
Figure 20. Form components in Nokia Asha
|The Android form components can be easily mapped to corresponding Nokia Asha form elements. The supported Items in Nokia Asha include TextField, StringItem, ChoiceGroup, DateField, Gauge, Spacer, ImageItem, and Ticker. There is a CustomItem component, which allows custom content to be defined by the app. The CustomItem component can be used to draw, for example, a Switch (on/off) component. For more information, see Forms in Nokia Asha Design Guidelines.
One additional design details is the organisation of confirmation buttons. In Android, the "positive" continuation button is always located on the right. In Nokia Asha, the "positive" continuation button is the topmost button of the button stack.
Last updated 9 July 2013