Human Interface Guidelines

[Seth Nickell]

> To Seth, I think we need to just slow down :)

*grin*. Definitely, especially since I planned to take a brief vacation
from major free software involvement post-HIG release and concentrate on
my RealJob(TM) and RealLife(TM) for a while. I actually (horrors) didn't
read e-mail yesterday :-)

> 1: How about nothing concrete on *anything* is done for a few days.  Again, 
> many of us have never heard of or seen the HIG before, and there's 130 very 
> densely packed pages of information there to digest.  So lets give everyone 
> who is interested a chance to go through it in more depth.
> 
> Specifically there are several people who should be involved in this
> discussion and haven't, so far.  I'm thinking here of Ryan Cumming, Malcolm
> Hunter, Stephen Binner, who have between them done the bulk of the work
> bringing KDE into line with the existing style guide and Waldo Bastian, who
> originally wrote most of it.
> 
> On first reading, it appears to be very GNOME specific, a closer reading shows
> that it needn't be, and what there is that looks GNOME specific, we can
> provide alternate KDE content for.

I think its important to remember that the actual writing is at most a
quarter of the work. Deciding *what* sort of design is best, *why* its
best, and then working that through a review process (as well as
considering its implications in terms of consistency between all the
guidelines) is a much more time (and of course mentally) intensive
process than the actual words on the page. Almost none of the design
work is specific to the toolkit; that is to say our reasoning was
largely independent of GTK/GNOME and would apply equally well to Qt/KDE.
Even the actual words on the page are mostly toolkit neutral.

Think of it as a model-view situation (and lets just leave control out
of the picture ;-). The real guidelines are a model, the existing GTK
version is just a thin view layer.

The actual work of modifying the guidelines to remove all GNOME
reference and replacing that with KDE references is actually quite easy.
I could convert a sample chapter, say, Windows or even Controls (which
is very GTK heavy atm), if that would help KDE developers quickly
evaluate the extent to which these guidelines could be applicable to
KDE.

As for the screenshots, I beg KDE developers to view them with their
eyes closed, and apologize profusely in advance for the horribly ugly
default GTK theme. :-)

> 2: A mailing list is a good idea.  freedesktop.org seems to me a good idea for 
> hosting it, IMHO.  I prefer to see more input from other KDE developers on 
> this first, so please, take a breather until there is some consensus - I 
> can't speak for all of KDE.
> 
> I think using the existing GNOME or KDE usability lists would either drown
> current traffic in HIG concerns, or vice versa, the HIG traffic would be
> smothered in desktop specific issues.

FreeDesktop.org is fine. I could also offer the existing hig at gnome.org
list (which is a small development list specifically for the HIG team)
list, but people may feel more comfortable having the list on openly
neutral ground.

> 3: Someone makes a new list, in a week or so, and invites interested parties
> to join, and we start there.  Take the HIG one section at a time, clearly
> demarcate what is different from KDE current best practise and/or diverges
> from the written KDE styleguides, and bring those issues back to KDE for
> discussion.  I think this would leave a large majority of the document intact
> exactly as it is, and will give a concrete list of changes for discussion by
> KDE's developers and usability team.

It would be fine to change the existing modus operandi of the HIG if
people prefer. Our experience has been that *much* better results are
achieved using a limited set of individuals rather than a general open
invitation (which is what we use now). We tried to balance team
composition (i.e. it wasn't all interface designers), but we also
limited it to people with proven experience and dedication to usability.
We are opening this up more in terms of access by the members of the
GNOME usability list at the moment, but I'm sure many KDE people have
shared my experience with needing a lot of filtering and cat herding to
help less experienced usability-enthusiasts contribute productively. :-)

I think your proposed process is good, though I would like to see some
concentration on not just "syncing up" GNOME and KDE interfaces but
actually moving to a future where we base our interface design off the
same document (with specific extensions for each desktop of course).
This means not just demarcating where KDE diverges, but figuring out
where the HIG guidelines might need to be modified to be palatable for
KDE. (that is not to say that I think we should modify the HIG to avoid
necessitating any changes to KDE were it adopted....if the guidelines
don't necessitate change, in some sense they aren't very useful
guidelines at all, because you were already doing the best thing). For
example though, some (but not all!) of the guidelines for icons are
purely stylistic differences which should be removed from the HIG and
seperate versions written for KDE and GNOME.

WRT to large changes... I think its worth pointing out that KDE 3 is
already closer to the HIG than GNOME 1.4 was. Despite what the
introduction says about retaining a uniquely GNOME flavour, to a large
extent there is almost nothing "GNOME-ish" about these guidelines. KDE 3
is actually more HIG-ish than GNOME 1.4 was. I think GNOME 2.0 (the
first release where the guidelines had any effect) is somewhat closer to
HIG compliance than KDE 3 would be, though even GNOME 2.0 has a looong
way to go toward compliance. I guess what I'm trying to say is that
adopting the HIG isn't "making KDE like GNOME" since the HIG is actually
more similar to KDE than it was to the GNOME that existed when the HIG
process began.  

A number of the HIG driven changes from GNOME 1.4 to GNOME 2.0 were
actually from something like what KDE uses today to something we believe
has better usability. Most of the larger changes that KDE would
hypothetically make if it magically decided to adopt the HIG as-is are
changes that GNOME also recently made in pursuit of better usability
through design guidelines (or will make, for example dropping bordered
frames in favour of a cleaner layout system).

> Seth, please also note the timing: We're nearly ready to start serious
> preparation for a release, the feature freeze is already in place, and the
> message freeze is not too far away.  KDE Developers will be fairly busy in
> the next while, and changes to the code will be impossible for this period
> too.  All of this will be ready for discussion and or implementation (or not)
> for KDE 3.2.

I don't think there's a major emergency here. If we wait a couple months
until KDE developers are able to give the problem better attention I
think everyone is better off than if we do a poor job now.

> speak.  I expect I can be useful with the DocBook too :)

yummy!

-Seth