Modes in UI are bad; even worse are timed modes
ilyabirman.net
ilyabirman.net
Of course, this is essentially true of the entire god damned computer experience. Knowing what programs, or modes, available is not an easy task for many to undertake.
To think that you can simplify your model of computers to the point that you can eliminate modes is to simplify your model to the point that it is useless for a great many things.
And to think that timed modes is bad misses an essential point. The vast majority of users do not want to be in these extra modes. Returning to a "default covers 99.999% of the users" is far from a bad thing. Of course, the first lesson many should be taught, but aren't, is not how to find these modes. Rather, it is how to completely reset the system to defaults.
And yes.... I'm a vim user.
> In Raskin's sense and according to his definition, an interface is not modal as long as the user is fully aware of its current state.
Given this definition, eliminating modes is as simple as making sure that the user is aware of what mode they are in at all times. This makes your assertion problematic:
> To think that you can simplify your model of computers to the point that you can eliminate modes is to simplify your model to the point that it is useless for a great many things.
I don't think you would argue against the notion that users should be made aware of what mode they are in. A pretty common example comes from the CSS `cursor` property:
- If its `default`, clicking should have no effect
- If its `pointer`, clicking should have an effect
- If its `move`, clicking and dragging should have an effect
These cues are far from useless and help transition a modal interface into a modeless one.
Think of your currently active app on a mobile device. It's a mode. But if you're in Chrome, you will not accidentally open a link instead of drawing a line because you thought you were in SketchBookX.
The problem with modes is that you are not constantly aware of
the current mode, which leads to errors: you want to draw a line,
but accidentally create a gradient fill.
I definitely agree with Ilya on his assertion that modal interfaces are bad news when other factors of the situation require you to not pay attention to the interface, for example a car's computer or a mobile phone. I find it incredibly frustrating when the interface I'm forced to use is giving me shit, because it jeopardizes my safety while driving. I've learned over the years when to just "put it down", and to always have backup CD music in my car in case my lovely iPhone which can play any track ever made (if I have a decent LTE connection) decides that it's just not going to do that today. In most situations, it seems that a modal or even timed-modal user interface is not what you want, and certainly not the most efficient use of brainpower for your device.
On the other hand, given that someone is aware of his mode at all times, modal interfaces do give an extraordinary level of efficiency to even simple interfaces. Ilya's "TV Remote" analogy is a perfect example of this. A remote isn't something you need to use while in motion, nor is it typically something that is lunged for, grabbed, and acted upon very quickly as a response to something insane happening around you (like a gun, for example). I think it would be preferred to have a remote with less buttons and more modes, with very clear ways of knowing which mode you're in. The vim-powerline plugin (for my favorite text editor) is a perfect example of this, I can know what mode I'm in simply by being aware of the color of the bottom bar in Vim. It would require devices with far less complexity, instead of needing a dedicated control for each and every action you take.
I think Native Instruments' MASCHINE, a groovebox and hardware/software production studio, does a very good job with this. There are few times, except early on, where you are unaware of which mode you are in. It was designed for live performance as well as home studio usage, so its interface is very simple, yet very complex at the same time. It has dedicated controls for parts of the song that always need to be adjustable (for example, volume/tempo/swing control), and defaults to "performance mode" where the easiest thing to do right off the bat is start banging out beats or melodies. There are other "edit modes" which let you write new parts in a step sequencer, record live beat mashing or sample-fuckery, and adjust effect processing for damn near everything, but access to these modes require a level of "intent", wherein you need to definitely know you're in that mode. It's also very easy to see when you're in a given mode, because the dual LCD interface is so simple that it's very easy to tell that you're in the wrong place.
Wow, that was a lot. Sorry if it's a big mash of paragraphs but I really am fascinated with UI and UX creation.
>"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.
I am a vim user and have developed a habit of only ever being in insert mode when I am typing, after each unit of input I return to command mode. Using this approach modal error is very minimal.
I then remap away all the modes that cause me issues (record mode is a common cause of modal-error for me).
I'm in HN tab right now, that's a mode.
I'm editing a textarea, that's a mode.
All these are legitimate "modes" in the sense they dictate what happens next when I type or click. The real advice is to be mindful of modes and make users aware of which mode(s) they're in. Sometimes they help, sometimes they don't.
I'm using Debian right now (to run Chrome), that's a mode.
I'm using Xen right now (to run Debian), that's a mode.
And yes, these are captive, modal systems. But from a UI point we have to take some strata as granted, as operating system level. Yes, perhaps Debian is a modal interface, whether it's hosting Xorg or Mir or Wayland or KMSCon or ssh sessions. But these are host environments for the proper interface, and so is gdm or slim or lightdm running my X session, and so is openbox or kde or gnome-shell or awesome running my wm, and so is chrome running my browser.
These are all concatenative contexts providing strata for the application. They are modal systems, but notably every one of them exists to provide an amodal system for the host of services running underneath it. Amodality still has to derive functionality from some greater level, so the distinction I think your not encompassing is one of composition versus aggregation.
In composition something owns and dictates the interface.
In aggregation things contribute to available interface options.
If I wanted to, I could have a media player running and control it via global hotkeys. If I wanted to, I could open multiple chrome windows. If I wanted to, I could open multiple tabs perhaps across multiple windows (Awesome powers activate). If I had multi-pointer-X and a good browser I could edit multiple text boxes.
In contrast, when we talk about modal UI the discussion is around UI that captures the context. It locks out other modes of operations. Modal systems do not provide aggregate strata into sub-systems running under them, they lock out other sub-system from running. Amodal systems contribute capabilities to users.
I'd like to find a way to loop back around and describe MDI as contextual without being modal (on the grounds that it's the same mode repeated), but I don't think I have sufficient argumentation to press that far ahead. I feel on firmer grounds taking issue with your characterization of what really is modal by standing on the aggregation versus composition point, and by highlighting the concatenative nature of the systems you describe.
Yeah that's why sometimes when I hit Tab in a text box I'm momentarily confused because my cursor disappears. Sometimes I want a hard tab. Modes mean I can't use my muscle memory, which means I have to be "mindful" which sucks.
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.
>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.
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.
Vim definitely sucks when you start, especially in terms of discoverability. You have to learn by either reading the colossal manual, or (as most do) using bits and pieces from external sources. But once you learn enough and gain the muscle memory and understanding of how to use the different modes best (eg in vim's case, normal should be your default state), it becomes wonderful to use.
here are some http://en.wikipedia.org/wiki/GOMS http://en.wikipedia.org/wiki/Fittss_law
Regarding modes, I encourage you to read this 1973 study, which spawned the first modeless text editor.
http://www.nomodes.com/Larry_Tesler_Consulting/1973_User_Stu...
I wish I had ready access to the piles of studies that show modal interfaces are bad. I trust they exist. I just haven't seen them myself!
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.
And if you can avoid errors in cases where they are life threatening, why wouldn't you want to avoid errors everywhere else?
I suppose that's not what everyone wants and in the examples the OP gives he has a point.I agree completely on the car audio part, not sure about photoshop(not much experience designing), but have some frustrating experiences with photoshop to suspect he's right.
Also you know, Raskin invented quite a lot of things you've probably never complained about. Like click and drag to select text, dragging and dropping of icons. double clicking. UNDO.
All idiotic ideas.
> UNDO.
An obvious invention. Not one requiring much thought, only the resources to implement it.
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.
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.
:norm is a lesser-known trick that also helps quite a bit.
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.
FirstName MiddleName LastName
converted to:
a.FirstName = b.FirstName, a.MiddleName = b.MiddleName, a.LastName = b.LastName,
To do 20 iterations of that, you can hit qw, do the first with the same commands you use all day, stop recording and hit 19@w for the rest. The whole thing flows into your normal editing so easily you barely think about it. You build macros as you go for tiny little repetitive actions that aren't worth the bother to write a script for, or that you may never use again. I don't bother saving my macros, and I've barely touched vimscript.
I wouldn't say it takes anywhere near three years to learn that either, more like six months. After a week or two you stop going insane, and have basic Notepad-level competence. Then you just gradually add keystrokes, and each one makes you a little more productive.
I don't get the "repeat count" functionality that I know comes for free in vim, but at the same time, I rarely know HOW many lines I need to apply a macro to, and so just letting key-repeat take over until I'm almost done works for me. There are also times when the macro works on blocks of text, but there are occasional line breaks that would break the macro, and repeating until I get to a line break, skipping it, and then proceeding is easy.
When I AM in vim and I need to, for example, delete some large number of lines, I find myself trying to guess how many lines, but guess on the small size. Then I guess again, until I get close enough to see the exact number.
I probably should use "visual" mode more often for that particular task, but the point is that being able to repeat a macro an exact number of times is (for me) LESS useful than just being able to use key-repeat at 10/second until the task is done.
That's my biggest issue using vim, the need to count lines before every operation. I keep getting the feeling I'm doing something wrong when I do that. Sometimes I just break down and use visual selection mode to select the text and delete the whole group, much like I'd do in another editor.
Is there something I'm missing about having to count before doing operations in vim?
There's a lot of alternatives depending on what you're counting. If you're deleting a block of lines say, usually it's not just some random block, and so usually you want some more targeted motion. Like e.g. d} or d[m for an exotic example. Or d/stuff if you're lazy, like I often am.
There's also `relativenumber` for when you really do need to count, but I'm ambivalent on whether I like it.
And sometimes you just want `.`. It's dirty, but sometimes it's quicker. I like to basically always be typing every time I have a goal in mind. So I never want to be thinking really for too long once I've decided where I want to get. So I'll do dw... once in awhile.
So yeah, it depends.
:set relativenumber
1. find the last line of the block you want to operate on
2. see the number you need to use
3. use that number
Motions and text-objects are very useful as well:
dip
da{
d{
d/foo
d?bar
d'a
d]m
…Every single "modern editor" I'm talking about is scriptable, and they're scriptable in languages that are easier to code in than vimscript (which is infamously awful) or Lisp. Some are even scriptable in positively awesome languages.
Not sure what "modern editor" you're talking about. See:
Notepad++:
http://sourceforge.net/p/notepad-plus/discussion/1290590
Visual Studio: You can record a macro and get code that you can then edit, adding loops and logic and such, and then play back the macro. Or you can extend it in an arbitrary way:
http://msdn.microsoft.com/en-us/vstudio/ff718165.aspx
Visual Slickedit: Half of the app is written in its own custom C-like scripting language. Similar to Visual Studio, you can record a macro and edit the resulting source code, so you don't have to guess how to start creating a script.
TextAdept: Scriptable in Lua.
TextMate: "Plug-able Through Your Favorite Scripting Language"
Sublime Text: "Sublime Text has a powerful, Python based plugin API. Along with the API, it comes with a built in Python console to interactively experiment in real time." -- This one I haven't used, so I can't be CERTAIN that you can write-and-use scripts immediately and trivially, but it certainly sounds like it.
NEdit: "NEdit is extensible through a C-like macro language"
https://en.wikipedia.org/wiki/NEdit
SCIte: "In addition, the Lua programming language is embedded in SciTE, allowing the user further customization. One can write Lua scripts that have access to the contents of the buffer and the Scintilla API."
https://en.wikipedia.org/wiki/SciTE
I've been clicking on random ones in the WikiPedia article on text editors [1], and except for the editors that "come with the OS" (Notepad, etc.), every one I checked had scripting. I actually clicked on SciTE to give a counter-example, since SciTE is mostly a proof-of-concept for the Scintilla editor library.
I would have to say, given the ubiquity of scripting languages in editors, that you haven't LOOKED for scripting in other editors. Which is FINE, but You Do Not Know Of What You Speak (TM).
Even if you can point to some that don't have scripting, it doesn't matter. Plenty do, and scripting is important to me as well. The crucial thing for me is the ability to quickly record and play back a macro; I wouldn't use any editor long term without that feature.
You really can't win this argument. I've traded blows with many extremely experienced vim users, and for every transform that's easier in vim than in another editor, I can come up with three more transforms easier in one or more editors I know. And the real win of using a modern editor is that the core keys (arrows, shift-arrow to select, control-arrow to jump by word, etc.) also work in thousands of other GUI apps, so you don't have to mode shift to be reasonably productive in a Firefox text box, for example.
That's key to how I work. In a typical day I jump around between Komodo, IntelliJ IDEA, Visual Studio, UltraEdit, XML Marker, MarkdownPad, Araxis Merge, Word, Google Docs, Notepad, Evernote, and a few other editors. Thank goodness basic editing works the same in all of them!
Quite often I'll have the same file open in more than one editor and do some of my editing in one and some in another. I can save changes in one of the editors, switch to another, and it loads my changes and I pick up right from where I left off in the other editor.
Why would I do this crazy thing? One example: if I've got a file open in Komodo or IDEA or whatever and I'm ready to commit it, I always diff it first in Araxis Merge. I'm likely to make some final changes to the file at that point. (Left in a console.log, anyone?) I can make those changes in Araxis or in the other editor I'm working in - and it doesn't matter which, they both work the same and pick up each other's changes.
So, I don't have to take sides in any editor wars: I use a bunch of 'em! :-)
To add to your scripting list, Komodo is scriptable in Python and JavaScript, with a pretty thorough object model you can use from either language.
This is akin to arguing that someone should consider switching to non-stick pans for all of their cooking. Because, think of all the time wasted cleaning a pan. Well... for experienced cooks, this really isn't any time that needs saving.
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?
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.
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.
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.
Utterly wrong, which discredits a lot of the other things you said. In particular, it discredits any claim you have to objectivity.
Hey, I have opinions, too. I don't claim they're objective fact, which you do.
> I'm not talking about a dumbed-down, feature-poor UI.
Yes, you are.
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
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_astonishmen...
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.
There's no question that you need to be aware of the state of the world. The position of a pen isn't an interface; the pen itself isn't modal. The "interface" to a pan is its handle. The "tuning" of an instrument isn't an interface; the strings are (the mode of a synth makes it modal, certainly, but I'll get to that).
There are some interfaces that are easily mapped by humans, though. The forward/reverse setting in a car is one of them. I don't doubt that many accidents have been caused by that modal interface, but it's still better than any other interface for that task than any other I can think of. You don't WANT the user to be able to just start driving backward without going through a specific (non-normal-driving) action to put the car into that mode.
The keyboard example is the same: A modal interface that makes sense. You have limited resources there: Most musicians can't afford to have a separate keyboard for every sound they want a synth to make.
Even Photoshop is a "necessary" kind of modal interface, because Photoshop isn't representing a user doing a single task: Photoshop is a simulation of dozens of potential "brushes" or effects, and it's far more economical to use the same interface (the left mouse button) to control them all.
It's all about cognitive mapping: A good UI for a stove has the controls arranged in the same physical orientation as the burners. Four burners in a square? Four controls in a square. No instructions necessary (to anyone with even a rudimentary idea of how stoves work).
Editors are an amusing example, because they come up a lot. But, for many, getting the computer to the damned editor is enough of a mode change that it is hard to do.
With GUI applications, the march lately has been to hide as many of the "buttons" as possible. Which is not really doable while still adding buttons. This is the same problem as faced by car interface designers. Even the iPod did this. "Spinning" back then was either selection or volume control, you know, depending on the mode. :)
So, yes, I agree excessive modes are bad. I even agree that vim is a bad interface for most folks. (Most being everyone else I know that uses a computer, honestly.) I disagree that "modes are bad" is at all a useful mantra by itself. It is only helpful when you take all of the other context into consideration, as well.
That make sense? (As far as the "better" interface for a car, this one is easy to imagine. Come up with an interface where you really just tell the car what it is you are wanting to do. "Take me to the store." "Pick up my daughter from school." ...)
> 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
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.
I think vim's strength is not being modal. Its strength is having less modes than other editors.
That said, I'm not sure I'm prepared to categorically dismiss modes in interfaces. Photoshop is an interesting example where I actually think the moded interface is helpful, given that the interface makes it clear what mode is active right now.
Another example that may divide readers of this humble comment is vim, where some may argue that its mode-based interface is core to its strengths.
In regards to the TV remote I don't see why buttons should be dedicated to functions that you are not going to use 99% of the time. Personally I'd prefer a smaller remote because I'm not going to be wanting to change the aspect ratio every half an hour.
Also who adjusts the Bass EQ while waiting at a traffic light anyway? You're most likely in the minority if you adjust the EQ on your car stereo at all, let alone adjusting it so often you find yourself trying to adjust it while at a traffic light.
I think really it comes down to simplicity. Sure, the user might, once, when setting up their TV get annoyed that the settings disappeared while they were trying to alter something but I'd much rather have a more convenient and simpler remote then having a billion buttons on it for every single possible operation. Plus I'm sure many of us have experienced the classic "I pressed some unknown button on the remote now x has screwed up" from family/friends who are less technically inclined.
With the TV remote however, I'd flip it around and say that realistically, you are going to be using the volume and channel controls 99% of the time, and so it does not make sense to change the functionality of those buttons depending on context.
So by extension we're required to clutter the interface with dedicated buttons that are used 1% or less of the time, just to make sure the user isn't confused? Sounds confusing.
A quasimode is a mode that is active only as long as a particular key is being held down. The pressure of the key on the user's finger is what makes the user constantly aware of the mode.
Caps-lock is a mode. The shift-key is the quasimodal version of that same function.
quite a lot of photoshops toolbar buttons are assigned keys already. M for marquee for instance. Modal keys. like caps-lock. Those modal keys could be switched to quasimodal keys that act essentially like extra mouse keys.
Photoshop already has 3 modal quasi-modal "modifiers" keys, in shift, alt, and (command/control), whose quasi mode changes depending on which mode you are in. So imaging a modeless photoshop where each tool and function is invoked by holding down a chord on the keyboard. Ta-da. Modeless photoshop.
Of course, Such a photoshop would be much more difficult to learn-as we are sacrificing discoverability. but it it would be easier to use for an expert.
and discoverability could probably be recovered using another of raskin's ideas: an dynamic displayed list of commands. Say you hold down the "m" key, and it lists in large type on screen what function that is, and what other keys you can hold down to modify it, and what functions those do.
This would be pretty awesome. But it will never happen because grumpy coders like vim and think it's great, and thus stand in the way of UI progress.
At the moment, Photoshop is difficult to use, but has thousands of features (I have no idea exactly how many) that presumably professionals make use of, at least to some degree or another.
Try making a modeless version of Photoshop like you describe and most people would have to look up the key combination before doing anything, at least until they've learned all the modifier keys (which sounds remarkably like emacs). Not exactly the paragon of usability.
As with almost everything, UI is a tradeoff between several different factors. In the case of modes, the applications that people like them in tend to be used by professionals or experts for a very specific purpose. In such a case, the utility, power and expressiveness is much more important than the initial ease of use.
If your aim is to create something that doesn't have thousands of features and should be usability immediately (or relatively so) by new users, then modes are likely a bad idea; if your aim is to create something powerful for experts who will be using it 8 hours a day for the next 5 years, modes may be worth considering.
On its own, chords would hurt discoverability. But as I wrote originally, discoverability can be restored using another of raskin's ideas, a dynamic style of command line demonstrated by his son Aza in the Ubiquity and Enso projects, and also present in the Sublime Text 2 text editor (called the command palette there)-- In essence, if your program has thousands of features, then make them invokable from an efficient specialised search engine. If we are using chords, make the available chords discoverable and visible in the UI.
You can entirely avoid modes AND have an efficient and powerful interface for experts to use day in and day out. They are not opposing forces.
Yammer yammer yammer namedropping and proselytizing buzzwords like gospel.
Modal interfaces are bad? Man, what the hell does modal interface even mean anymore? Like when I'm drawing vectors and my cursor changes to a selection tool instead of an "add point tool" when I hover over an existing point. That's bad now? Even though it's really annoying to create a duplicate points in a small area?
Restricting functionality to a relevant subset of behaviours based on the task you're doing can be a great idea. Yes, it can also be annoying. E.g. in the case of file explorers that don't let me create folders when I'm opening a file.
But that's just it. Spend some time thinking about how people interact with your application rather than making some thoughtless generalization. Otherwise you get Metro.
Please do you us all a favor, I beg of you, read "The Humane Interface" by Jef Raskin, and have an open mind about it. Actually read it. If you've done that, and still disagree that modes are bad, you're going to have to give a really good reason. With evidence.
Isn't he the one who thought configurability was always bad?
> You guys stand in the way of UI progress.
And here we go. You think we're so stupid that we can't know what's best for us, and need to be condescended to by someone who has no idea of what our workflow is like but Knows Better because he's... what? An Expert?
You guys stand in the way of UI progress.
Of course if you aren't interested, perhaps you are better off with a vt100 using VIM while modemed into a unix system V mainframe?
Thoroughly debunked. The fact you keep citing to it shows the depth of your ignorance.
Now do your own research instead of citing to debunked nonsense.
What does this is an explosion of possibilities with limited input capabilities. This is a dual with the other rule of "do not overload users." To fix the car example, dedicated bass controls can be used. Of course, most folks don't want that control. It "confuses" them. So... what do you do?
It all depends on how complex the UI has to be. As long as you don't punish a user by making the same button do something "irreversible" or do something which takes a fair amount of effort to undo ("fair amount" is relative here) then modes can be very useful.
Also, Photoshop is a prime example of a piece of software that's been around for over a decade, and has grown to such an extend that it's probably impossible to not have modes.
Modes are a great way to expand a UI. You just have to be very careful that ctrl+z doesn't turn into "quit without saving". They're one of those tools that every UI/UX person should have in their pocket, to pull out - at the right time.
As for timed modes; I reckon it's all about feedback. Letting someone know what's happening, what's going to happen, and when it will happen.
In my opinion, you can't make a blanket statement like "Modes in UI are bad". It depends entirely on context.
"... who made it his personal crusade to “eliminate modes from software design” during his work on the early desktop user interface at Xerox PARC. The cause became so central to his life that his license plate read “NO MODES”, and he reportedly wore the slogan “Don’t Mode Me In” on a t-shirt."
Bad mode: I use an awesome car service when I'm in Seattle called Car2Go. They have a really bad touch screen in the car. Pushing the physical volume button only turns off the radio if the touch screen is in radio mode. If you're in navigation mode, it mutes the volume of the turn-by-turn directions. It's distracting and confusing at the worst possible time.
Good mode: The Apple TV remote is so simple. It's just four arrows and a select button. The arrows may change your selection, fast forward, or change volume all depending on what mode the software is in. It's so natural, you don't even think of it as a "mode" -- it just works.
I suppose my grievance is with this:
> If I have changed my mind and don’t want to set up the TV or adjust the bass, I will just press cancel myself.
Sure, the über hacker would just press cancel because they know that's what they should do. The rest of the world, who doesn't have nearly as much experience with computer interfaces as you do? They might not even know what a cancel button is, let alone that they should look for it.
So, in order to protect against the rare case of someone bumping into a button you want to annoy everyone else with timed modes?
And honestly, how often are you in the settings that it would annoy you? So you go in there maybe two times a year to adjust your bass when you stop liking house music and start liking indie rock, and that only takes a few seconds, so what are you doing in there that requires an extended period of time and enough contemplation that you wouldn't be able to immediately alter the settings and instead would have to pause for >10 seconds?
I don't consider it a big problem, but you did ask. You can't do it while driving since depending on the mode the same control does a while bunch of different things.
My stereo is far from pretty, but I now have tactile buttons laid out in a logical fashion and instead of an LCD screen, it gives vocal feedback (via voice synthesis). So I no longer need to take my eyes off the road to switch music.
As an added bonus, I'm about to hook a 500GB laptop HDD into the device so that I can have my complete music collection on the road.
For example, having excessive controls in the car stereo might be a bad idea since drivers could potentially be distracted. So having the big volume knob to fine tune the bass level for example would be much more preferable to having six individual knobs that the user would have to look through and find.
Then there is the fact that if you only have one knob, you still have to learn how to put it in the mode you want (via secondary buttons, or even worse, just one you have to keep pressing); you gained nothing.
Also, compare typing an a cell phone "keyboard" and a PC keyboard. While you wouldn't want to have a single button for every little function (like upper-case letters), it generally makes for better usability to have a dedicated button for most of them, because while I press one key, my other fingers can already get into position to press the next in sequence.
I think the "shaking icons" mode in iPhone is complex too. Your average iPhone user probably do not know it but she/he wouldn't miss a big part of their device.
My point may be moot, though; who uses a watch in the 21st century? I use my phone to tell the time.
If you pay attention , you always know what tool you've selected ,so it is not really an issue. And just stating something is bad without proposing an alternative is just bashing for the sake of bashing. That's not interesting.
Complex tools require complexe interfaces. Not everything should or need to be simple. I dont like ergonomists/designers that just say something is bad without thinking about context. We are not talking about PAINT, but a professional software that needs to do many things. Photoshop has issues , but mode in photoshops are not a problem. Photoshop is supposed to be used by an audience that will take the time to learn it and understand it. It is not a tv or a car stereo where nobody bother read the doc. You cant master photoshop without learning it , it's interface has its own logic one needs to learn.
I toyed with the idea of a timed keyboard for mobiles/pads; a variant of the Hexagon game controls -- basically left and right buttons, turning a wheel of chars really quickly. (After a while with Hexagon, you get really good timing.)
The keyboard would need some additional way to fine tune the last selected char a few steps up/down on the wheel.
I assumed that similar models have been tried and found too slow. Or too demanding on concentration.