KDE HIG, CIG and AG

[James Richard Tyrer]

Aaron Seigo wrote:
> Hi all...
> 
> yesterday we had a lengthy and very productive BOF to discuss the creation of 
> a new set of KDE development-related guidelines. members of the following 
> groups where present:
>  
>  Who     What
>  KDE accessibility   Team accessibility Guidelines (AG)
>  KDE Artists      Community Identify Guidelines (CIG)
>  KDE Usability Team  KDE Human Interface Guidelines (HIG)
>  KDE Documentation  provided docbook expertise
>  KDE developers   input and feedback from the developer's perspective
> 
> we ended up with the following proposal:
> 
> each of the three proposed guidelines will be authored in cooperation with the 
> others since they all need to reference each other. for instance, the AG will 
> often be referenced from the HIG and vice versa. when it comes to issues of 
> splash screens and icon, the HIG will point to the CIG for matters of colour, 
> dimensions and artistic layout.
> 
> to facilitate this, we will probably be working in Docbook format in a CVS 
> module (proposed name: kdeguidelines). Docbook should allow us to create html 
> and print (e.g. PDF) versions of the guidelines as well as support the high 
> degree of cross-referencing we desire. 
> 
> only the maintainers (more on them in a bit) will have commit rights and final 
> paches to the guidliens will appear on a kde-guidelines list. this will allow 
> domain-specific discussion to occur where appropriate with items considered 
> ready by the respective teams to be reviewed for correctness. this is 
> important as proposed usability guidelines may have accessibility impacts, 
> for instance.
> 
> each of the guidelines will have a pair of people responsible for the 
> documents (the "maintainers"). the proposed maintainers, who were all present 
> and agreed to the responsibilities, are:
> 
>  AG  Olaf Schmidt and Gunnar Schmidt
>  CIG  Torsten Rahn and Ken Weimer
>  HIG  Ellen Reitmayr and Jan Muehlig
> 
> this will keep the authorship process on track, though the actual authorship 
> of the guidlines will not be only up to these people but all who would like 
> to participate.
> 
> the AG and CIG and both new to KDE, with the AG yet to be written. the CIG is 
> well on its way, however. the HIG needs to be written from scratch, as the 
> current set of guidelines is too limited even as a starting point. it is 
> proposed that this new HIG will be made up of several parallel components, 
> including:
> 
>  Developer Guidelines
>   this part will appear much like our current guidelines: straight to the
>   point without much sidetracking into usability theory
>  Rational
>   this part will provide the usability reasoning and theory behind the
>   guidelines
>  Examples
>   code snippets, screenshots, etc demonstrating the guidelines in action
>  Usability Checklists
>   a series of quick checklists that can be used while developing UIs or when 
>   auditing them to ensure compliance with the guidelines
>  Usability Principles
>   general usability principles towards creating highly usable interfaces. this
>   will likely consist of several articles that may be of interest to
>   developers and others interested in general usability.
> 
> each of these components will be viewable in part or as a whole, allowing 
> developers to see just the guidelines themselves and the examples, for 
> instance, while those more interested in usability as a topic may choose to 
> display the rationals as well.
> 
> the AG will take a similar form, and all three guidelines will be linked 
> together. it is proposed that they will be housed at a common website 
> (http://guidelines.kde.org) and linked to by the appropriate websites 
> (artist.kde.org, accessibility.kde.org, usability.kde.org, developer.kde.org, 
> etc).
> 
> the timeline by which these documents will be completed will be defined 
> further after the BOF on Thursday discussing the post-3.3 devel schedule. the 
> CIG should be ready for the next release, be it 3.4 or 4.0 while the HIG may 
> not be ready until 4.0. we'll keep you posted, however.
> 
> these guidelines will be written with longevity in mind. our current User 
> Interface Guidelines have serviced us well for several years, and we expect 
> that these new sets of guidelines will have a similar lifespan. we expect 
> them to be actively maintained and developed over time, however, and 
> therefore they will be versioned much as we do with our software including 
> having both a stable and a devel (HEAD) branch in CVS for these guidelines. 
> stable releases will be made according to milestone achievements that will be 
> scheduled and defined as part of a release cycle.
> 
> the action items that were defined at this point are:
> 
>  o define a target release schedule for the 3 guidelines
>  o set up a CVS module: kdeguidelines
>  o set up a mailing list: kde-guidelines at kde.org
>  o set up a website: guidelines.kde.org
> 
> comments, thoughts, ideas welcome.

I'm not sure what the point is here.

I see problems with the user interface design, icons, and styles.  It appears to 
me that it won't be of much help to produce User (Human) Interface Guidelines 
that specify the use of "magic buttons" and hidden configuration options that 
confuse users and Guidelines for artwork that specify low contrast bluish icons 
containing no black or dark lines (icons that have little information according 
to classic information theory and are, therefore, not easy to see) and busy 
styles (with signal to noise ratio issues) that are not easy to use.

So, the important issue is to establish what the usability mistakes are before 
guidelines can be written to prevent them in the future.  After it is determined 
what these usability mistakes are, it is probably more important to correct them 
than to write guidelines.  But, if guidelines are needed as part of the process 
to fix the problem, then that is what should be done.

And, yes such guidelines are needed and it would have been a good thing if they 
had existed before some of the recent usability "improvements" were implemented 
and before the Crystal icon theme and Keramik style were implemented.  Actually, 
we have icons guidelines, but some of the Crystal icons that have too much 
detail (e.g. Krita), and therefore have low usability in small sizes, were still 
committed.

The major problem is, are the developers that implemented these serious 
usability mistakes and those that produced the Crystal icons and the Keramik 
style going to be willing to produce guidelines that recognize that mistakes 
were made and that they need to be corrected.

--
JRT