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

On Fri, 2002-09-20 at 17:42, Justin Moore wrote:
>    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 right now there is no RIGHT way to do it...there are differing
historical ways to do it. And fortunately/unfortunately an open platform
like the linux desktop will see competing ways of doing things...at the
application level...especially if there is not a single long standing
open specification to meet and adhere to.  Is there an established open
specification overseen by any group that keeps track of such open
specifications...that dictates proper placement?   Button
placement..menu layout are uncritical to functionality...if they were
critical we would be able to turn off the text and the icons and cruise
around inside an application..or in a consistant environment just via
positional hinting.....position was never meant to be micromanaged to
this extent. 

No you can argue that in an ideal world toolkits should be so
configurable that this kind of stuff can be themable across toolkits. 
And I think I'd agree with that...maybe in a decade or so we can see a
specification on how this would work.  But Redhat certaintly can't do
that in the fixed time period of a release cycle.  There is bad...there
is good...there is better....and there is best.  But a best outcome
usually requires a crapload of manhours.  And the point of all this
debate is about Redhat has chosen to do in the short term.  In the short
term fixing the UI inconsistancy was not worth the development
time...and its certainly not in Redhat's power to make a lasting fix
that would be acceptible to the whole community.  Would themable UI's
across toolkits be the best outcome...hell yeah...is this going to
happen in the next year...no way.  This UI conflict is not going away
till there is a specification that outlines how toolkits can allow
themable UI element layout across toolkits.  But thats going to be a lot
of work...well past the manhours Redhat has to spend in a few release
cycles and this needs to be a full community effort.  Redhat can  not
march in an dictate this specification.  Redhat is right...applications
should be chosen on feature set...that is what they are trying to do by
mixing apps from different toolkits across the desktops.  Look long term
and Redhat's bold move to focus more on the features of applications
instead of the toolkits is going to help resolve these UI issues
faster.  We can stop hiding in different environments and missing the
"best" applications.  We can start demanding that toolkits start
allowing for themable behavior. Leading to more choices where it
matters...the applications!    

> Give me one reason why it's a Good Thing for them to use
> a standard toolkit but nonstandard dialogs for common tasks like this.

Because there is no good reason for a "particular" layout at all.  
Fact:there are currently different layouts embedded in different
toolkits..and different layouts have existed since the dawn of time.

assumption: there is no established open specification to handle how to
build a layout between toolkits. Toolkit builders have looked into the
dim past to pick how things are layouted out for their
toolkit/environment.  There is no RIGHT way for how this stuff is
suppose to work across "modern" toolkits.

premise: the developer of an application chose a toolkit on factors
other than UI layout...or has picked a UI layout that makes sense to
them and is consistant with respect to a few apps they feel are
important to be consistant with.  Since there is no one and only RIGHT
way handed down from on high..personal preference becomes a guiding
factor. And once developers are allowed to have their personal
perferences impact how users interact  yer going to see this kind of
inconsistancy across developer groups and the applications they create.

>    Yeah, don't hurt yourself with the sarcasm there.  I *strongly*
> believe in the need for people to educate themselves.  But there are
> 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.

Yes applications should be self consistant...but there is no great need
for consistancy across applications.

> Making them paranoid and irritable at your product because you randomly
> switch around standard dialogs in a nonstandard way is the wrong way.
And I argue that filling your product with inferior applications because
of where they break down into categories of dialog button placement is
the worse evil.  Building the perfect redhat distro is going to take an
infinite amount of time.  Right now having good applications is more
important than forcing UI consistancy.  It would be more wrong if Redhat
blessed one UI layout over the other and threw away strong applications
because of such minor things as dialog button placement.  Take the
millisecond and read the buttons...and in exchange you get to see the
gimp in a kde applications menu.  

>    Two completely different issues.  
not from a usage point of view....I login to a bank website or ebay or
whatever and use it..in a similar way that I use something like
gnucash...and I certainly don't expect similar layout from gnucash to a
bank website's application interfaace. Different
applications...different layouts....and yet we are pefectly okay with
it....

>Visiting a website is a temporary
> experience, and users expect that each site will have vastly different
> layout and look-n-feel.  
And I say using any application is a temporary experience...though it
make seem like i live in my email client..i don't.

>To support that idea there are loads of visual
> clues (each site has different color schemes and logos and such).  To
> make two applications look 95% like each other but then have weird
> differences in stupid stuff like common dialog boxes is just going to
> confuse users.

Right...now you are arguing for grandiose application to application
differences...and I'm all for that.  I want to KNOW by looking at it
that I'm using balsa....or evo. Wait I do know by looking at it that I'm
using balsa or evo... mozilla or galeon or opera.  I'm pretty aware of
what application I'm using just by looking at its different layout...
the metacity window titlebars help a lot too.  Applications should
differentiate themselves but be internally consistant. Websites do
it...desktop applications should be doing it as well for best effect. 
The desktop paradigm is being replaced by webtop paradigm...and in the
webtop , applications (websites) are diverse and stylish....The desktop
is pathetically plain and uninteresting in comparison.  You know all
that talk of mozilla as a platform..mozilla as middleware. If that idea
takes traction a lot of these layout issues move to the webtop where the
diversity in layout is immense....fear that day while I rejoice.

> 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.
that's right this really is nitpicky stuff.....strong default
applications make a much bigger impact on usability.  So concerning that
redhat only has so many manhours to give...and a release schedule you
have to wonder if lasting UI fixes are really something Redhat can focus
on in the short term.  I don't think its a quick fix...

