About settings

Posted in Thoughts by

Next thing twisting around into my head is the settings application. And the first thing that comes into my mind is the stupidness of the iPhone approach, that like everything iPhone, is being copied around without any attempt to think.

Consolidating all the settings for all applications in the settings app, is plain stupid. It does not even work towards it’s main goal: consistency. There is no reason whatsoever that I would want to tweak a setting in the documents application and twitter application at the same time. So there is no reason that those two should be together. Now when I am in the camera application, I expect to be able to change settings like image size or flash used or quality of saved pictures fast. It’s unacceptable to have to suspend the camera, go to the launcher, swipe one or two pages away, open settings, scroll to camera, change setting, go to the launcher, launch camera and take a snap. Obviously the settings should be in the camera application hence we just introduced inconsistency, because the camera settings are in-app and the twitter settings are in the control panel. Not that in twitter the above procedure should be acceptable, but anyway.

Harmattan takes this stupidness to another level. Not only it copies the all-settings-in-settings app, there are two kind of settings applets. One that is an application by itself and another that is a page in the settings stack. So you go to one entry and you have to press back to go back, and then you go to another, and you have to close the window to go back. Madness. The weirdest thing of all is that instead of fixing this, Nokia just replaced the entries that point to different apps with buttons instead of list items producing this ugly, confusing interface.

Of course there should be a control panel application, and developers should be able to develop applets for it for things that do not otherwise need to have their own icon, like calendar feed, theme customizer etc. But for all other applications that have their own window, it is absolutely saner that they put their settings in their app.

There should be a specification for where the preferences/settings/options should be in each application so that the user will know how to find them, as well as how the menu item should be named. For example on a windows machine you expect to find Tools|Options in every program. On a Gnome Desktop, you expect to find Edit|Preferences in every app. Firefox changes it’s behaviour accordingly, and you will find Edit|Preferences on Ubuntu with no modal windows and live updating settings while on windows you will find a modal settings window with an OK button under Tools.

So, let’s say that we will call the settings page Settings, and it will reside either in the toolbar behind a gear icon, or in the menu, under a settings item.

Mockups of the notifications using the home nav-bar

Posted in Thoughts by

This is how it could be in real life. Please notice the two possible implementations at the top of the phone. The first one moves the whole window up, which causes the titlebar to be covered. This is easier for application developers because they don’t have to care about resizing of the application window (which they will probably will anyway, to cater for the vkb) but if the application has controls on the titlebar, the user will have to dismiss the notification before using them.

The second solution resizes the window so that the above problem does not occur, but it is less impressive. During the animation, the application window will not move, and thus the notification will be less obvious (or less distractive depending on they way you see it).

For how the whole system interacts see two posts back.

Don’t judge the message/call icons, I didn’t put any effort in those, they are just for illustration purposes. Of course we’ll have to make better ones if this is to be implemented.

The third image shows the state if more than one type of notification is present. This could be replaced by a slow crossfading slideshow of those two icons instead. (I vote for the slideshow)

Notifications

Posted in Core User Interface, Thoughts by

In every mobile os there is a need to notify the user about incoming messages, calls, emails etc. Let’s first check out how the others are doing it.

Modal popup

Older Symbian, Windows Mobile and the iPhone use the classic method of a modal pop-up window.

New Message: info

OK     CANCEL

This is the simpler way of all to notify the user, but it’s obtrusive and annoying. All three have since switched to less obtrusive methods, so there is nothing to see here. Let’s move on.

Banner

Newer iOS and WP7 use a banner that appears at the top of the screen (with the respective animation) which upon clicking redirects the user to the proper application.

This is less obtrusive than the previous one, but it still is, and there isn’t any obvious way to dismiss it. Auto hiding it after some seconds means that there isn’t a quick way to go to that notification anymore, and one must check which of the icons or tiles has a new notification balloon. With many users not bothering to check every notification that comes in, it may easily be lost between the 124 twitter notifications and 36 unread mails.

Status menu

Symbian has copied android where the notifications reside in the pull-down status menu. The notification flashes on the status bar and an icon stays there to remind the user that something has happened. The status menu is omnipresent, and with a quick swipe the user can check the notifications at his convenience, after finishing the task at hand, dismiss any one of them by swiping it away (android) or all of them. This is one of the best approaches. It is unobtrusive, yet informative and provides quick access to both interact or dismiss.

Harmattan madness

