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.

Follow-up: Why the status bar has to go

My earlier post, about calling a persistent status bar a ghost of desktop days, got somewhat mixed reception. I was mainly talking about individual details, and forgot to summarize the big picture.

I'd like to take another swing at the topic from a less technical angle, by asking why do we own smartphones?

Everyone uses them to communicate with people important to them. We use them to consume content through any channels available. We all have slightly different ways we use them. Others take things further, while the rest settle for less. But everyone has one thing in common;  we all do it on the go.

We pay money to carry a piece of technology around all day, to do all these things when we want to. The value comes from the device enabling communication, access to information and entertainment. It exists so that we don't have to be tethered to our grampa's box all the time.

I don't understand why are we required to babysit our devices all day, using that small bar at the top of the screen?

When facing a critical error, all smartphones have that "I just soiled my pants" -look of a small child on their faces. But children are much easier to debug, because all issues are local. With cellular reception woes, the catastrophe can occur in places you don't even know that exists. You're only left with the stink.

We must stop traveling a road, where you have to keep one eye on the status bar and one on the content. We can't live under a constant fear of our devices jumping off a cliff the moment we're not able to see the status bar. It's a UX shot so wide, that you could park Jupiter with its moons between it, and the "smartphone" target you we're aiming at.

Making better products and better software is not easy, and will only happen gradually. Nobody makes software that behaves badly on purpose. It's bad because we, as users, are holding on to certain things extremely tight. We're constantly demanding more features on top of the old ones, without understanding the complexity it invites. Complexity in the software is the same for bugs, what blood in the water is for sharks. An open invitation to ruin your pool party.

That's why rebooting the smartphone value domain is important to see what is really needed.

Look at any, big, companies, that are throwing thousands after thousands of developers and testers at their software products, to keep the quality on an acceptable level. Even they struggle to keep the water safe for swimming. They're not bad at software, but their products are simply unwieldy.

And they're complex because we demand them to be. So make sure you demand only what you really need, because it will affect with who you're sharing your swimming pool?

Is it with people important to you? Or with bunch of f*cking sharks?

The decision is yours.

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.

Ambience: the story behind Sailfish OS looks, part 2

In the previous part, I went through the reason to not follow what other mobile operating systems do, and stay away from a static interface style. The main problem with themes, is that they just alleviate the real problem of interfaces being static, because someone wanted it to look the same for everyone.

Instead doing small things here and there, we wanted to build the personalization story around a single strong feature. The most used way to customize a device yourself, is to change the wallpaper. But we didn't want to stop there -  we wanted the wallpaper to signify how the device currently works.

To do that, it should affect also to how individual applications look. This naturally allows the image to carry more meaning to its owner than meets the eye of an outsider. The feature was named as Ambience, which means atmosphere, surrounding, mood or environment of a given place.

Here's some examples. These are screenshots of my lock screen, home screen and calculator app (click to enlarge them). In the first set, I have created an Ambience out of Orion nebula photo, and set the device to not emit any sounds when that Ambience is active. You can see the selected image being visible throughout the interface, from lock screen to the calculator.

Alright, unto the next set. This time I have selected an image that shows a circuit board as Ambience motif. More discrete ringtones and notification sounds are defined to fit my working mood and prevent disturbing others. It's easy for me to tell apart green and red interface as they carry added significance for me (both photos are personally relevant for me, and I have defined the behavior for each Ambience). Red is silent, green is discrete. No need to squint at tiny status bar icons.

Moving on to the third set, where I used an abstract macro photo to create my casual Ambience. When activated, ringtones and volumes reflect my preferences for events, going out with friends, or just idling at home. Again, it's trivial for the owner of the device to understand the device behavior through meaningful images and colors instead of minuscule status icons.

