
Modes in UI are bad; even worse are timed modes - ilyabirman
http://ilyabirman.net/meanwhile/all/timed-modes/
======
taeric
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.

And yes.... I'm a vim user.

~~~
SomeCallMeTim
>And yes.... I'm a vim user.

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.

~~~
JulianWasTaken
> 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.

~~~
SomeCallMeTim
>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:

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>

~~~
Stratoscope
> 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.

------
krig
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.

------
Tomdarkness
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.

~~~
TheZenPsycho
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.

~~~
bengillies
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.

~~~
TheZenPsycho
"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.

------
koobz
Modal/modeless, stateless/stateful, functional/imperative,
declarative/procedural, schemaless, distributed, asynchronous.

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.

------
TheZenPsycho
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.

~~~
subsection1h

        You guys stand in the way of UI progress. 
    

Progress from whose perspective? The masses or the elite? Is a UI that's
optimal for Joe Average also optimal for tech geniuses?

~~~
TheZenPsycho
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?

~~~
derleth
> "The Humane Interface" by Jef Raskin

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.

~~~
TheZenPsycho
debunked by who? [citation needed]

------
richforrester
Don't agree entirely with this article.

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.

------
JosephRedfern
<sarcasm>Yeah, emacs and vim - how shit are they? I'd rather nano any
day.</sarcasm>

In my opinion, you can't make a blanket statement like "Modes in UI are bad".
It depends entirely on context.

~~~
mafro
I completely agree. It depends entirely on what mode you're in.

------
platz
Obligatory Larry Tesler reference.

"... 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."

------
nostromo
It's more complicated than that.

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.

~~~
jcromartie
The key being that the entire context of the mode is staring you in the face
the whole time.

------
darkchasma
Modes in UI are not bad. Unexpected behaviour is bad. Don't confuse the two.

------
ctbeiser
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.

------
ceol
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.

~~~
ars
If you are unable to read the button that says "cancel" how were you able to
read the button that got you into the settings mode in the first place?

~~~
nitrogen
Who says you read the button or intended to push it at all?

~~~
ars
Yah, I don't think we can make a user interface for people who flail wildly
and press random buttons.

~~~
ceol
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.

~~~
ars
Your cure is worse than the disease.

So, in order to protect against the rare case of someone bumping into a button
you want to annoy everyone else with timed modes?

~~~
ceol
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?

~~~
ars
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.

------
laumars
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.

------
onster
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.

------
Aardwolf
And even worse is removing all buttons, settings and flexibility in the name
of "simplicity for consumer users", like seems to be the trend lately.

------
asifjamil
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.

~~~
PavlovsCat
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.

------
coherentpony
Wait, isn't vim built entirely on the concept of modes?

~~~
msoad
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.

~~~
coherentpony
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.

~~~
jordanthoms
Since I got my Pebble, I wear a watch almost all the time

------
camus
"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.

------
berntb
Hmm... Timed modes are bad?

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.

