The visual look and feel of Nokia Asha UI is very different from the previous Series 40 UI’s. Luckily, most of the API’s remained the same!
Direct technical comment from Nokia engineers about the latest app development issues
The visual look and feel of Nokia Asha UI is very different from the previous Series 40 UI’s. Luckily, most of the API’s remained the same!
Want to know how the Asha UI looks like and read the UX documentation? Well, aren’t you lucky: here’s the link!
The Nokia Asha design guidelines provide a comprehensive set of UI component descriptions and UI patterns. For app icons, templates and guidelines are of course included. And to make things as simple as they can get, there’s also a UX checklist.
Stay tuned for more updates on the Asha UI in this blog. And don’t forget to check the Event calendar for Asha UI webinars!
Happy developing,
Sanna
The Nokia Asha full touch offering introduced an API called Category bar. In the UX guidelines it says that you should never, ever, in a million years place actions in there. Now why is that? Are we just trying to fool you with this guidance? No, we’re not. And this is why.
Nowadays everything seems to be getting smaller; SIM cards, computers, prices for TVs, transistors, pixel sizes of video screens. So, why not also reduce the size of a font or icon to get more information into your app? Small graphics look sharp and crisp on small displays with very low pixel sizes. It’s very tempting.
The answer is simple: We are now getting to a saturation point—actually we have been there for a while. In this context, saturation means that relevant UI components will not benefit from higher resolution.
No of course you don’t need a style guide. But people who are using your application desperately need you to need one. You know, the people who create the revenue for your application, either with ads or by paying for the application…
On touch user interfaces, visual feedback is as important as it is on non-touch UIs. But it’s a bit different.
With a non-touch UI you need to indicate which UI element is currently in focus in order to operate with it. In a mobile context this is usually done with a highlight on the elements. One element is always highlighted, and the highlight is then moved with a navigation key and selection done with the selection key.
Hello again,
A few weeks ago I was listing the top things to consider when moving from non-touch screens to touch screens. One of the things I mentioned was to ensure that the touch areas for your UI elements are big enough.
As I said then, we recommend the minimum size to be approximately 7×7 mm with 1 mm gaps. What this actually means is that when placing two separate UI elements next to each other, there is a 1mm non-touchable gap between them. This is to ensure that it’s easier for your app to recognize which element has been tapped.
What image comes to your mind when I say “color contrast”?
Perhaps your first thought is the famously hard-to-read combination of red and green; and you are right. For example, 9 percent of men cannot distinguish between red and green. Even though a minority, it’s helpful to keep in mind that a substantial percentage of your potential customers are affected by improper red-green design.
Based on what I’ve recently seen it seems to be a bit of a mystery what you should do when moving your app from non-touch screens to touch screens. Here are three things for you to consider!
Continuing with the topic of icons…
From the start, the appearance of your application in the app menu makes a difference in how people interpret your app. If your icon looks stylish, has the correct shape, and people can guess from the app’s name what it does, your app is on the right track.
If the shape of the icon is different from the rest of the icons on the phone, your app will feel alien and not like an integral part of the phone. Some people might think the app is a (cheap?) copy of something else; others might think you simply don’t care. This opens the door to bad reviews, since people launch your app with a negative attitude even before they have really seen it. It is very hard to recover from that initial negative first impression!
![]()
Example of a badly shaped launcher icon and truncated app name.
The same holds for the app name; you should try to keep it short enough that it will not be truncated. It’s not easy to come up with a short and catchy name, but it’s definitely worth the effort. In addition to looking better on the phone (let’s be honest here; it does look better when it’s not truncated), a short app name is more likely to be remembered by users. This makes it more likely that they will recommend it to their friends (because they will also love the app, of course!).
So, how to make things right?
By taking care of just these seemingly minor details, you help set people into a positive attitude before they even open your app.
Happy developing,
Sanna