Editing UI

ec2-72-44-48-122.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic

[ToothyWiki:UI UserInterface]

That bit of a computer that you interact with.

By default, it is impossible to say anything good about a UserInterface.  If you ever notice it, then it's gone wrong.  The BaseLine user interface is telepathic and anticipates you in a polite way.  It gives you all the information you need ''and'' all of the information you want, in an easy to digest way.  It responds instantly (though it may not always complete tasks instantly)  It also, obviously, requires no training to use.

Current interfaces fall a teensy tiny bit short of this mark.

I have no idea what a 'good' or 'excellent' UserInterface would be like.

The proper user interface is invisible, allowing the user to concentrate on what they want to do and not how to do it. 
::I already said that above.  Though 'invisible' is shorter, it's not quite the right word.  Unless you can see what invisible things are doing ;)  --Vitenka

:Mmmm... I disagree. I do notice exceptionally well designed UIs - although I guess you could say that's only because *other* UIs look bad in comparison.  A good UI should (realistically) have options or tasks classified logically from the end-users point of view (this will probably include providing links to the same dialog from multiple places); be highly customisable without being obtrusive; provide a bit of relevant information when it asks the question with an easy button or link for full details; have "Don't ask me this again" buttons (for all available choices), plus info on how to unset that if you change your mind.  Admittedly it's much easier to list characteristics of bad UIs, I think, so something of the spirit of the [[OP]]'s point still holds...  --AlexChurchill
::All fair points, but all of those features are still well below acceptable quality.  They are a step up from the current performance, of course.  Task based working I heartily agree with - but it has one major problem: How to identify the task the user wants to work on and how to provide all possible tasks in advance?  The answer is obvious.  Telepathy and adapting to the user.  --Vitenka (Seriously though, accepting an interface that is telepathic anticipative and learning - what can you add?)
:::Not much, I'll agree. Assuming it understands very complex (telepathic) commands, in the spirit they were meant, without the user needing to know the detail of how they work.  But while this is fun, people actually writing program now rather than 50 years hence need some guidelines on what's good user interface design in the unfortunate absence of a mind-reading helmet on every computer.  --AC
::Nup - a helmet is a bug too :)  Yeah, an interesting discussion might be had here on what makes a good/poor design.  But I think staking out our aim point is a decent way to start it.  'Where we currently are' is probably well known by all here (though pointing each other at particularly corner-case examples might help) so if we've got 'where we want to be' then we can start trying to get there.  I doubt we're fifty years away from computers that can work out what their user is trying to do 99% of the time, and fail gracefully in a non-irritating fashion the rest.  --Vitenka
:::But that's not what you were talking about. You were giving implementation specifics (telepathy) ;)  But what you just listed (work out what the user wants to do, and the rest of the time fail gracefully and non-irritatingly) is a useful and practical goal, if not actually achievable (if only because irritation thresholds are subjective, and nothing more  is required for irritation than "it didn't do what I want" or even "it did what I want but I don't want it now").  Staking out the aim is fair and (arguably) useful, though, agreed. --AC
::The telepathy reference was that I see it as a necc. requirement for the kind of level of intuition such a system must have.  But it shouldn't have a helmet!  That would irritate me!  :)  --Vitenka (sorry that I didn't make that more obvious)
::Scratch that, I thought of a second way to do it.  Time travel.  Do something, see how the user likes it, go back in time and do something else.  Repeat until you find the best irritation / performance tradeoff.  --Vitenka

----

In TheMonastery: Useful Information, the provision of which is a cause for expulsion and attitude readjustment.

----
:''It also, obviously, requires no training to use''.

Most of the paragraph this comes form I agree with: but why this? Why is it 'obvious' and why is it true at all? What is the problem with an interface that requires training to use, if after that training the interface fades into the background and never needs to be consciously thought about?

Or do you hold that to be a contradiction: you think that any interface which requires training can never fade into the background? In which case I point you to driving as a counter-example.