Harmattan has a similar status menu. It doesn’t open with a swipe but with a click but that’s not a significant difference. The notifications flash on the status bar as above, and if you are ninja-quick and click them in the brief moment they show there it takes you to the relevant application (which has to launch and that sometimes takes some time). If you don’t click the notification an icon remains on the status bar to remind you. If you do the most intuitive thing, click the icon (or if you miss the notification by a fraction of a second) the status menu opens, which has nothing relevant. You need to close the status menu, swipe away any open application, swipe to the events screen where the notifications reside with an option to view any of them or clear them all.

I understand that the notifications naturally fit in the event screen, but even now, more than half a year with a N9 as my primary phone, I still open the status menu to find the notifications, so this is clearly bad design. They could have used redundancy there as the least bad solution.

Maemo glowing switcher

In maemo when a notification comes in, a banner flies on the screen briefly and then the switcher icon starts glowing. The respective application opens in the background and is overlayed in the switcher by a nice looking overview of the notification. While this method uses only a subtle glow to notify the user that some application needs attention, and without going to the switcher there is no info about the kind of notification, it is unobtrusive, beautiful, and quick, as the application has already been started in the background, and activating it is instant. It doesn’t work well when there are so many applications open that the switcher needs scrolling, but this can be solved by moving the glowing apps to the top.

Next post will include two possible solutions of the notifications problem on nemo.

More thoughts about discoverability

Posted in Thoughts by

Timur’s blog made me think of some things about discoverability so I’m posting a follow up. Hidden UI features are very appealing to designers because they make interfaces look good by removing clutter. They also remove complexity from procedures. But they are completely useless if the user can’t know they exist, or frustrating if the user expects them to be there and can’t find them.

Redundancy

The iPhone uses a very nice gesture to implement the delete function in lists: swipe away. This is completely hidden, however, so they implemented the classic method too (click delete items – select – ok). Not perfect, but preserves discoverability while providing a more efficient way to delete things for those who know the secret.

Redundancy while not removing clutter, it does help to simplify procedures for the adventurous user.

When hidden features are actually ok

There are two cases where hidden features are ok. Mobile phone OS interactions and well known features. The first one, (harmattan swipe falls in this category) is okay because, as Timur mentioned, an intro video is enough for the user to learn it. A mobile phone is personal, you don’t expect other users to use it regularly, and being so personal it gives the user some satisfaction “to know it’s secrets”. Just as swipe is hidden and confusing, so was the inexistent back button of iOS. Coming from a pc/symbian/winMo environment I couldn’t expect to have to go back to the switcher to exit an app. But it made iPhone owners laugh at me, put on their professor face and ‘teach’ me how to use the iPhone.

The second one is when the interaction is well known (tap&hold) or when you expect it to be well known. Things like drag&drop, tap&hold, pinch to zoom would never become mainstream if somebody didn’t put them there in the first place accompanied with an annoying ‘Don’t show me this again’ intro screen to explain them. Now of course the designer must be modest as to what he can expect to become well known.

P.S. Google Chrome for Android has implemented swipe from edge to change tabs. This shows that in a few years time this gesture may be well known and fall into the second category instead of the first.

Of home screens and discoverability

Posted in Thoughts by

Hi! My name is Timur and Qwazix was very nice to invite me to this blog. I’d like to share some of my views and ideas about mobile user experience.

Let’s talk about home screens on mobile devices.

A home screen should get a lot of things right to be able to call itself user friendly. First of all, everything should be available as easily as possible and frequently or recently used things should be reachable in as few interactions as possible. It also has to do this in a consistent, non-confusing manner.
Most of the home screens nowadays can get you to your favourite app in at most 2 taps (+1 if the screen is locked). Examples: Fremantle, where one click takes you to the app launcher and the other click will launch the app. Harmattan can also do this: one swipe to get to the app launcher screen and a tap to launch an app. Android and Symbian offers the same way.

A more difficult thing to get right is correct presenting of multitasking. This appears to be very hard to get right, because most mobile OSes actually get it wrong. Android almost gets it right but makes it very unintuitive, iOS got it wrong by making it totally unintuitive, and Symbian got it wrong by hard navigation and sluggishness. Fremantle is quite okay, but Harmattan is the best because of its obvious simplicity and straightforwardness. WP7 got it totally wrong because sometimes it shows the same app multiple times, apps being freezed in the background, and the actual annoyingness of navigating the multitasking screen.
There are quite a few lessons to be learned here: first: the OS shouldn’t kill or freeze your apps when you deactivate them. The user should be in control. Second: simplicity and ease of use is key. Third: showing thumbnails of running apps instead of their icons makes it lots more intuitive. (And also reduces visual confusion by setting it apart from the app launcher.)

