7 ms·

>And yes.... I'm a vim user. Yes, it was that obvious. But there are piles of UI design research studies that show modal interfaces are, in fact, bad. Object

>And yes.... I'm a vim user. Yes, it was that obvious. But there are piles of UI design research studies that show modal interfaces are, in fact, bad. Objectively bad. Measurably bad. I get sick of the vim apologists who try to claim that vim has a good UI. It is objectively, measurably, terrible. Granted, once you've learned it, you can be amazingly productive. But the power of a program is completely orthogonal to how good of a UI design it has; the latter pretty much has to include discoverability. In the words of one of the current foremost user interface design experts, a "good user interface shouldn't require instructions." (-- Donald Norman) I use vim when I'm doing editing on terminals. I'm not a vim expert, and I don't intend to ever become one. It's far more efficient to get my file locally and edit it in my flashy GUI editor if I have to do serious development on it, than it would be to become that level of expert at vim. And I'm basing this on the many stories I've heard, written by vim experts, about how much work it is to get good at vim. Continue to use vim, by all means; you've climbed the hill and you know it, so it will be more productive for you than anything I could point you at to compare it to. But please, please stop trying to claim it has a "good" user interface. Both vim and Emacs have interfaces designed before any serious work was done on human interface design, and like the microwaves and VCRs designed back then, their interfaces are measurably, objectively terrible. Modern editors can do 99% of what a 3+ year expert in vim can do, but you can get to that 99% in a month or less. Just because you had to spend three years of your life to get to your current level of productivity doesn't mean you should haze new developers the same way.

derleth 13y ago
> But there are piles of UI design research studies that show modal interfaces are, in fact, bad. Then how do Vim users work? If they're doing something that doesn't let them work, how do they work? Or is that not what you were saying? Then what the Hell were you saying, and how is it relevant?
- TheZenPsycho 13y ago
  It is fully possible for humans to adapt to terrible computer interfaces. That doesn't mean the interface is not terrible, it just means that humans are adaptable.
  - derleth 13y ago
    So humans who do that don't know their own minds? They're too stupid to know what a good UI for their style of thinking is?
Avshalom 13y ago
>But there are piles of UI design research studies that show modal interfaces are, in fact, bad. >Objectively bad. Measurably bad. Yeah but that's because modes are more or less tautologically defined to be bad. As long as there was a big blinking sign that said "normal" or "insert" vi(m) wouldn't be modal; see the raskin quotes elsewhere in the thread.
- TheZenPsycho 13y ago
  Incorrect- don't read quotes to get the meaning of what Raskin wrote. READ HIS BOOK. 1. Objectively bad not by definition, but by MEASUREMENT. and Experiment. Yes, UI quality can be objectively measured. Read the book. 2. That wouldn't fix VIM's problems. it would make them worse. READ THE BOOK.
  - aangjie 13y ago
    Am sorry, i just have to reply to this. Disclaimer: I use vim. Anti-disclaimer?: I spent two years studying cognitive science and one of my electives was HCI.(though i wasn't excited about it to be honest :P) By measurement of what? UI quality? what is it's operational/measurable definition. I suspect modes are unavoidable to deliver the kind of power vim does (over text editing )with only keystrokes. P.S: That said, i think it's a very sad thing that we can't have that joystick at the centre for the keyboard(in the home row, like in thinkpads) for all laptop keyboards.
    - TheZenPsycho 13y ago
      It's quite a simple matter to measure /rates of error/ in modal interfaces versus non-modal interfaces. This may seem trivial for text editors in particular, but modal errors are a big cause of aeronautical accidents (and deaths), so even one error is too many in that case. And if you can avoid errors in cases where they are life threatening, why wouldn't you want to avoid errors everywhere else?
      - aangjie 13y ago
JulianWasTaken 13y ago
> Modern editors can do 99% of what a 3+ year expert in vim can do, but you can get to that 99% in a month or less. Just because you had to spend three years of your life to get to your current level of productivity doesn't mean you should haze new developers the same way. I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.
- ehsanu1 13y ago
  Agreed. But though I'm a vim user, in day-to-day coding, my colleagues using say sublime don't see to suffer all that much. I occasionally see them doing something a bit inefficient with the mouse that could have been a few keystrokes in vim, but it's not that big of a deal really. Now, there are definitely a lot of things I could do in vim with macros and such that would be impossible to do efficiently in sublime. But I rarely have to do such complex text manipulation, so does it matter all that much? As far as scripting your editor, most IDEs have some sort of plugin system, which you may not use yourself, but you'd use to find something that already roughly does what you want. To be honest, that's pretty much what I personally do with vim myself, relying on others' vimscripts to get me the functionality I so crave, whether it be indentation-based text objects, or in-editor s-expression evaluation.
  - DennisP 13y ago
    I use vim macros frequently. It's not that I'm doing something complex, but that I'm doing something repetitive. Having such an easy way to create macros on the fly means that I never have to do repetitive editing. (How important that is depends on the language; in SQL, for example, it's a huge help.) :norm is a lesser-known trick that also helps quite a bit.
    - SomeCallMeTim 13y ago
      I use Visual Slickedit, Notepad++, and Visual Studio macros frequently. I typically map them to ctrl-f11 (record/stop recording) and ctrl-f12 (playback). In all three editors, I can just record, hit keys, stop, and playback (as many times as I hit the key). Notepad++ and Slickedit both offer you the option of binding the macro to a key more permanently too. As I mention in this other comment [1], vim and Emacs hardly have a corner on the macro market. :norm looks powerful, yes. But when I want to do something like that, I create a regex search that matches what I want and then record a macro that includes the "search next" key. Not quite as nice, because I have to keep hitting the "play macro" key, but gets me 95% of the way there. More complex (or numerous) transforms just become a script that I run on the file. But that's an extremely rare operation for me. For me it comes down to the fact that saving the 5 minutes to set up that script, once a year when I need something that complicated, would take a crazy long time to amortize over the three years it would take me to become that good at vim. [1] https://news.ycombinator.com/item?id=5696927 https://news.ycombinator.com/item?id=5696927
