https://futureofcoding.org/ logo
Join SlackCommunities
Powered by
Larry Tesler and NOMODES > During Larry's time...
# thinking-together
k
Larry Tesler and NOMODES
During Larry's time in Xerox PARC there really wasn't such a thing as personal computers. At the time, software interfaces were designed around modes. In a text editor you couldn't just start typing and have words appear on the screen.. Larry pioneered the concept of software user studies, and found that many people would fail to get comfortable with the computer even after many weeks of use. And he believed that these modes were to blame, and they represented a threat to the dream of what personal computing could be.
So Larry made it his personal mission to eliminate modes from software. And he formed a principle. No person should ever be trapped in a mode. His slogan that he'd go around saying is, "don't mode me in." And his website is called: nomodes.com.
-- Bret Victor, 2012 (

https://www.youtube.com/watch?v=PUv66718DII▾

) I've been thinking about this a lot for a few weeks as I take my first hesitant steps into UI design and find myself immediately creating modal dialogs. What are people's opinions on the priority of modelessness relative to the other considerations we often discuss here? For example, my UI tries to follow a couple of other principles Bret Victor likes. It minimizes interaction and always shows the complete state at a glance (http://worrydream.com/MagicInk), and it tries to reduce the need for the human to "play computer". Following Christopher Alexander, it tries to keep the display fairly stable and slow-changing. But. It has modal dialogs. 3 so far and counting. Once you bring one up, it's like a database transaction and you have to either commit or roll back. My current thinking: it's ok if the time spent in a mode is short. A word seems short. It's not a huge hardship if you have to retype a word. Most of the time, words you type appear on screen. But I also notice that browsers used to bring up modal dialogs for say searching for a word on a page, and now they do so in a non-modal way where the panel pops up above or below the page while allowing you to interact with the page. I'm in text mode, so there's a fundamental limitation of only ever being able to interact where the cursor is. Perhaps that's the fundamental 'modefulness' here? I'm curious to hear what others think, and what stories people have about their experiences trying to avoid modes.
This thread was partly triggered by @Emmanuel Oga's recent thread on autocompletion wizards (https://futureofcoding.slack.com/archives/C5T9GPWFL/p1607263213204500). Autocompletion is typically a mode, but so lightweight we don't think of it as such. Turning it into a wizard definitely makes it much more obviously modal. Just something to think about.
e
the obvious huge counterpoint to "modes are bad" is vim, where everything is about modes. From the top of my head, it seems modes can be a great asset for the "advanced user" but could take a bit longer to get used to. Modes are so useful that even a lot of emacs users use them (evil mode). I have never related modal editing in vim to modal dialogs though, I guess there are points of contact but the experience seems pretty different.
➕ 1
h
one way i have been thinking about it is "the least restrictive UIs provide the highest possible branching factor from current state to next action"
❤️ 4
vim's command mode lets you do an incredible number of things very quickly after entering it, so while modal, it isn't super restrictive in terms of the order you have to trigger it in, or the facilities it exposes once in it. if vim had 4000 modes, each for each little operation, it'd be different because the user would have to spend a lot more time trying to figure out which mode to use
➕ 2
modal dialogs in UIs and especially wizards I think fall prey to that same issue, the user has to spend time figuring out how to trigger the right UI state to do the thing they actually want to do. "i know this button is somewhere but i have to figure out how to bring it up to press it" happens with modals sometimes
i think autocompletes are an interesting pattern too because they aren't completely modal, they only change what some of the interactions you could take do, not all of them. you could keep typing characters along your merry way and dismiss the autocomplete. In that sense you never experienced the other mode, it's only if you press an arrow key or enter or escape that you have ... experienced ... the mode. I think with those keys in particular we're super accustomed to their behaviour changing in different contexts so the friction may not be as obvious or painful as the kind Larry hated
so i agree with the idea that time-in-strange-modes being short is better, but maybe an added quality would be different modes should overlap as much as possible
💡 1
k
@Emmanuel Oga I actually had a few notes about Vim that I dropped on the editing floor 🙂 A few ways to work within a modal interface: * Make it obvious what mode is active. * Perfect undo/redo everywhere. * Add all the things to history. In Vim for example, you can start typing a command at the 
:
prompt, change your mind, hit 
Esc
and go back to other things, hit 
:
and hit up-arrow -- and find the command you typed in but never ran. You're right that modal dialogs aren't exactly the same thing as Vim's modes. I'd actually not connected the two until Bret Victor mentioned Vim above. It might have been some creative license, since Larry Tesler's work seems to mostly predate Bill Joy's creation of vi. So @Harry Brundage's over-arching framework of "how restrictive is your UI?" seems useful. @Harry Brundage While you're right that I don't usually think of autocomplete as a mode, I have little skirmishes with autocomplete in various apps on a near-daily basis, where the app gets in my way and I have to backspace out of what it 'helpfully' completed. So it does seem useful to think of it as a modal interface, because the errors happen when I'm not conscious of what mode I've suddenly gotten put into. Particularly in combination with overly sensitive multi-touch or palms accidentally touching the trackpad, patterns that have sadly gotten all too common. To me, "never autocomplete" feels like a useful corollary to "don't mode me in" that also overlaps with Christopher Alexander's principles of giving UIs a sense of stability. I was nodding along when you said, minimize restrictions. However, I think Vim has way too many modes: https://en.wikibooks.org/wiki/Learning_the_vi_Editor/Vim/Modes
h
because the errors happen when I'm not conscious of what mode I've suddenly gotten put into
Does that happen to you in traditional code editors? I totally know what you mean and I think you're right, if the implementation is actually interjecting content into the medium without you asking it to that's violating direct manipulation and surprising / uncomfortable. I haven't experienced that with code editors though, usually it shows a ghost or what have you until you confirm or select a different suggestion, which I like
However, I think Vim has way too many modes
I agree, I never invested enough time in learning all of them or find a need for the strange ones often enough to stay practiced in using them effectively
i am mostly just parroting principles from About Face too, they go into a lot of depth on modes and the difference between designing for beginners vs intermediates vs experts and what considerations apply when
💡 1
k
Does that happen to you in traditional code editors? I totally know what you mean and I think you're right, if the implementation is actually interjecting content into the medium without you asking it to that's violating direct manipulation and surprising / uncomfortable.
Totally. I never experience this with Vim anymore, because while there are lots of modes the transitions are well-defined and the rules don't keep changing over time. So while I take seriously when people say it's hard to learn, yeah, it doesn't affect me. Stable opt-in transitions does feel like a good principle to add to the list.
e
Let them flounder about in their "normal mode." Normal isn't good enough for me! I want exceptional, IDEAL, I want… glorious mode, that's what I want.
https://emacsconf.org/2020/talks/07/
😹 1
I honestly did not fully get the proposal but I think is related to your question. It seems to describe a way to "stack modes" such that modal editing can be more regular and require less time to learn.
j
The best treatment of modes that I can recommend in book form is The Humane Interface. Tesler's "NOMODES" was one of those cases where one makes the mantra a target toward which to strive, even if it is beyond achieving completely.
❤️ 3
k
e
Raskin may have been biased by his choice of computers:
😂 2
sorry, couldn't help it 😛
a
From what I recall of The Humane Interface, "modes" are defined such that they only count when the user's main attention is on something other than the fact that program is in a "mode". Vim's modes count because the user is looking at and thinking about the text. I'm not sure "modal" dialogs count, since it's pretty hard to be confused about whether your actions will be interpreted by the dialog or not (which is not to say I fully endorse their use; IMO they tend to be clumsy).
💡 2
💯 1
👍 1
d
@Kartik Agaram "You're right that modal dialogs aren't exactly the same thing as Vim's modes. I'd actually not connected the two until Bret Victor mentioned Vim above. It might have been some creative license, since Larry Tesler's work seems to mostly predate Bill Joy's creation of vi."
Bill Joy didn't invent modal editors. Tesler didn't like the modes in the Bravo editor at Xerox, so he invented the Gypsy editor, which was modeless.
👍 1
k
s
Modes in the broad sense are unavoidable so we have to figure out how to wrangle them. Even in non-modal text editors, if I open the File menu I'm now in a 'mini mode' where I can't just type what I want. If I open a command palette, that's another mini mode. Dialog boxes are no different. Ted Nelson observed in one of his talks something to the effect of "applications are the ultimate mode" - talking about how each application is a mode in itself. The Photoshop mode on my computer works very different from the gmail mode, etc.
🤔 1
💯 1
w
The best demodifying I've seen is in the Civilization series of games. At the start of your turn, a bunch of things request your attention, "Okay, boss, what do I do now?" Originally, it was one modal dialog after another. A decision might require looking at the state of the map — unavailable since the mode had hijacked the UI. Late in the game at dozens of modal windows would show up before you could check, so you might adopt the strategy of making a silly choice as a signifier that you need to come back to it. In the latest Civ games (can't recall when exactly), instead of the modal hijack, you get a to-do list at the start of every turn. When you're good and ready you can pick an item, and if after looking you decide you weren't as good and ready as you thought, you can escape and look around more.
👍 3
Even when relatively small, modal forms can get in the way of you seeing what you need in order to fill the form. Consider find and replace. Sometimes you may think, "I want to do a find and replace action." You bring up the window/panel/tab, and it turn out the next thing you actually need to do is go hunt for the precise thing that you want to find.
a
"Applications are the ultimate mode": very true, and aptly explains why Raskin didn't really like applications. :D
k
The debate about modes has been going on for decades, but I have never managed to take sides. There are good and bad user interfaces (judging by experience) in both the modal and non-modal camps. Perhaps modes as such are not the fundamental criterion? Perhaps they are just the visible symptom of something else?
👍 1
h
@Kartik Agaram i think the autocomplete example falls into Raskin's category of "quasimodes" (hat tip Mr Rusher) , which are modes that a user knows that they are for sure in
Raskin advocates either getting rid of [modes] entirely or using "quasimodes" (a term he invented in the book); a quasimode is a state in which the user must make some constant physical action in order to keep the computer in that state, so that they cannot forget that they are in that mode; an example is the keyboard's shift key.
i think that the panel that pops up right below your cursor is a pretty darn obvious indicator that you've entered a different mode
j
@Harry Brundage Raskin was a bit more extreme than that. There were a pair of buttons on the Canon Cat called "Leap keys" that one could hold down while typing to incrementally search (one for forward, one for backward!). The idea was that you would develop an internalized physical pattern -- muscle memory, basically -- for this action that would result in increased fluidity with the interface.
h
that's awesome, i bet Raskin would have been a great organ player, sheesh
(because of all the foot pedals)
s
I'm slightly confused about what "modes" means in modern GUIs. The story about Tesler I always thought was about global modes in applications at the time, more towards the vim kind. To me it seems concepts like progressive disclosure and context sensitivity have replaced the need for global modes in complex modern GUIs, and the discussion of how these are somehow still related to modes seems somewhat moot to me, as I don't think they have much to with it…? For instance, I'm having a hard time understanding how an auto-completion overlay menu is related to modes. Am I missing something?
k
Probably not. This thread is showing me that I was conflating there.
👍 1
h
there's still some pretty modal modern GUIs if you ask me, like the tools palettes in Photoshop or AutoCAD or what have you. You have the cropping tool/mode, the brush tool/mode, the redeye correction tool/mode etc
p
there is a pretty sweet video about leap / cat on YT, if anyone is in quasi-modeless mood:

https://www.youtube.com/watch?v=o_TlE_U_X3c▾

👍 2
d
@Kartik Agaram The Humane Interface book is available at archive.org. I just read recently about the history of the autocomplete feature in the iPhone in Creative Selection. Turns out that autocorrect helps with a hardware constraint: keys in the original iPhone touch keyboard were too small for typing without making errors.
6 Views
Open in Slack
PreviousNext
Powered by