Too much design

www.wpsauce.com

A Windows phone design article by Paul Thurrot, summarizing a "ask-me-anything" thread in reddit, reminded me about something that easily goes wrong in design: the design itself becomes more important than the product or medium it's applied to. Meaning, that more work goes into sustaining design as an activity; instead of treating it as an integrated part of making a competitive product.

What kept popping up throughout the article, was the need to differentiate Windows phone from others, through Metro's unique visual and interaction design (mainly focusing on application side though). This resulted in design importance raising out of proportion, disturbing the actual product work (make a great product). The focus was on finding a striking and novel design (too much), instead of making a relevant alternative to iOS and Android.

Alternative can mean being different, but it doesn't have to. A product that's just different for the sake of being different, is bound to have a design overdose. The only way to deliver an industry-breaking products, is by not designing it for the industry (remember what Apple did when it entered the smartphone market). That alone requires you to focus on problems that the industry tries to hide. Too much design will just make things worse.

The mobile industry has a significant ability to resist changes. Look at any usability studies. They all basically state that Android and iOS have reached the pinnacle of touch screen interaction. To put that in some perspective: they say that majority of desktop interaction patterns (the way you use mouse and keyboard to do things) are just as usable on mobile devices, as they were 40 years ago. Nonsense.

Usability studies like that show how amazingly well people adapted to our messy past with computers. Studies can always help to spot problems in both design and implementation, but the they tell nothing about our potential, our hopes, dreams or what we'll do tomorrow.

So, at the end of the day, those studies tell that the industry doesn't want to be broken.

"To go against it (industry) you need to earn it. You need to be far, far better." Being different for the sake of difference, is not enough.

With Metro, Microsoft experienced the hard way what happens when you put in too much design, at the expense of end user value. It failed to be relevant.


Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

The story of SailfishOS browser

Why on earth would someone start yet another browser project, when there's so many already out there? Well, because all mainstream browsers are more or less scaled down desktop browsers, than something designed with one handed mobile use in mind.

Looking at the image above, the two examples from the left are impossible to comfortably use without altering your hand grip. Also the reason for such design is obvious just by looking at desktop browser interfaces: they hardly need to be operated with one hand alone. I mean, try lifting your desktop/laptop with one hand, and enter a website address.

Even if you can somehow do it, it's not comfortable; and downscaling that interface design to 5" screens does not change that. You'll still need both hands to operate it, which is an unacceptable requirement for a simple tool that should increase your potential, not decrease it.

And that's where the third example on the right comes to play. Obviously, we're not doing everything by ourselves. We chose to build our web browsing experience on top of Mozilla's Gecko rendering engine, developed for the Firefox browser.

Then, let's look at the two major steps we took before ending up with the current SailfishOS browser design. There's some good things we learned along the way.

Version one

In addition to moving the toolbar down, the first design (click to enlarge) used separate pages for both tabs and website address. The aim was to avoid the performance hungry scenario, where some web content is rendered in the background, a virtual keyboard is open, and there's search suggestions on top of everything.

The toolbar had buttons for back, address field, tabs, reload/stop and forward. In the end, the design was discarded as too complicated to understand. The root cause was in the magnifying glass icon. People didn't associate it to searching the web.

Version two

The next image shows the design that actually shipped with the Jolla phone sales release (click to enlarge). It combined both tab and addres entry into a single page. And instead of a separate address eentering icon, it promoted easier bookmarking.

We got a lot of negative feedback for that design, as it added an extra step to searching something or entering page address, and also made tabs functionality unnecessarily complicated to understand, use and develop.

Version three

The current design brought back separated tabs and address entry points. Tabs still use a page, but the latter one behaves like a toolbar extension, so that you can still see a bit of the webpage underneath. Much more useful functionality was also added throught the expanding/collapsing toolbar.

The feedback has been really good, and although I'm not completely happy about two different gestures to get back to browsing (flick address overlay down to close it vs. flick tabs page right to close it), we're much closer to a modern mobile browser interface.

