On the Widespread Misuse of the Mouse

An anonymous reader writes "Recently launched blog "The New Interface Advocate," has an entry about how mice are being applied to situations they are intrinsically poorly suited for. It also has an interesting proposal for how to keep most of the current paradigm of GUIs and still take advantage of the other control devices, such as the keyboard."

Comments

Using mouse hurts!!!

[b1ufox]

Really my wrist hurts as using mouse is obligation on my desktop, and that too for an average of 12 hours a day.

I know, i know CLI is there but CLI browsers are no match for GUI browsers sadly.

Moreover i would love to use keyboard keys for everything and for those who feel like me shifting to a more keyboard centric environment, try fluxbox. Wicked cool with all things in place, plus it is fast too, not to mention custom ways you can mould it to.

Re:Using mouse hurts!!!

[GFree]

Sorry... suffering massive packet loss... your post came out rather fragmented. I could only make out the following:

Really my wrist hurts

average of 12 hours a day

Testing...testing...one...two...three.

[Anonymous Coward]

And here I though the story was about the abuse of medical mice.

Article Text

[an.echte.trilingue]

I had no problems reading it, but since you can't seem to get to it, here is the text:

Now, I am by no means hoping to abolish the mouse. Its price to performance ratio is unmatched, and the best alternative pointing device (the tablet) can't be found for much less than an order of magnitude greater expense: hard to justify for the relatively small performance edge it offers. What I do wish to decry is the enormous reliance on the mouse to cover every possible user interface situation, failing to take advantage of other, better designs. Years of lazy design and low opinions of the user's desire (even ability) to learn have left us with a constant testing of Fitts' Law for such trivial tasks as saving, broken paradigms (what about a real-world button relates to replacing an old document irrevocably with the current one?), and a user experience that is more patronizing than productive.

Let's start with a few key ideas about interface devices. The keyboard is quantized (that is, it consists of discrete units of input, like a piano's notes), while the mouse is continuous (its input ranges without breaks across the entire screen, like the strings of a violin which cover every possible pitch in their range).

Now, think about the actions you perform on your computer in a given day. You type, save, open, close, select, resize, navigate, refresh, cancel, approve, and perform scores of other actions.

Now divide the tasks into groups. Which ones consist of discrete actions, and which require fine, continuous control? I'll be generous (and rude to my fellow console text editors--I know vi/emacs can both comfortably rely on keyboard input only) and say text selection and input positioning, color selection, drawing, and most (spatial) navigation is most naturally, perhaps even most effectively, performed with a continuous input device such as a mouse.

Now, for the discrete actions: type, save, open, close, refresh, cancel, approve, and most of the other basic actions. In fact, I'd say many users could count scores of daily activities that are discrete, whereas breaking a dozen continuous actions would be a challenge. (Let's put aside all window management like switching between windows, resizing them, moving them, and so on. These mostly seem continuous but I'll explain in a later post why they're usually not.)

Now, which of those actions are new users taught to do with the discrete input device? Typing.