>    That is part of "planning for it."  But what I was trying to get
> through with "plan for it" was to have applications be a) robust enough
> to recover from an incorrect decision or allow the user to correct it,
> and b) don't randomize messages because you will lose users and
> marketshare that way;
radomizing placement....enhances the point of reading the message.  If
you have to hunt for a button you more likely to take notice of the
message in the dialog.  The more I think about it the more I like the
idea of random yes/no placement...so if you put the mouse where you
think a button is...there is no button...its in a random location
somewhere else in the box.  That's garunteed to keep people from just
clicking through without attempting to read it.

> 
> > If people don't NEED the dialogs and are not READING the dialogs...why
> > in the hell do we have the dialogs there?
> 
>    Grr.  No no no.  I'm not saying all dialogs should be there, I'm
> saying all dialogs should be consistent.  
Consistant inside an app yes....from app to app....no so important. If
you know you are using mozilla...you can expect mozilla's windows to
behave a certain way...if you are using opera...you expect what opera
does for opera...not really a big deal as long as you can remember what
application is what.. And if you let applications be more about
indvidual style...it gets easier to keep track of which application you
are using.

What is so difficult with the
> concept of a nice, well-documented, logical, consistent layout, that can
> be configured up the wazoo?!?  
There is nothing wrong....but right now none of the toolkits allow for
themable layout elements to this extent....the toolkits have locked you
in....limiting application usage if you want consitant UI across
toolkits.  This is not something Redhat has the manhours to fix this
decade.

>    *bzzt*, wrong.  Layout == context, context == informative.  Context
> allows users to extract information from their environment and
> prioritize information and decision.

Fine go try living in a UI pure desktop where all the text and all the
graphic hinting is turned off...so all you are left with is layout
hinting.  It's not going to work very well. Nobody has ever expected
layout to matter to this extent.  The information are the labels and
graphics...the layout is more about style than it is about information. 
Context...deals with scope...and context by position is very limited in
scope, Positional context is at best a way to group similar things in a
window and to encourage how you read through items...positional context
certainly loses meaning across different windows....and then across
windows from different applications.  Expecting  layout to be consitant
across applications and you are taking things out of context.   

>  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.
But not across applications...or in this case cars.  If mozilla is a
saturn and opera is a chevy...expecting them to be the same visual
layout is absurb.  Layout across applications is more about style...than
context.  You learn a car...car by car....you learn an app...app by app.
  
>    Yes, "designing for" base human nature is wrong.  "Designing to
> withstand" base human nature is right.  Apparently the difference
> escapes you.

Random  dialog button placement withstands the desire to click-n-go
nicely....good thing I dont design UI in toolkits cuz i'd lock you into
a layout that I perfered,,,just like toolkit developers are doing to you
right now..

>    I'm saying that if you've got an ambitious long-term goal (the $1M)
> that will get you 100% of the way there but take 4 years to do, or a
> moderate short-term goal (say, $20) that will get you partway towards
> your goal and is considerably less work and time spent, which do you do?

both...i can understand the need to work on competing interests with
different time horizons.  Redhat has a release schedule...which is
literally set in stone from all appearences...Redhat's best efforts for
the short term can not include fixing the toolkit UI mess in a real
lasting way.  Are you saying Redhat's long term goals do not include
trying to fix this?  I think its clear Redhat wants this stuff sorted
out in the long run...so that you can choose the best application
regardless of toolkit and still have all nitpickily consistancy your
heart desires with other apps based on other toolkits.  That's the the
long term goal...and I think this move to trying to place applications
across desktops is going to help get that goal achieved faster by making
in harder to hide from from the problem...harder to hide in one
environment or anther and pretend like you don't have to think about the
application you are developing needs to work well across the desktop
environments. Choosing a desktop should not limit your application
selection.  

> If they want to have a stable
> desktop with a rich set of applications, then they should emphasize on
> features and consistency.  

competing goals right now....unforunately. 

> 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
> lost work and time.  If they want both, they should prioritize, but they
> do need to spend time on both.  

 and who sez that arent putting in long term focus on UI crap...but
Redhat certainty can't do that on their own...the toolkit developers
need to work out how to allow for UI layout customizations....give them
a decade to figure it all out.

And since distributions are more about
> polishing and presenting existing packages in an interoperable and
> user-friendly way than they are about writing desktop applications
> themselves, it makes sense for them to focus on UI goodness.
No i dont think it does...not in the short term...

>     "And in fact a little inconsistency in interface helps make people
>      read the information"
Lets clarify this....dictating a UI layout style at the toolkit level to
users is unimportant....and pretty futile.....
Figuring out a way to allow for UI customization across toolkits...is
not unimportant...but is certaintly less important for Redhat in the
short term than focusing on applications.  
> 
> > And how do you enforce consistency among the desktops or among
> > websites?  You can't enforce that...unless you OWN the platform and
> > dictate to developers.
> 
>    ... or projects are open-source and can be modified by anyone.
Right...you really want endusers have to modify the source code to get
the UI they want....thats still not enforcement...and if like you say
this is nittpicky sutff...there is a resource cost involved in getting
the nittpicky crap right...and at some point its no not worth the
effort.

>    Web development, true, OSS, false.  OSS gives you complete control.
> 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.
control at the development level...not at the user level.  Right now
users have very little control over UI layout...its bound up in the
toolkit development and then one later up at the application
development.  Nothing is stopping everyone from hacking in UI
consistancy into the next redhat release for themselves...but thats a
horrid amount of work to get nickpicky consistancy....this needs to be
hashed out at the developer level...and its going to take a while to do
it right.  Long term goals and short term efforts can and will seemly
contradict.

-jef

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA9i8ohrWLDmRitRZURAuSJAJ9eobLmoH2x7xKYMjbiwDNm78VMLQCgorCt
tpxwhVy6tWErRsXyW9JNd3k=
=pBRb
-----END PGP SIGNATURE-----