three random images with the header

Posted in Thoughts by

The fade to white header doesn’t look good, but specs aren’t made to look good. Here’s an example of the header on different backgrounds, plus one with a different gradient and icons



Posted in Thoughts by

Let’s say we have a 4″ inch phone and a 8″ tablet, both 1280×720 and we want to draw an icon on them. If we only take into consideration their ppi the button on both devices will have the exact same size. If we blindly use the same pixel size on both devices our icon would be double on the tablet compared to the phone.

In reality we actually need a bit bigger control on the tablet, because the viewer holds the tablet a bit farther away but not double the size.

The problem of units is a big one and until now nobody has solved it well enough. Pixels aren’t the right answer, obviously because of variable pixel densities. Real-life length units aren’t either because of varying viewing distances. 1cm on a phone is huge, on the TV is tiny.

The answer is viewing angle: the proportion of the user’s viewport the control takes.


There is a certain threshold of ppi below which, the actual number of pixels dictates the size of the components, because there isn’t enough detail when trying to do smaller things. This is around 125ppi. On a 96ppi computer screen, you can’t make the favicon any smaller, not because the user would have to squint, but because 16×16 pixels are barely enough to hold the icon. When going over 200ppi, the minimum size of things start to be dictated by what the human eye can distinguish comfortably, i.e. without squinting.

Phones and tablets have mostly got over with such lowly ppi’s so I will not bother again with this problem. If you’re trying to port nemo to a device that has so low ppi that it restricts the minimum size of text and icons, you’ll have to compensate by faking a smaller screen size so that everything is drawn a little bit bigger.

In this particular point in time a weird thing is happening. Almost everything, from your 5″ flagship phone, your 13″ ultrabook, the 24″ inch pc monitor and the 55″ TV, has 1080p. This makes things easy: design a button to be 100x100px and it will be about the same perceived size on any screen. Here’s a table with calculations of the field of view that a 100px element occupies in all the above devices: roughly 1.4 degrees.

diagonal (in) height (in) width (in) height (cm) width (in) ppc (width) ppc (height) control size (px) control size (cm) viewer distance (m) control size (angle)
5.00 2.48 4.35 6.29 11.05 171.80 173.77 100.00 0.58 0.25 1.33
13.00 6.44 11.31 16.34 28.73 66.08 66.84 100.00 1.51 0.60 1.44
22.00 11.88 20.88 30.18 53.04 35.79 36.20 100.00 2.79 1.00 1.47
55.00 27.23 47.85 69.15 121.54 15.62 15.80 100.00 6.40 2.75 1.33


but this while very nice for our example, isn’t true for everything: lowend phones still have HVGA’s, high end tv’s have 4K and the retina Mac’s have something in-between. We still want to keep the same view angle for the same controls though, and because we can’t measure the viewing distance, it’s wise to infer it.

Device Viewing distance (m)
phone 0.25
tablet 0.35
laptop 0.45
desktop 0.85
TV 2.5

Now let’s take a small button, like the back button of the N9 browser. It measures around 50px which translates to roughly 0.5cm (N9 has ~100 pixels per cm) so it has a viewing angle of ~1.1°
If the N9 had a 1280×720 resolution, we’d still want 0.5cm to fill a 1.1° viewing angle so we would have to bump up the pixel size to 75px.
On our 8″ tablet with the same 1280×720 resolution we will need a 0.73cm control (52px).

We need a unit of measurment that takes these calculations off the mind of the developer. There are two ways to do this: either patch Qt so that pixel sizes are being multiplied by a size factor, or by having an SIZE_FACTOR constant that the developer has to multiply all sizes with, and that will be different in each device. This size factor will be computed as following:

reference_px_per_mm = 10;
reference_viewing_distance = 0.250;
viewing_distance = ???; //in meters from above table
reference_viewing_angle = atan(1/(reference_px_per_mm*reference_viewing_distance));
viewing_angle = atan(1/(px_per_mm*viewing_distance));
size_factor = reference_viewing_angle/viewing_angle;

