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

Thomas Zander TZander at factotummedia.nl
Sun Sep 12 21:35:51 CEST 2004


Hi Siegfried,

On Thu, Sep 09, 2004 at 02:48:08PM +0200, Siegfried Olschner wrote:
> 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. 

Agreed;  for the people not familiar here is a nice research document I
recently found on the topic:
http://www.mi.sanu.ac.yu/vismath/ngo/
These items are deeper usability topics that could very well be referenced
from the relevant explaining topics.  I.e. not part of the main HIG-TOC.

> 6)  General content - Level of detail
> I do not agree to your statement that defined pixel spaces between 
> dialogelements are not necessary.
The statement was that we should not go to the detail of pixel-spacing in
the HIG.  That amount of detail is unwanted by the relevant parties.

That said:
> 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.

These are very real issues; but the problem here is not about pixel sizing
as the example of Ellen at akademy showed.  That example showed the designer
should have x pixels between row 1 and row 2 and more stuff like that.
The problems here are about
- general spacing (make everything line to the top left corner)
- not correctly using the Qt Layout managers (the yellow lines)

Stating that spacing and margins _are_ needed (purple/yellow) is relevant,
but not how many pixels that should be.
ps. the dialogs pointed out have had some fixes already and look a tad
better in CVS :)

> 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" ;-)

Hmm. you have me confused here; spacing and margin is about the unused space
between widgets; the obvious problem in the screenshot is that the long
translations make the list get wider. You can't set a sane minimum size for
all applications since german will always find a translation that is, well
VERY long :)
In practice; what would be the solution to fix these problems?  Just stating
a maximum size is not going to work; the horizontal scrollbar is even uglier.

Thanks!
-- 
Thomas Zander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kde-guidelines/attachments/20040912/3eab4532/attachment.pgp


More information about the kde-guidelines mailing list