Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 1 down vote favorite
1

I want to know more about status bars, what are they useful for and what is the appropriate way to use them.

I've noticed the following:

  • Status Bars are always located at the bottom with the most significant information in the rightmost side of the screen (why?)
  • Status Bars are often disabled by default (why?)
  • Is the concept of status bar lost while jumping from window-based applications to web, or is it just rendered differently?

I also want to know what kind of messages are appropriate for the status bar?

  • Information that changes often?
  • Modifiable Properties that change the behavior of the application (Modifiers?)?
  • Modeless Progress Bars (Finite or Infinite)

Is there anything I should avoid as a best practice for a status bar?

An example of a status bar is displayed in the image below:

mockup

download bmml source – Wireframes created with Balsamiq Mockups

So pretty much what I want to know is the dos and don'ts of status bars and how they can help enhance user experience. The information above is to be taken as a reference only, so don't feel constrained to ask the questions in this description.

share|improve this question
1  
Can you elaborate on what you mean by status bar here ? Are you referring to a status bar indicator like prof-uis.com/img/tour_ff_img/ff_140_status_bar.jpg or are you talking about progress indicators – Mervin Dec 11 '12 at 23:52
I'm talking about Status Bars. I'm considering that a status bar can have one progress indicator, for example... – edgarator Dec 12 '12 at 0:03
Update your question with some examples so that people know what you are talking about – Mervin Dec 12 '12 at 0:16
2  
I think this question is currently a bit vague. Do you have a specific question? – Kit Grose Dec 12 '12 at 4:48
1  
Consider if this question were about tables. "What are the dos and donts of tables? When should I use them? When shouldn't I?" In that case, the question is too broad. They are a design pattern, and patterns are used in a variety of situations. It's better to read a design pattern library that goes into detail (or a book) than to ask a question here. If you have a specific question, like "Is providing a zoom control in a status bar a good idea" then consider asking that. – Rahul♦ Dec 13 '12 at 12:28
show 1 more comment

closed as not a real question by Kit Grose, Benny Skogberg, dhmholley, JohnGB, Rahul♦ Dec 13 '12 at 12:28

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, see the FAQ.

1 Answer

up vote 1 down vote accepted

A status bar, as per definition of the term, communicates status. This means, by default, reserve it for things that identify the state of the application rather than user actions. Though I can't offer a authoritive source, some things that come to mind:

DOs:

  • application status (location, operational status, identifiers, cursor position, selected tool, ...)
  • background activity and progress (saving, compressing, loading)
  • clickable entries that open context menus for the above listed
  • clickable options that are both descriptive of the application status as well as user modifiable (zoom, settings, notifications)
  • consequences of user action, tooltip-like information (mouse hovering over a link in a web browser, for example)
  • populating the status bar does not change its distinction to content (in look)
  • optionally the status bar is only displayed when there is items to communicate or when change occurs

DONT's

  • user actions / buttons / application tools
  • menus
  • inputs
share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.