here’s a table for some common devices

Pixels per mm viewing distance size of 1px in mm veiwing angle of 1px factor
N9 (reference) 10 250 0.100 0.0229 1.000
Galaxy S4 17.5 250 0.057 0.0131 1.750
Nexus 7 8.2 350 0.122 0.0200 1.148

The road to Glacier UI

Posted in Thoughts by

Hello together!

The coding guys did an amazing job and almost all core apps are ported right now. Thus the coders are waiting now for us graphics guys to define, create or describe informations for component creation/styling. Knowing that Qwazix and Hurrian are busy at the moment, I had some thoughts about the way how we should start defining component styles. Take this with a grain of salt, as I don’t have any knowledge about UI work in QML. This is just a draft and I’ve chosen colors and sizes based on Hurrian’s Glacier UI mockup and Icefox browser concept and discussions on #nemomobile. So let’s start with the 3 main points we should adjust in my opinion.

  1. Default font
  2. Standards for colors and states (active, pressed, inactive)
  3. Standard sizes for elements

1. Default font will be Open Sans, as it was discussed in IRC, because of better support for cyrillic and greek characters and lots of weights. Qwazix already wrote about it a while ago:

Font sizes and weights will be described in each component.

2. I will give colors names here, so everyone knows in future what each color is refered to.