:The requirement of a 'learning to use' phase is a (specification) bug.  If I can't use it, for any reason whatsoever, it is the interface's fault.  Sure 'learn to use it' is a useful and practical workaround.  Bringing up driving is a good point.  I find the whole damn interface to be a horirble bug.  I want a single joystick control.  A wheel is a poor choice, and foot pedals are just insane.  Now - (assuming that all cars can inherit my interface requirements trivially, to shoot down the 'what if someone else has to drive your car or you have to drive another car) why should I take time to learn an interface I hate, rather than the car adapt to me?  --Vitenka

::''A joystick does not strike me as something that has a particularly good mapping of things-you-can-do-with-it to things-a-car-is-capable-of. A car cannot go sideways when you push the joystick sideways, for instance; finding out that pushing sideways on the joystick makes the car, e.g., turn, requires learning and getting used to. You are also trading away some control (top speed vs power; being able to not skid on snow and so on) by getting rid of the gearbox (which is why I like the idea of cars with manual gears). Moreover, "The requirement of a 'learning to use' phase is a (specification) bug." - I disagree. In order to perform any task, you need a base of knowledge which must at some point be learnt. Also, I think it's worth learning a specific interface to a system if it means you can get more out of the system than with a generic one. I'm sure we've had this [ToothyWiki:CloneD546 argument] [ToothyWiki:SwitchToLinux/DrivingACarFallacy somewhere] already, actually.. - MoonShadow''
:Yup - it's that allll over again.  A car should accept the command 'WantSweeties'; and take me to the sweetie shop :)  I agree that the TradeOff has to be made by the user.  Is it worth learning something in order to get something more.  I disagree that this means that the barrier should be kept high - the barrier should be lowered, in the limit, to nonexistence.  And nowhere do I argue for a generic interface.  I'm arguing for, effectively, one interface per person.  You do that by having the (single) interface controller work out what the user wants.  This is a HardTask involving telepathy. :)  Yeah, a joystick isn't a perfect match.  So make cars that drive sideways :)  I'd ask for a keyboard-and-mouse combo, really - but a mouse is a bit dangerous to use when the surface is bumping about and anyway the 'reach the edge of the pad' problem is another mismatch.  Manual versus automatic is a side argument if you ask me.  That task should be automatied away completely, presuming we can trust a car to identify bad-traction surfaces better than a person can.  --Vitenka (But still... Feet?  [[WTF]]?)
:: ''What's wrong with feet? I'm all up for using as many input/output channels as possible, personally. Feet, hands, head position, eyeball tracking, voice - preferably all at once. Same for feedback - engage as many of the senses as possible. - MoonShadow''
:Feet just aren't good for fine control, nor for being held in a single position for long periods.  Feet prefer to move as a part of a whole leg movement.  In the extreme, it is like using individual toe movements.  I don't ''have'' individual toe movements.  Again, this is a 'me' part of the argument.  Some people might prefer to have their car controlled only by their feet.  They may have no option.  But for me, having the feet control something that needs continual fine adjustment - without any eye feedback, or even decent pressure feedback (the two main pedals feel the same.  DOH!) Just not clever.  I agree with full spectrum control and feedback.  And here we delve into the telepathy requirement, because the machine has to know whether you intended to activate a control, or were just distracted by a fly, or turning to yell at the kids in the back seat.  And that's got to be triply important in a system like a car where rolling back transactions may not be an option.  --Vitenka ([[OTOP]] if you develop a Ctrl-Z for crashes first, I'll take it.)
::''Feet are as good as hands are. The ability to drive/draw/use a computer is in the brain (if an intangible can be said to be anywhere). People who were artists who've lost the use of their hands can use their feet as well as they could their hands, after practice. It's just that most people don't need to - SunKitten''
:Ok - admittedly I'm partially arguing this on the basis of common training - but I just don't buy it.  People who put that amount of time into using their hands can bend in all sorts of funky ways.  --Vitenka  (Besides, this part is a 'just me' thing, I already said that)

