[HIG] Re: GNOME Human Interface Guidelines

["Aaron J. Seigo" <aseigo olympusproject org>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 21 August 2002 01:27, snickell stanford edu wrote:
> Our user bases are fairly similar. They are rarely sufficiently
> different as to justify substantial interaction differences at the level

you subscribe to the "there is One True Way to do everything" school of 
thought?

there are often many ways of doing something that are roughly equivelant in 
Goodness. saying that "one user base, one solution" is the ticket is a bit 
shortsighted and assumes we have all the best answers today.

> If people basically stuck with only GNOME applications or KDE
> applications I think a merger of interface guidelines would be much less
> important.

irrelevant. users should be able to go from one desktop to another with as 
little pain as possible. i don't care if you run all GNOME and I run all KDE 
apps, we should be able to acclimatize to the other's env with as little 
turbulence as possible.

> The motive is a realization that most RealUsers(TM) work with
> a mix of applications.

what is this realization based on?

> homogenous environment that most of us would prefer. So what I want to
> achieve is a world where GNOME applications and KDE applications *work*
> the same way at a low level (they don't even have to look the same: the
> final visual appearance is less important to interop than things like
> using the same keyboard shortcuts, having alerts function the same way,
> etc etc).

we already have this, in a common clipboard, DnD, WM hints, thumbnails, etc. 
the style guide, however, impacts how something looks much more than how it 
works.

there are functionality adjustments, such as keyboard shortcuts. these indeed  
should be canonicalized as part of a base style guide document.

but let's be frank about it: borders or no borders around group boxes is a 
look thing (that can and does affect usability, but not actual function).

> > move forward for usability, but the interop costs are, IMO enormous.
> > no
> > amount of style guiding will put an end to this sort of thing, but
> > writing a
> > style guide is one step in the right direction.
>
> Sharing an interface guide *would* put an end to that (assuming people

no, you are simply relocating the issue. now the issue would be making changes 
to the style guide rather than to the projects. that could be an onerous 
task, perhaps to the point so as to curb the effectivity of making such 
decisions. the projects need to keep a certain level of autonomy and 
flexibility. a unified One True Way document will hurt that; a shared base 
document which each desktop can then "fill in the details on" is much less 
shackling. (sprinkle with IMO's where you see fit)

> > this is fine until it comes to genuine differences in design and
> > goals.
>
> In specific instances its easy to say "the KDE designers think guideline
> X, the GNOME designers think guideline Y, that must stem from a
> difference in audience or goals", but I think that's mostly not true,

not only is mostly not true, it's also not what i said. differences in designs 
and goals emminate from the creators of the product (developers, artists, 
documentors, traslators, etc). while the user base may be similar, the 
creators may have different thoughts on how best to service them. if the 
creators were the same and the user base were the same, there would be no 
problems.

> Now our designers, on the other hand, are unique individuals with
> opinions across the map ;-) The same dynamic can be found within a
> single project's usability team I'm sure (unless you guys agree a lot
> more than we do *wink*).

exactly why i think trying to tie the two projects together tightly on these 
issues would be a stupid waste of time. if there is enough divergence within 
each project, imagine harmonizing across projects.

again, i go back to the concept of a core document that each project then 
embelishes with the spirit of being as close as possible. if/as items become  
the same, they can organically be folded back into the core doc. this would 
also show us exactly where the differences are to allow us to examine the 
necessary changes while giving us an immediately useful and applicable 
document. don't underestimate the power of "immediately useful and 
applicable".

> > see my previous email re: my thoughts on how to accomplish this. it
> > will
> > involve much more than screenshots and code snippets. we'll probably
> > need a
> > base document and then implementation specifics for both GNOME and
> > KDE.
>
> That's screenshots and code snippets plus modifications to the base
> document to ensure recommendations are implementable on both desktops ;-)

that's exactly what i was not saying: it will not come down cleanly to 
screenshots and code snippets. to say so is to turn a blind eye to the 
differences and to foolishly believe that we can randomly impose via a 
document sweeping changes starting right here and now.

i'd rather see a document that gives us a roadmap (reflective of today) and 
work from there. it will get more developer buy in, help us see the work 
ahead of us, and not force us into a "must be the same!" situation (while 
still allowing us to choose it, if we so desire)

> > in the end i think it would simply be easier for each project to keep
> > their
> > own copy of a style guide but provide a common place for discussion
> > of these
> > guides and a concerted effort by all to make the guides as harmonious
> > as
> > possible.
>
> What I would propose is using the same base DocBook source and using
> XSLT to generate respective KDE and GNOME versions (DocBook has hooks
> for generating different versions which use different words, paragraphs
> and sections). Most of the document's guidelines (say, 90%+) are as
> applicable to KDE as they are to GNOME. The remaining 10% would be

window titles are handled differently, alert boxes are handled differently, 
button order is handled differently, dialog layout is handled differently, 
icons are a bit different, etc... there are lots of subtle differences. i 
love your world view of general harmony, i just don't share it. =)

as a side point, KDE apparently has a different way of handling 
standardization: the "correct" way is usually provided as an automated 
mechanism to the developer so guidelining a lot of those things is pretty 
much unecessary noise to the average developer. KDialogBase, XMLUI and 
kicker's applet handles are good examples of these things in action.

> This would be a good route for achieving the minimal necessary
> difference between the guidelines for the two environments, while still
> making it simple to write guidelines that only apply to one environment
> or another. It would also provide an easy way to publish a "generic"
> version that we could encourage developers not directly affiliated with
> either desktop to use.

hrm. ok, perhaps we are talking about the same thing after all.

would it be possible for you to:

 a) get a @freedesktop.org mailing list going for this?
 b) tag the GNOME specific parts (read: the parts that explain how GNOME is 
but where KDE differs)?

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

"Everything should be made as simple as possible, but not simpler"
    - Albert Einstein
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9ZAtz1rcusafx20MRAgScAJ41dF7sKTqdCnc2gg37JQKFmxehowCeOBOR
1ia8lH9C9G4Yqfyf1m7IDvQ=
=fBDq
-----END PGP SIGNATURE-----