Re: Self Documenting Interfaces

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

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.

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

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

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)?

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

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

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

But then you have to require full-motion video software to
install GNOME!  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.

John