Breaking free from my invisible prison

Everything that we know today is based on our past experiences. Our knowledge is limiting what we can create tomorrow.

When we solve a problem, we tend to stick with that solution and keep improving it. That affection prevents alternative discoveries from happening. Alternatives, that weren't possible at the time of our original idea. Alternatives, that have much higher potential in the long run.

Various limitations that are affecting our past tools, will silently keep limiting the potential of our future ones. It's not natural for us to consider our proven solutions as restraints. Well, this isn't a prison made of concrete and steel, but obsolete or incorrect knowledge that we fail to see. And what you can't see, you can't escape.

I joined Jolla in 2012. It took me almost three years to discover my self-imprisonment. Back then I could only work with knowledge withing those walls of mine. I was happy to repeat what had been done before. It didn't use to matter, as anything was always possible before. I was either creating concepts or working without time pressure. It all changed when I started working with Sailfish OS.

I guess it was the immense pressure that finally pitted me against my own knowledge. During these three years, I have questioned majority of what I know. Life of uncertainty and constant doubt has been hard, but at least those walls gave in before I did - ironically only to be replaced by tiredness and loneliness. Abandoning things I've held as facts for many years was a cruel journey. Mainly because I just traded one solitude for another.

Our existing knowledge is our happy place, and it's perfectly understandable to fight for that happiness. They say that ignorance can be a wonderful thing. It's only human to seek comfort through stability and order - until one dies. To me, that's a horrible waste. Loneliness I can deal with.

So remember. The knowledge you have gathered doesn't update itself. If there's something you really care about, you should question everything you know about it. Sure, it might get lonely for a while, but it's imperative that you do.

Because tomorrow will be just like yesterday if you don't.


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.

Tailoring graphical user interfaces for everyday life

When developing a graphical user interface for a product, it's easy to forget the outside world; the reality that your product will ultimately face.
 
It's tempting to downplay the importance of various everyday situations. Mundane, boring and even stupid situations, that have nothing to do with your amazing new product; yet everything to do with how much user attention they require. This common and critical mistake results in a struggle between the product and the environment it's being used in. Below is a simplified example of this conflict (click to enlarge).

The image shows how the environment affects our ability to focus and handle information. The more control we have over the environment we're in, the more demanding interfaces we can cope with.

Mobile and portable devices are widely adopeted because they conform to dynamic and unpredictable qualities of human life. We naturally have a lower barrier toward carrying small devices with us. Therefore a smartphone is more likely to be used inside a taxing situation than a desktop computer.