----

I find it bizarre that you think that you don't need to be trained to use a joystick, but you do a car. Why is that? Could it be just that you've already learned to use a joystick?
I suspect that if you gave a person who'd learned to drive a joystick interface they'd be clamouring that they couldn't use it, and they wanted their nice friendly wheel and pedals back. 
You're fooled into thinking the fact you already know how to use something (probably because you learned to use it when you were young, meaning both learning it was easier as it is when you're young, and you've forgotten that you did actually have to learn) means that it doesn't need training. Which is just wrong.   --ChiarkPerson
:And chiark misses the counter to this StrawMan which I already posted to avoid it.  Fine.  Here is that point again in ActionReplay.  I want my interface of choice and they want theirs.  Fine.  That's a good thing, and a goal to which I think we should be aiming.
:With cars, no - that's not something that can be easily acheieved.  With computers, it is.  I agree that a joystick also needs to be learnt.  I argue that a joystick is ''also'' an insufficient UserInterface and that it is simply closer to the ideal for me.  (That is, I find it closer to the ideal, not that each person has a separate ideal)  --Vitenka (Inserted some clarification in my paragraph)
:My point on training is that it is a bug and should not be necc.  In the ideal, no training ever.  Slightly worse is to leverage existing training into new domains (shoot me, I sound like a ManagementConsultant!)  Failing that, the absolute minimum of training.  --Vitenka (In fact, I'd suggest that as a good metric to measure an interface by.  Both the steepness and duration of the LearningCurve)
::Name me even one thing that you can do that required you to learn nothing at all before you could do it (apart from breaking wind and the like).  Even eating requires practice and learning... --[[M-A]]
::''As does, for example, relating to people.  It appears to be Vitenka Versus the Rest of ToothyWiki on the "having to learn is bad" issue :) --AC''
:::On a /SubPage I suggest?  I'd ask why though.  If something is easier to learn, and in all other respects the same, it is better, surely?  Anyway, I'm taking the weaker stance here and saying "learn as little as possible, as unintrusively as possible"  --Vitenka
:::''Mmm... not really. Because when you acquire a system you don't know what it can do. Learning its capabilities is, well, learning. If the user only uses it for word-processing, and is then (say) printing out the letters and writing addresses on by hand, then they haven't realised the address book capabilities - but how are they meant to know they exist?  What about instant messaging, or some future concept that we haven't imagined yet? We're going to have to *learn* about it.  Now I have no argument at all that the UI should '''make it easy to learn how to use it''' - i.e. make the learning curve gentle rather than steep.  But not flat, because then you don't climb anywhere.  --AC''
:Ah, now that seems to me to be branching into a seperate argument.  And one we've most certainly already had.  My point is "The user who just sends letters is happy doing that" and yours is "but would be better off if they went up a step."  What a user tries to use a device for is something completely different - but whatever it is, the user interface should make it zero effort (including setup cost) to do.  As soon as the user conceives of something they would like to do, the UI should let them do it.  Now yes, we've ventured wayy off into SciFi.  --Vitenka

