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
I have started working on speccing each and every glacier control.
If you want to contribute, please clone the repo at email@example.com:qwazix/glacier-controls-spec.git
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.
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)|
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)|
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|
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.
- Default font
- Standards for colors and states (active, pressed, inactive)
- 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: http://play.qwazix.com/grog/?p=318
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)
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:
Have you anything to add, comment or critic? Did I forget some fundamentory stuff? Please feel free to add your opinion.
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.
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
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
Active URL bar shows the full URL including protocoll.
Multi purpose favicons have three different behaviors.
- If an high-res favicon ( >= 40×40) is available, it will use this, but masked with a breeze browser icon shape.
- If there is no favicon at all, it will use a grey version of the breeze browser icon.
- 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.
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 (http://talk.maemo.org/subdir/archive/november/page.html) could be (talk.maemo.org – 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.
Extended URL bar
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.
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.