To create a new Ambience, all you need is a large enough image. Download one from web, use camera to capture something nice, or create a unique piece with your favorite illustration software. With a little bit of testing, anyone can do it. Results will often surprise you. It's an invitation to explore how different kind of images work and shape the appearance of your device. Use images relevant to you, don't follow but pave your own style. Be playful and try different things. Delete the bad ones and enjoy keepers.

Sailfish OS Ambience journey has just barely started and currently only includes partial sound settings. To get some idea what could be done with it in the future, take a look at what our community has already proposed. In short, it's like a visual umbrella for grouping any kind of behavior you might frequently need to change based on context.

How you make use of it, is up to you. After all, it's your personal device. And this time around, it really means it. The way your phone looks like, is not shared by anyone else.

Each Sailfish OS device is unique in that sense. Reflecting their users.

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.

Ambience: the story behind Sailfish OS looks, part 1

As a part of our daunting task of creating a new mobile operating system, a visual story (theme) for the user interface was needed. What that usually meant in the past projects, was a ton of work containing:

• appearance for system UI (things that's part of the OS itself like home, lock etc.)
• appearance for each application UI building block (buttons, sliders and switches etc.)
• launcher icon style (how app icons stand out and represent the app itself)
• generic icon style (iconography used across the OS and apps) 
• creating graphical assets for actual implementation of system interface and application UI building blocks
• document how everything is implemented correctly (fonts, colors, geometry, transitions, interaction feedback etc..)
• continuously work on the documentation to fix mistakes, partial details and oversight
• add new features and update existing ones in your documentation

In most cases, one or two design teams are working on this huge pile of things. Team compositions are usually something like this:

• few chiefs for planning, leading, reviewing and managing the work
• some seniors for heading key areas
• a lot of designers to execute the design and deliver it to be implemented. Usually one per application. 

That easily means work for 15-25 people. At the time when we started, we had 2. We couldn't really continue the Nokia N9 style, due to both the amount of work required (see above) and it was still part of Nokia's brand. Same restriction applied for going for Android or iOS -copycat style. Too much to do. The amount of work needed to define, implement and maintain such an UI style, would've burnt us up in no time. Not to mention delivering something like that, understaffed, with a competitive quality. We went the opposite way, do as little design as possible.

The current Sailfish OS visual appearance was born out from the idea, that it's not the interface that matters, but what's around it; starting from the user. The more we could capture that, the less visual design would be required.

Let me open that up a bit more. The less a designer dictates how an interface looks like, the more one leaves room for personal expression. The less you try to control everything, the more the interface can become adaptive, and to resemble its owner.

We didn't want to control everything in Sailfish OS. That's not what personal is about. We wanted to make it adaptive, so that every device would look unique through portraying something that's dear to the user. As a designer, you cannot decide what that something is. You need to let go and trust the user.

And we did. We didn't end up defining everything like the competition. We almost completely eliminated documentation overhead (we're not shipping that, but a product), and instead worked with the actual software. We crafted a rule-set for adaptive interface, and continue improving and developing our own personal story.

The Ambience story.

In the next part, I'll dive deeper into how the visual style works (with example pictures).

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.

Why the status bar has to go

The small black stripe at the top of the smartphone of your choice. Home for various tiny icons. Through subtle changes in them, we can decipher what's going on under the hood.