Something that supports the way your hand works, instead of how you moused around in desktop interfaces few decades ago.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

Sailfish OS growing pains

A pain that either forbids you from falling asleep, or aprubtly cuts your awesome dream short during the night.

It's your your junior legs that are hurting from a reason neither your parents nor doctors really know. A painkiller, accompanied with some medical jargon, is all that you're administered with. Followed by reassuring words about things getting better over time. And they do, because such are growing pains.

The Sailfish OS 2.0 demo software made its debut in Barcelona, at the Mobile World Congress. It got amazing reception from both Jolla booth visitors and media. It even landed us an award for the best tablet in show. However, our community and early adopters are not your average group of enthusiasts. Not too long after first hands-on videos reached youtube, various social media threads about missing features were open for business.

It's no wonder. That's the risk of demoing unfinished software publicly. But there's a solid reason behind us doing so. When it's your turn to be in the showroom spotlight, in-between some billion dollar companies with their competing products, you need to make everyone experience the end result. And demo software has the exactly opposite emphasis compared to something you use on a daily basis.

The demo software had to piggyback on easy and familiar features people can immediately recognize, understand and remember. Not on groundbreaking things that reboot the mobile computing or touch interaction, because those things require time to materialize during actual use. For someone already familiar with Sailfish OS, the demo software lacked many features that really add to the long term user experience.

But at the end, we didn't go to MWC just to show another product we've made. We didn't go there to show what we've done so far. We were there to represent everyone who has ever supported us. To make sure your decisions and voices count. This is a movement instead of technology. It's more human than anything else out there, so it has all the potential to grow to the right direction.

Even if it hurst a little.

I'm going to end with reassuring words about things getting better over time. And they do, because such are growing pains.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

4 design tips for edge gestures

This post is continuing my earlier article on harmonizing touch screen gestures.

Look closely at recent apps and mobile operating systems. Swiping over the screen edge to trigger navigation related action, is becoming increasingly popular. No wonder, as edge gestures are fast and comfortable way to interact with your mobile app or device. They have a huge potential in them, but only a fraction of it has been put into use.

It's not all unicorns, rainbows and marshmallows, though. These hidden gestures come with major drawback in discoverability and variation in use. Here's few tricks how to improve the way edge gestures can be put to use.

1. Keep it simple, consistent and fit for one hand.

I can't stress this enough. The less there's to memorize, the faster it's to master. Eliminate exceptions and special conditions when an edge gesture is not working, or does something completely different. Focus on a robust gesture recognition, and let the physical repetition do the work for you. It's like training in any sport, so make sure those training conditions are obvious to the user. Interfaces are just tools, and a good tool needs to be simple.

2. Think edges as physical buttons.

Edge gestures work especially well in controlling an operating system. A single edge gesture can be harnessed to perform similar kind of actions. For example, one edge can do things related to the power key (turn off screen, change profiles etc), while another one controls application window (minimize, close, windowed mode). Like in majority of other devices, notifications and whatnot could reside in another one.

So, with only three edges, an extremely competitive and simple interface can be built. If more than one action starts from the same edge, use absolute care in fine-tuning the feedback for it. The finger movement needs to feel different for your brain to associate them to their corresponding actions. Traveled distance, change in direction, speed or physical location, are all your usual suspects for separating them. Keep it simple, and prioritize the most used action.

The relation to hardware buttons helps people understand the idea behind it much better. Memorizing actions becomes faster and more natural, when there's a familiar relation between them. The reason for some actions not being available becomes more obvious that way. Take application window controls as an example. They are only available when there's an application window on the foreground.


3. The edge feedback is everything.

Just like with any other interactive elements, when user interacts with the edge, there should be an appropriate feedback on it. This is important for many users not familiar with interactive edges. Gestures in general can be performed so fast, that it's a good idea to keep the interacted edge highligted even after the gesture has been succesfully completed.

