Man and its computer, part 1

Our world is loaded with different computers that we use for a variety of things, ranging from good to bad, from luxury to necessity. And at their very nature, they're essentially the same. This and the following post emphasizes how similar they are (post 1), and how different user interface designs they ended up with (post 2).

Most importantly, it doesn't matter what computer we're talking about. Value is always generated through some type of application. Gaming, content creation & consumption, communication, and many other domains depend on using applications. Web browsers are eating away that pie all the time, but they as well are applications. Just hugely complex ones.

Depending of what we're doing with a computer, and where that happens, we use different input devices to help us. Keyboards, mice, trackpads, styli, cameras, game controllers and microphones, just to name a few. The line between computer specific input devices is blurring, as devices increasingly support a wider range of peripherals.

A displays is the dominant output device when it comes to computing. With a larger screen, you can see more without scrolling. Smaller screens are more portable, but the screen content needs to be scaled and restructured to make up for the reduced screen area. The more different display sizes a computer can support, the less limiting it is for the user.

To sum it up..

The way most common computers generates value for the end user, is identical. The way we control them is too, as well as the way they respond back. In the next post, we'll have a look at some of the most common computer categories and their graphical user interfaces. Stay tuned for the next post.


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.

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.

What's wrong with multiple home screens

Quite a bit. Hold on to something.

If thinking critically, what does multiple home screens really add? Aside from multiple screens off course. Is there any explanation for their existence?

I hear this even in my sleep already: "Everyone thinks they're amazing / Everyone is used to them." But, that's just repeating an opinion. It doesn't explain why do people need them?

Another common one is: "Statistics tell us that people like products with multiple home screens in them." With that logic, you can say that statistically people also like seats with feces in them, because they use bathrooms several times a day. Sorry, people would be happier without the poo being involved if it would be possible.

This as well: "We have done extensive consumer studies to prove it's a must feature to have." Sigh. On paper, you can make people like poo just by asking them the right questions.

This comes up every now and then: "It's for everyone to personalize their devices." I'm pretty sure the device is already a personal one, and what user does with it, will make it even more so. Also, there's countless other ways to make the interface a personal one.

But the winner is: "What is this heresy I hear! From the beginning of time as we know it, home screen content has always been arranged in horizontal pages!" From the beginning of 2007. But then why is pretty much every other content browsed in vertical direction? Web pages, content streams, call histories, messages and gallery grids. All vertically arranged.

So really. Why does a smartphone need multiple horizontally arranged home screens? How do they make a smartphone smarter? What is the user need they fulfill?

Anyone?

I think it's actually the other way around. A smartphone would be smarter if it didn't have multiple home screens. The main issue is in the thinking that adding more, automatically equals a better product. And as usual, people are blind to the opposite.

It's a better product, that equals more. Let's try it out.

You give a user seven home screens, instead of five. Did it make a single home screen any better? Is it easier to move or find things between seven home screens? Are seven screens easier to decorate with widgets? Is it easier to find nice widgets that don't look horrible? Is it more personal solution? Did the product become smarter than before? Does it free system resources for actual user tasks?

Nope.

Then try removing all but one home screen. Make that single remaining home screen better. Make it smarter. So that it adapts better to what user is actually doing with the device, removing the need to juggle between multiple home screens. Because everything you did and worked on, is found from the same home screen, everything becomes much faster. You launched a music player, and suddenly the controls are also there. You arrived at work and your email account summary is greeting you on your home screen. Suddenly the behavior feels more helpful and smarter, since you can do more by actually doing less.

Do you spot a pattern? Better, equals more.

There's even the age-old saying about quality trumping quantity. Well, marketing was clearly invented as an counter-argument. Because smart is hard to do. Just adding more is easy. A hammer with three heads instead of a single good one: a great idea everyone can boldly stand behind of. And with a good marketing campaign, nobody notices it's heavy as hell and unbalanced beyond practical. The rendering looks amazing, though.

So compared to doing smart and meaningful things, marketing is dirt cheap. Guess which path big manufacturers favor?

So let's try one more time: Does adding more home screens make a product easier to sell?

Hell yes it does!

If I buy a hammer, I want a better hammer than I had before. One that allows me to work faster, more efficiently and comfortably, not to forget improved safety. I don't want to buy an inferior hammer, just because it's easier to sell to other people; who at the end of the day, would also prefer a better hammer with a single good head, instead of having the option for multiple ones.

