The status bar.  A ubiquitous piece of the modern user interface, hardly anyone seems to pay it mind.  That attitude often extends to interaction designers as well.

The status bar, if you are new to the world of computers, is the (usually) gray strip commonly found at the bottom of application windows.  First introduced as a standard OS control as part of the Windows 95 common control library, the status bar has its roots in character mode programs, in which the bottom row of text was reserved space to show information about the program, document, or selection.  Commonly, the status bar in character mode programs would tell you which keys to press to perform certain actions.  For example, here's a rather advanced version of the MS-DOS Shell application complete with menus and its own status bar.


The MS-DOS Shell status bar (Click to view full picture)

Fast forward to today.  Most programs have status bars, but do they need them?  If you've read my post on the value of screen real-estate, you can guess what my answer is.  If I were starting design on a brand new piece of software today, I certainly wouldn't start with the assumption that a status bar was required.  This is a case where people seem to often confuse function for form.

The most egregious misuse of the status bar is probably the case of "an empty status bar just so my window gets a resize grippie."  Most resizable windows today include a little widget in the lower right-hand corner to give people a bigger grab handle by which to resize the window.  This is probably inspired by the original Macintosh which not only had a resize handle in the lower right-hand corner, but only allowed you to resize windows by using the widget.  (Unlike Windows which allows people to resize windows from any border.)


A program with a status bar and integrated resize widget (the "grippie")

When a designer wants a resize grippie, in many cases the easiest way for the developer to get one is to throw a status bar into the window.  Set a few bits and, voila, the resize grippie comes for free.  Unfortunately, this method is easier than carving out widget space in the window and handling the right non-client messages to make the resizing work right... hence, we get programs with an entire wasted line for nothing other than a resize widget.

Things don't get much better once people start using the status bar space, however.  How should the status bar be used?  No one seems to agree.

In the olden days (pre-Windows 95) the most popular use of the status bar was to include a clock in the application frame.  Of course, everyone implemented the clock differently, so some blinked, some showed seconds, some updated on a timer, some polled every second, some updated the time only when the window was in the foreground.  I remember lining up a bunch of windows in the college computer lab and noticing how they all showed different times.

Some designers have made the decision to use the status bar as a kind of help mechanism; I have several programs running that just say "For Help, press F1" most of the time.  In fact, in old versions of some Office programs, as you hovered over menu items, descriptions of them would appear in the status bar.

I have several web pages open in Firefox and the status bar is empty except for the word "Done."  Internet Explorer shows the same thing but helpfully adds the word "Internet" on the right side.  I have a Windows Explorer window open and the status bar reads "505 bytes" and "My Computer."

When we sat down to think about the status bar as part of the Office 12 redesign, the first question we asked was simply: "Do we need a status bar at all?"  Opera comes to mind as a program which at one point had a design in which the status bar would appear when there was truly status to impart, and then disappeared to give you the space back once the page was loaded.  In the most recent version, they've turned off the status bar altogether and integrated progress into other parts of the UI--something I think is a very clean design for a reading experience.

We've put a lot of thought into creating the right status bar experience for Office.  Tomorrow, I'll describe the details and the thought process behind the design.