[kde-guidelines] Styleguide: Status bar

[Teo Mrnjavac]

On Friday, October 04, 2013 17:26:26 Heiko Tietze wrote:
> On Thursday 03 October 2013 16:46:49 Thomas Pfeiffer wrote:
> > On Thursday 03 October 2013 11:51:45 Teo Mrnjavac wrote:
> > > The KDE way is what KDE wants it to be ;)
> 
> Exactly!
> 
> > > The guideline could simply say
> > > * Provide a status bar in the main window of an application if the
> > > application needs to constantly show relevant and changing status
> > > information.
> 
> That would be a compromise but I believe a bad one because it give too much
> leeway to the devs.
> 

As a developer I don't really subscribe to the too-much-leeway argument, but I 
understand your reasoning, so even if we assume that a guideline should be very strict, 
it makes no sense to require a status bar from applications that simply do not have 
relevant info to show there. At least to a point, form should follow function rather than 
the other way around. If anything, this has been the KDE way :)

> > I agree with Teo here: I don't think a status bar should be a must-have
> > component of every standard GUI. If it contains useful information, it's
> > worth the space it occupies, but if it has no real use, it wastes vertical
> > space and, frankly, an empty gray bar also looks rather ugly.
> 
> My pro status bar arguments are:
> 
> 1. It shows useful information, both static or long-term and variable short-
> term. It makes sense to know all is going right even with a simple 'Ready'
> status at kmail.
> 

Sometimes it does, sometimes it really doesn't. "Ready" is not useful information at all. 
Any GUI program worth its salt is ready for input most of the time. That's the 
fundamental idea of interactive applications since the appearance of event-driven 
programming. "Ready" is expected, and what is expected is not news.

> 2. We do not have a good replacement if we neglect status bars at all. Even
> if kmail would still be accessible without the 'Ready' information, it
> would lack of the progress bar on slow communications.
> 

I wasn't suggesting neglecting status bars, at all. I merely proposed using them only 
where needed. Again, as far as KMail is concerned, task progress could be comunicated 
in other ways and places.

> 3. A status bar frames the application. It denotes it as primary window and
> has a white-space function (I decline the rare vertical space argument).
> 

Only if we decide it does. The feeling of a status bar framing or not framing an 
application seems quite subjective to me. Besides, maybe there's some other way to 
"frame" and application that wouldn't take as much space ;)

> 4. Whether or not a status bar is used, along with the main menu bar and the
> tool bar, brands an applicaiton for an OS. Rekonq, for instance, looks like
> an alien to me.
> 

I guess I don't perceive a status bar as an element of branding as much as you do. 
Rekonq looks fairly slick to me, and not an alien at all... and I find it makes sense to 
*not* use a status bar in its case, because it would only show relevant info when 
hovering a link. Better to show as much of the web page as possible instead.
If status bars are used less prominently throughout the KDE environment, they 
automatically cease being an element of branding, so either way this is a non-issue.

> IMHO the last point is the most imortant.
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines

Cheers,
--
Teo Mrnjavac
http://teom.org | teo at kde.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20131004/92366ab6/attachment-0001.html>