Re: Self Documenting Interfaces

[John R Sheets <dusk smsi-roman com>]

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.

> 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?  I don't think we should tie any functionality to
toolbar text.  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.

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

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.

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

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?

John