[kde-guidelines] Styleguide: Status bar

[Thomas Pfeiffer]

On 04.11.2013 12:11, Heiko Tietze wrote:
> I still think it's a mistake to hide the status bar. But the voting at
> http://user-prompt.com/what-is-a-status-bar-good-for/ is clear (45/45% for
> hide completely and case-by-case vs. 10% for keep it always).
> Since the goal of any HIG should be consitency I recommend to write guidelines
> as below. The case-by-case whatever-you-want "guidelines" would simply be the
> last version without the strong advice to use the status bar, IMHO. What's
> your opinion?

The version below seems a bit contradictory to me, because in the 
introduction it gives arguments pro status bar and then in the 
guidelines it basically says "don't do it". Some suggestions:

> _________________________________________________________________________
>
> Viewing and Navigation > Access functions
> * Try to omit the status bar from your application.
>
> http://techbase.kde.org/Projects/Usability/HIG/StatusBar
>
> == Purpose ==
> A ''status bar'' is an area at the bottom of a primary window that displays
> information about the current window's state, background tasks, or other
> contextual information.

+1

> The status bar ‘frames’ the form and, thereby, has a
> white-space function which is part of the operating system or desktop
> environment branding. Because secondary forms like dialog boxes must not use a
> status bar it denotes a form as primary window too.

I'd remove that part because it primarily tries to sell the idea that it 
makes sense to always show a status bar, which makes it sound a little 
weird that we discourage its use in the next one.

> KDE applications should not use a conventional status bar by default to
> maximize the space for content <ref>http://user-prompt.com/what-is-a-status-bar-good-for/</ref>.

That almost seems a little too strong to me. Maybe
"KDE applications should only use a conventional status bar unless there 
is useful information which should be permanently displayed."? This may 
be too weak...

> == Examples ==
>
> == Guidelines ==
> === Is this the right control ===
> * Omit the status bar in the main window to maximize vertical space for
> content.

"Omit the status bar in the main window if there is no clear benefit to 
it in your application." Maybe too weak as well? I'm not sure...

> ** Do not show meaningless information like 'Ready'.
> ** Use a floating panel or [[Projects/Usability/HIG/Tooltip| tool-tips]] for
> short-term status information like full length text of links.

Is "floating panel" clear to people? Is this what it's called in 
Qt/KDElibs? Is there a standard widget for it?

> ** Move controls to the toolbar.

Okay. That means Aurélien should change Gwenview soon, so that at least 
the HIG authors are compliant with their own guidelines ;)

> * Do not display a status bar in secondary or internal windows.
> * If a status bar is really necessary in your application consider to use a
> [[Projects/Usability/HIG/Toolbar| toolbar]] with all customization features.

Devs: Is it technically possible to place a toolbar at the bottom?

> ===  Behavior ===
> * Do not use the status bars or any kind of replacement for crucial
> information. Users should never have to know what is in the status bar.
> * Do not use the status bar or any kind of replacement to display advisory
> messages in place of standard [[Projects/Usability/HIG/Tooltip|tool-tips]].
> * Keep the status information plain; e.g. do not add icons.
> ===  Appearance ===
>
> ==  Implementation ==
> ==  References ==
> <references>

I'm leaning more toward the "Use a status bar if it makes sense in that 
particular application" approach, but I'd be okay with generally 
discouraging their use as well.