A Brief History of the Status Bar

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.