Text font color should be plain white (#ffffff) as long it’s antialiased
Background color should be plain black (#000000)
Sub Background should be dark grey (#171717) for tabs, etc.
Active blue state should be light blue (#0091e5) for accept dialogs
Default blue state should be medium blue (#005f96)
Active grey state should be light grey (#474747) for decline dialogs
Default grey state should be medium grey (#313131)
Highlights should be frost (#dcdcdc) like on tab or speechbubble highlights
Lines, arrows, etc. should be frost (#dcdcdc)

3. I think we should use most of the times percental based sizes to minimize effort for different theme resolutions. Also pixel graphics should be used as less as possible. When graphics are used, borderimage should be used to implement them if possible. Speaking of different resolutions, we should support for the moment 3 different sizes:

  • 854×480 (should scale not that bad to 840×480 and 960 × 640)
  • 720p
  • 1080p

We should set a minimal size for pressable elements like a button or an arrow. Also minimal spacing should be defined. On my work on Icefox browser concept I failed at this, as I noticed after it was published and I tried it first time on my N9. Those items there were too small and had too less spacing. I inspected Harmattan’s buttons to get an idea what they did there and I quite liked it. Smalles buttons are 50×50 there (although not always visible) with a spacing of 3 pixels in each direction. So two buttons have a distance of 6 pixels between them. I have redone the URL bar of Icefox with those measures in mind and this is how it turned out:

(without boundaries shown)browser-main-ui-reworked-urlbar

(with boundaries shown)
Those buttons may look big on the screenshots, but they are in fact almost exactly same size as harmattan’s browser (grob) buttons.

(example on grob with changed colors to match harmattan’s UI)

Have you anything to add, comment or critic? Did I forget some fundamentory stuff? Please feel free to add your opinion.



Icefox browser concept – explained

Posted in Thoughts by


Hello together, this is Morpog known from TMO or several IRC channels on freenode such as #nemomobile. Qwazix kindly offered me to introduce my Icefox browser concept here, which is based on the great work done by Hurrian (Glacier UI) and Qwazix (Breeze browser icon).

First I have to thank all of you for the helpful critics/discussions on #nemomobile while doing drafts of this concept and comments after unveiling on twitter, it really improved it alot.

This concept is heavily influenced by the latest browser versions on Android OS such as Firefox, Opera and Chrome. As Icefox browser will be based on embedlite branch (IPCLiteAPI) of Mozilla code, it naturally shares alot of features with Firefox browser. Most of underlying work was/is done by Jolla and friends and it’s already ported to Qt5 and runs fine on Nemo wayland VM, however with a very basic UI (only URL bar). It’s Qt4 reference UI which was created by coderus (QmlMozbrowser) wasn’t ported to Qt5, as Jolla is doing it’s own Sailfish UI for it. Thats where this concept kicks in.

At the moment Glacier UI isn’t finished and technically not even started to being implemented. So it’s unsure if components I used or invented (like tabbed navigation) will work the way I describe it here, or even exist at all. The concept itself isn’t completed, as it lacks alot of pages like all settings, bookmarks, etc. But it outlines the main views and mechanics.

The concept

(click image for larger size)

General button behavior:
Inactive buttons are dimmed. Pressable buttons are white and Active buttons are blue styled.

General tab behavior:
Active navigation tabs have a blue line on top.
Inactive navigation tabs have a grey line at bottom
Active website tabs are blue outlined
Inactive website tabs are grey outlined

The startup experience

(click image for larger size)

URL bar to enter web adresses and show the startup experience. At first startup the Home tab will be active. On all later touches of URL bar, the last active navigation tab will be showed. Aslong the startup experience is shown, or while the URL bar is active, no page navigation buttons (back/forward and stop/reload) will be shown to maximize URL showing space.

Extend URL bar is a multi purpose button. It shows the number of opened local tabs and extends URL bar. See Extended URL bar description for more info.

Tabbed navigation to change between pages, either by pressing a tab or by swiping the whole area under the tabbed navigation to left or right.

Favorite pages are by default the 6 most viewed webpages. They can be configured and moved by touching them long. They can be deleted by pressing the close button in the bottom right corner.

Active URL bar

(click image for larger size)

Active URL bar shows the full URL including protocoll.

Multi purpose favicons have three different behaviors.

  1. If an high-res favicon ( >= 40×40) is available, it will use this, but masked with a breeze browser icon shape.
  2. If there is no favicon at all, it will use a grey version of the breeze browser icon.
  3. Last but not least if a normal favicon (usually 16×16) is available, it will be centered on top of a grey dimmed breeze browser icon.

Webpage view

(click image for larger size)

Back and forward button for webpage navigation.

Progress bar is only shown while loading a webpage and gets hidden again when thats done.

URL bar with website shown truncates the protocoll to show more of the URL. There are more possibilities like to truncate the middle of the URL and just show then end of it again. This could look like that for example ( could be ( – page.html). Also on secured or unsecured connections the domain name could be colored green or red.

Combined stop/reload button shows stop button while loading a webpage and reload button after it was loaded.

Scrollable area is the area used for the website. As you scroll down the URL bar moves with the webpage out of the screen. When scrolling to the top it will be shown again. To avoid scrolling pain on very long pages the URL bar should be pushed in again with a small but fast flick down (scroll up). This behavior is used on several browsers on Android and maximizes screen real estate while browsing. I have recorded a short Youtube clip to demsonstrate this on my Nexus 7 tablet with Firefox browser.

Firefox Android scrolling behavior

Extended URL bar

(click image for larger size)

Tab navigation tabs selects between 3 different types of tabs. Normal local tabs, Private local tabs and Synced remote tabs (if Firefox Sync gets implemented). No swipe changing available here.

Add new tab button adds a tab in the active Tab navigation tab

Active tab is shown by a blue outline. As soon as another tab gets selected, the extended URL bar gets decreased to normal size. Same happens for any touch outside the extended area.

Settings button will show in app setting or shortcuts to system settings. The final settings behavior for apps with Glacier UI is not decided yet.

Scrollable tab area is swipeable as soon as there are more than 3 tabs open in the active tab navigation tab.

Inactive tabs are grey outlined.

Tab description shows either page title or domain name of it’s tab.

Tab close button closes a tab. Tab closing could also be realized by swiping them up or down. Closing last tab from any tab navigation tab jumps to startup experience.

ContentRoller and ContextRoller

Posted in Thoughts by

While discussing how to do the context menu with Morpog over at #nemomobile and taking into account the problem of the ever-growing smartphone screens we came up with what I think is a brilliant idea.


On harmattan, when you long-tap on a list item or a browser link, the context menu appears right under your thumb, and that means you can’t see what’s in it until you get your thumb out of there. (This incidentally is why the menu bar on the original Windows Mobile was on the bottom of the screen rather than the top) so we thought about putting the context menu at the top, as we don’t have as status area to confuse the user with anyway. This has a slight problem in very big devices, as the user will have to stretch his thumbs a bit to be able to click the items in the context menu.

Morpog had the idea to make the context menu wrap around so that the user can bring the desired menu item somewhere he can reach, just by pulling down. The awesome thing about this is that it can work in all non-infinite lists, and provides some extra advantages too. Imagine if the contacts list could wrap around indefinitely. You can easily reach the Z contacts by just pulling down a bit, and makes it easier to bring the first few contacts to a more manageable latitude.

Of cource a clear indicator (seperator) of where the list wraps around is advised, and this could snap into place at the start and end of the list to make things easier. The user will have to deliberately force the wrap around of the list. When flicking normally, if the list reaches the end (or start) by just momentum, it should reveal a bit of the start and bounce back to the end. If the user still has his finger on the screen and continues to pull, the list will wrap around.

Thus the idea for ContentRoller and ContextRoller was born. The first is a wrappable ListView and the second one a wrappable ContextMenu.
A nice example of the above interaction is the harmattan picture gallery. Open up a picture, zoom it in and pan to the end of it, either left or right. You can see the previous/next picture getting slightly into view, and if you pull a little harder you can switch to it. In this case it needs a bit too much pull and makes it difficult, but a vertical implementation of this has the advantage of more space for movement.

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.

More icons and how to make your own

Posted in Thoughts by

I think I completed all the icons for the current built in applications of nemo. Here they are.


There are three types of icons in this iconset. The first, and preferred one, if you can manage to do it, is to find an object representative of your app that is circular, like the dialer, or the combination locker. It doesn’t have to be absolutely circular, some parts can stick out of the circle and actually this practice is recommended.

The second type of icons are objects that are not circular but can be easily recognized even if modified to a circular shape, like the sticky notes, or the packages. This can be done by either cropping or reshaping the object.

The third solution, least recommended but always easy to do, is to just paste any icon over a colored circle. This is actually recommended for logos of established brands/apps who do not allow their logos to be modified. The circle has a radial gradient from the center to the rim, with the lighter part at the center and maximum difference in lightness between rim and center at about 50.

Here is the calendar icon in svg to base your own icons on it. You will need the open sans font


Posted in Thoughts by

Icons are a very important aspect of a mobile OS. You see them all the time. And Nokia has treated us with what I believe is one of the most fine icon sets of all time with the N9.

While I admit that I like borderless/backgroundless icons (N900, Android) most app developers have no icon-making skills and make really ugly icons, especially in the FOSS world where no big corporations with design department do apps.
So when your app grid gets filled with 3rd party apps, having a background makes the grid as a whole look much more consistent and tidy.

That’s why apple auto-composites icons to it’s own background. So that dev’s don’t even have to bother with making an icon look like the others. They just choose an image and it does the compositing (there’s of course the option to disable that and create your own composited icon).

My idea is to create a dominating shape for all icons which is not a hard background like N9 but just a guideline for all OS apps. The icon is allowed to deviate a bit from that shape with things sticking out or negative space eating in.

For example look at the settings icon of FirefoxOS

FirefoxOS iconography

This gives freedom to designers to create something special but also allows developers to use a generator that slaps any icon of any shape on a circle (or crop it to a circle) and create an icon that doesn’t look out-of-place.

Hurrian’s icons use this approach, and I am readying an icon set myself that adheres to the same guidelines.

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.