philwelch 13y ago
Only if you define "good" and "bad" user interfaces by discoverability. I would argue that Vim is a tool that explicitly trades off discoverability in favor of enhancing the productivity of an experienced user. And I would argue that in the case of Vim, this is a good tradeoff. It's not a good tradeoff for a microwave or VCR.
- SomeCallMeTim 13y ago
  No, that's only a piece of the puzzle. See my other comments in this thread.
subsection1h 13y ago
Both vim and Emacs have interfaces designed before any serious work was done on human interface design, and like the microwaves and VCRs designed back then, their interfaces are measurably, objectively terrible. How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus? Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me.
- SomeCallMeTim 13y ago
  >How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus? Off the top of my head, though my depth of knowledge of Emacs is almost more shallow than that of vim: 1. Discoverability. I had to reverse engineer Emacs' basic key commands, due to a complete lack of documentation on the first system I encountered an Emacs clone on; I was able to do it, but I have a considerably higher IQ than 120, thank you. 2. Key combinations are somewhat random. Some have mnemonics; most don't. Saying "change the keybindings, then!" is beyond the point; I'm talking about the editor UI as a new user would learn it, and by definition a new user doesn't know what keys things "should" be assigned to. 3. LISP, the write-only language. There's a reason the 1950s-designed language hasn't ever caught on. PG forgive me. Languages like Lua grant you 95% of the power of LISP, but are much more readable. And the last 5% is part of the cause of the readability problems of LISP. 4. Sometimes a mouse IS the right answer for some tasks. In an editor, this is MOSTLY not true, but when it is true, it's powerful. 5. Modern standard keybindings DO EXIST, and neither are supported by vim or Emacs out of the box. Ctrl-ZXCV, for example, will be expected by 99% of users to do the standard things. (If someone reading this is so Unix-centric they don't know: Undo/Cut/Copy/Paste.) Shift-arrows for selecting text. Shift-Control-Arrows for selecting word-at-a-time. Etc. Both Emacs and vim are (nominally) terminal-based, and you can't GET those key combos over a terminal. 6. Two-key combos that AREN'T shift keys for important commands (M-w). 'nuff said. >Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me. I already commented on my own IQ, and I find it to be an irrelevant comment. A better UI tends to be better for any IQ. Do you really want to be using your IQ to decode your UI, or would you rather not have to think about it and instead think about the problem at hand? I'm not talking about a dumbed-down, feature-poor UI. There are very few features anyone can point to in vim or Emacs that I haven't seen, typically way more easily accessible, in modern editors with decent UIs (I don't know of any with a really good UI, but most are better than their ancient ancestors, though I haven't done a complete survey recently, and so I should again). And remember, I already said this is mostly irrelevant if you already have learned vim or Emacs. You've put in the time, and suffered the pain of their steep learning curves. You're past the hard parts. Enjoy your editors; I'm not trying to get you to change what you use. To be honest, I'm not really interested in debating particulars. I'm sure you'll find SOMETHING to pick at in the list above; I know you CAN use cua-mode to get some basic standard control keys. But when a new user starts with Emacs, will they know to enable cua-mode? The killer for me is that LISP just makes my eyes bleed. I've used it (in college) to create research apps, but I never liked it.
