glacier controls specs

Posted in Core User Interface by

I have started working on speccing each and every glacier control.

If you want to contribute, please clone the repo at

pick up a control and create a document like this:



How to use this document:

The first column shows the graphics of the button, along with sizes in u (see the previous post for explanation of device independent units). The second column shows the properties that define the appearance of the control. For different states, only the differenciating properties are mentioned. The third column provides some description and explanation of where the control is supposed to be used.

The pdf attached is not up to date, please visit github for the current version.

Unveiling Glacier

Posted in Core User Interface, Thoughts by


[Version 1.0 uploaded! I’d call it “Stable”, with most, if not all interactions and elements defined.]

Hello world! Hurrian here.

Following news of the Nemo UI rewrite, I decided to chime in with my thoughts of how a mobile UI should be like.

And following the naming scheme on here, I’m calling it Glacier – a smooth, liquid UI, on ice.

It’s a primarily high-contrast UI with light, airy text on dark backgrounds, borrowing heavily from contemporary design paradigms – Android 4.x, Firefox OS, iOS 7, OS X, Windows 8, Sailfish, and MeeGo-Harmattan.


  • A simple, large clock, with the date underneath is shown. The background under the text is always darkened and blurred to enhance the readability of the text.
  • Notifications are lined up under the clock – tapping on these will unlock/prompt for the unlock code (if any), and open the app.
  • Swiping the lockscreen away from the top edge lands you on the Search page
  • Swiping the lockscreen away from the bottom edge lands you on the app launcher.
  • Swiping the lockscreen away from the left edge lands you on the Event View
  • Swiping the lockscreen away from the right edge lands you on the Multitasking view

The rationale behind different targets for different swipe zones reinforces the user’s spatial awareness – a main point of the UI is the use of layers to imply navigation information. (Refer to the use of layers in Maemo 5.0/Fremantle and MeeGo-Harmattan)


  • Search uses Tracker’s indexed database, making searches fast
  • Search can prioritize results by user choice
  • A short description of the action an app will perform must be under the app’s search result
  • The Search page can be reached by swiping from the top edge in the app launcher or lockscreen.


  • As a list-based application, the list is arranged as the first, and foremost object on-screen.
  • Large text marks list items, with a small subtitle when necessary to explain its function
  • The use of titles and subtitles in conjunction with icons reinforces the mental correlation between these two

Event View:

  • Items on the Event View are populated by widgets
  • The user can rearrange the widgets in any way s/he so wishes
  • Similar to the lock screen, tapping on the widget redirects the user to the app.


  • All icons will have a circular background to enforce consistency, however, app developers may choose to create their own custom icons with a not-perfectly-round profile.
  • The use of color and not-perfectly-round icons makes apps easily recognizable
  • Apps are not hidden into folders, rather, they’re grouped into categories, which may be labeled by the user
  • Gaps in the app grid are permitted, for those users who insist on certain layouts ;)


  • Borrowing from Sailfish, a minimized app view is available.
  • Notifications can be put on the minimized app view, allowing quick access to them (and replacing the traditional notifications menu)
  • Borrowing from OS X’s Mission Control, the app icon and name are displayed on the bottom of the minimized app to let users quickly recognize the app

Sample apps – Camera:

  • The app’s focus is put front-and-center
  • UI chrome is left as minimal as possible
  • Controls are not hidden in gesture menus (more like Harmattan, and unlike Sailish’s pulley menus, which in certain contexts could be confusing, the removal of which causes a consistency issue)

Sample apps – Browser (and notifications!)

  • The notification pushes the active app up (and floats?) for a few seconds (see Harmattan in the lockscreen when someone calls/alarm fires)
  • The active app partically covers the notification, further indicating to the user that a swipe action can be performed
  • After a few seconds, the app comes back down, and an edge glow and app icon are shown to indicate an unread notification.

Sample apps – Messaging

  • Contact name is on top, with a small contact icon and availability (if services are connected) indicated by a green glow.
  • Ordinary chat bubbles. Move along…
  • Message type (SMS/IM/etc.) indicator – allows for unified messaging with a contact (Fremantle!)
  • Spacious virtual keyboard

Sample apps – Music Player

  • Just like in Harmattan, the album cover is put front-and-center
  • To save screen space, the app header and back button are overlaid on the album
  • The music progress is overlaid on the bottom third of the album cover. Drag it to quickly skip around the song.
  • Album/playlist song list is below the song/album/artist title, instead of hiding it behind the album cover, like Harmattan
  • Pause/previous/next buttons are at the bottom

Feel free to leave a comment or shoot me a mail (kenneth <{[gnat]}> meta <{[dot]}> mm <{[dot]}> am).