There is also a very important aspect to user experience that has been quite neglected lately. And that is discoverability.

What is discoverability?
It basically means that the user can discover how something works by just looking at it. Yes, this is as hard as it sounds. This involves giving visual indication about certain things. Such as hints to the user about what he/she can do on your UI.

A good example of this is WP7’s panorama pages feature, which indicates very clearly that you can scroll horizontally on it. (It’s not very effective for advanced UIs though because of its obvious disadvantage of losing lots of screen space.)
A bad example is the “hot corner” in Gnome Shell or Windows 8. While it’s fun, it’s totally non-discoverable, because you don’t have any idea that the feature exists until you read about it or accidentally trigger it. Not very nice.
This is where Harmattan doesn’t fare very well either. Swipe is a wonderous gesture, but you need to learn it – anyone who I show my N9 is totally clueless about how to use it. :) Fortunately it at least has a nice tutorial about it when you first turn on the phone, so at least owners of the device will definitely know how to use it.

About swipe to switch between Harmattan’s home screens: this concept works very nicely, but only if you have exactly 3 pages. When you have 3 pages, you can still reach any page from any other page with just a swipe. However if you had more pages, this wouldn’t be true anymore and would be annoying.

To eliminate this issue, I’ve introduced a tab bar to the new Nemo home screen. Right now only two of the tabs are implemented, but I plan to add more. Navigating with swipe remains possible.
With a tab bar, even someone who has no prior knowledge of the layout can easily navigate the interface. Also, if the interface has more than 3 pages, it remains possible to switch to any other page by just one tap. And the tab indicator helps keeping track of where you are now.

The first iteration of the home screen is done and available in Nemo now. It’s not perfect, as from various user feedback and contemplating I’ve got several new ideas on how to improve upon the design.

I plan to write a new post about this and the conclusions (with sketches, of course), but until then, if you have any feedback, I’d be very glad to hear about it from you! :)

“Direct” UI’s and the selection problem

Posted in Thoughts by

When the iPhone was released, in 2007 everything changed in mobile User Interface. Apple wasn’t the first to implement touch scrolling, (remember the HTC touchflo interface on the first HTC touch?) but the first to integrate it tightly with the system and use it consistently throughout the OS. I was really excited waiting for the Nokia 5800 to get the full kinetic scrolling update, and I loved the fact that they also kept the scrollbar.

Several years have passed and I recently got a N810, a device from the pre-kinetic era. I opened modest and I wanted to move several files to another folder. What a revelation! Drag to select as many files as you want, and then drag them over the destination folder. The same procedure on the “kinetic” N900? Menu -> Move -> tap on each file to select it -> move -> tap on destination folder -> tap to move. I think we have a regression here. The “scrolling” layer that resides above everything and disables one of the most used gestures in computer history, dragging, is sometimes a problem.

Three solutions to this problem:

Scroll Bars

What? scrollbars are a thing of the past. Even pc’s are getting rid of scroll bars! I know, I don’t mean traditional scrollbars. I mean that the area that allows for finger-scrolling should not be the whole screen. A band on the right side of the screen is enough for scrolling, and the rest of the screen can be used for selecting and dragging.

Multitouch

Dragging with two fingers can be configured to behave just like dragging with the mouse on a computer. This has the problem that the two fingers have a much bigger contact surface and would prove difficult to point accurately. This can be solved by providing a standard place for one finger which, while touched will enable the other to do dragging and selecting. This can also be done using the proximity sensor for non multitouch devices.

Cursor mode

Much like cursor mode of MicroB on the N900, a toggle can be clicked and the behaviour should be just like that of a desktop computer. Tap/drag to select, drag selection to move.

Introduction

Posted in Thoughts by

The following are my thoughts and ideas for a User Interface guide for #nemomobile. I think that a blog-like interface is the easiest way to collaborate around mockups and ideas for user interaction. I am hoping that my work, after discussion with the nemo developers and the necessary modifications, can evolve into the official UI guidelines for core nemo development as well as for nemo applications.

Nemo shares a lot with harmattan, and harmattan is a really user friendly and addictive OS, but many users and nemo developers have expressed their intention to incorporate some things missing from harmattan, like widgets. One of the goals of this project is to find a way to incorporate these additional features in a way that is consistent with harmattan’s simplicity and ease of use. Another goal is to give application developers ideas and guidelines so that nemo applications have a consistency between each other as well as between them and the stock applications.