Due to feedback and to better align with our goal to provide glacier-home as a drop-in replacement for jolla home, here’s a new mockup of the home screen edit mode.
I see people asking what is Glacier on IRC so I thought I’d write up a short piece about it.
Nemo is a mobile Linux distribution. It is based on mer core and provides a UI for it.
Historical note: Until recently Nemo also provided the middleware, which is pending to be folded into Mer simplifying things.
UI can be divided into three subcategories
- The controls: buttons, sliders, menus, tabs etc etc
- The home screen: the interface you see when you light up your device, think of it as the Desktop Environment on your desktop Linux distribution, e.g. Gnome Shell
- The core apps (phone, calculator, browser etc)
Nemomobile supports themes. The default theme (think Adwaita) is Glacier. Just like Android 3.0+ has Holo as it’s main theme. We plan adding an alternative theme, Breeze, when and if there is enough interest.
Most of the controls are already completed. Some of them need polish but they are mostly usable.
Most of the nemo applications still use the old Harmattan-ish look, and some are outright missing, with the biggest absence being a modern browser. The applications need a lot of work in order to be Glacierified and some of them still need to be coded from scratch. Due to limited time and contributors this will take some time.
We are very eager however to get our work to real users as soon as possible. Doing that will also help get more contributors. Scratching an itch is the cornerstone of the OSS world and we want to give developers an itch to scratch. Since we share a lot of common code with Sailfish, the Nemo homescreen can run unmodified on top of Sailfish. Thus, our short term goal is to make Glacier Home a viable alternative to Jolla home, just like the countless android launchers that are available on Google Play.
This means you get to experience the Nemo homescreen, any Nemo apps you want, plus all your Sailfish and Android applications. Things like the missing browser are no more a showstopper for using Nemo as your day to day phone OS as you can substitute the sailfish browser or your favorite Android browser. Of course consistency takes a big hit, but it’s a fair price to pay.
The next step is to provide a compatibility layer for Sailfish applications to look native on Nemo/Glacier, and finally finishing the applications that we need to have a workable and visually consistent open source OS
For the record, I’m currently using the heavily WIP (by locusf) Glacier Home on my SbJ and here are my notes about what works and what doesn’t. We are almost there so any brave soul that wants to dive in and gain an itch to scratch, follow this guide to try out the latest nightly http://locusf.blogspot.gr/2014/03/glacier-ui-homescreen-on-jolla.html
The folder should slide down when it’s icon is tapped, pushing everything below, just like the sailfish context menu does. We might consider flying the icons from the folder icon to their positions when the folder opens, but I don’t really know if this is too much animation.
The folder icon consists of the first four folder icons, at 90% of their normal size, overlayed and semi-transparent (0.6 opacity). Their follow the pattern below
If icon 1 is at coordinates 0,0 icon 2 has coordinates 6u,-6u icon 3 has -6u,6u and icon 4 6u,6u
Most of our interactions with a computer start with a text input box. Either the start menu, Google, or the browser url bar.
The new personal assistants devised by the big software companies are robots that are created to obey our commands and do what we tell them
wasn’t the original command line exactly an attempt to do that? The 1970’s and 1980’s processing power and computer programming accumulated knowledge wasn’t enough to make this interface easily usable and the focus shifted to other things like buttons and menus. The few features of those programs made it easy to arrange a set of icons of the screen one for each function.
Once the features started to increase, deeper and deeper menus and dialogs proliferated and finding a function or option was obviously harder when digging through endless windows than searching through a text file. But searching through text files or using the command line was already deemed old-fashioned and forgotten.
Even today, when somebody sees me typing into the linux terminal I get all kinds of reactions of awe and disgust , as if I am doing something magical. Most things I do through the terminal however are really easier to do that way.
$ convert image.png image.jpg
for example, is much easier than opening the image in GIMP, waiting for it to load fonts and extensions and then hitting file > export and then OK twice
So, what is the problem?
Discoverability. It’s hard to know what command to use and what it’s syntax is. This is greatly exaggerated by the multiple developer nature of GNU/Linux as each command has it’s own syntax and there is no consistency whatsoever
Can it be fixed?
In my opinion, easily. Using standard tools like aliases to make commands have more obvious names and by taking ideas from modern IDE’s to add visible autocompletion and help messages. This needs a couple of brainstorming sessions but here’s a first idea
How this affects nemo?
Nemo’s target audience, at least for now are geeks: Geeks like telling their computers what to do and are not afraid of using the terminal. So my proposal is to modify the home-screen search box to also accept terminal commands.
The commands will have a faded autocomplete with included help, and the various autocompleted options will transform into drop down menus when clicked. All this functionality will use plain old bash autocomplete to work.
Bash autocomplete can also be used to increase the size of the keyboard’s sensitive area for letters that are more likely to be next.
More traditional commands will be executed and the output will be printed in the results space in monospaced font, along with some relevant options.
There will be a whitelist for commands that execute instantaneously and the output of those commands shall be displayed as-you-type in the space below the search box
What is needed?
Not much. Apart from some GUI work, we just need to create sane aliases and commands for most phone functionality. These commands should be a bit lax on the syntax, for example the
call command should accept
call <contact/number> [[on|at|] <numbertype>] so all of
call Eva at home,
call Eva on mobile and the more classic command-like
call Eva mobile produce valid output.
There is no need to accept
please call Eva on mobile as the goal is not to create a natural language parser but rather to be similar enough so that commands are easy to remember.
I am a huge fan of mail clients. It was a time where I used to check every once in a while if new ones were available for my platforms. To tell the truth, I was rarely impressed.
What I found is that trends come and go, and devs tend to follow them blindlessly, mostly to get attention and money (the « mine is better than yours » addage). Sometimes, one stands out and got my particular attention. I’ll get to it in a minute. But right now, let’s review the competition.
Today, the trend is at action-based emails: set reminders, put them in your todo list for later review, file them in lists or folders, etc… We have Mailbox, Mail Pilot, Boxer, Dispatch… to name a few, while -sorry- they’re only for ios platforms. Another trend is at quick review clients, where you have your mails stacked and just flick through them quickly to get « inbox zero », the real trend behind them all.
Up there are in order of appearance: Mailbox and Triage for iOS
Stock mail clients are quite raw around the edges, some better than others. I didn’t try all of them but the most popular ones (android, ios…) and of course harmattan. They do the trick, but that’s all, no fancy here, just plain old mail management with no real advanced functionnality.
Stock Android client
Do we want advanced functionalities ? Do we need « inbox zero » ? Or is there something else that could be done to be more productive on mobile devices ? Of course, some of us like lists or folders, some like « uncluttered », but did they have the opportunity to try… well, something else ?
That’s where I stumbled upon Unibox. It’s a mac only client with a particular, unique philosophy: sorting mails by « people » instead of « conversations ».
Unibox for Mac, with it’s view “by people”
So simply put: you have a list of senders sorted by most recents, and choosing one show you *all* mails and conversations from him/her. Coupled with a good search engine, I believe this is a good workflow. Again, with the choice to sort by « people » or just « conversations » (have them both), this become a killer one. And that’s actually what lacks for Unibox in my eyes: an old conversation could be burried behind tons of new mails, even if they’re marked as « unread ». Quite a bummer that we tried to overcome in our new concept.
From top to bottom is older concept to newer one, aimed at simplicity.
Specs coming soon.
So basically, it’s two mail clients philosophy in one: people and conversations. The new, interesting concept and the old, legacy one.
I’ll let you judge by the screenshots, and encourage you to give your opinion or ask questions in the comments.
Following this post I completed the specs for the time and date picker. Here’s a sneak peek:
please comment if I missed something
My first thoughts about Sailfish were that it was a bit too convoluted, that they broke their own architecture of hierarchy either in app or out, at random.
I also didn’t like the new fade effect instead of harmattan’s swipe, and thought of it more as a patent avoidance issue.
Now I think I was wrong. I was trying to find an analogy to the actual world and I constructed one, then thought that some parts of the OS were breaking it. Truth is there wasn’t one.
The fade animation I mentioned above is not just a different way to handle swipes. It tells you right in your face, that there aren’t any layers. You can swipe from the same edge to toggle two views: good luck finding a structure with a physical equivalent that has this property.
iOS’ 6 skeuomorphy was a visual one. Harmattan’s was a structural one. You could always have an analogy of layers in your mind which helped you remember where you were supposed to find things. Like all other real-world analogies, they are good as long as the user is unfamiliar and hasn’t yet fully embraced technology, but after a tipping point it becomes an obstacle, and one very difficult to overcome, just because **everybody else does it that way**
For how many years have we put up with an inbox and outbox in our mail/sms software? It has clogged the internet and filled our mails with TOFU replies just because years ago we had inboxes and outboxes on our physical offices. It is obviously better to sort by conversation, we were just too blind to see it.
Files and folders in filesystems are another example. In the real world you can’t put a file, the same one (as in if you change one, changes appear in the other location too), in two places at the same time. We still keep that limitation in modern operating systems, despite being only a logical one. Hardlinks are supported by all modern filesystems, yet there is no integration in any modern OS. (On the other hand, GMail has abused IMAP folders -calls them labels- to put an email in two folders at once).
Sailfish has gotten rid of the structural skeuomorphy. And it’s beautiful. It allows gestures to be general purpose, just as software buttons are. A swipe right can mean different things, like Accept, or go to relevant information, or something else. Visual cues are there to teach you what a swipe will do at each time, you just need to erase your muscle memory and look before you swipe, just like you look at the label before you press a button. Is it slower? Maybe. But it allows for so much more functionality without adding clutter that it’s worth it. Because there are countless times where you can’t put something there just because it breaks the self-imposed structure.
This is the reason most reviews said it’s too complicated: you can’t expect things to be in a certain place neither because they are there in other platforms, nor because they follow a replica of a physical media. You have to learn where things are. But they are a few of them, they are easy to learn, and that effort is well-compensated with the ability to do more with less clutter.
I’ve got some concerns on the other hand too, however: silica is too much focused on listViews. A great bunch of content-consuming apps are really lists, but the current offering seems unable to support productive apps. What about editing a 10-page long document? Will I have to scroll to the top to access the pulley? How would a context menu on a page look like? Is it up to the developer to decide?
Even if the current component set is to be streched to it’s boundaries to support more advanced applications than your run-of-the-mill twitter client, I think that some official mockups would help a lot to establish UI practices.
Sidenote: I’d like if a swipe back from a specific view could be ‘undone’ just like forward in the browser, or like the nautilus breadcrumbs: as long as you don’t branch away from the path, the forward/deeper history remains.
What’s the most common dialog UX you see when you use a computer, irrespective of OS? I’d bet the « OK » / « CANCEL » type. The one that appear in the middle of your screen, yet can be moved in a less annoying place to let you see what it is talking about. This is for computer : you are asked to give immediate attention, with possibility (most of the time) to focus on another task and answer later.
With mobiles, that’s another story. Lack of screen real-estate does not allow for a convenient way to « move » a dialog, so they just appear and you have to deal with them now.
They could have made this more seamless, don’t you think ?
But, let’s get back to computer for a minute… As it always been like that ? I mean, OS wise, dialogs are almost always obtrusive, coming in the way that you like it or not.
This is where it all began
Yet, if you’re familiar with command line programs, and particularly DOS programs with a GUI from the early 90’s, you’d know that first GUI’s “dialogs” weren’t always obtrusive. Sometimes, since they were half textual/half graphical, they queried right at the bottom of the screen. Usually you’d have to press a key, but sometimes they’d appear complete with an « ok » / « cancel » type button (I remember a GUI for Povray that used those kind, although I couldn’t find a screenshot to show you). Those were not in the middle of the screen and you could see relevant stuffs you were doing before the query.
So unobtrusive queries exist since the 90’s. They were actually dialogs. The first unobtrusive dialogs. They asked or proposed the same thing as plain sight ones, but did it discreetly.
Old concepts of obtrusive dialogs are not relevant anymore, with mobile devices and enhanced multi-tasking in the game. In the first case, you’re back to the good old command line situation: the query dialog will not allow you to embed that much informations, due to screen size, so why use the whole screen? In the second case, well, you know: why be obtrusive when you can simply appear and disappear while the user do his stuffs ?
Screen edges notifications have always been there … (yes, it’s nano, but you know what I’m talking about – to the right is nemo notification concept, which shrinks the screen and disappear with a swipe)
That, industry giants have understood only since a couple of years, and it’s seen as the notifications revolution, while the idea was there since the beginning, only nobody seemed to have noticed… Yes: notifications are another form of dialogs, let’s say « semi-passive » dialogs
So let’s extend this “new” notification dialog concept to query dialogs, and see what we can do.
Well, what are we looking for exactly ? What do we need, dialog wise, when we’re not looking for « semi-passive » notifications ?
– Query dialogs for really important matters (you need to answer it now, and I will not let you procrastinate while I’m asking!)
– Normal dialogs for casual stuffs (you can continue your work, but would be good to answer soon: you can’t dismiss me, but you can still do limited stuffs while I’m displayed)
– Inline dialogs (there’s some added stuffs you can do here, so take a look and dismiss me when you’re done, I will not stand in the way)
Obtrusive, full-screen, not avoidable dialog. For critical matters only!
Appear at bottom, allow limited multitasking (like scrolling text, etc…), non obstrusive yet functional and informational.
Inline dialogs: you tap, it appears, you select, it disappears. Simple, yet elegant. And cherry on the cake : customizable by developers.
Working demo : link (use chrome if possible)
So here we are, new concepts are on the way, everybody trying to find something more intuitive than the competition, and that’s our take. You still have obtrusive dialogs, but we’ve decided it was impossible to avoid. Otherwise, Nemo Mobile will try to bother you as less as possible.
What do you think ?
To clarify the earlier post on notifications on Glacier, here’s a nice, short illustrated version. And a sneak peek at the Gallery app.
For notifications that need user attention (but don’t take the user completely away from the current context), the entire viewport lifts up, uncovering the notification. The user can then dismiss or act on that notification.
For other notifications that aren’t as urgent, the viewport simply shrinks, the notification appears, and disappears after some time.
Quite sleepy as I write this, so maybe I’ll finish it up more tomorrow, when I have time.
A few days ago, Qwazix and I were investigating on implementing a way to move text cursor in Nemo Mobile, something that today’s mobile operating systems have already in their store with more or less success and usability. So the question came: how to be original while keeping ease of use and clever user interaction?
- The needs
Let’s see what the user need in term of cursor interaction. Basically, you’ve got a text that needs reformating and want to navigate inside it easily. It need to be quick, intuitive, and without false positive (i.e: you want the cursor to be at the end of the line while the cursor stubornly stays two letters before, no matter the number of attempts). This last one is very important since today’s offerings tends to get on user’s nerves, even on platforms such as iOS and Android that have large funds and top developers to overcome such issues.
- The competition
So what’s in the shelves of the competition? Well, the most common cursor interaction is without a doubt the ‘long tap show lense’ method. If you’re familiar with Maemo/Meego handsets, you must already know this feature, since it seems to have gathered a consensus between major mobile firms. Indeed you can also find it in iOS, along with other major OS’s on the market.
While interesting and practical, bad implementation makes it difficult to use at times, and false positive are from experience far from being inexistant. You may have to be patient and try several times before placing the cursor in the right place. The good is that it is quite touch friendly and intuitive, and good looking too (particularly BlackBerry implementation, see below).
/ a bit to the left, and the cursor move smoothly with your finger to this direction, with a nice colored feedback /
In the other hand, we have keyboard cursor handling, as seen in Android (at least with third party keyboards) and WebOS Community Edition.
The later is, in my opinion, the most interesting approach. What we have is a stick-like cursor which behave like the little red stick from IBM laptop keyboards.
- Finding the most suitable cursor interaction
Back to the question: what’s best for Nemo Mobile? Well, since the OS will primarily be used on handled phones, we need something that require the less movements possible from the hand/finger, meaning we don’t want the user to need to touch and slide along the whole screen just to reach ‘this particular piece of text’. Secondly, we want the user to find his way easily, in that he would not need hours and a good manual to find how to move his cursor along his texts. And last but not least, we need the less false positive as possible (none at all would be best, in fact).
We can already dismiss the magnifying glass-like implementation from iOS and Harmattan since it conflicts with our first issue. Also, we would not want something *too* original since it would need the user to learn a new trick in the already overcrowded world of user interaction. It may also conflict with our third and last issue since it would require testings and testings to remove as much false positive as possible (and since it would be completely new, we would be in unknown territory without previous trials).
So we figured out that the WebOS community and IBM (sadly, yes^^) were not complete fools when they proposed this stick idea, and that we may have something interesting here to implement as a cursor position switch: it’s intuitive in that it has precedent in OS interaction and doesn’t require much intellect to use, and by design it remove much of the false positive possibilities (the WebOS community has also proved that it works flawlessly when implemented well).
Now, behold gentleman. Our mighty proposition as a cursor interaction for Nemo Mobile:
In between the WebOS community proposition and the IBM red stick, it would answer the forementioned issues while being consistent with the Glacier UI design.
But since we know that the Nemo Mobile community will be the first to undergo this new feature if released, we want to know your opinion. So, do you think this is the right move, or would you prefer us to think harder and find something more original and less from the ‘physical world’?