Re: [Haskell-cafe] Re: Editor
apfelmus wrote: I can't know whether that's the case, but the fact that virtually all commands are invoked with the keyboard clashes with HID research reported at http://www.asktog.com/TOI/toi06KeyboardVMouse1.html It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. The research there is reported as hearsay, it is not referenced research, so I can't check their methods. Despite the implicit claim that my brain must be lying to me and causing amnesia I'm unaware of, I would dispute the claims there. I suspect there might well be a large body of users (even 'most') for which it's true. However 'most' people are not fast typists. I'm sure that I can quite reliably hit the command editor keybindings I use many, many times faster than if I had to select them from a menu. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Re: Editor
I'm sure that I can quite reliably hit the command editor keybindings I use many, many times faster than if I had to select them from a menu. Note that the claimed time-consuming part is not to actually press the keybinding, but to chose and remember which one to press. Yes... except that for a lot of people, programmers especially, a lot of key bindings have become part of your motor memory, and so you can probably hit the common ones quite quickly without having to stop to think about which combination of keys to press. Cut/copy/paste are good examples of this, I think. Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
Alistair_Bayley: I'm sure that I can quite reliably hit the command editor keybindings I use many, many times faster than if I had to select them from a menu. Note that the claimed time-consuming part is not to actually press the keybinding, but to chose and remember which one to press. Yes... except that for a lot of people, programmers especially, a lot of key bindings have become part of your motor memory, and so you can probably hit the common ones quite quickly without having to stop to think about which combination of keys to press. Cut/copy/paste are good examples of this, I think. Exactly, this is why my shell, window manager, mp3 player, web browser, and editor all use hjkl to navigate :-) -- Don ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
On Tue, 2007-22-05 at 10:19 +0200, apfelmus wrote: I can't know whether that's the case, but the fact that virtually all commands are invoked with the keyboard clashes with HID research reported at http://www.asktog.com/TOI/toi06KeyboardVMouse1.html It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. You beat me to the punch. And to exactly the same URL, in fact. I see strong parallels between the insistence that keyboarding is faster than mousing and the insistence that manual memory management is faster than automated memory management. -- Michael T. Richter [EMAIL PROTECTED] (GoogleTalk: [EMAIL PROTECTED]) In his errors a man is true to type. Observe the errors and you will know the man. (孔夫子) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
Michael T. Richter wrote: On Tue, 2007-22-05 at 10:19 +0200, apfelmus wrote: I can't know whether that's the case, but the fact that virtually all commands are invoked with the keyboard clashes with HID research reported at http://www.asktog.com/TOI/toi06KeyboardVMouse1.html It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. You beat me to the punch. And to exactly the same URL, in fact. I see strong parallels between the insistence that keyboarding is faster than mousing and the insistence that manual memory management is faster than automated memory management. Why not abandon the keyboard, then, and have all your alphanumeric keys neatly lined up in menus? Or perhaps click on a picture of a keyboard? ;) Assuming you wouldn't find the above more convenient, you concede then that some things are faster with the keys than the mouse. So it really is a question of degree. The mouse excels at tasks like 'select a particular large but illdefined (unstructured) chunk of text' : it's a very natural gesture. However as a programmer I am often working with much more structured text, and operations like 'move forward one sub-expression' or 'parenthesise the next two sub-expressions' tilt the balance back in favour of the keyboards. The mouse is an analog input device and it excels at analog operations and exploratory ones (poking around menus and tabbed dialogs). The keyboard is a digital device and it excels at concise precision, such as 'let-float the next 4 definitions up one level'. Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
* Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. Even if it is empirically true that mousing is wall-clock faster than keyboarding, one has to ask the question why users feel internally that keyboarding wins. Perhaps it is because using the mouse requires a cognitive switch from editing the document, to a physical hand-eye co-ordination task, and back again? The mental effort of switching might be harder work than keeping your focus on the document at all times, and therefore switching _feels_ as if it must be slower. Of course this assumes that the person is sufficiently skilled at typing on a keyboard that they do not need to look at it, and hence their eye can stay with the cursor in a window on the screen. Perhaps you can find and move your mouse using only peripheral vision, but even so, the first cognitive task you need to accomplish is to find the mouse pointer on screen, which is invariably in a different place from the text cursor, and so drags your attention from one focus to another. Regards, Malcolm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
On Tue, 2007-22-05 at 13:48 +0100, Malcolm Wallace wrote: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. Even if it is empirically true that mousing is wall-clock faster than keyboarding, one has to ask the question why users feel internally that keyboarding wins. Perhaps it is because using the mouse requires a cognitive switch from editing the document, to a physical hand-eye co-ordination task, and back again? The mental effort of switching might be harder work than keeping your focus on the document at all times, and therefore switching _feels_ as if it must be slower. Of course this assumes that the person is sufficiently skilled at typing on a keyboard that they do not need to look at it, and hence their eye can stay with the cursor in a window on the screen. Perhaps you can find and move your mouse using only peripheral vision, but even so, the first cognitive task you need to accomplish is to find the mouse pointer on screen, which is invariably in a different place from the text cursor, and so drags your attention from one focus to another. All this talk about efficiency while editing text would make me believe that most of my time spend writing software is typing. Yet, oddly enough, I find that the typing is the least of my tasks. Most of my work is done in my head, on whiteboards or on scraps of paper long before my fingers stroke a keyboard. -- Michael T. Richter [EMAIL PROTECTED] (GoogleTalk: [EMAIL PROTECTED]) When debugging, novices insert corrective code; experts remove defective code. (Richard Pattis) signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
On Tue, 2007-05-22 at 10:19 +0200, apfelmus wrote: http://www.asktog.com/TOI/toi06KeyboardVMouse1.html It adresses the question whether selecting commands in menus with the mouse or accessing them via keyboard shortcuts is faster. The answer is: * Test subjects consistently report that keyboarding is faster than mousing. * The stopwatch consistently proves mousing is faster than keyboarding. Interesting! I did a quick test doing search and replace using the keyboard and the menus in Emacs. It takes me about six seconds with the keyboard, and closer to ten using the menus. (The first time, it took thirty as I spent time to locate the correct menu options :-) But I agree with the report that using the mouse *feels* a lot slower. Quoting the report: It takes two seconds to decide upon which special-function key to press. Deciding among abstract symbols is a high-level cognitive function. I'm not so sure I agree, using the mouse feels way more abrupt and intrusive. I can do M-x repl TAB str TAB foo RET bar RET with my eyes closed¹, but to use the mouse, I need to locate the mouse with my hand, locate the mouse cursor, locate the menu, etc etc. Maybe that'd change if I used the mouse more? -k ¹ I can, but probably shouldn't. I just tried, but didn't realize focus was not in Emacs but my mail client - which consequently promptly did a bunch of unpredictable things to my draft. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
This recent development of the thread leads me to these conclusions and conjectures. * If you want to demonstrate the mouse to be faster than the keyboard, you can contrive an experiment to do so. Example: Randomize occurences of X's in a text, ask to replace them by Y's, but make sure there is no find-replace command or wizard to help. * If you want to demonstrate the keyboard to be faster than the mouse, you can contrive an experiment to do so. Example: Ask to crack open your favourite Haskell textbook and enter it into the computer. Some of us raise that speed is not the only concern. Indeed, cognitive switch may be more taxing on the worker. However, going on a limb, I'm going to wager that: * If you want to demonstrate the mouse to be less taxing than the keyboard, you can probably contrive an experiment to do so. * If you want to demonstrate the keyboard to be less taxing than the mouse, you can probably contrive an experiment to do so. The keyboard-mouse duality (duelity?) doesn't end here. Some of us explains that keyboarding has become part of our motor skill, and mousing has not quite. So I ask, are there also people who are the opposite? One year I went to COMDEX Canada (in Toronto) and saw a live demo of Photoshop or something. The demonstrator was amazing. He clicked through the menu system faster than I could watch! He performed long sequences of back-to-back menu mousing at a sustained speed paralleling that of my keyboarding. You may say aha, Photoshop, analog! but no, in his demo analog operations were the minority, the majority was on the discrete menus - I do mean it when I say long sequences of back-to-back menu mousing. A possible objection would be that he practiced on his demo. But I do invite you to observe someone who uses Photoshop or the like professionally; you may see a level of mouse-fu you never thought possible. But all this musing on HCI and HCI research may all be just talking wind because: Michael T. Richter wrote: All this talk about efficiency while editing text would make me believe that most of my time spend writing software is typing. Yet, oddly enough, I find that the typing is the *least* of my tasks. Most of my work is done in my head, on whiteboards or on scraps of paper long before my fingers stroke a keyboard. Conventional wisdom would say: Then the priority is on improving the head, the whiteboard, and the paper. Give secondary priority to HCI and IDE dreams. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
Am 23.05.2007 um 00:20 schrieb Ashley Yakeley: I don't suppose you're familiar with the Dylan programming language, or more to the point, have looked at the IDE that Apple included in their original implementation of the language (around 1993 or so)? Characteristic of Apple of that time, the UI was both highly innovative and a joy to use. It was based around browsers, where each browser had a subject (such as a project, module, definition etc.) and an aspect (such as contents of, errors in, references to, direct methods of etc.). Browsers could be linked so that the selection in one browser became the subject in another. This made it very easy to navigate your project. All code was stored in a database rather than as text files, and individual code definitions were separate objects in the browsers rather than pieces of text in a big file. Info w/ screenshots: http://osteele.com/museum/apple-dylan http://wiki.opendylan.org/wiki/view.dsp?title=Apple%20Dylan Needless to say, this goes in rather the opposite UI direction to the Ctrl-M Ctrl-Meta-Z esc :edit qx approach to editors that some people prefer. Dylan's not a bad language, and there are open source implementations available for Gnu/Linux. But if you want to check out Apple's IDE, you'll really need a 68K Mac, as the PPC version is very buggy and I don't think the 68K version will run in PPC. Michael's blog: http://snakeratpig.blogspot.com/2007/02/road-to-haskell.html Dylan and Haskell are very similar in the multiple-dispatch (a haskeller would call that pattern matching on several arguments) respect. Cheers, Gabor PS: Btw, the Apple Dylan IDE works well on PPC if you apply a patch that was issued by Digitool shortly after the initial port of the IDE to PPC. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor (OT: keyboard mouse / one device + my 2 cents)
I did think about this topic many times. My conclusion: We need some other kind of interface (keyboard and mouse at the same time which would speed up your workflow very often, especially when doing some kind of graphics where you have to enter some text).. One solution I did find is http://www.combimouse.com/index.htm .. But I have'nt been able to afford this nice idea to test it. Another is one is http://www.jazzmutant.com/lemur_overview.php (too expensive to be buyed by me in the near future .. ) Another example is the iPod ... stop move the finger to on the surface to scroll play (or something like this), I don't have one. I totally agree that you can't say the one is faster than the other way. When I'm faster using the keyboard (Perhaps I only think I am? :) finding logout (find as you type firefox), because I can even reach the link if it's not in the visible area. Finding directories I use often (because I don't have to look at many files/ directories I'm not interested in.. Perhaps my visual perception is not as fast as the perception of others?) Compare using property editors with code (find property visibility in either alphabetical or sectioned).. Finding menus on Windows (Because the move very often if you install new software, work on foreign computers etc).. But that's why tools like lounchy (windows) exist. Moving Windows using wmii (althoug nifty windows for Win is very nice as well, but you have to take off your hands..) scrolling (using page down/ space / return application dependend) tying gimptab instead of (where the hell is that icon? Oh no it looks different because I have a newer version ..) using special commands such as goto previous cursor position... Opening files using glob patterns in vim (having mapped **/* (eg :e **/*some.hstabcr ) Opening most recent files having them listed in a buffer where I can use search. (compare this to File - Open - c:\MyProjects\. ) I'm faster using the mouse: navigating in directories I don't know.. (But often I use something like find | less to get an overview ) ... My friend is using the mouse most often. He is very fast. But Sometimes you can't get as fast as using the keyboard because you have to wait till the application pops up the window so that you see where to click. (Example: A lot of windows Dialogs (Eg change the PATH variable)) Anyway it would be really interesting to use 2 mice for some tasks. Then you can use one for scrolling and the other to click and drag. Or you can put both on menu items (where you think they'll pop up such as File - save) and click in sequence. But this havily depends on the application. Eg MS office (Not the new redisigned gui) is horrible because it does always hide the menu items I'm looking for (perhaps because I'm not using them very often or I don't know yet how to switch them off). Another horrible examples are tex editors wether you can click on buttons inserting \alpha \beta etc. Then you are switching between keyboard and mouse all the time. If the mouse is faster why does eclipse have so much opportunities to filter lists/ trees ? But I do know that I really like tools such as xfig / inckscape because they have the keyboard shortcuts I need (select tools/ view ..) And you are definitely faster using them using the mouse to select the tool and moving back. But of course you have to learn them. When watching my sister or my father using the mouse very often they simply click on the small triangle (step up / down) in scrollbars instead of PageUp/Down. But this is a kind of usage pattern which can be [ ] step page left move left improved by using scrolling (middle mouse button click), maximizing the window (Windows often doesn't permit this, eg when customizing menus or shortcuts (Visual Studio/ Word etc) before scrolling down a list etc.. I hope I didn't talk too much and that you have found some stuff in this post you didn't know already ... Marc PS: How would mouse gestures compare to keyboard shortcuts concerning the 2 seconds amnesia having been mentioned in article some posts ago? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Editor
it should also be noted that there are rsi issues with switching constantly between mouse and keyboard. moving to an environment that focuses on textual input (mutt+emacs+elinks on top of screen on top of xmonad) has allowed me to keep my hands in the ergonomic position dictated by my keyboard. for people with extreme-ergo keyboards (kinesis etc), keeping your fingers in position is important ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
