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

List:       kde-usability
Subject:    Re: HIG
From:       Frans Englich <frans.englich () telia ! com>
Date:       2004-09-03 5:32:44
Message-ID: 200409030532.44255.frans.englich () telia ! com
[Download RAW message or body]

On Thursday 02 September 2004 00:09, Aaron Seigo wrote:
> On September 1, 2004 15:56, Frans Englich wrote:
> > example, according to quotes from Kenneth on kde-artists from the
> > CIG(which I have a vague idea of what it is), it deals with how to select
> > icon themes, and that's only relevant for a small group of KDE developers
> > in rare occasions; The CIG is then not focused on 3rd parties and the
> > common cases KDE applications will need.
>
> actually, it is, for a couple of reasons.
>
> Consistency: visual consistency creates a finished, polished look and puts
> users at ease and makes KDE appear more professional. the CIG defines the
> artistic aspects of that, such as:
>
>  o Colours to use
>  o Layouts of splashscreens
>  o Official "K" logos in various colours/sizes
>  o Wording to be used in association with KDE
>  o How icons should look
>
> Legal: KDE e.V. has trademarks on "KDE". this means we need to / are
> allowed to have a say in how "KDE" and the related marks are used. the CIG
> will help outline those demands.
>
> these identity guidelines must work with the usability and accessability
> needs of KDE, however. which is why we are doing all of this together
> instead of each separately.

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). The CIG appears to 
have an organizational role within KDE..(much needed).

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.

I think I also prefer putting those sections in the HIG, because it is a 
usability matter. But most of all, those sections are relevant for the user 
audience the HIG has: 3rd parties and the common case in KDE. The HIG would 
be read by 3rd parties, but not the CIG.

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?)

>
> > What do you think practically will steer the content of the documents(for
> > example in that aspect)? In one of the mails I suggested having a small
> > "meta-HIG", document -- what do you think of that? Don't hesitate to go
> > into details.
>
> right now the DTDs and docbook stuff is being cooked up by those who know a
> lot more about it than i and most of us here do =) once we have that,
> that's a big part of things. but i don't know if we need to bog ourselves
> down by too many rules surrounding writing the guidelines. i just want to
> see them written and done so with consensus and cooperation by EVERYone
> (accessibility, art, developers, usability)

We aim for a clearly defined, tight, document(drawing from Jan's descriptions) 
and that means consciously writing in one direction. The Gnome HIG has(in the 
CVS module) some informal guidelines and I think it's good; it helps people 
get a grip on how things should be and where it's heading: If it's only a 
judgment call done by maintainers, it's less distributed. It also eases the 
editing burden for the maintainers. Nothing big, just an informal HTML 
doc(which will arise per demand). 

>
> > whether starting a new subdomain is a good idea,
>
> guidelines.kde.org ... the collective group of guidelines do not belong on
> usability.kde.org or accessibility.kde.org or artists.kde.org. but they do
> belong together as they reference each other. however, this does not
> prevent us from linking to appropriate areas in guidelines.kde.org from
> wherever appropriate (developer.kde.org, usability.kde.org, etc)

In the mail where I discussed it, there's still points not countered. I'll 
bring this up in a separate thread.

>
> > if it's good to separate accessibility/usability guidelines,
>
> they must reference each other thoroughly, but are not 1:1 matches. in
> particular, the HIG needs to reference the appropriate accessability
> principles for each part of the HIG. due to this "must be referenced
> thoroughly, but are not 1:1 matches" it was decided to go about it in this
> way.

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. 

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. 


Cheers,

		Frans



_______________________________________________
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]