What is a status bar good for?

The KDE usability team discusses pros and cons concerning the default visibility of the status bar and asks you to vote how the future should look like.

In the course of revising the KDE human interface guidelines we outlined recommendations for the status bar recently. But actually the status bar has taken flak from another side before. So we’d like to conclude the discussion here and want you to vote for the solution you like best.

Introduction

The status bar, or rather the function, is known and recommended for ages. For instance, the dinosaur Guidelines for Designing User Interface Software by Smith and Mosiers (1986) demands that

“Status information on current data processing should be available at all times, automatically or by request.”

On the other hand, Mac OS X dropped the status bar since Lion from its file manager (it can be re-shown via menu). Mozilla Firefox got rid of the static status bar with version 4+ and replaced it by a small pop-up (aka floating status bar). Most OS including Microsoft Windows and Gnome 3 omit the status bar in favor of a plain, flat design. Probably to fit mobile devices.

This recent development has soaked into KDE too.

Discussion

Alex Fiestas started the discussion ‘thoughts about statusbar’ at the plasma-devel mailing list last year:

Taking a look at some apps, I’ve noticed that most of them have an almost unused statusbar (or totally not used in some cases) resulting in a big empty grey space…. should we fix the status bar by removing it and placing somewhere else the content (if they are really needed?)

Rekonq was discussed as an example that does not provide a status bar at all. When the mouse cursor hovers over a link, the URL is shown as floating status information at the bottom. An other example is KMail that just notifies its state (usually: ‘Ready’) in its status bar. A compilation of how KDE apps make use of the status bar was done by David Edmundson.

Konqueror (static status bar vs. Rekonq (floating status information)

Figure 1: Konqueror (common status bar) vs. Rekonq (floating status information)

The general agreement was to use some kind of floating widget for short-term information, to place controls currently embedded in the status bar somewhere else (based on a case-by-case decision), and to move static information to another place.

Summarization

Unfortunately, no advocate of the status bar participated in the discussion. So we summarize first the outcome of the discussion on the mailing list and discuss some pro arguments then. To be fair we add antithesis against both pro and contra arguments afterwards.

Contra

  • The status bar occupies precious vertical space.
  • Information is often meaningless (e.g. ‘Ready’).
  • Applications make inconsistent use of the status bar.
  • Text is restricted to a single line; a fancy design is not possible (which might be relevant to notify about more important information).

Pro

  • The status bar is a well-known control that users are familiar with.
  • The status bar ‘frames’ the form. It denotes it as primary window (secondary windows like dialog boxes should not utilize a status bar at all) and has a white-space function.
  • It’s easier to always use a status bar and ‘brand’ the OS (or rather desktop environment in case of KDE) in this way as to omit it total. Case-by-case decisions shouldn’t be defined as the default (any app is free to defy the HIG).
  • Most users want to stay with conventional layout; e.g. there has been a lot of complains about removing the status bar from Mozilla Firefox.

Anti-Contra

  • Rare vertical space is a minor argument in times of 27″ displays with (W)QXGA resolution (Do you regularly maximize windows?).
  • Even simple ‘Ready’ messages are useful to keep users in a state of reliance.

Anti-Pro

  • Simple ‘Ready’ information should be the normal state, not worth noting.
  • Framing is a subjective argument and would get replaced soon by a new, plain design.

Please vote

So we have a lot of arguments pro and con. Any further conclusion without adding personal opinion is hard. And we, the KDE usability team, want to support you, the developers and users. Our goal is to define valuable defaults for the KDE HIG.

Please state your opinion:

How should KDE applications deal with the status bar in future by default?

View Results

Loading ... Loading ...

As always: developers are free to reject the guidelines (which sometimes makes sense), and it’s KDE style to let users switch features on or off.

Your comments, feedback and arguments are well appreciated. So: Join the discussion!