That means the product was intentionally made to perform poorly, just to make it sell more. Since the modular-wonder-hammer has the option to add more heads to it, the potential to develop a single good head is lost for the sake of a nonsense feature.

If Sailfish OS would have multiple home screens next to each other, it wouldn't be possible to have cover actions as explained in my previous post. It would mean that the ability for user to interact with tasks would be reduced.

For the sake of having a modular-wonder-hammer, that's heavy as hell and unbalanced beyond practical.

To be honest with all of you. Making a better product is really hard and painful. It's because the industry around you keeps repeating how more equals better. Especially when the rendering looks awesome.

The dumbest thing I've heard.

In the smartphone industry.

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.

Replacing widgets with minimized applications

One of the most unique aspects of Sailfish OS, are active application covers.

They're essentially small windows on your Home screen. Each one of them represents a minimized application (not currently in full-screen state). The same function is found from any desktop OS, in form of a task bar or an application dock, that show all your applications that are running in the background.

As you know, there's no separate task bar or switcher in Sailfish OS. Only one Home screen. These covers show relevant and legible information, and allow user to perform important actions directly from the home screen.

On the first encounter, they kind of come across like widgets. And it's no wonder, since they actually pull double duty. Primarily, they're used to maximize an application to full-screen, but also allow user to interact with common features without the need of entering the app.

When compared to for example Android home screen counterparts, similarities start to run shallow. Widgets on Android are not in the same place where active applications are shown, so there's no real connection between the two. Even if they also allow using common features, there's a problem with doing it with buttons. I made a simulated example below, about Sailfish OS having separate tappable areas.

Accurately clicking a correct physical location on the display is easy in a desktop environment, the birthplace of widgets. After all, mousing on a stable surface is a breeze. But when you're walking or otherwise active, the overall movement of your body easily transfers all the way to your hands, making it harder to tap the correct button. And just because this interaction method uses our fingers to emulate a mouse cursor, it's already by definition an inferior approach for mobile interfaces that are not used in stable environments.

Sailfish OS solves this by not using taps for cover actions at all. Instead, user flicks the cover horizontally to perform an action. This makes it irrelevant where you tap or flick a cover. Both tap and flick touch events can use the entire Cover area as a target. This makes a big difference in the accuracy requirement for performing an action.

Since it's the flick direction (left or right) that defines the action (media player play/pause and skip song for example), it naturally limits the maximum amount of actions into two. And since tapping and flicking to left or right all have a different effects on how, and in which order, your hand muscles behave; it's easier for our body to associate them for different things. Again, the design both supports and takes advantage of our unique capabilities.

Whether you use all the potential through these gestures or not, is up to you. Each of us takes tools we use to different levels of efficiency. Some push them all the way to their limits, while others are comfortable in casual use. Both are equally correct.

However there shouldn't be separate locations for these two ways of use. In Android, the requirement for widgets comes from the poor multi-tasking performance, as well as system complexity. It's nicer to have multiple home screens filled with widgets, where user can perform frequent tasks. However, that's just adding more complexity by fixing the wrong problem.

By solving how minimized applications allow different degrees of user focus, and reduce the need to enter an application, the need for a separate location for widgets is removed. It both makes the OS simpler and leaner, and greatly increases task handling speed, since various user needs can fulfilled in the same location.

Responding to user required level of efficiency and control.

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.

Multi-touch and bigger screens

Brace for disclaimer!

Note that this has nothing to do with Jolla. People have been asking me about how could Sailfish OS work on larger touch screens, so here it is folks. Some theoretical design thoughts about Sailfish OS user experience, on a bigger size. This is important for the sake of understanding a mobile operating system design and the effects different touch screen sizes have on it.

Fantastic, let's move on.

Multi-touch makes an excellent parallel subject, when talking about larger touch interfaces. I've personally grown to dislike majority of multi-touch implementations because they seem to be driven by technical capability to track, rather than supporting the way we use our hands.

So what should multi-touch be then?

Let's use another tool example to dig deeper. I like comparing things to tools because of their simple, efficient and purposeful interfaces.

Think about a hammer and a nail. The task is to hammer a nail into a piece of wood. Your other hand holds the nail while the other one hammers it in. When breaking that down, we can recognize multiple smaller operations inside that task. Pinching a nail while holding it perpendicular to the target surface, is one. Whacking it in with a hammer in your other hand, is another. This is a simple multi-touch use case from the real life. With two types of multi-touch.

Huh?

