I don't know if this has been posted before, but Matthew Thomas has posted a seering review of open-source UI designs which hits close to home for us.
http://mpt.phrasewise.com/2002/04/13
What can we do to avoid the fate of Mozilla's UI? Do we need a UI tsar to avoid disaster? Or, is there a way to make entire UI's be swappable in and out, so that people can make up UI's in a decentralized way and thus let the market work it out?
Here's a bit of flamage copied from the article:
"As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it's much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing."
This sounds exactly like us! Go read the whole thing; it's short and interesting.
-Lex
This recalls my work with Chris Alexander on The Nature Of Order (I should give the guy a ring these days...).
Turn the issue around: don't blame software builders for producing bad designs. Blame the software for letting them produce bad designs.
Chris' idea for the software we prototyped last year was to guide the user through a recipe that would automatically provide an acceptable, maybe even good design. You don't need to limit the user in any way to do that, the whole thing can be reached by taking various design decisions in the correct order.
His favorite example: usually, if you plan a house on an empty lot, you start deciding where the house will come. However, you *should* start deciding where the terrace/garden should come - the best piece of the lot (nicest sun/shade/soil/whatever) should be reserved for that, where the house will stand is bulldozered over anyway and doesn't matter. Simply by taking these design decisions in a different order, you get a much better end result.
Software design shouldn't be hard. I don't think a lot has changed since Apple literally wrote The Book on UI design (and subsequently, with MacOS X, failed to read it ;)). Jacob Nielsen also came to the conclusion that design standards are extremely stable over time. So we know what works and what doesn't.
But here I am, constructing user interfaces from scratch by composing the lowest possible UI elements, under time pressure, so in another mail to this list I'll proudly present a bit of Software-with-a-face which flagrantly ignores everything I know about UI design, and then some.
Why? Because the default behavior of this stupid software is to assist me in making bad UI's and indeed I ain't got no itch to scratch beyond throwing this UI together. Don't blame me, blame Morphic, yeah?
Now, *here* is a nice task for a Usability Team :)
On Feb 23, 2005, at 23:32, Cees de Groot wrote:
Turn the issue around: don't blame software builders for producing bad designs. Blame the software for letting them produce bad designs.
Well... for once... perhaps Smalltalk should try to catch up with good, old, IB:
http://developer.apple.com/tools/interfacebuilder/ http://developer.apple.com/documentation/DeveloperTools/Conceptual/ IBTips/index.html
Also comes bundled with "Aqua guides" to hold your hand when necessary:
http://developer.apple.com/documentation/DeveloperTools/Conceptual/ XcodeQuickTour/qt_interfaces/chapter_4_section_2.html
Cheers
-- PA, Onnay Equitursay http://alt.textdrive.com/
PA petite.abeille@gmail.com wrote:
On Feb 23, 2005, at 23:32, Cees de Groot wrote:
Turn the issue around: don't blame software builders for producing bad designs. Blame the software for letting them produce bad designs.
Well... for once... perhaps Smalltalk should try to catch up with good, old, IB:
Now don't get me started on Menu Bars again...
It's real simple. I have a menu bar on my mouse. It's called 'the middle button'. It's always very close and pretty much unmissable so it has a fabulous Fitz's Law figure of merit. It follows my point of attention around, even across multiple monitors. How anyone could fail to see the advantage over a screen-top menubar graphic I cannot imagine.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: CLOUT: Call Long-distance On Unused Telephone
On Wed, 23 Feb 2005 16:19:15 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button
Funny. Mine is called 'the right buttom' ;)
But, yes - pop-up menus are a blessing compared to the junk that sits on top of your window. In that respect, I think 3.9 is not Progress...
On Feb 24, 2005, at 01:30, Cees de Groot wrote:
But, yes - pop-up menus are a blessing compared to the junk that sits on top of your window. In that respect, I think 3.9 is not Progress...
Well... junk or not... the point of IB or such is to consistently enforce the junk flavor du jour.
Cheers
-- PA, Onnay Equitursay http://alt.textdrive.com/
Cees de Groot cg@cdegroot.com wrote:
On Wed, 23 Feb 2005 16:19:15 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button
Funny. Mine is called 'the right buttom' ;)
But the middle button is the right button. The right button is the wrong button. The left button isn't the right one either.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful Latin Phrases:- Recedite, plebes! Gero rem imperialem! = Stand aside plebians! I am on imperial business.
Il giorno mer, 23-02-2005 alle 16:48 -0800, Tim Rowledge ha scritto:
Cees de Groot cg@cdegroot.com wrote:
On Wed, 23 Feb 2005 16:19:15 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button
Funny. Mine is called 'the right buttom' ;)
But the middle button is the right button. The right button is the wrong button. The left button isn't the right one either.
Tim, can you expand your thoughts here? It may be my past Linux & Windows experience, but I feel the right button to be better then the middle one for invoking the menu.
Giovanni
Giovanni Corriga gcorriga@unica.it wrote:
But the middle button is the right button. The right button is the wrong button. The left button isn't the right one either.
Tim, can you expand your thoughts here? It may be my past Linux & Windows experience, but I feel the right button to be better then the middle one for invoking the menu.
The original format I got used to - since it was the only available GUI at the time - was Smalltalk's; left button to select, middle button for context menu, right button for window menu. That is a good hierarchy of meaning, going from very local (a single pixel, a character range, a button, a list item) upwards to the near-global of changing the menu.
I should mention that the current Squeak idiom (idiocy!) of using the select button to open a menu when on the main display is really stupid and can only be explained by the initial connection to Mac single button mice. Which is another dim idea.
The other good use of three buttons I'm familiar with (partly because I helped define it) is from RISC OS. There we have again the left button being to select and the middle button to open a menu. However the right button is a bit more interesting; it 'adjusts' the selection. It's a bit difficult to explain this without it seeming incredibly complicated but it works extremely well.
At the simplest level, 'adjust' can extend or shrink a text selection - like using shift-select in Squeak - or add/remove files to a selection in a filer window - like using option-click(?) on Macs. It can also 'adjust' the scrolling action; use select on the down scroll arrow and your text will scroll up as expected but 'adjust' and it will go in reverse. No need to move the mouse. Works for single line scroll and page jump. Saves motion.
It also works in menus. RISC OS menus are a little different to Squeak menus in that you must click on a menu entry to choose it. If you 'adjust' on a menu entry it selects BUT does not dismiss the menu and lets you select more items. For example, one can do menu>'select all' and menu>'ROT13 selection' without having to open the menu twice.
While I'm on the subject of menus, RISC OS uses an interesting approach born, I think, of a lack of understanding of the idea of subpanes back in 88 when we were doing the initial stuff. Even though I shewed off Smalltalk running on handmade prototypes and illustrated the menus, the RISC OS GUI ended up with the idiom of a main menu for the app window that is essentially a vertical menubar with 'very common' entries in the top level. Since hierarchical menus work very well if done fast this is surprisingly effective; add in rapid rebuilding of menus to account for whether anything is selected or not and it makes for a very fast GUI. Oh, and no having to move the mouse to the top of the screen or top of window and pick a tiny target a long way away.
In RISC OS web browsers we use select to follow a link, just like any other platform, but 'adjust' on a link opens a new tab/window - just like apple-click in safari but without needing to reach for the keyboard.
Basically, three buttons is a good number for mouse buttons since you can hold the mouse with littlefinger and thumb and use three fingers for buttons. Assuming of course that the mouse if physically well designed and believe me most of them are not. Scrollwheels? Yuck. If you have three buttons, use them sensibly.
So, that's the outline of why three buttons are good and why the menu should be on the middle button.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Any sufficiently advanced bug is indistinguishable from a feature. - Kulawiec
On Mon, 28 Feb 2005 11:06:04 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
Scrollwheels? Yuck.
Important middle-finger (aka "the finger") training, Tim.
So, that's the outline of why three buttons are good and why the menu should be on the middle button.
Thanks for the explanation. I like the idea of the hierarchy from left to right (iff that was the original design decision - you didn't make it clear whether it was so), but I think the right=popup has sort of sunken in.
Any sufficiently advanced bug is indistinguishable from a feature. -
and vice versa, probably
Hehe, a classic subject line ;-)
Tim Rowledge tim@sumeru.stanford.edu wrote: ...
I should mention that the current Squeak idiom (idiocy!) of using the select button to open a menu when on the main display is really stupid and can only be explained by the initial connection to Mac single button mice. Which is another dim idea.
You may think that a 1-button mouse is a bad idea (or can "dim" mean brilliant in Britain?), but it looks a lot more sensible if your other machine is a pen computer. I know you know this, Tim, but I just wouldn't want it omitted from this thread.
- Dan
Dan Ingalls Dan@SqueakLand.org wrote:
Hehe, a classic subject line ;-)
Tim Rowledge tim@sumeru.stanford.edu wrote: ...
I should mention that the current Squeak idiom (idiocy!) of using the select button to open a menu when on the main display is really stupid and can only be explained by the initial connection to Mac single button mice. Which is another dim idea.
You may think that a 1-button mouse is a bad idea (or can "dim" mean brilliant in Britain?),
Not so far as I know, but I've been away so long that I can hardly understand people when I do visit. What the hell does 'pants' mean, for example?
but it looks a lot more sensible if your other machine is a pen computer. I know you know this, Tim, but I just wouldn't want it omitted from this thread.
But a pen is completely and utterly different to a single button mouse! You use completely different actions, different muscle combinations... everything. With a pen you can sensibly use flick-gestures that could never work on any mouse I've seen. Pen based systems generally use quite small screens so having buttons across the top or a side is reasonable, a gesture can be used to get a menu, drag and drop can be done sensibly.
If anyone cares to offer suitable money I can happily return to UI research and write much more on the issues. Ghu knows there's been little enough progress in the two decades since I was at IBM UK.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Lights are on but nobody's home.
Tim Rowledge wrote:
Basically, three buttons is a good number for mouse buttons since you can hold the mouse with littlefinger and thumb and use three fingers for buttons. Assuming of course that the mouse if physically well designed and believe me most of them are not. Scrollwheels? Yuck. If you have three buttons, use them sensibly.
So, that's the outline of why three buttons are good and why the menu should be on the middle button.
Tim, you're the man!
The first "real" mice I've worked with were ugly as hell (looked like a half-sphere with buttons attached to the front) but passed the main usability tests: - they had 3 buttons - could be held with rounded fingers (your hand grips around the mouse instead of resting flat on it) That was so much easier on the hand than anything else which I met afterwards. Another idiocy which I'll never understand is mouse acceleration. It breaks muscle memory, a main factor of mouse usability. And don't get me started about optical mice! Not the good ones I saw at Xerox SIS which would work perfectly well on any structured surface, but the crap that became commercially available later... Even relatively new (2 yrs) logitech mice have such a jumpy positioning behavior that it's almost impossible to accurately select small-font text. Give me a good rubber-coated steel ball any time.
Cheers, Hans-Martin
Hans-Martin Mosner hmm@heeg.de wrote:
The first "real" mice I've worked with were ugly as hell (looked like a half-sphere with buttons attached to the front) but passed the main usability tests:
- they had 3 buttons
- could be held with rounded fingers (your hand grips around the mouse
instead of resting flat on it)
I had one of them! Blue, heavy, quite noisy mechanism but really quite comfortable.
That was so much easier on the hand than anything else which I met afterwards. Another idiocy which I'll never understand is mouse acceleration. It breaks muscle memory, a main factor of mouse usability.
Yes, it completely voids the 'direct' pointing aspect since moving from point A on your desk to point B and back will not neccessarily put the cursor back in the same place.
And don't get me started about optical mice! Not the good ones I saw at Xerox SIS which would work perfectly well on any structured surface, but the crap that became commercially available later... Even relatively new (2 yrs) logitech mice have such a jumpy positioning behavior that it's almost impossible to accurately select small-font text. Give me a good rubber-coated steel ball any time.
The DSP based optical mice are generally quite good in my experience. At least they kept the 'tangential' property of the mechanical mice, so that moving your hand in an anatomically sensible arc corresponds to left-right. The early opticals that needed the little grid-pad were really annoying because you had to move in actual straight lines aligned to the grid.
Bitpads/graphics tablets are less of a problem despite having that same property because they tend to be used with a pen and involve those different muscle groups. With large bitpads one tends to move the entire arm a good deal. I've even (so long ago it was clockwork and steam powered) used a CAD system with a bitpad that was Imperial size and almost required climbing gear to reach all of it.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Strange OpCodes: VMB: Verify, then Make Bad
On Wed, 02 Mar 2005 13:17:02 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
Yes, it completely voids the 'direct' pointing aspect since moving from point A on your desk to point B and back will not neccessarily put the cursor back in the same place.
OTOH, they do make navigating on big screens a bit easier, it seems. A trade-off, here?
At least they kept the 'tangential' property of the mechanical mice, so that moving your hand in an anatomically sensible arc corresponds to left-right.
Gosh. I never knew that. Just moved the cursor over a straight line left-to-right and back, checking the actual movement of the mouse, and indeed, it describes an arc rather than a straight line. Learned something again today (at least I know can go to bed knowing that my day was not completely spent in vain trying to cook up accounts for the taxman ;))
On Wed, Feb 23, 2005 at 04:48:15PM -0800, Tim Rowledge wrote:
Cees de Groot cg@cdegroot.com wrote:
On Wed, 23 Feb 2005 16:19:15 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button
Funny. Mine is called 'the right buttom' ;)
But the middle button is the right button. The right button is the wrong button. The left button isn't the right one either.
At last! Someone has finally explained the Squeak mouse buttons in language I can understand. I'm going to tape this to the side of my computer monitor as a quick reference ;)
David T. Lewis wrote:
On Wed, Feb 23, 2005 at 04:48:15PM -0800, Tim Rowledge wrote:
Cees de Groot cg@cdegroot.com wrote:
On Wed, 23 Feb 2005 16:19:15 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button
Funny. Mine is called 'the right buttom' ;)
But the middle button is the right button. The right button is the wrong button. The left button isn't the right one either.
At last! Someone has finally explained the Squeak mouse buttons in language I can understand. I'm going to tape this to the side of my computer monitor as a quick reference ;)
I hope you tape it on the right side. Karl
karl karl.ramberg@chello.se wrote:
David T. Lewis wrote:
At last! Someone has finally explained the Squeak mouse buttons in language I can understand. I'm going to tape this to the side of my computer monitor as a quick reference ;)
I hope you tape it on the right side.
No! The LEFT side; text usually ends up bunching on the left side (in left to right languages at least) so this note, like scrollbars, should go on the left.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Her modem lights are on but there's no carrier.
On Sat, 26 Feb 2005 11:13:40 -0800, Tim Rowledge tim@sumeru.stanford.edu wrote:
karl karl.ramberg@chello.se wrote:
David T. Lewis wrote:
At last! Someone has finally explained the Squeak mouse buttons in language I can understand. I'm going to tape this to the side of my computer monitor as a quick reference ;)
I hope you tape it on the right side.
No! The LEFT side; text usually ends up bunching on the left side (in left to right languages at least) so this note, like scrollbars, should go on the left.
Tim, you don't read very well: he *said* you should put it on the right side, and as you point out, the left side is the right side to put it on - so you're agreeing with him, aren't you?
I like the scrollbars on the right, though - you have to be more dextrous to use them but they look so sinister over on the left...
Avi
Avi Bryant avi.bryant@gmail.com wrote:
I like the scrollbars on the right, though - you have to be more dextrous to use them but they look so sinister over on the left...
You've been watching British TV haven't you ;-) Much more progress on these lines and we'll have to see about admitting you to the club.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Useful random insult:- Rusty springs in the mousetrap.
Tim Rowledge wrote:
karl karl.ramberg@chello.se wrote:
David T. Lewis wrote:
I hope you tape it on the right side.
No! The LEFT side; text usually ends up bunching on the left side (in left to right languages at least) so this note, like scrollbars, should go on the left.
It feels more natural to have the scrollbar on the right. I'm right-handed. If I flick through paper, I'll use the right-hand side of the paper to flick through. Ditto for most physical devices; having controls on the right-hand side is easier for me.
Ditto for resizing windows, closing windows, floating toolbars and probably other things if I think hard enough. If it were a real physical pen-and-paper desktop, all my tools would be near my right hand.
Apologies to all lefties. Perhaps we could make an option that mirrored all the UI components for left-handed people? :-P.
Mikevdg.
Michael van der Gulik squeakml@gulik.co.nz wrote:
Tim Rowledge wrote:
karl karl.ramberg@chello.se wrote:
David T. Lewis wrote:
I hope you tape it on the right side.
No! The LEFT side; text usually ends up bunching on the left side (in left to right languages at least) so this note, like scrollbars, should go on the left.
It feels more natural to have the scrollbar on the right. I'm right-handed.
Being right-handed is an obvious problem that we need to overcome since clearly only us left-handers are in our right minds.
If I flick through paper, I'll use the right-hand side of the paper to flick through. Ditto for most physical devices; having controls on the right-hand side is easier for me.
We have to be careful what metrics we use to decide upon 'correct'.
Purely emulating physical outer reality is often not very effective except to make it 'intuitive' to marketing people. A software system is really supposed to make it _better_ than reality, otherwise why not write our messages in pencil on scraps of paper and tie them to a pigeon?
One of the important metrics that ought to be used is how long a task takes once one is reasonably familiar with it; after all after a few emails we should be able to go a bit beyond the fake-writing-a-letter and fake-putting-it-into-an-envelope idiom. There is a clear need to make the learning curve as short as practical but attempting to make it flat and then limiting experienced users to the same kindergarten approach is terribly wasteful.
My expectation - and I happily admit it should be measured properly before it is accepted as established fact, send me money to run the study - is that since text (especially code, which we on this list spend a good deal of time editing) tends to bunch up on the left we would have our attention in that area most of the time. Moving the mouse around to select as part of editing would mean it was normally at the left and so access to the scrollbar would be faster (Fitz's Law applies reasonably well here) if it were on the left as well. This same closeness to the centre of attention is why contextual menus can be so much better than menubars, as well as the vast distances one need to move the dratted thing on a 30" screen,
Of course, there are other scrolling and control actions to be considered along with all this; key based scrolling is likely to be more convenient during text input for most people. Command keys can be much faster than a menu with a little experience, at least for a small well thought out group of keys.
Sadly, I know of no studies that point to a way to help cure your right-handedness :-)
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Use GOTOs only to implement a fundamental structure.
Tim Rowledge schrieb:
It's real simple. I have a menu bar on my mouse. It's called 'the middle button'. It's always very close and pretty much unmissable so it has a fabulous Fitz's Law figure of merit. It follows my point of attention around, even across multiple monitors. How anyone could fail to see the advantage over a screen-top menubar graphic I cannot imagine.
How about popup menus being a hidden feature and that context is not always clear? In extreme you could have a different popup menu for every single location on the screen, but you'll never know until you tried. In lack of a better example for unclear context take a (large) list of items. Some items are selected and you popup a menu over an unselected item. Now should the menu for the list, the selected items or the unselected item under the cursor popup (or even worse a combined menu for the list and selected items)?
I can't imagine how anyone could think that there is only one truth. Screen-top menubars have their problems, but popup menus aren't 42 either.
Alex
On Feb 23, 2005, at 4:19 PM, Tim Rowledge wrote:
PA petite.abeille@gmail.com wrote:
On Feb 23, 2005, at 23:32, Cees de Groot wrote:
Turn the issue around: don't blame software builders for producing bad designs. Blame the software for letting them produce bad designs.
Well... for once... perhaps Smalltalk should try to catch up with good, old, IB:
Now don't get me started on Menu Bars again...
Nevermind the menu bars - at least IB has an understandable layout model (struts, springs, voila). Morphic layout remains incomprehensible and cryptic. We could learn a lot from IB on specifying layout.
"Lex Spoon" lex@cc.gatech.edu wrote:
This sounds exactly like us! Go read the whole thing; it's short and interesting.
Doesn't it just! Time to flush the Augean stables.
tim -- Tim Rowledge, tim@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Do you like me for my brain or my baud?
Il giorno mer, 23-02-2005 alle 15:01 -0400, Lex Spoon ha scritto:
I don't know if this has been posted before, but Matthew Thomas has posted a seering review of open-source UI designs which hits close to home for us.
It's a good article, albeit it's becoming somewhat old. Open source project like Gnome and Mozilla Firefox have shown that usability and open source can live together.
What can we do to avoid the fate of Mozilla's UI? Do we need a UI tsar to avoid disaster? Or, is there a way to make entire UI's be swappable in and out, so that people can make up UI's in a decentralized way and thus let the market work it out?
I don't think we are doomed to the fate of Mozilla's UI, even if we don't have a UI tzar to impose his vision on the others. I think that the usability team should produce both _reasonable_ guidelines and suggestion, and also patches to implement those suggestions. The suggestions should be reasonable, so that noone can oppose them without pondering them too, and they should come with patches attached, so that everyone can see and evaluate "hands on" the advantages and disadvantages of those suggestions.
Here's a bit of flamage copied from the article:
"As in a professional project, in a volunteer project there will be times when the contributors disagree on a design issue. Where contributors are paid to work on something, they have an incentive to carry on even if they disagree with the design. Where volunteers are involved, however, it's much more likely that the project maintainer will agree to add a user preference for the issue in question, in return for the continued efforts of that contributor. The number, obscurity, and triviality of such preferences ends up confusing ordinary users immensely, while everyone is penalized by the resulting bloat and reduced thoroughness of testing."
The explosion of options is something that can and should be avoided. Options should exist to provide reasonable alternatives, not to avoid design decisions.
Giovanni
squeak-dev@lists.squeakfoundation.org
-
Alexander Lazarević -
Avi Bryant -
Cees de Groot -
Dan Ingalls -
David T. Lewis -
Giovanni Corriga -
Hans-Martin Mosner -
karl -
Lex Spoon -
Michael van der Gulik -
PA -
Tim Rowledge -
Todd Blanchard