Re: Self Documenting Interfaces

["Dan Kaminsky" <effugas best com>]

-----Original Message-----
From: John R Sheets <dusk@smsi-roman.com>
To: Dan Kaminsky <effugas@best.com>
Cc: dusk@smsi-roman.com <dusk@smsi-roman.com>; gnome-gui-list@gnome.org
<gnome-gui-list@gnome.org>
Date: Thursday, July 23, 1998 10:46 AM
Subject: Re: Self Documenting Interfaces


>Dan Kaminsky wrote:
>>
>> >Microsoft has proven countless times (almost a continuum of
>> >times) that it is more interested in adding new features than it
>> >is in fixing old ones.
>>
>> Can't resist a chance to get a dig in at Microsoft?
>
>Actually, I pay my bills as a Windows programmer.  Linux is my
>nightlife.  Not a dig.  Just an observation.  I've been paying
>very careful attention to Microsoft lately.


Windows programmers hate Microsoft more.  I'd hate my torturer too.

>>  With all the bad they
>> do to the competitive market with their CocaCola style threat tactics,
what
>> kind of sense does it make for us to level to contradictory charges
against
>> them?
>>
>> I mean, in one breath we bitch that Microsoft never fixes bugs, they just
>> add features.
>>
>> In the next breath, we wail on 98 for just fixing bugs and only adding a
few
>> features.
>
>Actually, I don't think Win98 fixed as many bugs as it created.
>The install is even _less_ stable than Win95.  And, AFAIK, the
>bug fixes were more patches than true fixes.  I don't see that as
>contradictory.  Win98 development was still feature-driven.


The install is less stable than Win95 on fewer machines and *MUCH* more
stable than 95 on many more.  You've been false-baselined by the media,
which is contradicting the Microsoft claim of stability because it sells
issues.

>> A few years back, Bill Gates said that there aren't any significant bugs
in
>> Windows 95 and that most calls are for features because uses don't really
>> care about bugs, they care about features.
>>
>> Now, with Win98, he's been proven right.
>
>Don't agree.  It may seem so at first glance, with the Microsoft
>propaganda machine in full motion.  However, I think once the
>gloss wears off, Win98 will leave people feeling rather hollow
>inside.  The building migration to Linux, et al., is no doubt
>related to this growing disillusionment.  Hopefully GNOME will
>provide a stronger migration path away from all the feature-noise
>coming out of Redmond.  One thing we need to really watch out for
>(with GNOME) is feature bloat -- tons of great little additions
>that don't really _need_ to be there.


The actual idea is not to excuse missing features on the basis of they'd add
bloat.  The idea is to realize every feature that has a substantive claim to
existence and incorporate them at the beginning so the original design
structures don't need to be patched and patched and patched again.