I’ll be continuously updating this post as I get comments and remarks.

Proposed iconset for breeze

Posted in Core User Interface, User Interface Guidelines by

This is my proposed iconset for breeze.

breeze iconset

The icons are all based on a circle for reasons outlined in the previous post. The circle has a very low contrast radial gradient with the center of the circle being slightly lighter than the rim.

Colors are still pale and playful and should match the tint colors of the apps (I know this isn’t the case yet with the mockup I did a few posts back, but this is going to be fixed)

A glimpse into the new design language

Posted in Core User Interface, Thoughts by

Here’s a scratchpad of some screens of the new design language I’m thinking about for nemo. Nothing is final here, the accompanying texts have double purpose: as guidelines but also as notes for me to remember what I was thinking while sketching this down.

These screens do not cover every control and every pattern but are a good indication of where I want to go.

The general ideas behind the theme are

  • Flat surfaces
  • Circular buttons with icons
  • Wavy, low contrast gradients
  • Pale colors
  • Clickable texts and list items without bevels
  • Simple icons, without sharp edges as much as possible
  • Use of different font weights, sizes and opacities to signify different in importance of various texts
  • Text inputs signified by bottom border only
  • Slight use of color to signify especially important operations like delete
  • Different color tint per application
  • Use of gestures but not too much of them
  • Saving clicks where possible by smart default actions

but most of all, I wanted to make every screen look like well designed printed material. The fact that the dpi of current devices surpass the dpi of standard commercial priters, allows us to take advantage of high quality type, that is easy to read and looks good, and do away with all the tricks we used to do on screens to hide the extremely low definition. The fact that users are familiar with basic touchscreen interactions allows us to not worry about affordances like buttons that look pressable and other effects that increase visual clutter.

Keeping the sea-themed naming scheme, the name of the new theme is breeze.


Let’s talk type

Posted in Core User Interface, User Interface Guidelines by

One of the basic things we’ve got to choose is the font we’ll be using. We need a sans serif font, with many weights and good quality. I personally like the new humanist sans fonts that have appeared (and almost dominated) the digital type in the last few years. Very nice examples are the Nokia Pure font, the Segoe UI font and Ubuntu.

For a free project we obviously need a free font. There is a very nice free/open source font recently developed by adobe, Source Sans.
That would be my choice for the nemo main font but, it doesn’t yet speak Greek, and you know, I would be filing bugs about my own choice :)

I’d like to note here that Greek and Cyrillic are a bit different than all the other scripts out there that can easily use their own font. Because Greek and Cyrillic have common glyphs with Latin, it’s important that they look the same. Especially for Greek as the GSM alphabet is mixed Greek/Latin (there is no true Greek support but only the capital Greek letters that do not have counterparts in the latin alphabet exist). Thus, if we had to fall back to another font, different fonts would be used only for the missing glyphs and Greek SMS message would look like this:


unacceptable and unprofessional

So the choice, at least for the time being, is Steve Matteson’s open sans.
open sans

It’s a font that looks modern, it’s easy to read, has many weights and isn’t extreme in any way. The only thing I have against it, is that it’s being used too much.

Happy reading!

Home screen survey: initial thoughts

Posted in Core User Interface, Thoughts by

Before moving the Nemo home screen to the next level, we decided to create a survey and ask people about how they use their home screens on their devices. I’m going to publish more details in another post, this is just for my initial thoughts and impressions.

First, thanks to everyone who filled the survey and to those who shared or retweeted it. Without you guys, I don’t know what I’d have done. It also feels very nice that there are lots of people who we can count on when it comes to these matters.

I had the survey and questions carefully reviewed by people, but still, the end result wasn’t perfect. Lots of people didn’t understand what we mean by “home screen”, and this was the major source of misunderstanding. Perhaps we should have used the term “operating system” or something more general, because there was people who thought hey, this or that feature is in the operating system, not the home screen, blah-blah. Of course, from a technical point of view, these features are a part of a piece of software which lays on top of the operating system (this is what I call home screen), but for non-technical people, it indeed might be quite challenging to see the difference. Apart from this, most of the questions themselves were okay, and we’ve had useful answers coming in.

So, let’s go through the first few parts.

9% of people think that a home screen is not important. The rest of them think they are important for this or that reason. The next thing we see is the audience is quite biased, unsurprisingly, towards MeeGo 1.2 Harmattan. Since Nemo is mostly of interest to those people, we must accept this for now. Most of the people who answered have used every sort of OSes, but of course the majority is Maemo or MeeGo users. The things they liked most are Harmattan (57%), Fremantle (19%) and Android (10%). Some people did like WP7 and a few iOS.