Yes, I think there's two kinds of multi-touch. The first type is related to the task itself. You need to use both hands simultaneously for the same task to succeed. Hold the nail and use the hammer. The second type is related to individual hand operations inside that task. Pinching a nail with at least two fingers, and gripping a hammer with up to five. The latter is the most common use of multi-touch to implement a pinch/spread-to-zoom for example.

Ok, two types of multi-touch. Two-handed task type and multi-fingered operation type. There is no need to discuss about how many fingers you need to do something, because then you're focusing on wrong things. And I feel many existing interfaces are limited to only the operation type, because they're not focused on user tasks, but in something completely different. Not to mention forgetting totally what our hands are capable of.

So, I ended up with this definition because there wasn't really anything tangible behind existing multi-touch interfaces, in the mobile OS space. At least I haven't ran into anything that made sense. What I've found abundantly, though, is a lot of complexity that multi-touch can help to add. It's very easy by introducing more and more fingers on the screen, and mapping that to do yet another thing in the software. The amount of needed fingers has lately gotten kind of out of hand. Pun intended.

If you need more than 1 finger to move around in your OS, you should seriously look at the interface architecture and feature priorities.

"But with multi-touch , I could have an OS feature to directly alter orbits of celestial objects and.."

No. Stop it. You'd be still browsing, watching videos and gaming. And the only celestial object you know is Starbucks. Stop looking at increasing OS features, and pay more attention to enhancing user potential.

Alright, apologies for the slow intro. This is where some illustrations comes into play, and hopefully make more sense of the multitasking stuff above.

Sailfish OS was designed to be less dependent on display sizes than other mobile operating systems. This is because the most common user interactions are not depending on the user handedness, hand size or thumb reach, so the gesture based interface naturally allowed one-handed use of a smartphone sized devices.

"Hah, you can't really use a huge device comfortably with one hand, so your one-handed use benefit is lost then?"

Yes and no. The same way that Sailfish OS made a small interface fit into a single hand, it makes any larger interfaces fit two. This opens new ways to interact with larger devices due to the analog nature of touch gestures.

We should also understand that people are very liberal in how they use and hold devices in real life environments. In commute, at home or during a holiday trip. Most of the time, it's resting against something, and simply hold in place with one hand.

This a two hands grip, while using a full-screen application. This is a precondition to completing a task. My tool comparison is holding a nail in the other hand and a hammer in another.