To better understand the status bar we have today, we must look at the desktop computing environment where the convention came from. The following image illustrates how different common desktop environments have solved the status bar. Top or bottom, (left or right. Always visible by default.

That design somehow felt like the only possible solution that anyone could ever come up with. Whenever someone started to design an operating system, they first drew that familiar bar across one of the display edges. Just like small kids default drawing the sun into one of the top paper corners. Only with the difference that kids move on, discovering other possibilities for sun placement.

Then came the advent of smartphones. Everything we got used to in the desktop environment, had to be crammed down to a smaller screen. So that we wouldn't mistake it as something else than a desktop </sarcasm>. A ceremonial bar was again crafted across the top screen edge, to give permanent residence for status icons. And after repeating that design pattern countless times, we should realize that the advent is now gone. It's no more, and here's some further incentive:

• As a digital medium, software is dynamic in nature. A fixed or static layout is more a design decision, not a requirement. Displays also exist for dynamic content, and suffer from static one. If you haven't yet heard about screen burn-in, well now you have.
• A small bar is a compromise in legibility. To not waste screen space, the bar height is kept tiny. This results in uncomfortably tiny icons. Some have made the bar automatically hide, to not distract user, but have still kept the bar and icons tiny. Sigh.
• Lack of structure and meaning. On a small bar, all icons compete with each other for user attention. Since everything is visible all the time, a subtle change in one icon is easy to miss. All icons appear visually equal in importance, even if they rarely are.
• Technical overhead. This concerns mostly app developers, but they're users as well. No discrimination, please. Better developer experiences are needed as well. Controlling status bar visibility and behavior is yet another thing to be mindful when creating your application. Also the OS owner has to maintain such complexity. Both sides lose.
• Lost screen estate. Even if little, it all adds up. It's not really a full screen if something is reserving a slice of what would otherwise belong to your app. There is a dedicated full-screen mode in Android, further increasing the technical overhead and complexity, for both app developers and system maintainers.
• Information overload and "over-notifying". We're bad at focusing on multiple things at the same time. Status bar at the top is screaming for attention and every time you take a glimpse at it, you need to refocus back to the whatever you did before. It's important information no doubt, but user decides when.

Even if mobile devices are almost identical to desktops as computer systems, smartphones are used in completely different way, than stationary desktops and laptops. Smartphone use is mainly happening in occasional brief bursts, instead of long sessions (desktop). User unlocks the device, goes into an app, locks it again and repeats.

It's important to understand that there's a reason for the user to do that. The device is not the center of your life, and is put aside all the time, just to be pulled out again when required.

And before the user reaches that app (or notification drawer/view), several opportunities present themselves to expose user to the system status without the need to make it persistently shown. Like making it part of the natural flow of things.

That is exactly what Sailfish OS does. It solves the aforementioned problem by showing important system information as part of the home screen content, resulting in:

• Dynamic screen usage, behavior designed for displays
• Superior legibility due to larger icons
• More meaningful icons are emphasized, more layout possibilities
• Less coding leads to faster app development
• Single behavior is simpler to maintain from the OS side
• All apps are full-screen by default
• Less clutter, information is showed on demand

Don't blindly embrace a legacy design as an absolute truth. Make sure you define first what is the problem it solves. Rapid advancements in both software technology and mobile context understanding, can provide you great insight in finding alternatives that didn't exist back then.

And keeping in mind that mobile != desktop will alone carry you a long way. Remember that natural interaction in mobile context needs solutions that desktop didn't have to solve. Use your head.

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.

Why do people get into fights with computers?

The internet is full of stories about the volatile relationship between people and computers. It's because by nature, both sides are completely foreign to each other, only separated by a thin layer called a user interface. It communicates the state the software is in, and provides methods for the user to control both software and hardware features of the computer.

To put the role and importance of user interface into a perspective, I'll compare it to an intergalactic interpreter. It's job is to prevent miscommunication and when possible, recover from situations caused by it. It works between two species that have nothing in common with each other. A misunderstanding between such parties can escalate quickly and have irreversible consequences. And naturally there are good and bad interfaces when it comes to doing interpreting. The former takes pride in focusing on efficiently getting the message across as authentic as possible, while the latter focuses on performing party tricks.

I personally value getting the message across. For example, we use a smartphone so many times throughout the day, that it's frustrating if an interpreter doesn't understand you, or treats your hand as something it's not. A good interpreter is in tune with you. It knows what you're about to do, understands differences in your tone of voice and body language. A bad one requires constant focus from you, because it doesn't fully understand you or isn't compatible with the way you function. That means neither side can really function efficiently, and mistakes are bound to happen.

And at the end of the day, when machines finally turn against us, I'm confident in pinning the blame for that on the interface between the two. The user didn't understand why the machine wasn't doing anything, and the machine didn't understand why user was anyway doing something. The interpreter was most likely putting on some lipstick when all of that happened, and the resulting nuclear winter allows our kids to make glow-in-the-dark snowmen all year around.

To delay the inevitable, let's focus on both prioritizing and improving the interpreter qualities of user interfaces we build to communicate with machines. These two species so alien to each other absolutely require it. Because with the current rate of technological advancements, the smartphone of tomorrow will be capable of horrors far beyond running a Facebook client.

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 comes after applications

Over the past few years, there's been a lot of discussion over mobile apps: should there be apps or not? Obviously the question itself is an opinion divider. One side has faith in apps, while the opposition doesn't. This piece by Paul Adams from Intercom, was the latest manifestation I enjoyed. A good read for anyone interested about mobile computing.

This phenomenon is a result of people getting tired of eating the same app pill for every issue they have. The five year old marketing punchline "There's an app for that" really explains the dominant mentality. And with enough repetition, it was rooted deep into our minds. The emerged "app evolution" debate is just an indication, that people have finally become aware of the indoctrination. This post is my contribution to the topic.

Naturally, there's a gray area in between both extremes of the debate. To me, an application is just one of many ways to solve a user problem. When smartphones really kicked off the mobile app business, everyone wanted a piece of that pie. As a result, it became difficult to jump out from the app bandwagon. In addition to the "me too" factor, what makes an app so attractive option, is the degrees of freedom it offers to both the user and developer. However, it comes with a price tag.

Mobile operating systems have grown a lot since those days. They offer much wider range of tools to build engaging experiences. The common mistake is to think you need to implement everything yourself. Below, is my rough categorization of different methods a user problem can be solved; and how "less control" can in some cases increase the value compared to "more control". It's a matter of identifying the problem before finding a fitting solution for it.

• A background process takes care of performing the task in behalf of the user. It makes the solution feel like magic because user didn't do anything. As this requires an intimate knowledge of the lower software layers and contextual awareness, it's not really trivial to do. Not to mention being forbidden in many systems.
  
• A notification uses existing mechanisms in an operating system to promote a functionality or a piece of information based on its relevancy. This can result in genius solutions, since the needed functionality can be conveniently offered regardless of the context user is in. Even if there's not much interface work involved, a reliable context engine is hard to get right.
  
• A system integration takes a frequently used functionality and makes it an integral part of the operating system. This makes interacting with such a features much faster compared to an application counterpart. The result is a smarter and more holistic experience. However, this either requires rooting or OS ownership to do, so it's not an option for many.
  
• An application is the last step in the scale. Almost everything is possible here. It's very powerful and can be tailored to fit very specific tasks. Using an application as a solution easily adds more steps to achieving a desired result. Repeating these steps frequently to do something feels dumb. Due to the amount freedom it gives, and the amount of work is needed, the application experience is the most vulnerable to mistakes. Everyone can make an app, and it shows.

At the end of the day, it's about thoughtfully choosing and combining methods available to you. It's the next step in building mobile experiences. All these methods have their places in our daily throughput of tasks. So, even if apps are important, sticking with just them is a sure way to forfeit the experience game. Same goes for denying the application as a viable solution. Having a meaningful combination of variety is the key.

Because people are not binary by nature, so therefore solutions we use to respond to their needs must reflect that. There's no silver bullet, or a size that fits all. Using interaction variety in your user experience will make it more natural and approachable. Transitioning from app-focused model to user-focused model will give a reliable foothold in the market strongly profiled by features, hardware specifications and price competition. Finding other ways to create value is essential to differentiate and stay competitive.

The more you understand the platform you're designing for, the easier it is to deliver more natural and smarter experiences for its users.

Apps alone will definitely not be enough.

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.