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

Thu Sep 9 16:59:21 CEST 2004

Hi,

After discussion on the kde-usability mailinglist (Frans,Sigi), this is
the *new* preliminary structure of the TOC:

1.Preface
1.What is this document about?
2.Who should read this document?
3.Organization of this document
4.Conventions used in this document
5.See also

2.Usability Principles 
1.Design for People 
2.Don't Limit Your User Base (Accessibility, Internationalization and
Localization)
3.Create a Match Between Your Application and the Real World 
4.Make Your Application Consistent 
5.Keep the User Informed 
6.Keep It Simple and Pretty 
7.Put the User in Control 
8.Forgive the User 
9.Provide Direct Manipulation 

3.System and Desktop Integration
1.Session Management
2.Placing Entries in the KMenu (Menu Item Names, Menu Item Tooltips)
4.Mapping Document Types to Applications 
5.Using the System Tray

4.Mouse Operations
1.Pointer Feedback
2.Mouse-over Feedback
3.Clicking and Selecting Objects
4.Displaying Contextual Menus

5. Keyboard Operations
1.Keyboard Focus
2.Keyboard Navigation and Activation
3.Keyboard Shortcuts
4.Mnemonics

6.Drag-and-Drop Operations
1.Typical Drag and Drop
2.Pointer and Destination Feedback

7.Application Design Principles
1.General Design Principles
2.Using Widgets Effectively
3.Terminology
4.Sensitivity
5.Choosing Components (Overview with reference to the chapters)
6.Interaction (Overview with reference to the chapters)
7.Layout and Design (Overview with reference to the chapters)

8.Windows
1.Types of Windows 
2.Window Appearance
3.Window Behavior
4.Utility Windows
5.The About Window
6.Settings Windows
7.Properties Windows
8.Find Window
9.Fonts Window and Colors Window

9.Dialogs
1.Types of Dialogs and When to Use Them (Modality, Focus)
2.Dialog Appearance
3.Dialog Behavior 
4.The File Open Dialog
5.Dialogs for Saving, Closing, and Quitting
6.The Printing Dialogs

11.Menus
1.The Menubar
2.Types of Menu
3.Designing a Menu
4.Standard Menus

12.Toolbars
1.The Toolbar
2.Types of Toolbars 
3.Toolbar Appearance
4.Toolbar Control
5.Standard Toolbar Menus 

13.Other Widgets
1.Text Input
2.Spin Boxes
3.Sliders
4.Buttons
5.Check Boxes
6.Radio Buttons
7.Toggle Buttons
8.Drop-down Lists
9.Drop-down Combination Boxes
10.Scrollbars
11.Lists
12.Trees
13.Tabbed Widgets
14.Progress Bars
15.Statusbars
16.Frames and Separators

14.Feedback
1.Characteristics of Responsive Applications
2.Acceptable Response Times
3.Responding to User Requests
4.Types of Visual Feedback
5.Choosing Appropriate Feedback
6.Allowing Interruptions

15.Help
1.Types of Help
2.Choosing Appropriate Help
3.Inline Help
4.Online Help
5.What's This Help
6.Help Wizards

16.Language
1.Wording and Naming
2.Warnings and Error Messages 
3.Online Help
4.Translations

17.Layout and Visual Design
1.Color
2.Window Layout
3.Text Labels
4.Fonts

18.Icons
1.Kinds of Icons
2.Designing Effective Icons
3.Designing Accessible Icons

19.Checklists and Quick References
1.Widgets and Components Quick Refernce
2.Standard Menu and Toolbar Quick Reference
3.Keyboard Shortcut Quick Reference
4.Icon Quick Reference
5.Keyboard Access and Focus Checklist
6.Theming, Colours and Contrast Checklist

20. External Resources

Especially the 'Widgets' section might miss entries. Would it be useful
to introduce some further grouping, e.g. Text Input (Numerical Input,
Date and Time), Selection (Buttons, Radio Buttons, Checkboxes, List,
Drop-Down List), Views (Trees, Tables, Lists), Organizers (Tabbed
Widgets, Group Boxes) etc., or do you think it is too hard to find an
intuitive categorisation?

Another point: Should we integrate 'Layout' and 'Icons' with
'Application Design Principles' to obtain the 'General Design
Principles' subchapter Sigi asked for? 

With respect to the 'International Norms' section:
I think it would be useful to tell the developers there ARE norms, and
to give them an idea of what they are about. but it should not be
extensive. Rather, the norms should be used in the rationales sections
as they sometimes give very clear explanations (if it is allowed to cite
them).

greetings
/el

Am Do, 2004-09-09 um 14.48 schrieb Siegfried Olschner:
> 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.
-- 
______________________________________________________

Ellen Reitmayr          email: reitmayr at relevantive.de
Usability Engineer      mobil: +49.177.3325867
relevantive AG          fon:   +49.30.23455630
Zehdenicker Str. 21     fax:   +49.30.23455639
10119 Berlin            web:   www.relevantive.de
_______________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.kde.org/pipermail/kde-guidelines/attachments/20040909/2eba9e60/attachment.pgp