Post tags

Featured

Posted in Core User Interface, Marketing material, User Interface Guidelines by

The posts are tagged proposal, draft and final. The proposals are just that. Things that come off our minds, and they might be plain stupid. Drafts are ideas that are generally acceptable and work can be started based on them, but more discussion around them may bring changes. Finals are guidelines or mockups that should be implemented as specified.

All the sources of this project available at https://github.com/qwazix/nemoux

the homescreen

Posted in Core User Interface by

This is the first draft of the homescreen. Next up is a visual guide of how everything stacks up.

We are keeping the basic layout of Harmattan with three homescreens. The events screen stays almost the same with the difference that the user can act upon the entries there (reply to a tweet etc). The app grid has the added functionality of widgets. Widgets can be tied to a specific app, or be an app by itself (i.e. an app that doesn’t have a full screen UI at all). Widgets are configurable, and can be configured by pressing the pencil button in edit mode. Pulling down beyond the first row should reveal a search box, just like on Harmattan mail application.

The multitasking view gains the possibility to pin applications to specific positions, just like the new tab page of firefox. Pinned apps should autostart at boot.

The notifications section is grouped by person instead of by app. I think this is a more natural approach, but I’d like your feedback on that.

homescreen

Edit mode can be activated by long tapping on any icon. There you can change positions of apps and widgets, or throw them away by dropping them over the top area of the screen. Flicking them to that direction should also work (see android desktop for that effect).

homescreen-editmode

some thoughts about sailfish

Posted in Thoughts by

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.

Quest for unobtrusive dialogs

Posted in Thoughts by

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.

Custom_Dialog

android-usb-mount

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.

doseditwindow

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.

melody_makerYes, I dare to call that a dialog! (a query notification if you prefer)

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 ?

2013-11-28 at 03.21QtControls

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)

query_dialogs

Obtrusive, full-screen, not avoidable dialog. For critical matters only!

normal_dialogs

Appear at bottom, allow limited multitasking (like scrolling text, etc…), non obstrusive yet functional and informational.

inline_dialogs

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 ?

Notifications on Glacier UI

Posted in Thoughts by

Notifications for GlacierPositioning for emphasis.

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 cursor interaction investigation for Nemo Mobile

Posted in Thoughts by

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.

ios_n9_cursor

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).

q5cursor2

/ 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.

android_cursorwoce_cursor

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.

ibm_cursor

  • 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:

nemo_cursor_props

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’?

selectRoller

Posted in Core User Interface by

This is the first of a series of controls which will use the Roller interface. More about the roller and how it works here http://play.qwazix.com/grog/?p=385

selectRoller

There are certainly more details missing, so please give it some thought and ask, as I can’t right now figure out what is really needed for a complete spec.