>Consider two ways to design a particular UI feature: one way is
>simple and somewhat blunt; the other way is elegant, yet more
>complex...more visually appealing but harder to use.  Which way
>do WE choose?  Ask a UNIX programmer, and he'll probably say the
>former.  Ask a Windows programmer, and he'll most likely say the
>latter.  (Correct me if I'm wrong?)  What does that tell you?
>Should we be more concerned about completeness, or about
>ease-of-use (at least when they come into odds with each other)?


Microsoft Windows allows multiple paths to the same destination.  If this is
a piece of functionality that you disagree with, then I must differ in
opinion with you.  It is my opinion that completeness and ease of use do not
conflict.  A function that appears to add completeness but does not make the
system easier doesn't have a place in that user interface.  The key value in
a UI is ease of use.

What you might be thinking of is, say, a situation where you consider adding
too many menu entries in an attempt to clarify what is available to the
user.  To which I reply, break the menu into pieces, or provide an "advanced
functionality" checkmenu for those who can handle it.

>> >While this would be a helpful thing to have, I think it might end
>> >up cluttering the toolbar, with all the extra text formatting &
>> >coloring.  And what if the user turns off the text for the
>> >toolbar?  Does this mean that he loses a slice of core
>> >functionality?
>>
>> Well, this is more of an icon in the sense of iconify/minimize, maximize,
or
>> whatever.  If you disable it, you still have the option of a key combo or
>> maybe a drag-and-drop question mark from the gnome bar to the app.
>
>I still think persistent tooltips would clutter up the
>workspace.  Much better to jump directly to the help-browser,
>without leaving behind floating residue.  Leave the hyperlinking
>to the help system, where you expect it to be.


Fine.  Integrate tooltips and the help browser.  Point is it should be
direct, instead of the standard Windows method of forcing you to hunt
through an ungodly number of steps every single time.  (Lack of completeness
causing problems with ease of use)

>> >  And by "appear in their normal boxes" do you mean
>> >the "help me" tooltips would appear on the physical surface of
>> >the toolbar when that feature is turned on?  If they don't become
>> >permanent, then how do you click on them...really quick, before
>> >they go away?  I don't think we want to train our users to click
>> >on tiny popup windows.
>>
>> They're basically similar to local web links.  Take a few columns of
icons
>> and draw arrows to their tooltip definition and links to documentation.
I
>> mean, damn, it's just a line of text enclosed in a box.
>
>Yeah, but once you have 3-8 of these tiny, persistent push-pinned
>text boxes with underlined, colored text floating around, won't
>that be clutter?  Like swatting flies.  If Joe User is allowed to
>keep these help links up permanently, he will!  Help is his
>lifeline.  The closer to it he gets, the better he will feel.
>Give him the opportunity to needlessly clutter up his workspace
>with dozens of little "clickables", and that's what'll happen.
>And then he'll complain because they're always in the way.  Gotta
>think like a user.  (c:


Ha.  So you're saying we should only have a single help window allowed to be
open?  Because all those little pushpinned miniguides are are help windows.

If a user wants something a given way, I am not really sure we have the
right to prevent it.

>I don't follow your comment about "columns of icons" and drawing
>arrows from/to them.  What do you mean?
>
>> I was under the impression that GNOME was at least going to become some
form
>> of Window Manager,
>
>Nope.
>
>> or maybe have constructs that Window Managers could use.
>
>Yep.  Sorta.
>
>> A non-GNOME compliant window manager wouldn't support titlebar keydefs, a
>> compliant one would allow it if requested.  No big wh00p.
>
>I don't think we want to get into requiring WM's to embed widgets
>in their decorations to gain compliance.  This would be pushing
>things too far.  There's gotta be a better way than that.


How the heck couldn't we require specific widget methods?  What, some WMs
have minimize, some don't, etc.?  Microsoft has a significant degree of
class that it derives from minimize/maximize/close.  Emphatically yes, it is
definitely within the purview of GNOME to request that WMs provide support
for specific features.


>But then you have to require full-motion video software to
>install GNOME!

It is *significantly* simpler to record a screen than it is to record video.
In some ways, you're just logging the X stream.

>  The idea is to keep GNOME as lean and productive
>as we can.  We want GNOME to be _easy_ to port to.  The more
>mandates we put on it, the fewer applications will get ported to
>it, and the fewer WM's will support it.  No WM author in his
>right mind is going to add support for video streaming, just to
>gain GNOME certification.  I know that's not what you meant, but
>it does serve to prove the point I'm trying to make.  It's just a
>matter of degrees.  Light == good.  Heavy == bad.


We're out to make a UI that's better than Windows, Mac, or anything else
that's been shoved on users plates.  We want to make a UI that's so clean,
so simple yet powerful, so accessable yet non condescending that users
question how they could have lived without it.  We want mothers to use this.

Whatever features are going to significantly increase the penetration and
understandability of this user interface must be part of it.  I can make a
strong case for arguing that the single most effective way to learn an
application is not to read a help file but rather to watch a demonstration
of a given feature being used accompanied by either text or voice.  It
should be *standard* to have the author of an app walk you through actually
using it, either with text or with voice.  *THIS* is the way GNOME can
overpower the competition by sheer quality.

>John
>
>
>--
>         To unsubscribe: mail gnome-gui-list-request@gnome.org with
>                       "unsubscribe" as the Subject.
>
>