The left (or right, it doesn't matter) hand performs the Peek gesture to expose the Home screen. The hand with the nail is placing it against the wood surface.

While keeping finger on the screen, user is able to see what three other applications are doing in Home screen. The nail is ready to be hammered in.

Without releasing the left thumb, user performs a cover action to play/pause/skip a song with the right hand as an example. Releasing left thumb after interacting with any active cover, would keep user in the application 1 (first image). That's a fast way to look into Home (just like on the phone), perform an action (enabled by the larger screen) and get back to the app. All without even really leaving it.

Alternatively, if user would tap another application cover, or trigger a cover action that requires a full-screen state, the screen real-estate would be divided between the two. The nail has been hammered in, and user is back to default state that precedes the next task.

This behavior is a natural progression of Sailfish OS Peek gesture and how application windows are handled. Only the support for the other hand and screen division was added. Both hands performed an individual operation that alone, completed a single task (pinch a nail and hold/carry a hammer). When they're performed together, a different task is completed (a piece of wood is attached to another). Just like we do so many things with in our physical environment. I wanted to focus on illustrating the task type, because there are countless examples about the single hand multi-touch, the operation type.

The value in all of this, is that the entire interaction sequence is built into the same application usage behavior, without any additional windowing modes or mechanisms that need to be separately activated and used. It supports the way we work and enhances our natural potential. After all, you don't turn your hand into a separate mode when you're driving nails into planks of wood. No, it's the same hand, all the time.

Similarly, when you need to reach something from a tool drawer, you will not physically enter the drawer yourself. You wouldn't fit. Instead, you stand next to it, open the desired drawer and pick up the tool you needed, before closing it again. The Sailfish OS peek gesture is doing exactly the same on larger screens because of multi-touch. Exposing another location (Home/events = drawer) with the other hand, to see what's there and perform a task (trigger an action = take a tool) with another. All without actually going to that location.

That's what multi-touch should be.

Something that focuses on enhancing our potential, instead of enhancing features we are required to use.

Button based tablet operating systems (excluding Win 8 etc) are not going to do something like that any time soon. Not only because they treat active applications in a different way (as second class citizens), but it would be challenging to implement the behavior into the way how buttons work. Also the button locations do not support ergonomic use of individual hands when gripping the device from the bezel. On the other hand, the sliding gesture over the screen edge is very natural to perform, because it happens where your thumb is most comfortable any given time.

This conventional button approach, that many Android devices use, exhibit another problem in enforcing a hand preference in controlling the device. As you can see from the image above, the left hand is not able to reach notifications on the right, and similarly the right hand struggles in reaching Home, back and task switcher buttons on the left.

It's not about changing the interface between a phone and a tablet. Tasks are anyway the same. It's how the two-handed use is enhancing our potential through the increased touch screen area.

Don't try fitting an existing multi-touch solution into your interface, but think how an interface can handle both one- and two-handed use.

Then, the rest will find their own places naturally.

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.

Together tomorrow

Dear Jolla users and enthusiasts, Jolla Ltd and its partners.

Who I am, or where I work, means nothing for what I’m about to say. On the other hand, what I believe in and what I choose to do, means everything.

I believe in this community and I'm asking it to act.

If someone can shape the smartphone industry, it’s all of us. We have already begun. Big things have happened thanks to all of you.

Let’s forget about Jolla for a moment. This is not about Jolla. Jolla is a small company with limited resources. I’m tired of both hearing and repeating it. It’s going to stop today.

It doesn't change the fact, that our community enabled the possibility we have today. And together, we either make or break that opportunity to give this stagnated industry a run for its money.

I see desperation in the smartphone industry. Same things are repeated and recycled. Over and over again. Big manufacturers are locked in an eternal patent war. A game of sudden death. Each focusing on getting better hardware cheaper. What it actually means, is selling compromised hardware for the user, with the same software experience as last time. A lot of corners are cut in that process. Only rivaled by the ridiculous amount of marketing that goes into covering it all up. Operators and retailers are trying to somehow come by.

Meanwhile, the end user is looking from the sidelines. Everything is badly derailed. It’s not sustainable. It’s not what tomorrow should be.

And we've known it for a long time. We all challenged that.

I'd like to point out that it's very rare for a community of this size, to have two real products shipping in several regions. A phone and an operating system.

Unfortunately, that is playing by the wrong rules.

It's the exceptional bunch of people behind it what matters. They all had real courage to do new things. They all bravely stood behind new ideas and promoted them. And their message was:

"We want to buy tools that fit what we do, not what the industry wants us to do."

It's essential to understand how this industry works. What are the rules it plays by. Because those rules aren't for people. They’re rules for business. Rules how to make profit for companies. The smartphone industry has long since stopped being user driven. Why else would you have to buy a new phone every six months.

Therefore our own style of play has to focus on user values. There is only one rope to pull. And only a single direction to pull it. We need to get noticed as individuals with different things we need a smartphone for, not a distraction from them.

Whatever the reasons was for all of you to get involved in this movement, I bet it was much more personal than any hardware specification. Every manufacturer is focused on how to distract users from the fact, that a smartphone should be useful in your everyday lives, instead of use up our lives.

A phone is an important tool that should comfortably fit to the center of our daily chores, instead of being your daily chore.

Stand tall. There's nothing to apologize. Be proud of what we've achieved together. Be open about how you feel in this community and help others to clear out common misunderstandings. Many simply don't know what this community is about. They don't have any idea what Sailfish OS even is? Why does it exist in the first place? What was the story behind its creation?

Nearly all of you know it very well, and can pass it on. Please do. Even if it's all work in progress. Our community, OS and available hardware; are all glimpses of what tomorrow could be.

The choice is ours. What do we all choose to do.

Smartphone manufacturers will not magically become aware of our values. We need to do something about it. That includes everyone.

Everyone can affect what Sailfish OS will be tomorrow. Because when working with the smartphone industry, we all need to be very clear about one thing.

Sailfish OS exists to serve user needs.

User has the control of what happens on their devices. If we don't make that clear, the OS will surely, as others before it, slowly turn into an industry tool, instead of being your tool. It will gradually stop fitting to the center of your daily chores by turning into your daily chore. For the same old stubborn game to continue. That is the inevitable effect that the industry has on undefended products.

It's caused by the way this industry plays. It's gotten blind to alternatives. Forcing everything it comes in contact with to submit to its rules. It needs help in finding other ways to play. Other ways to create value and also profit from it.

You're all a living proof that it can be done.

What this industry needs is a wake-up call. Nobody else will do it on your behalf. Either we keep doing what we do also tomorrow, or we don't.

Simple as that.

If you agree, grab that rope and give it a good pull.

#PhoneIndustryWakeup

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 develop apps for Sailfish

I get asked this a lot so I did a post about it.

Simple really.

A Sailfish application has a much higher UX potential than any other platform counterpart. The whole operating system is designed around an unobstructed and efficient use of applications. What you as a user want to do.

In addition to harmonized gesture usage, Sailfish apps have also unique UX pattern called cover actions, that's missing from all other platforms. These allow you to interact with a common application feature, directly from your home screen without entering that app.

Why not use Android apps. Well, even though Android apps run on Sailfish OS, they don't always feel right because of the button based navigation at the screen bottom. So each native Sailfish application removes another Android app dependency and makes the user experience more complete overall.

Native apps are also much faster to load, use far less disk space and memory than Android apps. Every aspect of a Sailfish application is designed the mobile use in mind. Because when you're on the move, you are limited by four things.

A limited screen size, a limited battery capacity, a limited storage and limited processing power. But the biggest limitation is our own inability to focus on multiple things at the same time.

There is a live and active world out there. A ton of things happening everywhere. Both lovely and dangerous things. When you use your smartphone, you want to go in fast and get out faster. The world and people close you are the thing you don't want to miss out. Especially when it's about being part of something really wonderful, or avoiding something really painful.

That's why Sailfish OS and Silica apps work like they do. They're intended for mobile use, leaner in many ways than the competition. And what they can do, will get you there and back before anything else out there. So you wouldn't miss out the important things.

Now, fire up the SDK and let's get started.

Creating a Sailfish apps

Start from an app idea. The best ideas arise out from a problem cause. You don't want to do more on the go, but less by doing the right things.

Don't look at a desktop applications, or other mobile applications for that matter. Start from a concrete problem. Don't start off from a feature. Look into why that feature is needed. Process your ideas before you sketch out anything. Leave the huge ideas and projects for desktop environment.

Only after you've done that, start coding.

Look at example projects from github, and also shamelessly use both the Silica references and component gallery project that comes with the SDK. Most of the time, you don't need to write your own components. Unless that's the main point. But remember, from the user perspective, how your app fits the platform UX, is more important than how nice graphics you can make or transitions you can code.

Naturally, it's much faster to use existing blocks and focus on solving a problem instead of solving an interface. Also, Jolla will focus on keeping those components working. If our apps are based on them, they’re much more resistant to UI breakages caused by any system update. Apps done with Sailfish Silica components also load faster and scale nicer to different resolutions.

As much as it's fun, avoid innovating on top of already new interface paradigm. It will not help your users. They've just learned a new way to use their devices. Please reinforce that.

Prioritize. Promote the main app functionality. Allow favorites and some history to help access frequently used content. Make your app excellent at the thing it does. Not mediocre at everything another app does. Follow common UI patterns. Keep your graphic assets to minimum to reduce app loading time, memory usage and disk space, and overall improve the app performance. Users have an ambience for their devices, don't intentionally block it, even if you don't personally like it.

Sometimes you have to build something from scratch.

Then, make it look like it fits. Use styles from the Silica theme object. Avoid hard-coding colors, pixel or font sizes. Because if taken to another screen resolution, your app interface will break. Build it to last. Silica component gallery sources and provided references are again your friends to see how components internals look like. Pay attention to UX details and avoid common pitfalls.

Finally, spend time on performance optimization. Load your pages and content asynchronously if possible, to avoid blocking the UI and gesture use. Profiler is your friend. Rince and repeat. No matter what the app does, if it’s not smooth, it’s not very pleasant to use.

Also, don't do things alone. Do it together. Ask from the guy next to you.

There's a lot of people among you who know their stuff and can help. Don't get blocked by lack of support. And many people don't. As a result, Sailfish OS has a huge ratio of community created apps. Apps created by self-organized individuals, out of their own free will. They work on them in their spare time to allow us all make some things easier on the go.

They do it regardless of any payment mechanism in the Jolla store and part of those apps are not even accepted, because some features of the OS are not considered stable yet to hook in by third party apps.

Our community set up their own repository to overcome that. So that there would be an open alternative market to get apps easily from.

You don't do something like that if you don't believe in what you're doing. They believe that having native apps matter. And I agree.

My hat's off to all of you.

Thank you for putting your though and dedication in something you believe in.

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.

Let's talk about multitasking as a feature

And immediately stop before doing any more damage. Look at any recent smartphone or tablet advertisements about multitasking. They're awful.

"You know what, we glued this clunky multitasking mode on the side of an already kind of lost operating system. Are you excited? We surely are, because it super easy for you to multitask when you're in the mood for multitasking."

Seriously. Multitasking is not a feature and you shouldn't talk about it as one. Ever.

An operating system either is or is not designed for handling multiple tasks simultaneously. It's the behavior how the OS treats applications and their windows. Whether it's giving its user a desktop pedigree control over them or not.

Without doing a serious overhaul to your operating system, you cannot change those things. Adding another feature to the side will definitely not do that. It just makes you look funny.

Unless you make stuff up of course. And that's exactly what happens in those advertisements. That will make you look even worse than funny.

Now, the main purpose of a mobile operating system is to allow user tasks to be done on the go. To enable whatever user wishes to do. Be it business, pleasure or both at the same time. The user is in control and the operating system responds to that call without questioning it.

For the experience to be responsive and smooth, the OS needs to be lean and unobtrusive. After all, the OS will always be secondary to what user wishes to do with the device. Complex operating systems require more memory and processing power than simple ones, eating away system resources from user tasks like gaming, browsing or watching movies.

However, implementing multiple home screens, truckload of widgets, separate app drawers or dedicated places user needs to go, to do different things, is just an amusement ride. Disguised usually as personalization. Yet another dishonest word used to cram in features.

Do these features give more visibility or priority to user tasks? Do they free system resources for those applications user wishes to keep ready to be used? Do they improve how application windows can be controlled?

No. They do not.

Not a single one of them had anything to do with improving how the operating system handles applications or makes them perform any better. Neither do they make it any more personal. Personal is not about giving you more things to manage. Personal is about you, how a device fits to your needs.

But what they do contribute towards is increased operating system complexity, increased hardware requirements and development effort. The resulting software is slower to load, slower to learn, slower to develop, maintain and fix. Most unfortunately, it's also slower to use since user tasks aren second class citizens.

Why do people buy that stuff then?

Most of the time they have too much faith in technology. It's easy to show a potential buyer how to flick between home screens or play around decorating them, changing sizes of things and managing bits and pieces. Just an illusion of power or relevance. Merely additional things you need to do since it's there and you bought it.

When buying a hammer, the sales person will not tell you how easy that specific product is to keep on a table, or how well does it match with your favorite novel or coffee brand. You will not hear how pets in general think about that hammer.

Anyone buying a hammer would walk straight out, unless sticking around out of mad curiosity, to maybe get a glimpse of where the sales department ends and the padded cells begin.

But when it comes to phones and tablets, people just blindly trust the technology and ignore all the insanity. They trust that these devises with their operating systems and applications give user needs the highest priority.

Sadly the mainstream crop of smart-devices fail miserably in that. The operating system has become more important. Both the manufacturer brand and the OS are treated as celebrities. User tasks on the other hand can be stopped to save system resources.

The OS race is currently about coming up with desperate distractions. A race that rewards competitor with increased OS complexity, increased hardware requirements and increased development effort. A race funded by its spectators.

Everybody needs to stop supporting this unsustainable competition. Your local school will at least thank you for your donation.

Stop believing blindly in technology because it's so easy to get wrong.

Imagine a mobile operating system as a modern version of a workbench. Only, that this virtual counterpart travels in your pocket. A workbench that has apps instead of tools, to let you do different things. A workbench that runs on your smartphone or a tablet.

It's important that this virtual workbench is designed to support your intentions and the tools you need to fulfill them. Tools that enhance and augment your abilities. Anything outside that is not helping.

One key function of a workbench is to keep all your tools neatly arranged and easily found. When you have plugged in and properly adjusted several tools, it's important that there's plenty of room on your bench for them to avoid repeating unnecessary steps in preparing them for use.

It's how naturally you're able to switch from using a single tool to another one, that defines how good of a workbench you've gotten yourself. It's how much the "generator" inside the bench can provide power to your tools in relation to using it for the bench itself. How many tools it can support simultaneously, without you having to turn off some of the ones you need.  It's how long can you go without having to top up the generator tank.

It's how the overall experience works for you, and for the tools you use.
Multitasking is not a feature. It will never be.

The next time when a sales person tells you how easy it's to flick between home screens, or how well does a widget or a tile match with your favorite novel or coffee brand, or how newly added features are approved by pets, and how all that will make you more efficient; walk out and buy a workbench.

At least you know it doesn't try to cheat or distract you from the purpose it's intended for.

That is an honest product. People. Demand the same from your smart-devices.

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.