If your design uses gestures to control the application content, having different transitions for edge gestures and application content gestures is an advisable idea. It's a valuable difference to tell the two appart. After all, if edge gestures control the system level navigation, the feedback should be different than the application level navigation. Let's look at the hint animation for unlocking a smartphone as an example.

If you want to use edge gesture to unlock, you should direct attention to the interaction area. If everything moves (right side example), it implies parallel navigation (like going through images in gallery) instead. If you have plans for any lock screen controls (phone call controls, maps, flashlight, audio playback), you most likely should reserve that center screen flick for such actions.


4. Edge notifications and toggles.

This kind of edge indication can be used in several different ways to draw user attention to it. It can be indication of new content, or simply a reminder for a new user, that an edge gesture exist. The catch is that it doesn't introduce a tappable object on top of a keyboard or other interactive elements.

Since user is not able to control when someone sends a message to them (or when the system decides to emit one), it's annoying when a banner appears on top of link, only milliseconds before user touches it.

However, if the notification access is tied to the edge interaction, your tap will be registered by whatever it was intended for. The duration can also be shorter to avoid banners loitering on your screen for too long. You anyway know where to check those notifications.

Finally, if you want your edge to function as a toggle, the edge indication should also behave as one. This means that subsequent swipes across that edge turn the edge indication "on" and "off" again. Just like tapping on a regular toggle switch would.

The cool thing with edge toggles is in the effortless way to control it, compared to traditional notification panels. Those you need to close with the an opposite edge gesture, which require considerable thumb mobility to perform with a single hand.

With these tips, you should be able to considerably increase edge gesture benefits, while avoiding the common gesture pitfalls that plague major operating systems and applications.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

To evolve, or not to evolve?

That's not even a question.

Be it building shelters, gathering food or traveling long distances; people always had an innate desire to do things better and faster. It's been always possible to improve some part of an activity or a tool related to it. Even entire professions have been forgotten after becoming obsolete. Thanks to the increasing pace of technological advancements, our children won't anymore recognize objects their parents grew up with.

Except when it comes to user interfaces.

I grew up with computers around me, and my kids will grow up with even more computers around them. Over the years, they've gotten a lot smaller and immensely more powerful. What hasn't really changed, is the graphical user interface staring back at us. The desktop metaphor with windows, icons, menus and a pointer (WIMP) has stayed intact for over 40 years.

The first mobile devices had no touch screens, and had to be navigated with either directional keys or a scroll wheel. It was logical to use the same approach for such a miniaturized desktop, but when touch screens became more popular, user could directly interact with things. This made controlling a pointer redundant.

After the mouse pointer was removed and touchable things made a bit bigger for suitable finger operation, everything was ready for profit-making. Nobody seemed to question, whether an interface paradigm originally designed to be operated with a keyboard and mouse (WIMP), was really applicable for a mobile touch screen use:

Unlike desktops, mobile devices

• are primarily used without a supporting surface (table or similar)
• are used in dynamic environments with disruptions
• can't assume user is constantly looking at the screen
• can't assume both hands are available for a basic operation
• can't assume equal amount of time is available to perform a task

Regardless, all mainstream mobile operating systems treat mobile use the same way as desktop use. The familiar button-based navigation model, dating back 40 years, does not really qualify for mobile use. It requires too much attention from it's user to be efficient. Too much precision to be comfortable. Too much time to be fast.

Replacing mouse and keyboard with touch alone, just decreases the speed user can control the system, making it actually worse than the desktop. It's been a wobbly decade of mobile user interface infancy. The only way it's gotten any better, is through nicer visuals and smoother transitions. But that's just surface - a better hardware clad in finer clothes.

At this rate, my grandchildren can still identify an Android phone, because baby steps were considered good enough. That's a valid strategy as long as everyone copies one another, and no alternatives exist: a family tree that looks like a ladder. It's an open invitation for smaller companies to deliver less inbred products, that are designed to adapt to your life, instead the other way around.

