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

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.