[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Human Interface Guidelines
From:       "Jon Doud" <jdoud () myrealbox ! com>
Date:       2002-08-23 13:18:32
[Download RAW message or body]

I just want to point out a couple of issues that I have with a combined HIG document.

1. The idea that everyone looks at things the same way is incorrect.  Therefore, \
creating a single document that says, "This is the correct way!" is also incorrect.  \
The button order has been brought up many times.  How do we decide what is the proper \
order?  Alphabetic?  That would break across languages.  Most used button?  That is \
inconsistent across dialogs.  Default button?  Some dialogs would change the default \
based on previous input.  One other thing is that different languages see things in a \
different order righ-to-left, top-to-bottom is not universal.  What is "correct" for \
English would not always be correct for Japanese, Hebrew or even French.  I \
understand that these standards need to exist for usability, but those standards \
should be limited to each window manager/desktop environment individually.  If I move \
from a GNOME application to a KDE application, every standard (New, Open, Save) icon \
will be different.  This is a huge retraining issue for the average user, probably \
bigger than the idea of the button order on dialogs.

2. Having a combined document for both the KDE and GNOME projects detracts from the \
choice inherent in each project.  I personally like KDE better, but if the GNOME HIG \
version of certain things becomes the "standard", it could very well break the things \
I like about KDE.  The inverse is probably true for others.  I like KDE because it \
was developed with KDE users in mind, not GNOME users, not WindowMaker users, etc.  

3.  There are many window managers available that would not apply to these standards. \
KDE and GNOME may combine to be the de facto standards, but this will limit the \
freedom available to the desktop in general.  As a WindowMaker or BlackBox developer, \
someone may feel compelled to use the KDE/GNOME (read Linux) HIG and decide not to \
try something new.  Users will look at applications and ask, "Is this compatable (or \
certified) with the KDE/GNOME (read Linux) HIG?"  The next step is coercion for \
design on the desktop.

4.  Possibly the biggest issue I have with the combined document is that the \
guidelines written by for KDE are simple and short.  I have worked on writing \
usability guidelines for a couple of different software companies.  What I have \
learned is that a long document will not be read, let alone used.  If these \
guidelines are to be adhered to, they need to be something that a developer will read \
and refer to easily, not a giant document that takes twenty minutes to find the \
section they need.  Too much detail will turn off most developers.

Now, I am not against standards in general.  I agree with HIG standards as a rule, I \
work on them professionally.  I like the current documents that exist for KDE. They \
are short and direct.  The target audience for the guidelines are people who develop \
for fun in their spare time.  This is not the audience who will be receptive to a \
large standards document.  The GNOME project can probably get by with a document like \
this because of their ties to Sun and other corporations, and perhaps such a document \
would be of use to Trolltech in designing QT, but the average KDE developer probably \
will not even know about the document, let alone read it or implement it.

Jon Doud

_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability


[prev in list] [next in list] [prev in thread] [next in thread]