eikenberry 13y ago
> "good user interface shouldn't require instructions." (-- Donald Norman) I assume you are taking Mr. Norman here out of context and vastly simplifying his position because the naive, simple reading of this statement makes him sound like an idiot. Humans require instructions for everything... "The only intuitive interface is the nipple. After that it's all learned." -- origin disputed
- SomeCallMeTim 13y ago
  Umm...he's clearly not an idiot. Check his CV if you don't believe me. But he does say that. There are two possible conclusions: 1. Despite all the evidence to the contrary, he is in fact an idiot. 2. I'm quoting him out of context. I took classes from him at UCSD. Maybe I didn't understand him. But maybe I did. 3. You don't know enough about his philosophy to understand what he means, but he really, really does mean that. Not "in context," but always. Now despite my respect for him, I think he does gloss over the power user UI when he says that. He has an entire book on how bad the Unix command line is, and yet there are some things I wouldn't want to use a GUI for. But I'm not a typical user; probably very few people on HN are. Think about the "Principle of Least Astonishment," though. [1] The more things that work as you expect, the better an API or language is, right? The same should be true of an editor. I know that in vim you can reuse your knowledge in many ways, but it's all restricted to the vim environment. You can hack that environment onto a command line; maybe even hack it into Firefox text entry boxes. But there are dozens of apps that won't have that ability, and you'll be handicapped in all of them. And there are millions of people who know how to use CUA keyboard shortcuts, and for them the PLA says to have the basic controls use CUA standards. [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...
taeric 13y ago
But see, here is the thing. I was not arguing for modes, per se. I was definitely not arguing for vim. Just had to acknowledge that I use it. I do think that quote is taking great liberties. The best user interfaces came with mentors. I would go so far as to argue that vim sucked for me, as I did not have anyone to ask for help. Indeed, I was a heavy eclipse/idea/various other user for a good 8 years before I really got into vim. Probably the only reason I did so was because I was a remote worker for a while with a connection too slow for any graphical forwarding. Then, eclipse went through a garbage period where it was too slow or just crashed a lot. (My understanding is that it has improved, greatly.) But, back to my argument. Modes are bloody everywhere. Want the car to go forward, put it in the correct mode for the accelerator to cause that to happen. Backwards? Similar. (And no, I'm not even talking about a manual transmission.) Consider cooking. Want to make an omelette? Well, start by heating the pan. Depending on the cooktop you have and the pan you have, this will take a differing amount of time. Then, add the ingredients. Make sure to add enough, but not too much, salt. Want to know how much is too much? Well, practice. Experiment. There is absolutely no indicator for this. Moving over to writing. Make sure you are holding the pen/pencil the correct way. And on the correct surface. (Anyone that thinks these are obvious things hasn't had to teach kids to draw on a piece of paper.) (This goes back to my "mentor" idea.) Now, move on over to music for a minute. What do you mean the instrument has to be in tune? And you typically have to use both hands? Often with a foot pedal? Clearly humanity should have given up on that endeaver years ago. (Do I need to even discuss sports?) Which brings me to what I think is my point. Modes are something that adds difficulty, for sure. But life is not about making all things easier. For many, that challenge can help add appreciation to what they accomplish. The goal is not to eliminate modes, but to make sure users can accomplish what they want. Mainly by addressing the majority case, not the fringe ones. "Changing the bass" setting of your car stereo is something 99.999% of the populace doesn't give a crap about. It is not that they wish to have no way to do it, they just don't care. Having the interface revert back to "change the station" after an interval of no use makes perfect sense in that regard. Why not bitch that your phone will revert to a "locked" state after a period of no use? You can argue that they just need a screen with more information on it, so they can change bass and station at the same time. Yet, my hypothesis would be that that is exactly backwards. Most people only want in front of them what they need to accomplish what they are doing.
derleth 13y ago
According to this, Vim isn't modal: > The definition of modes given by Jef Raskin in the Humane Interface (Page 42): >>"An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." > According to this definition an interface is not modal if the user is aware of the current mode at all times. https://news.ycombinator.com/item?id=5696227 https://news.ycombinator.com/item?id=5696227 But the real problem here is that the people citing to Raskin are trying to treat their opinions, which are no better (or worse) than mine, as objective fact, and claiming others are stupid for not instantly falling in line.

derleth 13y ago

> But there are piles of UI design research studies that show modal interfaces are, in fact, bad. Then how do Vim users work? If they're doing something that doesn't let them work, how do they work? Or is that not what you were saying? Then what the Hell were you saying, and how is it relevant?

TheZenPsycho 13y ago
It is fully possible for humans to adapt to terrible computer interfaces. That doesn't mean the interface is not terrible, it just means that humans are adaptable.
- derleth 13y ago
  So humans who do that don't know their own minds? They're too stupid to know what a good UI for their style of thinking is?

Avshalom 13y ago

>But there are piles of UI design research studies that show modal interfaces are, in fact, bad. >Objectively bad. Measurably bad. Yeah but that's because modes are more or less tautologically defined to be bad. As long as there was a big blinking sign that said "normal" or "insert" vi(m) wouldn't be modal; see the raskin quotes elsewhere in the thread.

TheZenPsycho 13y ago
Incorrect- don't read quotes to get the meaning of what Raskin wrote. READ HIS BOOK. 1. Objectively bad not by definition, but by MEASUREMENT. and Experiment. Yes, UI quality can be objectively measured. Read the book. 2. That wouldn't fix VIM's problems. it would make them worse. READ THE BOOK.
- aangjie 13y ago
  Am sorry, i just have to reply to this. Disclaimer: I use vim. Anti-disclaimer?: I spent two years studying cognitive science and one of my electives was HCI.(though i wasn't excited about it to be honest :P) By measurement of what? UI quality? what is it's operational/measurable definition. I suspect modes are unavoidable to deliver the kind of power vim does (over text editing )with only keystrokes. P.S: That said, i think it's a very sad thing that we can't have that joystick at the centre for the keyboard(in the home row, like in thinkpads) for all laptop keyboards.
  - TheZenPsycho 13y ago
    It's quite a simple matter to measure /rates of error/ in modal interfaces versus non-modal interfaces. This may seem trivial for text editors in particular, but modal errors are a big cause of aeronautical accidents (and deaths), so even one error is too many in that case. And if you can avoid errors in cases where they are life threatening, why wouldn't you want to avoid errors everywhere else?
    - aangjie 13y ago

JulianWasTaken 13y ago

> Modern editors can do 99% of what a 3+ year expert in vim can do, but you can get to that 99% in a month or less. Just because you had to spend three years of your life to get to your current level of productivity doesn't mean you should haze new developers the same way. I don't begin to believe this statement, not least of which because 99% of what you can do with vim or emacs is make vim or emacs do what you want by heavily scripting them. That eliminates most "modern editors" right off the bat.

ehsanu1 13y ago
Agreed. But though I'm a vim user, in day-to-day coding, my colleagues using say sublime don't see to suffer all that much. I occasionally see them doing something a bit inefficient with the mouse that could have been a few keystrokes in vim, but it's not that big of a deal really. Now, there are definitely a lot of things I could do in vim with macros and such that would be impossible to do efficiently in sublime. But I rarely have to do such complex text manipulation, so does it matter all that much? As far as scripting your editor, most IDEs have some sort of plugin system, which you may not use yourself, but you'd use to find something that already roughly does what you want. To be honest, that's pretty much what I personally do with vim myself, relying on others' vimscripts to get me the functionality I so crave, whether it be indentation-based text objects, or in-editor s-expression evaluation.
- DennisP 13y ago
  I use vim macros frequently. It's not that I'm doing something complex, but that I'm doing something repetitive. Having such an easy way to create macros on the fly means that I never have to do repetitive editing. (How important that is depends on the language; in SQL, for example, it's a huge help.) :norm is a lesser-known trick that also helps quite a bit.
  - SomeCallMeTim 13y ago
    I use Visual Slickedit, Notepad++, and Visual Studio macros frequently. I typically map them to ctrl-f11 (record/stop recording) and ctrl-f12 (playback). In all three editors, I can just record, hit keys, stop, and playback (as many times as I hit the key). Notepad++ and Slickedit both offer you the option of binding the macro to a key more permanently too. As I mention in this other comment [1], vim and Emacs hardly have a corner on the macro market. :norm looks powerful, yes. But when I want to do something like that, I create a regex search that matches what I want and then record a macro that includes the "search next" key. Not quite as nice, because I have to keep hitting the "play macro" key, but gets me 95% of the way there. More complex (or numerous) transforms just become a script that I run on the file. But that's an extremely rare operation for me. For me it comes down to the fact that saving the 5 minutes to set up that script, once a year when I need something that complicated, would take a crazy long time to amortize over the three years it would take me to become that good at vim. [1] https://news.ycombinator.com/item?id=5696927 https://news.ycombinator.com/item?id=5696927

philwelch 13y ago

Only if you define "good" and "bad" user interfaces by discoverability. I would argue that Vim is a tool that explicitly trades off discoverability in favor of enhancing the productivity of an experienced user. And I would argue that in the case of Vim, this is a good tradeoff. It's not a good tradeoff for a microwave or VCR.

SomeCallMeTim 13y ago
No, that's only a piece of the puzzle. See my other comments in this thread.

subsection1h 13y ago

Both vim and Emacs have interfaces designed before any serious work was done on human interface design, and like the microwaves and VCRs designed back then, their interfaces are measurably, objectively terrible. How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus? Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me.

SomeCallMeTim 13y ago
>How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus? Off the top of my head, though my depth of knowledge of Emacs is almost more shallow than that of vim: 1. Discoverability. I had to reverse engineer Emacs' basic key commands, due to a complete lack of documentation on the first system I encountered an Emacs clone on; I was able to do it, but I have a considerably higher IQ than 120, thank you. 2. Key combinations are somewhat random. Some have mnemonics; most don't. Saying "change the keybindings, then!" is beyond the point; I'm talking about the editor UI as a new user would learn it, and by definition a new user doesn't know what keys things "should" be assigned to. 3. LISP, the write-only language. There's a reason the 1950s-designed language hasn't ever caught on. PG forgive me. Languages like Lua grant you 95% of the power of LISP, but are much more readable. And the last 5% is part of the cause of the readability problems of LISP. 4. Sometimes a mouse IS the right answer for some tasks. In an editor, this is MOSTLY not true, but when it is true, it's powerful. 5. Modern standard keybindings DO EXIST, and neither are supported by vim or Emacs out of the box. Ctrl-ZXCV, for example, will be expected by 99% of users to do the standard things. (If someone reading this is so Unix-centric they don't know: Undo/Cut/Copy/Paste.) Shift-arrows for selecting text. Shift-Control-Arrows for selecting word-at-a-time. Etc. Both Emacs and vim are (nominally) terminal-based, and you can't GET those key combos over a terminal. 6. Two-key combos that AREN'T shift keys for important commands (M-w). 'nuff said. >Also, when we talk about "measurably, objectively terrible" interfaces, were the measurements made by researchers whose test subjects all had 120+ IQs? Those would be the only measurements that interest me. I already commented on my own IQ, and I find it to be an irrelevant comment. A better UI tends to be better for any IQ. Do you really want to be using your IQ to decode your UI, or would you rather not have to think about it and instead think about the problem at hand? I'm not talking about a dumbed-down, feature-poor UI. There are very few features anyone can point to in vim or Emacs that I haven't seen, typically way more easily accessible, in modern editors with decent UIs (I don't know of any with a really good UI, but most are better than their ancient ancestors, though I haven't done a complete survey recently, and so I should again). And remember, I already said this is mostly irrelevant if you already have learned vim or Emacs. You've put in the time, and suffered the pain of their steep learning curves. You're past the hard parts. Enjoy your editors; I'm not trying to get you to change what you use. To be honest, I'm not really interested in debating particulars. I'm sure you'll find SOMETHING to pick at in the list above; I know you CAN use cua-mode to get some basic standard control keys. But when a new user starts with Emacs, will they know to enable cua-mode? The killer for me is that LISP just makes my eyes bleed. I've used it (in college) to create research apps, but I never liked it.