If you still think those archaic desktop conventions are enough to keep your massive software business afloat today, you're not the first one. The bad news is, that the only way a dinosaur could avoid extinction, was to stop being one, and evolve into something else.

Before it was too late.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

Breaking the application grid

Some time ago, I wrote an article about the role of applications on a smartphone. This time, I want to burrow deeper both into their actual presentation and location, where apps are physically found from.

Meet the app grid (launcher / app drawer). Before gunning everything down, let's find out the problem before fixing it. We should always try to live how we preach, right. My top issues with multiple pages, filled with app icons in an neverending array, are:

• Icon arrangement is the only way to personalize how the grid looks. It might work for some cases, but as it grows longer, it starts to be tedious to find anything from it.
• Related to the above, an even grid does not offer enough cues to find things in it. It's slow to scan through a single row after another.
• Moreover, icon folders/groups alone leave little room for building information hierarchies. Be it an app, contact or a link to a website, attaching them to your launcher makes everything one step closer to a mess you don't want to tread on. This is the point when Android home screens start to sound like a great idea.
• Finally, and partially related, your app usage is traditionally divided between a task switcher (active apps) and a launcher (installed apps). If the app is not present in the task switcher, you have to exit it, and go to the launcher instead. Even worse if you have to hunt through multiple home screens between the two.

While Sailfish OS already solves the last one by combining app drawer and switcher, to form a single location, the grid is still just a huge mass of identically spaced icon rows, with very little visual cues for our eyes to lock on. That's the gray part on the image below (click to enlarge).

The blue half of the image on the other hand, illustrates how user could arrange icons to support their personal use. Don't take it as a suggestion how to arrange anything, as it's just an illustration. Obviously, the problem exists also horizontally arranged pages, but the presented solution is a bit challenging to pull of in that direction.

If you find the idea ugly or messy, it's easy to understand. From a visual point of view, a repeating pattern and a strict order is appealing to look at, even though they harm the long term usability of finding things from it, especially when the amount of icons increase. Don't worry, it's not the first time usability and aesthetics collide.

It's also worth noting, that while most people might not concider the app grid a problem on their Android devices, they still like to pin app icons and other stuff on their home screens. It clearly tells that the grid quickly becomes unwieldly to browse.

Now, I would like to entertain a thought: what if the app grid would've been fixed to support more dynamic layout for people to personalize. As a part of the software, the launcher already exists. Why not make it more customizable, instead of building Home screens on top to hide the issue?

Would Android still have multiple home screens? Nobody knows.

Would it be simpler? Absolutely.

Would it break the Android UX? Nope, just that archaic app grid.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.

What if game controllers were designed like smartphones

Sometimes, we find products that are carefully designed with human body limitations in mind. And sometimes products go to market with utter disregard to how and where people use them.

I started wondering how would it look if, for example, a game controller would be designed without actually thinking how our hands interact with it. Here is an existing smartphone, next to a made-up game controller:

Click to enlarge

Obviously, that wouldn't really work out for any gamer, since your thumbs would be functioning on their movement range limits most of the time. It would be painful in two ways: one, your hands would be killing you even after a short session. Two, in an online game, everyone else would too. As a gamer, I'm glad we don't have such controllers, but sadly we have phones that are painful to use with one hand. And that's killing me.

Naturally, I'll just go ahead and flip that around. Here you can see the same focus to ergonomics that's applied to existing game controllers, going into a smartphone interface design. To most of you, it looks familiar:

Click to enlarge

Just like that, we can play games and use smartphones as much as we like without collateral thumb damage. And trust me when I say this, we clock in some impressive amounts per day on both. Something that smartphone interface designers in the past didn't take into consideration.

Or chose to ignore.

Thanks for reading and see you in the next post. In the meantime, agree or disagree, debate or shout. Bring it on and spread the word.