Brad Myer's 1990 video "All The Widgets" demonstrates various implementations of selecting text [1], including Xerox PARC Bravo, Xerox PARC Smalltalk, Symbolics Dynamic Windows, Xerox STAR, Xerox Interlisp-D, Apple Macintosh, Xerox PARC Cedar, Xerox PARC Alternate Reality Kit, Xerox Viewpoint (multi-direction Arabic and Hebrew text), Microsoft Presentation Manager, Sun OPEN LOOK, NeXT NeXtStep, Open Software Foundation Motif, Digital Equipment Corporation DECWindows.
It also covers text entry [2], including SRI International NLS, Xerox XDE, Xerox Star, Apple Macintosh, Xerox PARC Cedar, Sun OPEN LOOK, Open Software Foundation Motif, Digital Equipment Corporation DECWindows.
In vi you can operate on N chars, words, lines etc. quite efficiently. Mouse based editing, at least beyond what you see on the screen, is more laborious and less accurate. Typing a regexp to find or replace, or moving to a specific location in the file is still modal in a mode less editor.
I've never been a vi expert, but I've gone for long enough periods using vi keybindings to have been fluent with them. I think there is some kind of emotional/flow/mastery element - it just feels good to acquire these kinds of skills.
I don't use vi keybindings now for a number of reasons. Not using them hasn't slowed me down (which may not mean much either way). But I do see the appeal.
The article mentions one facet of this: once you’ve mastered a modal interface, it can feel really fast. It may or may not actually be fast, but it feels fast, and that is a pleasant feeling.
I can definitely see that. Whereas doing something in vim requires multiple keybinds which may take a while to trigger, using mouse and some menu shortcut may take exactly the same amount of time. The shortcut version of vi just feels shorter because you’re doing something the whole time.
Comment 20671834 (by bakul) and 20671975 (by liability) make some good points. I also like vi. It is also why I made ZZTQED, being more modal than ZZT and KevEdit, and it also supports numeric command prefixes. I would also like it for TV/VCR, but, I have not seen such thing for a TV and VCR; many new ones don't even have numbered menus, and numbered menus are very advantageous.
I like [e]vi[l] because there is less to learn. In normal mode if you learn N movements and M actions, then you've actually learned N*M things, not N+M. That means a little bit of studying pays off huge.
Mode errors become easy to ignore at some point, but I actually noticed that I was definitely making a decent amount of mode errors for the first 2 years of my vi life.
I wouldn't be surprised if most people don't actually notice this, but I'm sure it happens.
Wow, what a fantastic article jam-packed with history!
Here is a collection of my notes and responses.
Line breaks indicate separate ideas.
---
- Ted Nelson would point out that word processor copy and paste misses the analogy to the real world cutting and pasting for posters that Tesler cites in this article in that the copy buffer can only contain one item and whenever another selection is made it silently loses the previous content. (The physical world cut and paste has the cut items still existing).
This is addressed in the box: "Objections to Modeless Editing and Cut/Copy-Paste" but the response is not satisfying.
> Objection 1. User mistakes. After performing a cut, the user might forget that important text was in what we now call the clipboard. She could lose it by cutting or copying something else without an intervening paste or undo.
> Response: The ability to do other things between cut and paste entails more benefits than risks.
> Response: A suitable undoing or versioning facility will allow recovery of accidentally deleted data.
The first response is too general, certainly there is a way to design separate cut/copy and paste functionality without this risk.
I have yet to use a word processor that has a "suitable undoing or versioning facility". This problem plagues each word processor I have ever seen used. It looks like Tesler overestimated the developers behind word processor applications that came after his on modern PCs. We have more still yet to learn from Gypsy than is represented in Microsoft Word (or google docs or apple word).
---
- Early text editors seemed to be a mess of keyboard playing, likely a result of the lack of screens when most were designed and so it makes sense that there needed to be a first invention of the cursor and interactive word processing that we now have thanks to Tesler and others. The cause doesn't matter, but it seems there is room for another transition as they have obsoleted their greatest pain points.
In the box "How Modes Degrade Usability" bullet 2:
> If unmodified letter keys are typed in command mode but the user things the system is in text mode, unintended and sometimes disastrous results ensue.
It seems that these mode errors should and have been obsoleted by interactive displays as your editor or application can maintain a visual indicator of the mode a user is in. It also seems that this issue would only effect novice users of a software and so shouldn't encourage us to avoid the use of modes when they might overall simplify the user experience.
Once taught about vim's command and insert mode, do users with a visual mode indicator make mode errors? That seems hard to believe.
I also see some other holes in the "NOMODES" philosophy in the dialog box as presented in this article:
> The typical dialog prevented the user from continuing work while it was open. That made it modal. But the widgets within the dialog could be operated in any order, making it locally modeless. And the mode escape was performed in a consistent way...
---
- It's fascinating to read the anecdote that:
> Jef Raskin, who was beginning work on a concept he called Macintosh, was skeptical about the mouse but generously offered suggestions and support.
because Jef Raskin went on to develop the Cannon Cat, and mouseless office and personal secretary computer which was unique for its "Leap" key functionality which allowed the user a press of a button to enable file wide text search to move its cursor.
---
- Doug Engelbart would contest the value of the idea that NLS was "hard". That powerful software should be full of features and becoming situated with them shouldn't "need" to be a simple task. Tesler gets into the fine points of number of key presses and the mental models behind having a copy paste buffer, but I don't think that Tesler's advances in this area should indicate a failure of NLS as a whole. It seems the two could have been reconciled, simplifying Engelbart's NLS control system by adopting Tesler's improvements and the methodology of his user studies.
---
A last mention: Tesler developed the Smalltalk Browser, and I cannot find the source now but there does exist some record of conversations within PARC about that development that are not what we might expect if we just think of this Browser as a code editor. The browser was (as stated in the article) a precursor to modern IDEs and was intended and used to edit code and text within Smalltalk, but it's origin story is more than that, including thought as to how non-programmers would access information in a computer system. The Smalltalk browser was designed as the browser for all text, not just code, within the personal computer.
There is so much more to go into here, this history is so very rich and still full of insights for us to learn from today.
> The first response is too general, certainly there is a way to design separate cut/copy and paste functionality without this risk.
Star had no clipboard; instead it had COPY and MOVE ‘modes’. The user made a selection, then invoked COPY or MOVE, and then (while the mouse cursor shows the pending operation) clicks on the destination. Presumably this is why Tesler called it ‘nearly modeless’, and presumably he thought this was worse than having invisible fragile state. One can however imagine a modeless variation, where invoking COPY or MOVE immediately performs the operation, targetting the current mouse position.
> Once taught about vim's command and insert mode, do users with a visual mode indicator make mode errors? That seems hard to believe.
I do it all the time. When you’re deep in flow, it’s easy to miss the mode indicator and accidentally trigger an unexpected result.
> because Jef Raskin went on to develop the Cannon Cat, and mouseless office and personal secretary computer which was unique for its "Leap" key functionality which allowed the user a press of a button to enable file wide text search to move its cursor.
Everything I’ve read about Raskin’s original vision for the Macintosh makes it sound much closer to the Cat than to the Mac the world eventually got: no GUI, keyboard-centric navigation, etc. The Mac turned out the way it did because Steve Jobs, after leading the failed Lisa project, ousted Raskin and turned the Mac into a kind of Lisa Jr.
> I do it all the time. When you’re deep in flow, it’s easy to miss the mode indicator and accidentally trigger an unexpected result.
Good point, I suppose I do as well. But I feel that my mode errors in vim have to do with anti-patterns (such as failing to hit esc after every insertion to make it easy, I should always be in Normal mode).
That's interesting to read about Raskin, I have forgotten some of his history, thank you for sharing. I wonder how many better usability ideas were lost in search of performance or the politics of appearance, it seems the list is endless.
[1] All The Widgets - Selecting Text: https://www.youtube.com/watch?v=9qtd8Hc90Hw&t=1h1m50s
It also covers text entry [2], including SRI International NLS, Xerox XDE, Xerox Star, Apple Macintosh, Xerox PARC Cedar, Sun OPEN LOOK, Open Software Foundation Motif, Digital Equipment Corporation DECWindows.
[2] All The Widgets - Basic Text Editing: https://www.youtube.com/watch?v=9qtd8Hc90Hw&t=1h13m33s