eikenberry 13y ago

> "good user interface shouldn't require instructions." (-- Donald Norman) I assume you are taking Mr. Norman here out of context and vastly simplifying his position because the naive, simple reading of this statement makes him sound like an idiot. Humans require instructions for everything... "The only intuitive interface is the nipple. After that it's all learned." -- origin disputed

SomeCallMeTim 13y ago
Umm...he's clearly not an idiot. Check his CV if you don't believe me. But he does say that. There are two possible conclusions: 1. Despite all the evidence to the contrary, he is in fact an idiot. 2. I'm quoting him out of context. I took classes from him at UCSD. Maybe I didn't understand him. But maybe I did. 3. You don't know enough about his philosophy to understand what he means, but he really, really does mean that. Not "in context," but always. Now despite my respect for him, I think he does gloss over the power user UI when he says that. He has an entire book on how bad the Unix command line is, and yet there are some things I wouldn't want to use a GUI for. But I'm not a typical user; probably very few people on HN are. Think about the "Principle of Least Astonishment," though. [1] The more things that work as you expect, the better an API or language is, right? The same should be true of an editor. I know that in vim you can reuse your knowledge in many ways, but it's all restricted to the vim environment. You can hack that environment onto a command line; maybe even hack it into Firefox text entry boxes. But there are dozens of apps that won't have that ability, and you'll be handicapped in all of them. And there are millions of people who know how to use CUA keyboard shortcuts, and for them the PLA says to have the basic controls use CUA standards. [1] https://en.wikipedia.org/wiki/Principle_of_least_astonishment https://en.wikipedia.org/wiki/Principle_of_least_astonishmen...

