KDE HIG, CIG and AG

[Aaron Seigo]

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.

-- 
Aaron Seigo, currently in Ludwigsburg
KDE World Conference 2004: aKademy