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

List:       kde-usability
Subject:    Re: User Interface Guidelines
From:       Allan Fields <kde () afields ! ca>
Date:       2004-08-06 6:51:03
Message-ID: 20040806065103.GC64603 () afields ! ca
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thu, Aug 05, 2004 at 10:31:57PM +0100, Segedunum wrote:
> On Thu, 5 Aug 2004 14:49:38, Aaron Seigo wrote:
> > as you probably know, at the last KDE World Conference there were people 
> > interested in rewriting them with us.
> 
> Well, once someone can point to an adequate way of making amendments to 
> documents etc. and posting changes (rather than posting to lists) I'll be 
> waiting for some good feedback after aKademy. Has anyone thought of having a 
> usability documents area in CVS somewhere?

The Wiki is a good idea.  Or just fire off diffs to the list of the
docbook.  Either way the multiple forums should remain in sync.

Another thing is that there should be a set of common or guiding
principals established for contributions/revisions to the document,
which might maintain authors:

	* Keep arguments "to the point".  [simplicity]
	(Trust me on this one, it's here for people like me.)

	* Strive to be unambiguous and consistent in ideas and
	terminology;  [clarity, consistency]

	* Keep arguments well reasoned and assumptions to a bare
	minimum (-- For instance: It can't be assumed KDE will
	always be architecturally same as KDE 3);  [validity, timeliness]

	* Grounded in practical design considerations w/ illustrative
	supporting examples;  [practicality]

	* Described completely and in sufficient detail; provide
	tables or figures of behaviours where necessary;  [completeness]

	* Well refined to address the full range of applicable cases
	and possible boundary conditions.  Avoiding unnecessary
	context.  [generality]

	* But, Avoiding too broad a scope: not all cases will hold
	true extrapolating from one specific line of reasoning,
	especially during actual implementation stages. Providing
	necessary context.  [specificity]

	* Keep it accessible: use simple to understand language;
	avoiding unnecessary technicalities where possible.
        [accessibility]

	* Foster open disc{ussion,ourse} based on logical reasoning
	balancing theoretical and implementation details.

	* Follow either, neither or both of the contradictory
	above-mentioned points where necessary.

	* <Revise this list.>  Incrementally strive to achieve the
	above-mentioned goals.

Sort of like what has happened on kde-usability to date.

Hmm.. it seems I've just done a usability analysis on the usability
document.. Meta evil!  Not sure I'm actually talking about anything
anymore, so feel free to tune out now. ;)

It seems mostly theoretical exchanges have taken place: anyone here
going to submit some diffs?

I suspect w/ some simple tweaks usability could be moved forward
significantly w/o writing a standard first.  One that still gets
me is icons, there are things that could be improved with icon
handling: and others have commented on it in the past.

> basis, so I would work on fleshing it out by using other literature, possibly 
> ideas from the Gnome HIG were appropriate and good usability books and ideas.

Of course, as is my common refrain: wouldn't want to add things to
have them there just because another desktop does.  Merits
consideration, careful analys..  bla bla..

> Before anyone even gets started however, I should point out that we are never 
> going to get usability utopia. We can work towards good, sensible ideas and 

And you can innovate in usability technology too... so if there is
a sticking point, new ways of solving usability problems can pave
the way toward common resolution/harmony.  "Quit" for some, "Exit"
for others.  Many dialogs for some, less for others.

Perhaps more free-binding / advanced UI resource usage and global
configuration profiles (newbie,regular,pro) is the first step?
Are there any objections to using multiple definitions/profiles
for differing user bases which determine the type of user interface
presented? (-- by default: form there the user can tweak to taste.)

The objective would be to keep these primarily identical (same core
function for all users), but then to separate-out the subtle
differences in interfaces for differing usage patterns.

One starting point would be dialog verbosity specification.  If a
user is a kid, maybe they need less menus, more dialog warnings and
an extra "quit" button?  But this presupposes that all kids are
necessarily less sophisticated users, which may prove false: so
the kid should be knowledgeable enough to choose "pro" mode.

We could also have a mode called "annoying" which serves to illustrate
bad UI so that people will know what not to do.

"This is annoying mode.  <OK>" ;)


> Cheers,
> 
> David

-- 
 Allan Fields, AFRSL - http://afields.ca
 2D4F 6806 D307 0889 6125  C31D F745 0D72 39B4 5541

[Attachment #5 (application/pgp-signature)]

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