Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.
Series 40 UX checklist webinar - companion article
This article is companion for the UX Checklist for Series 40 Full Touch webinars held in October and November 2012. It covers both sessions: 31st October 2012 and 1st November 2012.
This webinar provides pointers you can use to perform a basic user experience (UX) check of your Series 40 full-touch app, even if you have no formal experience in UX design. In it we review a list of some of the worst UX mistakes that we found in real-world app testing, and provide some specific solutions to these problems.
This checklist covers some basic UX mistakes, and is a great starting point if you’re not a UI design expert. Check out Series 40 UI design library for more advanced information and resources.
This wiki page is the "companion" to the webinar. It includes:
- Webinar exercises and proposals for how to solve them.
- Open issues from Q/A
- Link to slide deck
- Link to recording
- Webinar announcement
Solutions to webinar problems
This section contains problems raised in the webinar exercises, along with recommended solutions.
A custom view acts as a launchpad screen. Which chrome elements do you add?
There are several possibilities:
- Full custom header without chrome: there is no chance to add neither any primary command nor any options menu. This could work in case the launch-pad view just puts the user into the right flow, e.g. for a game:
- Start new single player game
- Start new multiple player game
- Resume last game
- Buy items
- Edit online profile
- Full custom header with one primary action: This works if there is a single very important action which the user will most often select, or which always has to be available, e.g. the play/pause button of a music player. The launch-pad view allows the user to continue directly with the main use cases.
- A view with predefined chrome, or chrome at the predefined position. This approach makes it easy to remove secondary items from the launchpad: i.e. Help and about might be moved to the Options menu.
The item menu is opened with long press on the item. It must contain only commands which directly the selected item (e.g. delete). It must not contain any commands which could act on multiple items (e.g. delete all). The latter go to the view menu. These are the design rationales for touch devices:
- The focus is implied with the touch down, but not beforehand, so the phone cannot anticipate which item is chosen
- The focus is lost with finger lift, so the phone cannot trace which item was chosen beforehand
- There are just few working interaction pattern which would resolve these issues:
- pointing at the item for longer time (all Nokia touch phones)
- bringing the phone into a selection mode and from there select the item (e.g. Android 4.0 and higher)
How many touchable items can you fit into a full screen layout?
- 4 items fit in one row if you use the minimum touch area. A 5th item will not fit completely and might interfere with the scroll bar (which is without function and just for indication purposes). We recommend you do not reduce the touch area below 7 mm x 7 mm and 1mm margin. If you need to fill the gaps, increase the touch area in preference to squeezing in another item.
- 7 items in a column are fully visible and 1 item is partially visible
- 28 full items
- 32 items the user is aware of
If using a 5th column, take the back button into account (i.e. 40 – 1 items). In this case make sure the context of use allows smaller touch areas (i.e. the user will always operate the app with 2 hands so thumb use is not required) or compensate using techniques like fish-eye.
Which icon sizes are used in Series 40 full touch?
Is the contrast of these two colors good enough for AAA compliance for text?
- Foreground: 33FFAA
- Background: AAFF33
AAA compliance means that you create a document in a way that also disabled people can access it. Even if not stated directly, it also means that your document (or application) can be accessed by non-disabled persons in a non-optimum environment, e.g. with sunlight shining directly to the display. More information from here.
If you fill the values to a contrast checker, the answer is "No". The colour contrast results in something like the image below:
You can check colour contrasts using sites like snook.ca.
Open issues from Q/A
Question: How do I have to scale the printout to match the phone's screen size (to have correct sized images for paper prototypes) ?
Answer: Scale the printout to 46% of the original size.
The next (planned) UX related webinar is: UI design for monetisation enablers for Series 40 full touch.
How you design and present monetisation interactions requires as much attention to user experience as does the rest of your app. If you use in-app ads or in-app purchasing, this UX webinar is for you. The webinar will walk you through the recommended flows of various monetisation stories in Series 40 full touch. It will also demonstrate common mistakes that developers make and will propose solutions for those problems. As usual for Nokia Developer UX webinars, the presentation will feature exercises that will receive follow-up treatment in a Nokia Developer Wiki article.