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.
It's a recurring rage of mine how bad and even dangerous many appliance and real-world UIs are. The car stereo with timed modes is only one example, stove-tops with unfriendly touch screen interfaces that make it hard to tell if the stove is on or not is another.
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.
I can't get past the first part. Modes aren't bad. Indeed, modes can be used to great benefit. The only problem with modes is one of discoverability. It can be difficult to know what mode you are in at times, as well knowing of the different modes available.
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.
If you read the Wikipedia article that the author linked to in that assertion[1], you'll find that it mostly agrees with you:
> 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.
As long as you make sure that the mode vim is in the user's locus of attention. Typically, a user is more focused on the actual text they are trying to edit and thus the vim mode falls out of their locus of attention.
So it's not just about displaying what mode the system is in but also making sure that the user is always aware of the mode. It's this mismatch that make modal interfaces bad.
Edit: Parent has since deleted their comment. It used to say something along the lines of:
> So if I make vim always display the mode its in, does that make it modeless?
Good points, displaying the mode isn't enough as you cannot guarantee that the point of display will be sufficient to keep the mode as the user's locus of attention.
In vim I get around this by habit, I stay in command mode and only enter insert mode for text entry, and then at the end of a 'unit' of text entry I return to command mode.
Thus I always know when I am in insert or command mode by asking 'am I currently entering text', for me hitting ctrl-c after finishing a sentence is part of the act of writing the sentence.
Modes are mostly bad when there is no feedback that you're in a given mode. If there's plenty of feedback, it's fine.
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.
I'm also a Vim user, and this bit stuck out to me somewhat:
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.
In Photoshop, where it is somewhat difficult (at least it was for me anyway) to understand which mode you were in at any given point, this kind of problem does exist. But hypothetically, suppose you could always be aware of which mode you were editing in? Would modal interfaces still pose the same sorts of problems?
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.
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.
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).
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.
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.
>But there are piles of UI design research studies that show modal interfaces are, in fact, bad.
>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.
Curious, is there by any luck a study on veteran vim users in particular? It seems like the quality of execution + the familiarity of the test subjects with the UI and modes available would make a huge different in any such measurements.
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.
Depending on which measurements you are talking about, experience is largely irrelevant- as most of the "objective measurements" we are talking about, are about the quality of the UI itself, not the specific quality of the user.
Am sorry, i just have to reply to this.
Disclaimer: I use vim.
Anti-disclaimer?: I spent two years studying cognitive science and one of my electives was HCI.(though i wasn't excited about it to be honest :P)
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.
It's quite a simple matter to measure /rates of error/ in modal interfaces versus non-modal interfaces. This may seem trivial for text editors in particular, but modal errors are a big cause of aeronautical accidents (and deaths), so even one error is too many in that case.
And if you can avoid errors in cases where they are life threatening, why wouldn't you want to avoid errors everywhere else?
I agree low error rates are the most critical quality measure in aeronautical accidents. Am just not sure i would use that measure for text editors. If i have to operationalize my previous comment, i would say, i care about the amount of time i spend hitting the keys compared to the amount of time i spend moving around the mouse.
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.
Interface design is not an entirely subjective thing as you imply. Humans have way more in common with each other than you are willing to admit.
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.
> 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.
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.
Agreed. But though I'm a vim user, in day-to-day coding, my colleagues using say sublime don't see to suffer all that much. I occasionally see them doing something a bit inefficient with the mouse that could have been a few keystrokes in vim, but it's not that big of a deal really. Now, there are definitely a lot of things I could do in vim with macros and such that would be impossible to do efficiently in sublime. But I rarely have to do such complex text manipulation, so does it matter all that much?
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.
I use vim macros frequently. It's not that I'm doing something complex, but that I'm doing something repetitive. Having such an easy way to create macros on the fly means that I never have to do repetitive editing. (How important that is depends on the language; in SQL, for example, it's a huge help.)
:norm is a lesser-known trick that also helps quite a bit.
I use Visual Slickedit, Notepad++, and Visual Studio macros frequently. I typically map them to ctrl-f11 (record/stop recording) and ctrl-f12 (playback). In all three editors, I can just record, hit keys, stop, and playback (as many times as I hit the key). Notepad++ and Slickedit both offer you the option of binding the macro to a key more permanently too.
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.
I'm not arguing that other editors aren't powerful. I have less experience with others in any case. But vim does work well. A simple example I show off to coworkers:
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 can do that pretty trivially in any of three editors as well. I just did it now in about 20 seconds, just as a proof of concept.
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.
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.
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.
>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.
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:
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:
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.
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.
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."
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.
> 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.
You are absolutely correct that "you can not win this argument." But for a reason you are not touching. This is a preference. Almost pure and simple. The idea that someone's preference in editor is enough to make them a good or a bad programmer is borderline laughable.
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.
Only if you define "good" and "bad" user interfaces by discoverability. I would argue that Vim is a tool that explicitly trades off discoverability in favor of enhancing the productivity of an experienced user. And I would argue that in the case of Vim, this is a good tradeoff. It's not a good tradeoff for a microwave or VCR.
It is fully possible for humans to adapt to terrible computer interfaces. That doesn't mean the interface is not terrible, it just means that humans are adaptable.
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.
How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus?
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.
>How is Emacs' interface terrible? Is it the default key bindings? Is it the lack of mouse-friendly buttons and menus?
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.
> "good user interface shouldn't require instructions." (-- Donald Norman)
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
Umm...he's clearly not an idiot. Check his CV if you don't believe me.
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.
But see, here is the thing. I was not arguing for modes, per se. I was definitely not arguing for vim. Just had to acknowledge that I use it.
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.
A lot of your examples aren't "modal human interfaces." They are examples of the state of the world, or the state of the human in question.
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).
But the different "modes" of anything are just the state of the input mechanism. To be clear, my argument is not to use modes for the sake of using modes. More that I do not understand the attitude in computer design where it is assumed that we can get down to no modes in an interface. There is this magical "all context switches to get here do not count." That is, it is a fine guideline, but treated as its own independent rule is missing all of the conflict and tradeoffs that actually go into many decisions where they arise.
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.
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.
Vim is often called a modal editor, but I think it in fact has fever modes than GUI editors. In vim, I usually need only 2 modes (command, insert). In Notepad, each menu is a mode of its own right (File, Edit, Format, Help)... And to get as feature-full as VIM, editors will need much more ad-hoc modes.
I think vim's strength is not being modal. Its strength is having less modes than other editors.
I'm not really convinced by the examples given. I'd like to see the author come up with some suggestions on how you'd be able to use Photoshop without "modes" since to me it seems pretty much impossible.
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.
I agree, I'd argue that Photoshop is an expert system, it (rightly so) has a huge number of features and being able to have all these features without modes would probably make the app completely unusable.
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.
> you are going to be using the volume and channel controls 99% of the time
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.
Fewer physical buttons doesn't make the interface less confusing. If a button does 5 different things, it becomes more confusing, because a given button is really 5 actions that you have to understand when they apply before using that button. Consider dedicated picture-in-picture controls as opposed to trying to reuse other buttons to do something different to control PiP. If you aren't using it, you just tune those buttons out. If you are, it's easier to use.
Raskin makes a special exception to his "No Modes" rule when it comes to paint and drawing programs, as he admits this is an obvious case where modes are needed. He does provide a mechanism though, that could be used to make photoshop modeless: Quasimodes.
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.
It wouldn't be "pretty awesome". It would be almost entirely unusable.
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.
"It wouldn't be "pretty awesome". It would be almost entirely unusable."
Compared to the paragon of usability that photoshop represents today?
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.
3:13 Then Nebuchadnezzar in his rage and fury commanded to bring
Shadrach, Meshach, and Abednego. Then they brought these men before
the king.
3:14 Nebuchadnezzar spake and said unto them, Is it true, O Shadrach,
Meshach, and Abednego, do not ye serve my gods, nor worship the golden
image which I have set up? 3:15 Now if ye be ready that at what time
ye hear the sound of the cornet, flute, harp, sackbut, psaltery, and
dulcimer, and all kinds of musick, ye fall down and worship the image
which I have made; well: but if ye worship not, ye shall be cast the
same hour into the midst of a burning fiery furnace; and who is that
God that shall deliver you out of my hands? 3:16 Shadrach, Meshach,
and Abednego, answered and said to the king, O Nebuchadnezzar, we are
not careful to answer thee in this matter.
3:17 If it be so, our God whom we serve is able to deliver us from the
burning fiery furnace, and he will deliver us out of thine hand, O
king.
----
God says...
-even gross-hearted self-command addition stored becomes
Father recondite otherwise consequential made NEGLIGENCE
based anything wandering desireth recoveredst tremble
spreadest preserving Rest x indefinitely brighter unreal
how_hard_could_it_be His admonition
Reusing modes can actually be quite good if you're concerned about space efficiency.
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.
But you only learn the interface once (and that doesn't have to happen while driving, either); then you use it again and again. So I would argue making it slightly harder to learn, but better to use in the long run (in the cases where you cannot have it both ways), makes the difference between a tool built to last, and a product made to sell.
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 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.
I disagree with the car stereo timed mode example. Imagine someone doesn't know beforehand how to cancel out of the settings. Now, they either have to figure that out while driving or they have to sit with their stereo on a useless menu screen until they stop. This is exacerbated by the fact that your average driver isn't familiar with computer menus in the first place, so they have no idea what they're supposed to do unless it's plainly spelled out for them.
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.
Because it's inconceivable that someone would reach for the volume button and accidentally hit the settings button, right? It's not like stereos ever have buttons next to each other, and it's not like cars ever go over bumps or anything.
It's not really rare. I've done it a few times, what with trying to reach the station dial while also concentrating on the road and accidentally pressing it in, causing the settings mode to activate.
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 change the front-back fader all the time depending on what I'm listening to and who in the car wants to hear it.
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.
That's why some people do not like it. It's more complex to learn. Vim is a good example of how modes can make UI confusing.
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.
I can understand that, but calling them 'bad' right off the bat is not necessarily true. Let's use a digital watch as an example. Digital watches are designed to be small enough to fit on your wrist. As a consequence, there are physical constraints on the number of buttons you can put on the side whilst maintaining usability. If you allow the use of a modal user interface, you can use fewer buttons. The downside is you have to read the manual to configure your watch.
My point may be moot, though; who uses a watch in the 21st century? I use my phone to tell the time.
I think that mode-theorists wouldn't consider the shaking icons thing to be a mode, since it's obvious when you're in it. What they call a mode is a program state that the user can easily be in without realizing it and that affects the results of user interactions. Something like that.
The authors example of a car stereo struck a particular chord with me as I was so fed up with counter-intuitive interface on my car stereo that I actually built my own one using a Raspberry Pi.
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.
"... 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.
"you want to draw a line, but accidentally create a gradient fill."
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.
Of course a forum full of VIM users is going to disagree with the notion that modes are bad. You guys stand in the way of UI progress. It's interesting too, because the software we are use to, the software we like, changes us and affects the way we think. But it's also a jail, preventing us from seeing new possibilities. Computers are capable of modeling and simulating ANYTHING and producing virtually any kind of interface, and yet we only ever use it with one or two different kinds of interface (typewriter-like, and desk-like). Not even very good interfaces.
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?
This is a terrible analogy since the people who MAKE automobiles weren't fervent and rabid horse adherents, and Henry Ford never had to convince his engineers that cars shouldn't have legs and saddles.
I could write an essay here, or you could take responsibility for your own curiosity and read a book. I suggest "The Humane Interface" by Jef Raskin and "The Design of Every Day Things" by Donald Norman. I consider these essential reading for those interested in UI concerns.
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?
There are few things as modal as a modern cell phone/tablet. You know, the bleeding edge of modern UI. To think that it is a few folks preference for older editors that does this, is just shallow.
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?
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.
The problem with modes is fundamentally that people make mode-errors; they're not sure what mode they're in. If you've got users who aren't looking at the device, then yes, they'll make mode errors, because they have no clue what they're doing. If it's an unambiguous mode, and people understand the ways into and out of the mode, sure, you've got no problem, but those conditions are typically only met by system-level conventions.
Oh yes, PhotoShop has way too many modes. Adobe should kill them all. When you drag a line across an image, PhotoShop should utilize its psychic power to figure out your real intention.
104 comments
[ 3.2 ms ] story [ 188 ms ] threadIt 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.
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.
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.
[1] http://en.wikipedia.org/wiki/Mode_(computer_interface)
So it's not just about displaying what mode the system is in but also making sure that the user is always aware of the mode. It's this mismatch that make modal interfaces bad.
Edit: Parent has since deleted their comment. It used to say something along the lines of:
> So if I make vim always display the mode its in, does that make it modeless?
In vim I get around this by habit, I stay in command mode and only enter insert mode for text entry, and then at the end of a 'unit' of text entry I return to command mode.
Thus I always know when I am in insert or command mode by asking 'am I currently entering text', for me hitting ctrl-c after finishing a sentence is part of the act of writing the sentence.
But have you ever had Caps Lock on by accident in normal mode? Most confusing 3 seconds of my life.
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.
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.
[1] https://news.ycombinator.com/item?id=5696927
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.
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:
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.
http://foicica.com/textadept/
TextMate: "Plug-able Through Your Favorite Scripting Language"
http://macromates.com/
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.
http://www.sublimetext.com/
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.
[1] https://en.wikipedia.org/wiki/List_of_text_editors
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?
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.
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.
I uses a stop-watch for random numbers.
God says...
3:13 Then Nebuchadnezzar in his rage and fury commanded to bring Shadrach, Meshach, and Abednego. Then they brought these men before the king.
3:14 Nebuchadnezzar spake and said unto them, Is it true, O Shadrach, Meshach, and Abednego, do not ye serve my gods, nor worship the golden image which I have set up? 3:15 Now if ye be ready that at what time ye hear the sound of the cornet, flute, harp, sackbut, psaltery, and dulcimer, and all kinds of musick, ye fall down and worship the image which I have made; well: but if ye worship not, ye shall be cast the same hour into the midst of a burning fiery furnace; and who is that God that shall deliver you out of my hands? 3:16 Shadrach, Meshach, and Abednego, answered and said to the king, O Nebuchadnezzar, we are not careful to answer thee in this matter.
3:17 If it be so, our God whom we serve is able to deliver us from the burning fiery furnace, and he will deliver us out of thine hand, O king.
----
God says...
-even gross-hearted self-command addition stored becomes Father recondite otherwise consequential made NEGLIGENCE based anything wandering desireth recoveredst tremble spreadest preserving Rest x indefinitely brighter unreal how_hard_could_it_be His admonition
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 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.
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.
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.
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.
"... 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.
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.
In my opinion, you can't make a blanket statement like "Modes in UI are bad". It depends entirely on context.
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?
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?
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.