Now, advanced users have memorized ways to do a large fraction of (or, if they're fanatical, all) discrete actions with their discrete-input device. If you're looking for evidence of the superiority of a keyboard over a mouse in most situations, look at these users. There is a strong correlation between how much time a person uses computers (especially professionally) and how much they switch away from the mouse whenever readily possible. I challenge you to find a hundredth as many IT professionals who prefer the mouse as who prefer the keyboard when either will perform a given action.

Further advantage of a keyboard over the mouse lies in "muscle memory." (For those who might not be familiar with the term, it's the re-enforced skill of repeated actions--and the reason we can speak, write, type, and a host of other skills, without having to consciously perform every muscle contraction in careful coordination.) This, however, isn't because it's quantized, but rather because our position on the keyboard is generally absolute, whereas whenever we grab the mouse the cursor could be anywhere. In fact, there are only five pixels we can hit with our eyes closed--the one we're on plus the four corners. That's less than 1/150,000th of the median computer screen's real estate that can be associated with muscle memory. The keyboard, on the other hand, can be entirely memorized (or close to it) in the course of general computer use. With combinations of control, alt, and shift, and even the more modestly skilled typists have literally hundreds of key combinat

Re:Article Text

[Corporate Troll]

I stopped reading after the first paragraph. A tablet? Orders of magnitude more expensive? What? A good mouse costs at least 20€ (Logitec/Microsoft), and a tablet costs a whopping 80€. A Voltio2 costs a whopping 40€. Both are Wacoms, I'm sure you can get cheaper elsewhere (Trust). Sure the Graphire Intuos3 A4, that I bought for my wife was 500€ back then (it still is), but not everyone needs that. Heck, my wife doesn't even need it!

Tablets have become very affordable, and if you like to use them, nothing stops you from buying one. Personally, I don't like them, but that my own inability to draw well that is at stake here ;-)

Better Yet Would Be a List of Trade-Offs

[eldavojohn]

Well, this is a really interesting article that, I must admit, I'm guilty of just following the crowd in this respect of allowing--no, relying on the mouse to do everything. It's very interesting and refreshing to read about someone suggesting something new and intuitive about user input to a computing device.

However, I found his premise inaccessible and, after reading the first part of this two part idea, I couldn't come up with a concrete advantage for using his method. At first, it seems like this is an argument for speed though I doubt rendering all those options in an overlay to display to the user would be much more efficient than a mouse click on a menu bar. The real estate gain is the obvious definitive advantage his system would have over everything I've used. However, the user must first know how to bring up the options overlay ... and I think he mentions the issues that would be associated with subselections. I tried to imagine the GIMP using this in my mind but the submenus would get out of hand. For example, you would like to use script-fu? Well, there's two submenus under that of a dynamic allotment of add ons that I can structure in directories however I want. Tough to deal with stuff like that.

I guess what I would have preferred in a blog like this is a more comprehensive analysis of trade offs when going against the grain in UI input methods. For example, using method A provides you with the benefits of speed & real estate saving but may be inaccessible for some users who are very used to the point and click paradigm and find new learning curves challenging or scary (there are people like that out there). In my opinion, keeping it as simple as possible and knowing your audience are the two biggest things to remember when designing a UI and I think this blog raises an excellent point that we shouldn't be afraid with re-examining the window system in operating systems but I don't think this is applicable in all situations.

Anyone out there (Edward Tufte students, psychologists, etc.) ever do a trade study on these features for their applications? Being a "form" ignorant engineer something like that would be most valuable to me.

Re:Better Yet Would Be a List of Trade-Offs

[morgan_greywolf]

Now that's where I differ. Depending on the application, I may use the mouse or the keyboard more. If it's a more typing-oriented application (like a word processor, text editor, spreadsheet) than I'm more likely to use the keyboard shortcuts for things like Save, Copy, Paste... If it's a more visual-interface-oriented application (like, say Rosegarden, Blender, or Ardour), then I'm more likely to use the mouse.

In some applications, I take a hybrid approach. For example, when using Inkscape or Corel Draw (which have similar interfaces and shortcuts), I might click on an object, and then say, press Ctrl+D to duplicate. Or I might click on text and then hit Ctrl+T to bring up the text editing dialog.

I don't think that the author's interface has to be all or nothing ... it depends on the application. You can keep both methods and allow the user to turn off the toolbars, etc., while turning on the keyboard overlay for user that want that.

Re:Better Yet Would Be a List of Trade-Offs

[ShieldW0lf]

The thing that the article doesn't appear to touch on, and the real reason for the fact that you can perform most actions using both a pointing device like a mouse and a button/chord device like a keyboard, is that the most time consuming part of operating a computer is switching back and forth between them.

If you really wanted to sit down and build yourself something that would be highly efficient, you'd use a chording keyboard on the one hand, a pointer with gesture support on the other hand, and never take your hands off either until you were ready to step away from your machine.

Having a trackball embedded into the lower section of the keyboard where you could manipulate it with either thumb without having to take your index fingers off the home row would be pretty efficient too. I'd buy one.

Not having read TFA yet..

[JoeCommodore]

I know of one misuse, is the overuse of popup lists in forms, especially when entering dates (one popup for month, one for day, and another for year)

When people are entering alphanumeric data give them as much keyboard access as possible, leaving the keyboard just adds to the entry time, stress injuries as well as potential for typing errors (reorienting to typing position after mouse usage.)

The second is popups instead of checklists and radio/selection lists, which add to the mouse gymnastics to select one or more options from a single line field.

It may be easier to make the popups (unfortunately many tutorials use date popups as an early example of web programming), either way you still have to validate the information, so take the extra effort to out in a generic text box, checklist or selection list and add a few more lines of validation code.

Keyboard as an alternative

[KingSkippus]

I skimmed the article, and I didn't see one other reason why I think everything that can be done with a mouse should also be doable by a keyboard, even stuff that is more efficient to do with a mouse: scripting.

Generally, scripting and automating mouse actions is very difficult. Scripting and automating keyboard actions is trivial.

CoralCache links

[Toffins]

page 1 and page 2

"A proposal for a nearly mouseless interface."

[bheer]

When I read that in TFA, I swear the first thought in my mind was -- he's going to reinvent Emacs?

Article Text, part 2

[an.echte.trilingue]

And this is part 2:

Since I said the mouse needed to be seriously re-examined as the primary device for interacting with the user-interface (see my previous entry), it's only fair that I give an example of a better way to do it. In this entry I explore one possible way to minimally change the interface to almost remove the mouse entirely, without increasing the difficulty of learning how to use software.

(Note: Click on Images for a full-size view.) Original OOo Screenshot (Here we have an unaltered screenshot of the experimental subject.)

First step: rip out essentially all of the traditional controls. That means drop-downs, buttons, and menus. Notable exceptions include the scroll bars and status bar (both of which provide excellent and frequently needed feedback like what the open file is, and where in the document the user is). Also, I'm going to take some liberties with the status bar to pull out some of the more cryptic (and rarely referenced) information in favor of somewhat more relevant data.

Original OOo Screenshot (The closest thing to a decapitation of an application you'll see.)

Second step: sit a user down (possibly with a close supply of anti-anxiety medication for those less comfortable with change), and tell them that if they want to "Control" the application, they need to press the "Control" key (great name for that key, huh?). When they do, overlay the application window with something like the following:

Design proposal for mouseless GUI (Okay, so I'm not a graphic designer, but I bet there are a few around who could pretty this up.)

Notes on the sketch: (1) Yes, this is a lot few functions than OpenOffice writer has. I'm just trying to present proof that all the icons and the most used part of the menu can readily be represented this way. Comprehensive feature lists are better represented by my menu-replacement sketch below. However, the idea is that that should be rarely needed. If it's used with any frequency, the application designer anticipated the user needs poorly. (2) I know some of the key-bindings are less than intuitive. I blame the 3am restarting of the whole design thanks to a bug that trashed my last design (followed by the same bug killing it a second time at 6am).

Now, there are some subtleties to the design. First, there could be two ways to access the dialog--tapping control, alt, or whatever could toggle the reference screen on until the modifier is tapped again, or, if the user holds down one of those modifiers, the reference screen disappears as soon as it's released. This makes the use of the control key much more accessible for those of us who haven't moved it from it's instant-carpel-tunnel-inducing location at the very edge of what an average-sized hand can reach.

Next, commands can be put in bold if they've been used recently. (The definition of "recently" was the subject of extensive debate when I was working with highlighting recently changed items in my last project. I'll leave "recent" undefined for lack of true resolution of that question for me.) Microsoft's "adaptive" menu system (also known as "Help! Where did half my menu go?") tries to address the same problem of adapting to user's usage patterns. This, however, is a much better way to speed finding of common commands. It doesn't shuffle items around or hide them, (both of which confound the user's ability to memorize the interface and wreaks havoc on users trying to use someone else's copy of a program).

Now, imagine the user's thought sequence as they try to enter a command. "Hm. I need to save. Hit 'Control,' save... ah, 's.'" Imagine that a few dozen times, and it starts to sound a lot like studying flashcards. For free, just by using the interface! Within weeks (assuming fairly sporadic usage), a user has memorized the shortcuts to all their common commands, obviating even looking as they execute them. Daily users could be fully proficient in even uncommonly-used combinations within days, with the pop-up

Re:Article Text, part 2

[antifoidulus]

Best sentence in the whole article: (Note: Click on Images for a full-size view.)

Re:Article Text, part 2

[pilgrim23]

It has been a pet gripe of mine: why do developers insist that data entry can be performed with a mouse? Programming, writing the great novel etc. that is what folks think of with this but..BUT! What of the lowly clerk? This poor soul data enters all day...They must key enter the vouchers the salesman brings in, the payment coupons, the thousand and one non-OCR compliant bits of data that need be digitized.. Ever watched a clerk do their job? - type type type in a field, click to the next field (because some wit forgot to make the fields tab-able), type type type, click, type, click, etc.. right hand is on the keyboard, then the mouse, then the keyboard then the mouse.... The action of reach and click reduces the clerk's effectiveness at their job by a goodly percentage. "elephant: Mouse designed by committee and built to government specifications" -seems to apply in this case too.

Cat the Mouse

[Doc Ruby]

I hate the mouse, except as a children's/newbie's teaching tool. If I've got desk space for a mousepad, I want to use that for my display. And why do all that (carpal tunnel inviting) work to move a virtual pointer?

I prefer the trackpad. But why don't I have a touchscreen with stability and accuracy already? There's no reason for a "pointer metaphor" device when I can just move the actual pointer.

Give me a touchscreen and maybe a little rubber pointer fingercap, if I'm freaked out by smudges, or need to see the pointed pixel under my fingertip. Or give me an antiglare screen that doesn't collect smudges, and put a rock-solid pointer just above my fingertip. Put some bumpy, but invisible, texture on the screen, and we've finally graduated from Xerox PARC into the 20th Century.

Hey Apple, can you finally redeem us from the nightmarish little box you cursed us with when you tempted us out of the terminal?

Re:Cat the Mouse

[kannibal_klown]

I prefer the trackpad. But why don't I have a touchscreen with stability and accuracy already? There's no reason for a "pointer metaphor" device when I can just move the actual pointer.

Touch screens are nice, but they have a major flaw: user fatigue.

Stick out your arm, just do it. Now hold it there for 5 minutes. Do you start to feel a little tired? Now leave it out there for another 10 minutes, see how good you feel.

Now imagine doing that straight through an 8-hour work day.

The only ways around this would be to make all screens flat against the desk (like a piece of paper) or to pivot your arm at the elbow. But even the elbow lever method would wear you out after a while. Sure it would probably be good exercise but I'm sure it would cause more health problems than a mouse in the long term.

If you don't like the mouse, try track pads, roller balls, pens, etc. Personally I use the trackball, with my only complaint being I have to continusouly clean the thing (more than my old ball-type mice).

Oh look, a "recently launched" blog

[Anonymous Coward]

...run by someone with no credentials, who couldn't even be bothered to make his own blog template.

He blathers on about some "proposal," which basically involves popping up menus based on modifier keys. Then he says "Without further adieu." This is a worthless blog, and a worthless post, and a new low for slashdot being used to jack up hit counters.

Emacs-ish

[BrokenSegue]

Is it just me or does this "new" system look a lot like the control system employed by Emacs (and even vi), but with a colorful overlay?

Mouse Gestures

[Romwell]

Just two words to save the mouse: Mouse Gestures. The author tells us how limited mouse is in terms "muscle memory", yet he doesn't know that mouse isn't only for clicking. Mouse gestures can, and are performed automatically from muscle memory. I've learned a copule for Opera, and then I had to LEARN to NOT APPLY mouse gesture (down-right) to close Explorer windows.

Programming....

[eggoeater]

...about how mice are being applied to situations they are intrinsically poorly suited for.

Yeah, like computer programming.
I deal with a lot of different vendor products used for call routing and IVR applications. One thing that's happened over the past 10 years is the move from text scripts to proprietary GUI based programming tools. I'm talking drag-n-drop blocks that perform specific functions which "hook" together by dragging lines between them.

Generally, this is to make configuring the systems more accessible to people not properly trained (or trained at ALL) in programming. ie. They're suppose to be good for writing error-free scripts. Unfortunately, these poor tools in no way reduce the number of bugs that find their way into the system.

Additionally, they also have the following draw-backs:
* Absolutely no error handling (try, catch, etc.)
* No way to program function calls....once you choose a path, there's no going back...this results in TONS of duplicate code.
* No way to know exactly what those blocks are doing under-the-hood.
* You're limited by the functionality of the blocks provided by the vendor.
* Many difficulties with source-control systems and build-and-release procedures.
* Don't even get me started on what it's like to debug with these stupid things....

Just this morning I was paged at 5:45am because someone made a change to a script. It took me an hour to find the problem because I had to zoom in and out, trying to get a feel of the layout, looking a block properties to see what's changed, etc. It turned out the lines connecting the day-of-the-week block were set correctly: they had the Monday line connected to Sunday's code.

Talk about a fubar'd system.
They should be outlawed.

Re:Mice Vs Keyboard

[jimstapleton]

People like mice because the way the GUI interfaces is set up with a mouse gives people information on the fly now to use the program, while doing things with a mouse. Accessing those same things with a keybaord can only really be done with the menus, and those are usually set up to be more mouse efficient.

I think the author hit the nail on the head with his article. You can't just make the application do everything via the keybaord. Rather, you have to have it able to use the keyboard for any task, and able to prompt the user so that they don't have to keep going to references to find what they want.

The overlay idea is fairly interesting and ingenious compared to what a normal keyboard-only interface produces. I kinda like that solution.

We already tried that

[Strawser]

It was called vi. [ctl]s isn't much more efficient than [esc]:s

I like the idea of making as many commands as possible doable with the keyboard, but half the point to a gui is the ability to use the mouse instead of having to memorize a bunch of cryptic commands. Just keep the most used commands accessible by keyboard, and leave the rest to be hit with the mouse. Yeah, mice are kind of crappy for an input device, but redesigning the mouse will work better than redesigning the interface. The reason vi and emacs and other command-based editors aren't in common use outside of the geek world is because no one wants to do that except geeks.

Re:We already tried that

[smellsofbikes]

>because no one wants to do that except geeks.

Where 'wants' == 'spends enough time using the tool to make learning the shortcuts worthwhile.'

Using a mouse is nice because someone who only uses the tool once a month, or who just started using it, can use it successfully and somewhat efficiently. However, people who use the program all the time, for hours a day, run into a whole other set of problems: their wrists hurt, and if they have keyboard shortcuts they learn to use them much more efficently than doing the same work with a mouse.

I think it's like learning to touch-type. Yeah, it's a big pain in the butt to memorize a keyboard and force the keybindings into your muscle memory, and a lot of people refuse to do it, but once you DO, it's much more efficient.

Now, it's entirely possible that anyone who uses programs enough to get to the point where learning and getting comfortable with keyboard shortcuts is, by virtue of that amount of use, defined as a geek. But I think that that's an effect, not a cause.

So this writer..

[abigsmurf]

Wants to go back to the 'good old days' where you'd have to tab 20 times to get to the text box you want (enevitably you'd press it 21 times and have to start over), have to remember different key combinations for every program (most keep the basics the same but advanced functions usually are different) and generally do most graphical activities slower?

Users like icons and using mouse for most activities because it's easier, safer and there's less risk of doing the wrong thing by accident. Who here hasn't experienced the frustration of losing 20 minutes of typing or resetting a connection because they pressed 'backspace' to try and delete some text only for a browser to go back a page?

Oh, it's the worst...

[Junior J. Junior III]

Try entering text with a mouse sometime... it goes something like this:

1. Scan document for instance of the letter you want to type, scrolling as necessary.
2. Highlight, right-click, hover to "Copy", click.
3. Scroll back to your insertion point, right-click, hover to "Paste", click again.

Man is that slow and inefficient!

Stop being such a geek

[Seraphim_72]

You know there are professions that have been in use for ages that require you to use your arms all day. Blacksmithing, weaving, farming, manufacturing, etc, etc. You would learn to do it, just as you have learned not to do it. Besides, if it was laid down on the desk, it would be like ... writing, you know, that people have done for ages. Maybe we could get some Franciscan Monks to teach us how to hold a pen for 8 hours. Yeesh.

Sera

Re:Stop being such a geek

[halcyon1234]

Or the disgruntled employee being dragged out of the building, all the while shouting "FORMAT C: YES"

Misses the point

[i am kman]

I doubt most folks would disagree with that for basic word processing, power computer users (which includes 98% of /. readers) often prefer memorizing tons of secret key strokes over using the mouse. Duh. But for folks that don't live and breath these apps, mouse-driven menus at least let folks easily access EVERYTHING.

The issue is that it's inefficient to switch between multiple input devices so one should design GUIs that allow users to go with the flow rather than forcing them to constantly switch in the middle of their workflow. But the article obsesses with trying to argue that the keyboard is far superior to the mouse rather than saying the keyboard is better for applications that focus on text entry.

Try creating Powerpoint slides without a mouse - or navigating the web - or playing games - or anything except for text-entry centric apps. It's a ridiculous premise to argue that the mouse is obsolete.

The guy has a point and a 1/2

[gurps_npc]

He basically has two ideas. One of which is BRILLIANT, the other is questionable.

Idea 1: Hide the non-essential icons/user interface tools behind a control key

That idea is brilliant in my opinion. Take the Internet Browser. When reading the pages on the internet you do NOT need the three or four or more menu bars. When you add in the file set, my links, the back etc., the address bar, and any google/yahoo/ etc. menu bar, that can add up to quite a lot of space not always neccessary. I have two hands, I see no reason why we can not implement his concept of HIDING that all away until you press the Control key.

Idea 2: Making all those controls key controlled. Now, I am in favor of more/better key commands. But honestly, I see no reason not to also button up those same commands. If we write "Alt-S: Save document" then why not draw a line around it and allow a mouse click as an alternate way to save the document.

Excel - designed for the keyboard

[klubar]

If you've ever watch an excel expert their hands almost never leave the keyboard. Excel is really well designed such that almost all the commands are easily accessible from keyboard shortcuts and power users quickly come up to speed on the commands. The interface for excel is extremely well thought out making it easy for beginners to be guided through the options and power users to be able to blaze through. Excel is perhaps one of the best designed and most usable programs ever. (The OSS alternatives for excel are good for basic lists and trival spreadsheets. Excel is one reason that Open Office is unlikely to succeed in corporate environments.)

Re:When mice go byebye

[earlymon]

I'm still waiting for them to develop the system that tracks eye movements, and just put left click / right click on the keyboard. Uhhhhh - dude. Left wink / right wink. And eyebrows for scrolling.....