[kde-guidelines] Some comments to KDE-HIG content

Siegfried Olschner siegfried.olschner at suse.com
Thu Sep 9 14:48:08 CEST 2004


Hi, 

some of you saw me at the aKademy, some of you did not. So I would like to 
introduce myself. My name is Sigi Olschner, I work at SUSE, and I am 
responsible for usability in some SUSE products.
Aaron asked me to join the KDE-HIG team. So... here I am.

I have some comments on the content of the style guide. I'm sorry, if I have 
overlooked something in a former thread.

1) New section
At the aKademy a usability test with the task "create an email account in 
Kmail" showed that a "normal" user can require a wizard for such a task. So 
in Ellen's document with the suggestions for content I miss (or did not 
found) a section about "design and use of wizards". Something similar to 
this: http://www.sapdesignguild.org./resources/wizard_html/index.htm 

2) Enhancement of Applications Design Principles
Chapter 5 (Application Design Principles) will use references to other 
chapters. Do you think a separate section describing the power of some 
designing principles like 
- Spatial coding
- Alignment
- Grouping
- Stimulus-Response-Compatibility
- ... and other ...
could be useful?
My experience shows that developers often do have no idea of user's internal 
processing and the limitations (cognition, perception, memory, ...). Perhaps 
a little section for people that are interestend in such things could be 
usefull. 

3) New section
I miss a section about "international norms" and the consequences. The 
DIN/EN/ISO 9241 Part 13 to 17 formulates some very specific demands. E.g. in 
Germany the law on employment protection has a nebulous demand for software 
conform with ergonomic principles. I will try to get some information from 
our lawyers how "close" a citation can be with a DIN-copyright in the 
background. 

4) New section
Links to external ressources. If the HIGs are deliverd via pdf-file or as 
printed manual, a section with links, available books or information about 
other resources could be usefull.

5) Enhancement of Language
Wording/naming/translation problem. The basic terms and names in the HIG 
document are written in English. So we need a section with standardized 
translations for the available languages.

6)  General content - Level of detail
I do not agree to your statement that defined pixel spaces between 
dialogelements are not necessary. E.g. the configuration dialogs of kword 
show
- Different spaces between frame of a box and next dialog element
- Different widths for spinboxes (different look, too)
- Different spaces between text label and following combo box
- Different spaces between frame of tab filed and frame of box
- Different use of location for text label for slider
http://www.suse.de/~sigi/projects/kde_hig/koffice_01.png
If qt is used by one developer with default settings, he will get a unique 
look & feel, but qt with x developers will produce differences.

Also the different width for some KDE configuration dialogs could be an 
example. See the dialogs of Konqueror, Kmail, Korganizer at
http://www.suse.de/~sigi/projects/kde_hig/selection_list_box.png

I know the power of selfadjusting width for different languages, but I think 
it is necessary to define the default layoutSpacing and layoutMargin, the 
general use of the stretchable dialog elements with stretchable spacers. A 
strong micro usability via well defined spacing will result in a strong 
consistency and a strong professional look & feel. Perhaps the user cannot 
name the inconsistency directly, but in his subconscious he will see it - and 
perhaps think "oh, Apple applications look very very professional, ... and 
this not" ;-)

I hope the links are OK.
If you miss a file, my /suse/public_html directory syncs every 40 minutes.

-- 

Greetings!
Sigi
________________________________________________________
Siegfried Olschner, SUSE Usability & Design
SUSE LINUX AG - a Novell Business
Maxfeldstraße 5, 90409 Nürnberg, Germany
T: +49 (0) 911 74053-192
F: +49 (0) 911 74053-483 - <siegfried.olschner at suse.com>



More information about the kde-guidelines mailing list