An attempt for a better mail client

Posted in Thoughts by

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.

mailbox_iphone_5_screens

triage_screenshots

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.

nexusae0_2013-10-31-22.34.48

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

2014-05-11 at 18.21

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.

mail_main_view_mockup1

mail_main_view_mockup2

mail_main_view_mockup3

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.

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 ?

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