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 firstname.lastname@example.org: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|
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.
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
This is my proposed iconset for breeze.
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)