Human Interface Guidelines

Jon Doud jdoud at myrealbox.com
Fri Aug 23 14:18:32 BST 2002


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





More information about the kde-core-devel mailing list