Re: To answer your question about the upcoming Style-Guide...

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: Berin Loritsch <BERIN.LORITSCH@cpmx.saic.com>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>; Preben Randhol
<randhol@dusken4.samfundet.ntnu.no>; Russell Nelson <nelson@crynwr.com>
Date: Friday, July 24, 1998 7:30 AM
Subject: Re: To answer your question about the upcoming Style-Guide...


>Overnight I have seen something on the order of 40 messages ranting and
raving
>about online tutorials.  We should have audio... We should have video...
We
>shouldn't do anything besides html help...


They're not all on online tutorials.  ;-)

>The long and the short of it is that we shouldn't be worried about full
blown
>tutorials for the Gnome project--yet.  We are too early in development to
worry
>about these features.  We haven't even agreed on keybindings (except for
>making them configurable) at this point.


Accepting a slow pace is death for an interface with effective and
microsoftish(KDE) competition.

>As far as documentation goes, I have seen horrendous manuals: "This is a
>button.  Can you say BUTT un?  Don't worry about what it does.  It is
called
>'Format Disk'.  Press it and see what happens."  Granted this is
exaggerated
>to make a point.  I have also seen excellent examples.  S.u.S.E. Linux
(while
>I couldn't get past the outdated libraries they include with their
distribution)
>does a wonderful two tiered approach to documentation.  They have the
>beginner's press this and type that approach, followed by a more detailed
>power user's approach.


When I get to school, I'll distribute a survey asking how many people read
the documentation or use the help file, and why they do or don't.  Though I
can't be sure, I do think the vast majority haven't used paper documentation
and rarely use online help because it's "just so confusing".

>As a requirement for Gnome compliance, an app should be required to include
>(at the very least) a beginner's instruction set.  Anything above and
beyond
>that is gravy.  If one app has full motion video with surround sound,
having
>contracted the Turkish belly-dancing troupe to implement their help system,
>that is up to them.  We just need a standard interface for how to access
that
>help.


When I was in english class, we were always told to show not tell.  I think
that no matter how good a writer you are, you're always telling the user
what to do.  We don't have "imaginations" for applications like we do for
dramatic scenes.  That's why a screenplay should be a prefered interface.
It's easy to generate and transmits the most information per unit time.
Should it be accompanied by written documentation?  Of course.  But the idea
that written documentation will ever suffice is one I just don't hold.

>Remember to KISS (Keep It Simple, Stupid) in all things.  The way some of
you
>are talking, it reminds me of a young, married couple.  They want
everything
>their parents have, but can't pay for it all.  Consequently, they go into
debt, hate
>each other and get divorced.  The analogy is their because some among us
want
>elaborate help systems and configurable everything, but forget the cost in
time,
>frustration, blood, sweat, and tears required to make these things work.


Who gets the blood, sweat, and tears?  Do we feel the pain before we toss
something off to the user, or do we get it right the first time, thus not
alienating our client base?  The user population for Linux is expected to
double over the next year.  That's *alot* of people who are going to be
using Yet Another Propietary Interface(KDE) unless Gnome gets some features
people decide they can't live without.

>We need a solid foundation first.  Let's get a firm bed, allowing for
future growth,
>and we will add amenities as we go on.


One must have an idea of the planned amenities if one is to build an
appropriate foundation.  Look at Microsoft's spaghetti evolution ;-)  We
don't have the time or the energy for that.

>>From one of the best KISSers out their, let's get a sanity check.  Be wary
of
>new *features*, and try a sample test app to see if the thing really works
>like you envisioned it.  Having a sample to play with and pass around goes
>a long way toward stopping people from talkin' out the side of their neck.
>Everyone, including the conceptualizer, has a good basis for accepting,
>denying, or improvig the feature for inclusion.  A static picture doesn't
really
>give the proper idea either.  You need to see how it feels, first.  As an
added
>bonus, you have sample code that is ready for inclusion into Gnome.


Well, the first step before sample code has to be the static mockup.

>That way we all have a sanity check.  Yes, having a central key-binding
>repository would be a *Cool Idea* TM, but having an example can give
>us an idea of what a system would cost in terms of ease of setting up,
>changing the bindings, and performance.


What do you think of the Keybox, which states the key combo necessary to
execute the previous mouse-driven command?