On the opposite ends of that scale, we can either be fully engaged with the environment, or with the graphical user interface. Even a familiar and simple interface will be problematic in a demanding situation. Like composing an email while outrunning a bear. Similarly, any smartwatch interface feels lethally boring and restrictive, while waiting for another meeting to end (you'd rather tussle a bear). For reference, see the following image (click to enlarge).

Our available time, at any given moment, affects what we consider important. When a situation requires any attention, completing another task will costs you situational control and awareness. The expense amount depending on both interface needs and the task complexity in question. In short, if you text and drive, you'll suck at both. Human multitasking in all its glory.

Therefore it's important for interfaces input requirements to scale accordingly. The problem is that many interfaces today, like Android, iOS and WP, are already beyond their capability to do so, forcing the user to give in. The reason is a devious one. Even if people don't like to carry around tower PCs, they still love the familiar interface logic derived from them. Even though many human interaction methods, that were developed for desktop computing, are far too demanding for the life outside those cubicles they were never meant to leave.

The smaller your product is, the more focused, effortless and fault tolerant the interface needs to be. I know that our work on Sailfish OS is not there yet either, but it's still easier to keep on building it on top of thoughts like these.

A mobile device that fits your life, is valuable. One preventing you from living yours to the fullest, is not.


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.

Opinions kill open software

It's happening. Silently, slowly, without exceptions. Dead, gone, deceased. You just don't know it yet.

Some background before proceeding. My previous post, about good and bad software, underlined how important it's for everyone to know why a particular piece of software exists. Especially in FOSS development.

The problem is user expectations. Our past experiences naturally affect our preferences, and we subconciously project them to new software. This pulls developer toward how, away from what the software was created to do. And since we're all unique, it's difficult to see the real reason from our equally subjective viewpoints, steering the software into a direction illustrated below.

The reason is that FOSS users engage much more in software development, when compared to proprietary software users. Everyone knows that much about software, that anything is possible with it. It's a holy grail of every software project to be pursue sophisticated frameworks that support our highly heterogenous user preferences.

You might not realize it, but the price a proprietary software user pays in cash, a FOSS user pays in responsibility. We're all priviledged to have an alternative, and we should respect the reason it exists. Don't neglect or avoid it by suggesting yet another user setting or customization framework. That's always away from what the software can do to everyone.

If FOSS alternatives will ever reach a wider consumer adoption, they'll do so being faster to develop and maintain. By going faster to places a proprietary software is too heavy and cumbersome to go. By helping people to do more, faster, simpler and more reliably. By giving us our time back.

That's why it's imperative that the development is focused. One software can't adapt to seven billion amazing opinions, but seven billion people can adapt to one amazing software.

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.

 

Good and bad software

I'm going to start with an argument.

Software exists because people are lazy; not that it's a bad thing. Throughout the history, it's been one of the greatest sources of ingenuity. A wonderful catalyst for ridding inefficiency.

It all started with a lazy person, defining a set of instructions for a machine, for it to do something people are bad at, and machines fantastic.

Those lines of code, running on a piece of hardware, helped that person to get more work done. Ideally, the time invested in instructing a machine to work for us, is far less in a long run compared to us doing all that work ourselves, impeded by human limitations.

Software exists to use computer's potential on tasks which people struggle with. People simply need to focus on instructing it. Sadly it's the focusing part where things usually take an unexpected turn from the ideal road. Right through the safety rail of professional training. Over and off the cliff of common sense. Straight into the bottomless pit of irrational. I visualized the problem below.

Given that a same amount of people, with equal skillsets, are working on a software project with identical goals, it's more likely that they end up with what I personally think as bad software.

Such software doesn't do what software is supposed to do. If you get stuck on the user interface part, you're missing the reason why people use your product. You have just instructed the machine to play hopscotch with the user, instead solving a user problem. The balance is just way off. Bad instructions, bad software. No amount of excuses change that.

Beautiful, well performing and behaving user interfaces can be built with relatively little amount of code, if you know what you're doing. If not, you easily end up with a complex and overdone interface; a monstrosity that needs even more complex customization options to tame -- or fire to kill, as it depends.

Still, game over.

Becoming blinded and trapped by the user interface iteration loop is very easy. It's the most visible thing for everyone in the project. That's why it's so important to be aware of this danger. Adding more interface easily feels like adding more value. How wrong can people be. You only waste resources on things that:

• end up eating even more resources since you're stuck with maintaining it
• restrict your options for potential devices and businesses in the long run
• distract user from the real value your product offers = less appealing product

"But Jaakko, isn't there many other areas as well that affect software goodness / badness?"

Yes. There are. A lot in fact. However, this one is something everyone can and should understand. It doesn't take a computer science PhD to figure this stuff out. It's especially important for companies whose business depends on software quality. Even more so with startups and small companies.

I'm going to end with an argument.

Your company exists because people are lazy. Make sure your product focuses on helping them, like a good software does.

 

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.

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.

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.

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

Responsible product development. Family style.

When creating something, you sign a responsibility pact.

By respecting that pact, your creation has all the potential in the world. Just like a child has.

The same parenting guideline applies equally for new products. You have already developed a deep understanding between your child, and it's your responsibility to make everyone understand and respect that. A small child cannot yet communicate that. Neither can a new product.

It doesn't matter how many of you there are, you're all mutual parents. The whole company is.

You all have valuable information related to the well-being and success of your child. If you share that information with new people becoming involved in your child's life, everyone greatly benefits from that. Especially your child.

The challenging part is, that most of the time, it's people you don't see. People in meetings you never attend. People in cities you never visit. People in companies you've never heard off. They all have expectations for that potential you've been meticulously nurturing.

Therefore it's important that everyone of you understands their role as a parent. All of those new external expectations can be perfect opportunities for your child.

Just remember to ask and also listen if your child wants to play hockey or piano. Break down those expectations to see how they fit the personality and traits of your child. Don't just blindly decide and demand something.

Because that breaks children, instead of helping them to grow. Don't expect opportunities to create a perfect child for you. That's just horribly wrong.

Treat those expectations as goals. Because they'll help your child to grow; to become stronger by overcoming challenges. However, it works only as long as it's the child who's overcoming them. Everyone else around is just a safety net, allowing graceful failing, and encouraging to retry. It's about honesty toward your child and ones potential.

If you solve a puzzle for your child, it's you who did it. No matter how hard you claim otherwise.

So don't make dishonest promises to anyone. Those just end up hurting both the growth of your child, and your role as a parent. Don't ask your child to skip elementary school in favor of dreaming about university.

People will understand if you openly explain your family values to them. What makes your child behave like one does. Also, if your child suffers from a permanent illness, it's only good if people involved are aware of it.

In the same way, every product has their shortcomings and weaknesses. Be open about them to others, and avoid planning the future on those weaknesses. A lifetime of failure will break children as well.

So remember to listen to your children.

Don't force them into being something they're not. Nobody benefits from that.

Because if you do, I sincerely hope that the responsibility pact in question was not signed in blood.

Our children deserve better.

Both in family life and product development.

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.

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.

Keep moving forward

When launching a new product, you have already analyzed existing products and planned the best place to operate from. Due to customer base size, you compensate the overall offering by focusing hard on areas other products fail to excel in.

This justifies your claim to the land for now. Other manufacturers have to work much harder to offset your offering in these neglected areas.

But they most likely have already started to plan their move. Their problem is your strength in area, so you've got some time. But the last thing you want to be doing is to sit down and admire the scenery.

First and foremost, you need to move forward.

If you're not moving forward, you're staying still; but since the competition will be always moving forward, it makes the time spent on sitting still, look like moving backwards from the consumer perspective.

What causes a company to stay still? Most of the time it's caused by obscure company targets, but the biggest threat usually comes from within. We're all sources of potential disaster. Everybody might know that there's a need to sustain the movement.

But instead, somebody gets an idea.

Most of the time, ideas are harmless, abundant and pop up everywhere. Everyone has them and there's always good ones in the lot. The problem with ideas is usually in both what affected to the idea creation and how we treat that idea.

How an idea is processed.

The most common type of an idea is a borrowed one. And the cheapest too, in many ways. It's easy to take something that already exist and swallow it as a whole. Hope that nobody notices. However, if everything is copied from existing products, there's no way they fit together and form an enjoyable product to use. At least don't market it as such.

To make it easy for you in a long term, take the idea apart, see what's inside that makes the idea valuable (how does the idea create value with the end user). Grab that, and move on.

From an idea, salvage only what you can carry. Don't carry a car wreck if you only need a spare fuse.

By doing that, the idea is easier to fit to everything around it, so that you don't fit your product into the new idea you had/found/borrowed. That's insane amount of work. You don't want to do that when you need to advance.

Treat all ideas as means to expand towards a new areas, not to move your whole camp. Remember to strip ideas down, so you don't have to deal with any of that dead weight. Then, look at those areas (cloud storage as an example) and see how you can replicate the end result and value that competing products create, but do it from your direction. Do it with your tools and ways.

It's much easier for you, and it will reinforce and harden your existing product. The idea will work together with other ideas.

This is what moving forward means. Moving without risking your foothold. Because the direction you approach an area, is on the opposite side from the competition perspective, and it will be difficult for them to come knocking hard on your doorstep. Creating value is not patented. Creating it with their way usually is.

Having your own direction to look at things, solve problems and empower user, builds on top of your existing strength. You appear moving without leaving the place you struck down your flag. And the longer you keep doing this, the deeper to the ground the pole goes.

But

Sometimes things don't work out like planned. An idea slips past. It doesn't get properly dissected and analyzed. If you end up integrating the unprocessed idea into your product, you'll be adding all that dead weight of the car wreck as well.

Even if you just needed that spare fuse.

It can sometimes be intentional. It can be driven by someone who thinks the car wreck plays an important role in the user experience. Or that the user experience is not relevant, and the wreck is welcomed to stay. Horrible things are set in motion. It usually starts with these words.

"Taking just what you need is not enough"

It's no joke folks. Fear it like the Plague. When you hear those words, things are about to take an irreversible turn to the fiery purgatory. A new entry will be written in the book of atrocities, under the Eternal torment chapter.

The idea has become more important than reaching the value it represents.

And the idea, at the end, will consume you, your product and everyone else working with it. I tried to make as accurate image as I could, of an unprocessed idea gone bad, so you can avoid it when you see it.

Behold.

Still, hyperbole aside. Process your ideas, treat them as ways to enter new areas from your direction and stop integrating dead weight.

Carrying dead weight is stupid.

What makes things unsustainable is the complexity and unnecessary amount of code it introduces. It will be there forever and you just have to deal with it. Maintain it, fix it and love it.

Unconditionally. Look at the previous picture. Make piece with it and give it a kiss.

If you're a developer working with that idea, or next to it, be afraid. Be very very afraid. You're not going to be moving anytime soon.

And when you finally nudge into motion, with all that weight you've picked up and maintained over the years, your product will be extremely complicated. It had to overcome unnecessary software complexity, horrible legacy, and also bypass and re-route countless user flows to hide it all. For what?

Good luck quickly entering any new areas or responding to business opportunities. Even a team of seasoned software exorcists will not be able to mop up that stuff anymore.

Finally, after a hard lifetime of slowly pushing a software behemoth like that forward, you'll probably ask yourself, and your thousands of in-house brethren: Why didn't we just take what we needed?

Something as simple as a spare fuse, can make a difference between moving forward or staying still.

Make sure that everybody in your company understands that.

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.

Thoughts about doing the impossible

Happened on a beautiful autumn day at Kangasala, near Tampere.

We were having a get-together with our friends. Kids were nicely playing outside, when my friend and I were tasked to lure them back in.

And out we went.

While persuading the loud lot to seize their sandbox adventure, in favor of sitting around the table inside, the topic of something being impossible somehow popped up.

Saying that something is impossible is very easy.

People default to impossible all the time when they don't care to think about it. When Jolla first came out with the news of continuing from where MeeGo had previously fallen off the grid, many reached out for the default reaction.

To build a new operating system, with a smaller crew than what Samsung has people for making coffee, was treated as nothing short of hilarious.

It was a good laugh. People from all over the technology industry stood up for a chuckle. Important people. Powerful people.

Impossible was contagious. Once someone said it, it was easy to agree on. All you had to do, is repeat it.

We got told it's impossible without 100M€ investment and serious commitments from industry partners. The emphasis was on impossible.

When repeated enough times, it turned into a truth. It was now officially as impossible as it was hilarious.

I don't like the word impossible.

Improbable is much better. Because that's how it usually is. Things have varying degrees of probability.

When you think about the word impossible, it's a stop sign for your thoughts. You're not allowed to proceed. It really is impossible. However, if you replace the impossible with improbable and think again, you're allowed to take a closer look.

I like to take things apart. In my opinion, many things are more beautiful on the inside. For me as a kid, it meant great fun.

For my parents, property damage.

Taking thins apart is a good way to judge probability? Up-close, you can identify things that increase or decrease the probability.

For Jolla, the improbability factor was in the insane ratio between the amount of work and the amount of people working on it. Since we couldn't really help the people part, only the workload remained.

Let's summarize it.

It was considered improbable for a small start-up company to be able to build an operating system by themselves.

Now, that's already pretty well defined. Then all you need to do, is to increase the probability of building it. And that happens by focusing on what you're going to build.

What counts as an operating system?

Do we automatically imagine Android or Windows, both of which have accumulated an unhealthy amount of complexity over the years. Building something like that might be very improbable for Jolla. So, can you leave something out to increase the probability. To design something that counts as an operating system, that can be still built with the few people we had available.

All of a sudden you're talking about what is important, in what order and who does what.

A huge step from impossible.

When the news started to flow in, about global operators and retail chains signing partnerships with Jolla, the chuckling suddenly stopped. People from all over the technology industry stood up to look at each other. Important people. Powerful people.

With a question on everyone's lips: who said it was impossible?

Not to mention shipping also a phone running that operating system.

Only 10 days late of reported schedule.

With less than 100 people.

With around 30M€ of total investment, instead of estimated 100M€.

Be careful what you label as impossible. Because if you do, someone is bound to prove otherwise. What you deem impossible today, will most likely be only improbable tomorrow. And when that happens, it doesn't matter how important or powerful you are. It doesn't change the fact that you're mistaken.

So, every time you wish to dismiss something as impossible. Don't.

Just replace the word impossible with the word improbable, and think. Work your way with increasing its probability. Wonderful things can be achieved with an open mind and a positive approach. And if it's not probable enough today, pursue it tomorrow.

At the end of the day, negotiating kids to stop all the fun and go inside to wash their hands, wasn't impossible.

Just improbable.

And that we could already work with.

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.

Pushing the touch interface to the next level

Earlier this year, at World Mobile Congress in Barcelona.

Before his main interview, I explained a journalist what Sailfish OS interface is all about. Why improving how touch interfaces work was important.

In the evening, I got to read this.

Breaking the smartphone mold isn't easy. Just ask Jolla

I was taken to school that day. Learned a thing or two about talking to media.

No regrets, though. To keep sucking, I got a vacuum cleaner as a gift (it was waiting for me at the office - I love you guys), and the resulting article title is spot on to wrap this post around.

Before you start creating anything, you have to make a choice.

Is it enough to stick with what you have? Is there anything you can keep and re-use? Or is it all beyond saving and starting from scratch is the right thing to do?

As I mentioned in my previous post, the problem is in the interface. The reason for the hurt came from the button based navigation. The solution that already existed before the problem did.

We raised our sledgehammer high, and brought it down hard. Buttons had to go.

As the dust settled, our creation emerged as pictured below. A smartphone with three buttons less. It doesn't look like much, now does it?

And that’s exactly the point. It’s not about the looks. It's how it works with your hand. It's your hand that completes the touch interface.

Not by adapting, but by the way it naturally works.

It's more than what you see. Much more. When you take advantage of how the human body works, several benefits are gained over other interfaces, that treat our hand mainly as a mouse cursor replacement.

First comes comfort, because your hand size is irrelevant. Then speed, since less accuracy is needed.

Finally, when your brain recognizes a familiar pattern, it can immediately perform the matching interaction without eyes confirming it. It's just the way our body works.

And the interface works with it. Not against it.

Meet Sailfish OS.

The most commonly used actions (Home, back...) are based on simple gestures. This means they can be performed exactly where your thumb is most comfortable during content interactions (and not like this).

The notifications page access is also moved to the screen bottom edge for easier access with larger devices. Your hand is usually closer to that edge. Especially with larger phones and tablets.

My next post will illustrate better how Sailfish OS interface works. Meanwhile, you can check some quick tutorials on Jolla's Youtube channel.

In short, you swipe over the screen edge to interact with what you feel. From the screen center, you interact with what you see or know. But, I'll do a more detailed post about it next.

For a touch screen interface, our ability to know at all times where our thumb is in relation to other fingers, is important. To test it, close your eyes and pick up a phone. With your eyes closed, try placing your thumb on the center of the display. Next, try finding the device edge.

Both are very easy to do, because you've had that hand (and brain) since you were born. It's natural for you.

However, allowing you to make use of it on a smartphone, someone has to break the smartphone mold.

The one with the buttons.

Help us break it.

We're few against the many. The perception of what a smartphone is doesn't give in easily. It's been the toughest thing to face in my professional career. Almost every day I hear or read from someone how both back and home buttons are etched in the minds of smartphone users so deep, that it's impossible to change.

And that's sad to hear because it's not true. It's improbable to happen overnight, but definitely possible when given time.

Just by following others and copying what they do, takes nothing forward. Copying is the reason we're stuck with over a decade old touch interface with buttons in wrong places. When you copy, you don't think. When you don't think, stupid stuff happens.

Sticking to a vision has already made a big difference for our community. Instead of copying what others do, we challenged the smartphone industry. A tiny company with a wonderful community succeeded where many companies have failed.

In being themselves.

If you ask me or anyone working at Jolla, you will hear it's not easy to break the mold. Ask our community the same question, and they'll tell you it's already been broken.

A more natural touch interface might not sound like a big thing. Until you try it yourself.

And you've just hammered off a good chunk out from the smartphone mold.

Roughly the size of you.

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.