:The canonical example is breast feeding ;)  As I said - it's a limit.  Approach it, don't expect to meet it.  Although, since I'm postulating working telepathy, why not postulated insertion of learnings?  If the machine teaches you how to do it instantly, that'd come a bit closer.  --Vitenka
::''[http://www.greenend.org.uk/rjk/2002/08/nipple.html There is no intuitive interface, not even the nipple. It's all learned.]''

----

Let's try a better way to state it.
"The goal of a User Interface should include placing as little requirement upon the user as possible"

Is that better?  --Vitenka
:Much better.  Aiming for a limit of "no learning needed" denies the vast difference between "no learning needed" and "minimal amount of learning needed". Aiming for "no learning needed" just makes you cut back on the '''amount''' of learning needed for a particular interface, whereas aiming for the "minimal amount of learning needed" acknowledges the need to make the learning itself '''easy'''. Which is a route much more worth taking. --[[M-A]]
::I still don't like it though.  It opens up a huge gulf with that "as possible."  People will just say "Oh, it's imposisble to need less than this" (either value of less).  I acknowledge that learning here is (at least) a two dimensional quantitiy - but still think that 0 should be the goal.  --Vitenka  (Of course, the goal of the UI and the goal of the system (to do a particular task) don't agree.  A big block of nothing has a perfect UI, but it isn't very powerful.)

----
There is of course a wonderful user interface system which has been in operation for millenia that people seem to be ignoring. It is one employed for at least 10 years on computers by my father with moderate degrees of sucess. It goes like this:

Get someone else to do it for you.

To take the above examples and demonstrate how these translate to the SomeoneElse system:

Internet: "James, can you get this for me off the interweb?"
Driving: Taxis
Cookery: Chefs
Walking: Sedan Chair

While this form of user interface certainly requires a great deal of resources to opertate sucessfully (in my father's case he raised two children to be his slave labour, but rich people usually skip this and get hired help) it is remarkably effective and simple to use.

:Also the famed HighLevel ProgrammingLanguage: Graduate Student
:Problem is, it doesn't scale well.  The sedan-chair carriers need people to carry them, and so on ad-infinitum.  And a human pyramid gets a bit wobbly after the seventh layer or so.  --Vitenka

Of course, we could just rely on Synchroonicity.  [http://www.theregister.co.uk/content/4/33673.html Posted while I ate lunch.]  --Vitenka

----

It's not much - but it's a [http://www.modbee.com/life/wheels/story/8015603p-8880060c.html start]...

----

Are commandline UIs actually [http://osnews.com/story.php?news_id=6282 easier to pick up] than [[GUI]]s?
:From the ensuing /. thread - no.  Whatever you happen to be taught first, is easiest to pick up.  So if you teach someone the command line, they think it's easy.  Having said that, there ''are'' some [[HCI]] advantages to the command line.  --Vitenka
:: (PeterTaylor) Taught? Bah. I figured both out myself with the help of the manuals.

----

"A user interface is well-designed when the program behaves exactly how the user thought it would. (..) Anything else is a corollary." [http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html Wonderful text on UI design]. Is making MoonShadow seriously consider rejigging his FVWM bindings to be more Windows-like, at least for the guest desktop. Interestingly, he spends an entire chapter in defence of the stance that denial of decisions to users (albeit arguably short of the [[CloneD546]] point) is the way forward. 
''Yes. I really disagree with the way he presents Chapter 3, although I agree with some of his less polemical points. I agree that accidental reconfiguring should be really really hard, but I strongly disagree (with his implication) that it shouldn't be possible at all. I agree the WinHelp database wizard is very pointless, but I *love* customisability, especially toolbars and (pre-RSI) keyboard shortcuts; and Office apps are good these days at importing settings from previous versions. I agree that "Lock the taskbar" should be on by default (and ''perhaps'' not even on the taskbar context menu), but it definitely ought to be somewhere. However, apart from sections of chapter 3, the rest of this is very very good. Excellent rants on the *sensible* ways to make it easy to use dropdown boxes, window positioning, text in dialogs, etc etc. --AlexChurchill''

----

See also: [http://www.jnd.org/dn.mss/simplicity_is_highly.html Simplicity is highly overrated]; [http://www.joelonsoftware.com/items/2006/12/09.html Joel's commentary] [http://www.google.com/googlebooks/chrome/# Google like reduction (UI starts about page 20 ish)].

----
CategoryComputing | CategoryAbbreviation; see also [http://www.catb.org/~esr//writings/unix-koans/gui-programmer.html UI koan]
[[OP]] = [[Vitenka]]
ToDo: refactor with big stick

Summary:
Editing revision 48, which is the newest. This change is a minor edit.
(Visit Preferences to set your user name.)

View other revisions
ec2-72-44-48-122.compute-1.amazonaws.com | ToothyWiki | RecentChanges | Login | Webcomic