Re: UI design [was Owen Taylor's paper]

> >    This e-mail is probably against my better judgement, but oh well ... :)
> It's fun no?

   It was Friday and I'd had a long week. :)

> >    I agree that important dialogs should stand out and say "Your system
> > will EXPLODE if you hit ENTER [ BZZT BZZT BZZT!!! ]", but why should
> > three nearly-identical web browsers have three different arrangements of
> > Menu Bars or placements of "Continue/Cancel" and "Yes/No"?
> 
> Because the writer wanted that way. It felt better to him that way.

   *nod* But I think there should be some sort of standard agreed upon
by at least the toolkit developers for some of the more common
situations (ie, closing an unsaved document).  Even if that standard is
only expressed by some default building blocks within the toolkit
itself.  I mean, look at glade; it's got plenty of selections for menu
bars, items, etc.  Have stuff like that standardized somewhat would go a
long way towards consistent menus, dialog boxes, buttons, etc.

> > boxes on and off, but weird UI placement throws me off _for no good
> > reason_.
> 
> You are assuming "no good reason".
> There may be one you just don't know.

   All true.  I'm just saying that the developer may have a good reason;
it's still not necessarily a good thing to do (in the big picture.)

> > right ways and wrong ways to go about it.  Giving a user a nice app with
> > a consistent dialog and plenty of help documentation is the right way.
> > Making them paranoid and irritable at your product because you randomly
> > switch around standard dialogs in a nonstandard way is the wrong way.
> 
> Notice you said app with consistent dialogs.
>  From app to app they can vary.

   Well, yes, they do vary.  And while I have no issues with dialog
boxes and buttons varying between, say, Abiword and Mozilla, it would be
nice if the same class of tools -- like Mozilla and Konqueror -- had
similar kinds of boxes, hotkeys, etc (to some degree) for common tasks.

> > If they *do* want to gain marketshare from Joe Q. Public, they're going
> > to have to get their ducks in a row over even nitpicky stuff like dialog
> > box placement.
> 
> You mean button placement right?

   Err, yeah. :)

> >    Yes, don't give them an excuse to click-through, but do this through
> > intelligent selection of when you present dialog boxes and giving the
> > user control over what they want questions about.
> 
> That's tangent to the discussion of the placement and ordering
> of the action buttons in a dialog.

   Yes, but I think it all falls under the same category of managing the
kind of information that is presented to the user, when it is presented
to the user, and how the user informs the application of what he/she
wants the application to do.

> I got bit by this once. The question was "Do you want to save
> your changes? YES/NO". I used another app and the question was
> "Are you sure you want to exit with unsaved changes? YES/NO"
> I noticed the Question was different as my finger hit the "YES"
> button. Here the fact that the dilog was so similar, I think
> both has titles like "Unsaved file", caused a problem.

   See my above comment about toolkit and GUI builder primitives. :)

> >    Grr.  No no no.  I'm not saying all dialogs should be there, I'm
> > saying all dialogs should be consistent.  What is so difficult with the
> > concept of a nice, well-documented, logical, consistent layout, that can
> 
> Who do you suggest defines this layout?
> What if I want a button label that's not in the definition?

   XML has DTD's.  Glade can build a GUI from an XML file.  Why not use
the tools we already have to allow themeable layout and arrangement? 
That way RedHat (or whoever) can simply apply the "RedHat DTD" to the
GUI, compile, and distribute.  Application developers can create their
own non-standard dialogs/buttons if necessary, and just let the DTD have
stuff fall through unchanged if it doesn't match.

> Once you have the layout defined, Do you a) not allow apps that
> violate the spec in, or b) spend lots of man-years rewriting the
> app to follow the spec?

   Well, I see this as something similar to security or reliability. 
The developer needs to have {the spec,security,reliability} in mind from
Day 1.  I would say that it would be just fine to allow apps that don't
meet the spec in; there's no good reason not to give the user a choice
of two applications just because one isn't pretty-fied.  The bottom line
is that I don't have an easy answer for this. :)

> >    *bzzt*, wrong.  Layout == context, context == informative.  Context
> > allows users to extract information from their environment and
> > prioritize information and decision.  If I know that my car's important
> > warning lights are on the right (engine check, overheating), and the
> > stupid stuff is on the right (ie, Saturn's "you should upshift" light),
> > I am going to pay more attention when a light on my right-hand-side
> > comes on than one on the left.  Context conveys information.
> 
> So, should Ford or GM not be allowed to put the important
> lights on the left? What about moving the "stupid" stuff
> to the center,and having important stuff on the right and left?

   No, they should be allowed to.  But look how similar most cars are
nowadays.  The UI for a vehicle is pretty consistent: headlights on the
left, windshield wipers on the right, gearshift in the center, radio in
the center, etc, etc.  What differentiates cars is their reliability and
what they offer to the driver (performance, safety, etc).  Cars have
reached that level of consistency because the manufacturers all came to
the same design some way or another, and now focus more on features.

> > We have laws against creating accidents and speeding, but it still
> > happens, which is why cars are designed to be crash-resistant and
> > protect the passengers.
> 
> They are more for protection from other drivers that don't
> follow the rules. And for situations beyond your control,
> like hitting a pothole, and it blowing-out a tire.
> 
> For applictaion, those uncontrollable situatiuons are
> more like someone/think killing the app, instead of
> exiting correctly. Or the UPS incase a storm knows out
> the power.

   I would venture to say that most apps "blow up" because the user does
not use it the way the author intended.  That usage might be benevolent
(closing the app without exiting) or malevolent (intentionally
overflowing a buffer).  How many security problems have we as a
community dealt with over the last 20 years because "the user won't
input any more than X chars for their name" or the like?

> > features and consistency.  People are more willing to put up with nice
> > looking crap that works most of the time than they are with
> > full-featured stuff that confuses them and leads to a greater chance of
> 
> If you want that, use Windoze. That why I no longer do.
> Lots of pertty, consistian, *CRAP*. I'd rather have the full features 
> stuff I have to pay attention to, in order to reduce risks.

   Yes, so would I.  I'm just saying that Joe Q Public probably isn't
like that.  JQP often gets confused if the background image on one
Windows box is different than what they're used to.  The computer is a
tool, just like a car or a toaster, and they want to UI to reflect
that.  I'm just trying to play devil's advocate here on behalf of the
common man (or woman). :)

> > 100% So much so that recently some of the less reasonable advocates (but
> > not developers) of Gnome2 and KDE got their panties in a twist about
> > their work being changed.
> 
> I disagree with the changes made. That was discussed before.
> To restate. The Red Hat version are nice. But I'd prefer a
> simple choice to get the defaults. Yes, gconf will get me the
> default icons, and UI look, but it requires several, undocumented
> changes. And there is no easy way to seperate the GNOME, KDE and
> neither applications in the menus.

   I haven't seen the changes outside of screenshots, but I do agree
that RedHat needs better documentation of the changes if the "put this
back to Gnome2/KDE defaults" command is not a click away.  This is a .0
release after all (I assume) and is bound to have rough edges.  My
comment was more to refute the assertion that OSS is not flexible, and
that if you're going to write OSS you have to be aware of all the
consequences thereof. :)

-jdm

Department of Computer Science, Duke University, Durham, NC 27708-0129
Email:  [email protected]