[ACCEPTED]-Why are there so few modal-editors that aren't vi*?-vi
Early software was often modal, but usability 17 took a turn at some point, away from this 16 style.
VI-based editors are total enigmas 15 -- they're the only real surviving members 14 of that order of software.
Modes are a no-no 13 in usability and interaction design because 12 we humans are fickle mammals who cannot 11 be trusted to remember what mode the application 10 is in.
If you think you are in one "mode" when 9 you are actually in another, then all sorts 8 of badness can ensue. What you believe to 7 be a series of harmless keystrokes can (in 6 the wrong mode) cause unlimited catastrophe. This 5 is known as a "mode error".
To learn more, search 4 for the term "modeless" (and "usability")
As 3 mentioned in the comments below, a Modal 2 interface in the hands of an experienced 1 and non-fickle person can be extremely efficient.
Um... maybe there isn't much of a need for 3 one, given that Vi/Vim is pretty much available 2 everywhere and got the whole modal thing 1 right? :)
I think that it's because vi (and its ilk) already 11 occupies the ecological niche of modal editors.
The 10 number of people who prefer modal and haven't 9 yet been attracted to vi is probably 0, so 8 the hypothetical vi competitor would have 7 to be so great as to make a significant 6 number of vi users switch. This isn't likely. The 5 cost of switching editors is huge and the 4 vi-s are probably already as good as modal 3 editors go. Well, maybe a significant breakthrough 2 could improve upon them, but I find this 1 unlikely.
@Leon: Great answer.
@dbr: Modal editing 13 is something that takes a while to get used 12 to. If you were to build a new editor that 11 fits this paradigm, how would you improve 10 on VI/VIM/Emacs? I think that is, in part, an 9 answer to the question. Getting it "right" is 8 hard enough, competing agains the likes 7 of VI/VIM/Emacs would be extremely tough 6 -- most people who use these editors are 5 "die hard" fans, and you'd have to give 4 them a compelling reason to move to another 3 editor. Those people who don't use them 2 already are most likely going to stay in 1 a non-modal editor. IMHO of course ;)
Modal editors have the huge advantage to 6 touch typists that you can navigate around 5 the screen without taking your hands off 4 the home row. My wrists only hurt when 3 I'm doing stuff that requires me to move 2 my hand off the keyboard and onto the mouse 1 or arrow keys and back constantly.
Remember that Notepad is a modal editor!
To 9 see this, try typing E, D, I, T; now try typing 8 Alt, E, D, I, T. In the second case the Alt key 7 activates the "menu mode" so the results 6 are different. :oP People seem to cope 5 with that.
(Yes, this is a feature of Windows 4 rather than specifically of Notepad. I 3 think it's a bad feature because it is easy 2 to hit Alt by mistake and I don't think 1 you can turn it off.)
VIM and emacs make about as much user interface 5 design sense as qwerty. We now have available 4 modern computer optimized key layouts (see 3 the colemak layout and the carpalx project); it's 2 only a matter of time before someone does 1 the same for text editors.
I believe Eclipse has Vi bindings and there 2 is a Visual Studio plugin/extension, too 1 (which is called Vi-Emu, or something).
It's worth noting that the vi input models 10 survival is in part due it's adoption in 9 the POSIX standard, so investing time in 8 learning would mean your guarenteed to be 7 able to work on any system complying to 6 these standards. So, like English, theres 5 power in ubiquity.
As far as alternatives 4 go, I doubt an alternate model editor would 3 survive a 30 day free trial period, so its 2 the same reason more people drive automatics 1 than fly jets.
Since this is a question already at odds with the "no subjective issues" mantra, allow me to face that head on in kind.
Non-Modal editing seeks to solve the problem 16 caused by non-modal editing in the first 15 place.
Simply put, with Modal editing I can 14 do nearly everything without my hands leaving 13 the keyboard, and without even tormenting 12 my pinky with reaching for the control, or 11 interrupting my finger placement by hunting 10 for the arrow keys.
Reaching for mouse completely 9 interrupts the train of thought. I have 8 hated the intense reliance upon this with 7 Intellij IDEA and Netbeans for many years. Even 6 with vim-style addons.
Most of what you do 5 has to do with fine-tuning with very small 4 increments and changes within the same paragraph 3 of code. Move up, move over, change character, etc., etc. These 2 things are interrupted with control keys 1 and arrows and mouse.
Though not really answering your question, there 9 used to be a "modal like" way to write Japanese 8 on cell phones before : The first letter 7 you hit was a conson let's say K, and then, and 6 then the next key you would hit would have 5 the role of a conson. (Having two conson 4 in a row is impossible in Japanese)
Though 3 it was main a few years ago, today it's 2 only used by people who really want to hit 1 fast.
I recently came across divascheme - an alternative 13 set of key bindings for DrScheme. This is modal, and 12 part of the justification is to do with 11 RSI - specifically avoiding lots of wrist 10 twisting to hit Ctrl-Alt-Shift-something. The coder has done 9 an informal survey of fellow coders and 8 found that emacs users suffered from more 7 wrist pain than vi coders.
You can see him 6 doing a short talk at LugRadio Live USA. (The video is a series of 5 5 minute talks and I can't remember how 4 far through it is, sorry - if someone watches 3 it and posts that here I'll edit this post 2 to say when in the video it is).
Note I have 1 not used divascheme.
I think the answer to the question is actually 11 there are quite a few modal text editors 10 that aren't forks of vi/vim. However they all use the vi key bindings. Vi 9 users get the key bindings into their muscle 8 memory so relearning a different set of 7 key bindings would be really hard, so no-one 6 would create a different set of key bindings.
But 5 lots of different editors have re-implemented 4 the vi key bindings from scratch. Just look 3 at this question about IDEs with vi key bindings. At least half of the answers are editors 2 built from scratch that implement vi key 1 bindings, not versions of vi embedded.
The invention of the mouse took one mode and 28 moved it to an input device, and context 27 menus took another mode and moved it to 26 a button. Ironically, the advent of touch 25 devices has had the reverse effect, producing 24 multi-modal interfaces:
aware multi-modal - touch and 23 speech are aware of each other and intersect
unaware 22 multi-modal - touch and speech are unaware 21 of each other and conflict
The traditional 20 WIMP interfaces have the basic premise that 19 the information can flow in and out of the 18 system through a single channel or an event 17 stream. This event stream can be in the 16 form of input (mouse, keyboard etc) where 15 the user enters data to the system and expects 14 feedback in the form of output (voice, vibration, visual, etc) when 13 the system responds. But the channel maintains 12 its singularity and can process information 11 one source at a time. For example, in today’s 10 interaction, the computer ignores typed 9 information (through a keyboard) when a 8 mouse button is depressed.
This is very much 7 different from a multimodal interaction 6 where the system has multiple event streams 5 and channels and can process information 4 coming through various input modes acting 3 in parallel, such as those described above. For 2 example, in an IVR system a user can either 1 type or speak to navigate through the menu.
User Agent Accessibility Guidelines working group (UAWG): Keyboard Interface use cases
W3C Multimodal Standard Brings Web to More People, More Ways
Beyond Mouse and Keyboard: Expanding Design Considerations for Information Visualization Interactions - naturalinfovis_infovis2012.pdf
Multi-modal design: Gesture, Touch and Mobile devices...next big thing? | Experience Dynamics
More Related questions