The textual info here is very interesting, seems that people like to fill large text boxes with their hearts’ content. Basically, the ideas were mostly the same things repeated. I have here an extract of the answers.

  • According to some people, the traditional app grid is boring. Some suggest to categorize app or allow searching between them.
  • Many people noted that the home screen should allow to find what you need most, either by hiding irrelevant info or pinning relevant info or features.
  • Many people want close integration with IM, calendar, email, calls apps and other events to see what’s happening at a glance.
  • Some people want widgets and customizability, and some specific features related to widgets.
  • Many people (more than the above) have realized that widgets are just cluttering up their space, so they simply want the info they need without any clutter

Obviously, the most challenging here is to find a balance between those guys who want all-customizable widgets and whatnot, and those who actually want to get stuff done. This is an interesting question and it’s well worth a post on its own.

Of the basic features, the app switcher wins. 83% of people want to have it in their reach all the time, with only 6% saying that it’s not important. App launcher has similar figures, but only 68% feel that it always has to be in their reach. The widgets question was tricky (should have been asked in a better way), but there only 58% feel that it has to be always in their reach, despite that most of them are saying that widgets are just clutter and are ineffective at quickly conveying relevant information to them. To the question asking which feature is the most important, widgets win (40%) and social feeds are next (26%).

NOTE: There were a few “easter egg” features in the survey as well (eg. favorite web sites and media) which most people identified as “doesn’t belong to the home screen”.

The gestures part is also very interesting. Most people perhaps don’t know the meaning of the word “flick” and they answered “swipe”. Apart from this finding, the “what gesture do you prefer” style questions were quite useless, as long as the accessibility of frequently used features was the topic. It was nice to find out though that most people don’t care how rarely used features are accessible.

The questions with pre-defined answers are kinda easy to analyze (google even draws pretty graphs from them), but very surprisingly we received lot of long textual data as well, which I haven’t finished processing for all questions yet. I’m going to write another post when I have.

In the meantime, if anyone is interested in the actual survey data, I’d be happy to share.

Theme Plastic Introduction

Posted in Core User Interface by

Current default Nemo theme is rather visually inconsistent so I started working on a new one.

Main idea of this theme alternative is easy recognition. Unified icons’ outer shape enables smooth visual flow without informational noise. Additionally, big square icon’s area filled mostly with single colour, helps colour based recognition, which is faster than e.g. shape based recognition. Shape needs more complex attention process. Plus, during motion blur that occurs during tracking elements on the screen, we loose their shape (due to loss of high spacial frequencies) and are more likely to use colour as main recognition clue. Navigation bar is integrated with wallpaper, so it’s less obtrusive. Wallpaper is used also as a lock screen.

There is currently wallpaper, navigation bar and set of icons in this theme, so still a lot to do… The idea was to create a theme accordingly to UI guidelines, which are about to be published soon.

Circular slider and timepicker in qml

Posted in Core User Interface by

The default qml components timepicker uses a slotmachine arrangement which is terrible in terms of usability, and is by definition a dialog, which is not always desired.

On the other hand the circular meegotouch timepicker is visually beautiful, easy and intuitive to use (like an analog clock), so I decided to implement a similar qml component for nemo. The component is not a direct clone nor it uses the harmattan meegotouch theme assets, but if somebody wants to change the artwork it should be trivial to do it.

For the time being it doesn’t have animations (PathAnimation, which is coming in qml2 will help do that animation easily, so for now it’s deferred) and it is 12h only (you have to create a switch by yourself to cater for AM/PM.

The component is comprised by two circular slider components which are also part of the project. So if you need a custom qml circular slider just include CircularSlider.qml in your project.
The code is on

P.S. The reasons I think the slotmachine is not good in terms of usability are the following:

1. 60 items are too much to show in a flickable list. The user can’t know how hard to flick to go directly to (or even near) the minute he wants, and one big swipe often isn’t enough (you run out of screen). On the other hand you need one tap on the circle, and it’s obvious where to tap unless you can’t read an analog clock.

2. When you flick upwards you cover the slot with your finger so it’s difficult to see what you’re going to choose

3. If we had an inline slotmachine with only the selected time visible and the other values showed up only while dragging I might prefer it in some circumstances (depending on the frequency of choosing times and screen space constraints) over a pop-up circular picker but in the current situation the qml timepicker is a dialog that by definition takes up the whole screen and adds two unnecessary taps.

4. Inconsistency: There’s no cancel button in other dialogs, the buttons aren’t themed like the other dialog buttons, and there is no X button. That dialog is like a hastily made custom component.









I also feel obliged to mention this effort which I was not aware of and tries to bring the meegotouch timepicker to harmattan qml.