[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: HIG
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2004-09-03 7:26:27
Message-ID: 200409030126.28067.aseigo () kde ! org
[Download RAW message or body]

On Thursday 02 September 2004 11:32, Frans Englich wrote:
> Thanks, I have a better picture now. So, the CIG is an in-house document
> for running the KDE project, but wouldn't be read by people who work on 3rd
> party apps using KDE technologies(but they would read the HIG). 

no. it should also be followed by any 3rd party developer who wishes to use 
the KDE trademarks and/or who wishes their application to look like a proper 
KDE app

> The CIG 
> appears to have an organizational role within KDE..(much needed).

yes

> Comparing Ellen's suggestion in the HIG review paper(p. 2) with yours
> description above; I think they contradicts. Ellen wants Icon and Colors in
> the HIG while it above(and according to Ken's mails IIRC) is in the CIG.

icon content and colour usage are usability issues; icon style and colour 
pallete are corporate/community identity issues. so they don't contradict, 
they compliment. which is why they need to be written together and why they 
need to reference each other where appropriate

> The HIG would
> be read by 3rd parties, but not the CIG.

they are a collection of guidelines that are cross-referenced. people can (and 
will) read the appropriate bits of the entire body of guidelines. they are 
not as divided as you may be thinking they are.

> But, how to select a icon theme for KDE, that would be in the CIG since it
> concerns KDE as a project. Comments? (Ellen, Aaron?)

selecting an icon theme would be a practice of satisfying both the CIG and the 
HIG. and the two would be written in a way that this is possible to do...

> I can clarify a little; I would rather see a chapter in the HIG about a11y
> than it being a separate document.
>
> We want focus on a11y; that developers read it and design for it. a11y is a
> little trickier than other cases since it is seldom an itch and is easily
> forgotten(and down priorited). When a11y is in a separate document people
> can forget it(they print the HIG only). If it's in the HIG there are big
> chances it gets read on the fly with all the rest. And we reference a
> chapter instead of a separate document.

well, these guidelines are less separate documents as they are different 
sections of a larger work. Janina noted that the best way to present this is 
to have a complete a11y document and have prominent markings _throughout_ the 
HIG noting the "a11y impact" (low, medium, high) of that section with a link 
to the appropriate place in the a11y document. i can only trust she knows 
what she's talking about as she has done this before and is something of an 
expert in the field =)

> I also think it would make it easier for us: we want things simple and
> avoid yet another document project if possible; KISS, and ease maintenance.
> I doubt the a11y text will be very large(perhaps 40 pages or less) and
> that's quite suitable for a chapter. In case it becomes too big, we split
> first then.

the a11y stuff is being written by the accessability team (namely the Schmidt 
brothers). this isn't something we will be writing here as it is somewhat 
out-of-scope for the usability team. the writing of the a11y guidelines will 
happen in tandem to the HIG authoring by a second team of people, just like 
the CIG.

ergo, the need for the kde-guidelines mailing list =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]