taeric 13y ago

But see, here is the thing. I was not arguing for modes, per se. I was definitely not arguing for vim. Just had to acknowledge that I use it. I do think that quote is taking great liberties. The best user interfaces came with mentors. I would go so far as to argue that vim sucked for me, as I did not have anyone to ask for help. Indeed, I was a heavy eclipse/idea/various other user for a good 8 years before I really got into vim. Probably the only reason I did so was because I was a remote worker for a while with a connection too slow for any graphical forwarding. Then, eclipse went through a garbage period where it was too slow or just crashed a lot. (My understanding is that it has improved, greatly.) But, back to my argument. Modes are bloody everywhere. Want the car to go forward, put it in the correct mode for the accelerator to cause that to happen. Backwards? Similar. (And no, I'm not even talking about a manual transmission.) Consider cooking. Want to make an omelette? Well, start by heating the pan. Depending on the cooktop you have and the pan you have, this will take a differing amount of time. Then, add the ingredients. Make sure to add enough, but not too much, salt. Want to know how much is too much? Well, practice. Experiment. There is absolutely no indicator for this. Moving over to writing. Make sure you are holding the pen/pencil the correct way. And on the correct surface. (Anyone that thinks these are obvious things hasn't had to teach kids to draw on a piece of paper.) (This goes back to my "mentor" idea.) Now, move on over to music for a minute. What do you mean the instrument has to be in tune? And you typically have to use both hands? Often with a foot pedal? Clearly humanity should have given up on that endeaver years ago. (Do I need to even discuss sports?) Which brings me to what I think is my point. Modes are something that adds difficulty, for sure. But life is not about making all things easier. For many, that challenge can help add appreciation to what they accomplish. The goal is not to eliminate modes, but to make sure users can accomplish what they want. Mainly by addressing the majority case, not the fringe ones. "Changing the bass" setting of your car stereo is something 99.999% of the populace doesn't give a crap about. It is not that they wish to have no way to do it, they just don't care. Having the interface revert back to "change the station" after an interval of no use makes perfect sense in that regard. Why not bitch that your phone will revert to a "locked" state after a period of no use? You can argue that they just need a screen with more information on it, so they can change bass and station at the same time. Yet, my hypothesis would be that that is exactly backwards. Most people only want in front of them what they need to accomplish what they are doing.

derleth 13y ago

According to this, Vim isn't modal: > The definition of modes given by Jef Raskin in the Humane Interface (Page 42): >>"An human-machine interface is modal with respect to a given gesture when (1) the current state of the interface is not the user's locus of attention and (2) the interface will execute one among several different responses to the gesture, depending on the system's current state." > According to this definition an interface is not modal if the user is aware of the current mode at all times. https://news.ycombinator.com/item?id=5696227 https://news.ycombinator.com/item?id=5696227 But the real problem here is that the people citing to Raskin are trying to treat their opinions, which are no better (or worse) than mine, as objective fact, and claiming others are stupid for not instantly falling in line.