rdale at foton.es
Sun Feb 21 12:06:45 GMT 2010
On Saturday 20 February 2010 05:49:48 pm Eike Hein wrote:
> On 02/20/2010 06:17 PM, Aaron J. Seigo wrote:
> > the lack of a menu bar, or the lack of a status bar?
> The lack of the menu bar was foremost on my mind, 'cause
> that creates problems with keyboard navigation and so on.
> I don't think a status bar is mandatory as far as the HIG
> is concerned, but it sure is useful to show the action de-
> scriptions as one hovers menu actions. I suppose one could
> do that with Rekonq's popup status bar as well though.
> Anyhow ... in general, also on other app platforms,
> there's this trend to see it as a-ok for the browser to
> diverge from the normal platform UI standards since it's
> in some sense a platform unto itself. Who knows, maybe
> that's even a correct conclusion to make, but it's some-
> thing that our HIGs would need to be augmented to address
> head-on, otherwise the divergence strains their credibi-
> lity. Just like the credibility of Apple's HIG is strain-
> ed every time Apple decides to ignore them and just do
> something different because they feel like it.
Well which platform has always tended to be one of the best at innovating in
UI terms? People have always been continually experimenting on Apple platforms
in the past, and often some of the interesting ideas get incorporated into a
I think the best way to regard HIG documents is that the aid the average
designer to achieve a minimum standard. But great designers like Will Shipley
are able to innovate without the aid of 'doing it by numbers' type guides.
> I think our HIG is really important to the KDE SC's iden-
> tity as an app platform - we're not just a set of libs,
> we're a user experience with its own set of conventions -
> and we should really take care to manage that responsi-
> bly and not lose cohesion.
There is a document called 'KDE HIG' on TechBase certainly, but I don't
remember seeing a discussion about HIG compliance being mandatory. The 'G' in
HIG stands for 'Guidelines' for instance. Mostly in KDE we use frameworks
which mean the apps end up looking similar, and we don't need to follow docs
to make that happen.
> At the same time we also shouldn't be afraid to evolve
> our interfaces, of course. It's a fine line to walk.
On the one hand you are saying that doing something as 'daring' as leaving out
the often pointless status bar at the bottom of the screen, is violating the
HIG, and now you say people shouldn't be too afraid to experiment. I think the
idea that Microsoft wrote the book on how to do UIs ten or fifteen years ago
(the kind of UI described in the KDE HIG), is just plain wrong, and it is very
important that we move forward and try out new things.
More information about the kde-core-devel