Saturday, December 13, 2014

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


  1. Honestly, all I get from this is that you have an irrational vendetta against status bars. You appear to have given up trying to make a rational argument, in favour of flimsy rhetoric, and refuse to consider allowing people to use them in Sailfish because you don't like them. Really not keen on this attitude ...

    1. Hi bluefoot,

      It's not about what any of us likes or hates. It's about what you can develop and maintain with under 100 developers. If you want a status bar, you have to let go of something else. We can't have everything we want.

      I apologize if I've offended you or made no sense, but do you think that the reason for other operating systems having issues, is because their developers want to write bad code?

      If there's a way to reduce the amount of code and work, please forgive us for going that way. I hope you understand <3

      Thanks for your honest comments :)

    2. This and the previous article referenced seem like perfectly rational arguments. Removing the status bar and tool bar opens up all the screen to app use and a full screen for the status is much easier to read.

      Perhaps you should describe why you think status bars are better?

    3. In retrospect, it Jolla would've had more comparable resources to Nokia, Google, Apple or Microsoft; we've would've most likely ended up with more or less identical solutions as they did. I believe the driver for design would've been more or less a pretty paint job, not to find ways to do a minimum viable product.

      In such case, the status quo would've stayed the same - avoiding this discussion. On the other hand, there would be discussions about "same sh*t, different pile" or "someone is copying someone, but who is copying who", and finally someone suing everyone.

      The usual mobile industry..

  2. Hi bluefoot,

    I think you dont get the point behind this topic. Beside the complexity added for developers, status bar takes place on the smartphones small screen (don't get me wrong, even 6" is a small screen compared to laptops and PCs) instead of this place to be left to display content that we consume. When I watch a video on my smartphone, usually there is no status bar on any platform, because it is not needed and it is natural not have the status bar, so why the status bar (or any other bar), sould be displayed when I read an article in the browser or when I use another app? To me it is natural to have all display reserved to the content I am using, everytime...


  3. Good read. I like the minimalistic, gesture driven approach you have followed for Sailfish. I agree, the status bar has no real function most of the time and shouldn't be constantly visible. One thing that concerned me a bit about your comment above, is that you mention that the decission about not having a status bar is also related to resources and system complexity, wich you wanted to avoid. To me the concept of peeking is brilliant, and I just hope that you keep following ideas like these, not because they are easier to implement and reduce costs, but because that is your vision as a designer. Keep up the good work!

    1. Thanks, much appreciated :)

      I agree, just making something because it's easy, is doing it for the wrong reasons. That should be naturally avoided.

      To me, a vision equals an excellent understanding of both the product (OS) and the material used in that product (software). When you have worked years with those two, you just do less mistakes, assume less, and finally know how to use those materials to make a better product than the previous one.

      The vision is rarely about smaller details as such, but the bigger picture. Our vision is one handed, mobile optimized and user task centered user experience. Doing an OS like that, is a huge challenge, so our design goal was to make those technologies we have in our use, to serve user needs as efficiently as we could.

      That way, you focus on designing value to the end user through promoting the good qualities of software, while demoting the bad ones.

      Rest assured, I'll keep following the same path, and we'll all make the OS better together.

      Thanks for commenting!

  4. Statusbar or not, it would be great to be able to check the current date easier. I mean status bar would show it all the time. In Sailfish you have to swipe left or right to put the current app into background, then swipe up. Why the current date isnt showed under the clock, so that you could peak from any app swiping left or right. Other status bar info is already there...

    1. Absolutely, the way date is in the lock screen alone (or at home if you're keeping the calendar app open), is not good.

      Having the date next to time is an option we have studied, but the events view might end up to be more probable place for it. There, it's always a one gesture away to check, and can be made more legible compared to status area.

      What do you think, would that work for you?

      Thanks for commenting about it :)

    2. I would like it more if the date would appear next to time as they are both the same kind of info, time units. But I wouldnt mind if users could customize these things a bit more in ui, make more (smaller) icons available in launcher (the current 4 x 6 grid > 5 x 7, 6 x 8), a way to customize how the led indicator works (I would like to stop led blinking after battery is charged) and so on. Those kind of tiny customizable options would make sailfish fit better for different needs. But to the topic, make it an option to show date next to time and an option to show it on events page, users like to choose how to use it. No need for status bar = true!

    3. Yeah, they're all time units. The reason why hh:mm is only displayed, is that date changes too slow to be required _all_ the time (currently user exposure to date information is bad and needs to be fixed). Same goes for seconds and tenth of a seconds, too fast to be really useful _all_ the time, even if they're time units as well :)

      Adding options to customize layouts like that are possible in the future. There's such amount of functionality and maturity work in our backlog, that actually prevents SFOS from being a daily OS for many.

      What I have learned in the past, about layout options in platform work (not just apps), that they always break at some point since the amount of testing goes up with the amount of possible combinations individual settings generate. It's not impossible to manage, but just something that we have to be mindful.

      Don't take this as a no, because it's not. I'm just being honest with the priorities we need to operate with.

      Thanks for explaining your preferences, it's very useful :)

    4. Hi Jaakko,
      I agree with the poster above. Since date is time related info, it would make sense to display it with the clock. I understand the desire to keep the UI clutter free, but many people do need to know what date it is, even if they only check once a week. Checking the date by peeking would certainly be useful. Maybe a possible solution would be to make a "smart" peeking view that would show the most useful information, depending on the context, and the longer the user stays in "peek mode" the more information is displayed. This way, quick peeks would just display the most relevant info, like it is now, but if you wait a little longer, you get additional info, like the date, or if you just got an email, or someone sent you a message, it would show you a preview, or if you just woke up, it could show the weather forecast, etc. Any way, you get the idea.

    5. True. Context awareness is starting to get really popular, but it's not trivial to implement with good quality. It also requires access to user location, data, connections and communication events. I would imagine people might have problems accepting that (based on related Apple and Google news). Tricky tricky.

      Time based information priority is possible (user waits for an information to appear) is easy to do. I've played around with the idea you just described in the past, but selling it forward hasn't gained support.

      All in all, date information is hidden atm, and the UX related to that is broken beyond bad. We're working on it :)

      Thanks for sharing your thoughts, see you around!

  5. I prefer full screen for apps, most of the status bar info is static and accessible by swiping left.

    1. Many apps wish to be full screen these days. Android way to double top swipe to get status bar back is a pain.

      Thanks for stopping by to comment..