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: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Thursday, July 23, 1998 8:46 AM
Subject: Re: Self Documenting Interfaces


>Dan Kaminsky wrote:
>>
>[SNIP]
>>
>> But, Microsoft has a point:  Interfaces *need* to tell users how to do
>> things.  The problem is that Microsoft created two systems by which a
*new*
>> interface was created instead of bringing users up to speed on the
superior
>> old system.
>
>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?  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.

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.

>> While tooltips shouldn't disappear, I'd like a helpme checkbox up next to
>> the rest of the buttons.  This button would signal all tooltips to appear
in
>> their normal boxes, blue and underlined.  They should be links to the
>> help/man/whatever file that describes their usage.  Click once, and the
>> tooltip unfolds in front of you with an indepth description of the
function.
>> This would of course posess a pushpin so if you wanted to have the docs
>> available while attempting to utilize a function, they'd be there for
you.
>> That's A Good Thing!
>
>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 don't think we should tie any functionality to
>toolbar text.

Whoa, neither do I.  I said TOOLTIPS, which are basically little windows
that pop up near an icon while hovering above.

>  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.

>> There's more.  Us "experts" know that keyboard operations are orders of
>> magnitude more efficient than using a mouse.  The Xerox PARC designers
knew
>> this too.  So lets shift up a gear documenting what keypresses do what.
Why
>> not have a text entry box on the title that continually lists the key
>> combination that would have executed the last command.
>
>A better, cleaner solution would be to add the keyboard shortcut
>to the tooltip text, e.g. "Copy Ctrl-C".  By requiring more
>editiable fields, popping up from all over, I think you'll end up
>confusing the user even more.  Plus, you'll be mandating the use
>of more fixed screen real estate.

Sure, it's fixed real estate, but it's dynamic.  That makes it better--more
information transfer per minute.  And, guess what, user doesn't like it?
Gone.  No big wh00p.

>  Every GNOME app would have to
>make room for all these always-on tooltips (as I understand
>you).  And finally, you can't put an entry field on the title
>bar, because the title bar belongs to the window manager.  You'd
>have to put it on the toolbar (or status bar, which many people
>don't like, and should be able to turn off), which would clutter
>it even more.


I was under the impression that GNOME was at least going to become some form
of Window Manager, or maybe have constructs that Window Managers could use.
A non-GNOME compliant window manager wouldn't support titlebar keydefs, a
compliant one would allow it if requested.  No big wh00p.

>IMHO, we should put the key bindings in a generic properties-type
>window that we can share between applications.  Then we're not
>limited to designing a (key binding) UI that must overlay
>transparently over a different, unrelated interface (the main
>app).  Cross purposes.


We need a standard set of keyboard shortcuts first.  If they're too large
they'll be ignored and if they're too small they'll be useless.

Eep.

>> Finally, there's something I think is critical, absolutely *necessary*
for
>> GNOME to be the most explosive SDI out there:  RECORDING CAPABILITIES.
>> Record the X environment, allow it to be played back with a compressed
and
>> live-encoded soundtrack, and watch *real* tutorials occur.  Best of
all(but
>> perhaps hardest), since Gnome would be doing the recording, the themes
could
>> still be those of the user him or herself!
>
>Oh, I dunno.  Sounds more like a separate full-motion
>screen-capture application, rather than an integrated part of
>GNOME.  (Talk about feature bloat.)  I think GNOME would benefit
>from such an _application_, but not from such a _feature_.


That's just it, though.  GNOME's inherent *design* influences the window
managers that follow--Enlightenment, for example, is being Gnomified.  If
its accepted that GNOME should support recording well, that means additional
functions get exposed, implemented, etc.

>All in all, some good ideas in this and your other posts, but not
>fully thought through.  But that's why you're here, right?


Bingo.

>John
>