Talk:Mode (user interface)

Modes are generally frowned upon in interface design

With something like the vim editor, I can understand why/how it is that modes can generally lead to confusion when implemented in a way that is not immediate to the user. However, I severely doubt that user confusion is inherent within the concept of modal computer interface usage. More likely, modifying implementation (say, by making the background screen colour of different modes change in a manner that corresponds to those different modes, is the most likely way in which it would be possible to implement modal computer interfaces whilst preventing user confusion).

I would be interested in any comments that are out there in regards to this. --[[Nukemason]|[Nukemason]] 08 August 2006 1911 (UTC)

Note that for your proposed modification, the user must be aware of the screen state in order not to make errors. Say that users aren't looking at screen (for example by touch-typing), then the modal interface may catch them. Jef Raskin opossed to modal interfaces because they prevent becoming habituated - performing common actions without conscious reasoning. If you include the application state into the action loop, you break the instinctive performing of the action (what's often called "muscle memory").

There are limited places where modes can be useful - specially with direct manipulation. See for example the use of tool palettes in graphic applications. Normally these tools work well because 1) users of these applications are highly trained and 2) the current state is persistently shown as the cursor shape, which is the focus of the user attention (so according to Raskin's definition, this change of state is not a mode).Diego 07:20, 21 August 2006 (UTC)

Hmm?? Touch-typing means not looking at the keyboard, which means that you probably are looking at the screen. I guess you mean the opposite? Also, I think Jef Raskin's point about modes preventing users from becoming habituated is wrong. Can you think of a program which advanced users are more habituated to than vi? Let me scroll down to see: jjjjjjjjjjjjjj (that mistake is one of the criticisms, but I would be quick to point out that issue in this case is lack of modes)

I think the major point is that modal interfaces (vi in particular) have a steep learning curve. I would certainly accept that it takes longer to become habituated with vi than.. Microsoft word. Both programs are ubiquitous in their particular area, so I think people become relatively advanced users of both regardless of their will. I think that most people that use vi enough come to love it. MS Word.. I don't know if it ever ceases to annoy. Granted, that is a different concern.

In other words, I think the criticisms are valid and should stand, but there is another side of the argument too, I wish that was addressed better. Why is it used in vi and photoshop, etc? Because it gives you a lot of possibilities fast, you don't have to fool around with menus and the like. Anyway, I already used old MS Word in a somewhat modal way (navigating the menus with the alt key), they are making it more so: http://lifehacker.com/software/microsoft-office/screenshot-tour-the-keyboard-shortcut-goodness-of-microsoft-office-2007-229556.php

If modes can be avoided, they should be, but sometimes I don't think that they can without something even more awkward. I think that is worth mention. 160.36.230.100 (talk) 16:43, 12 February 2009 (UTC)

@Nukemason: The mode you are proposing is not a mode in the sense of Raskin's definition. Have a look at "when (1) the current state of the interface is not the user's locus of attention". This means, that the either has to be hidden (like, there is no way for the user to know about the change of state), or the user has to be unaware of the different state. For instance, if the background color changes to indicate the change of system state, we could say it is no longer 'modal'. Only if the user ignores or forgets about the background color, and thus loses awareness of the state change, the interface can be called "modal" again.

As another example, think about the search box in Firefox. You hit F3, the search box opens (the thing in the window bottom). You are very aware of that, and that your keyboard input will fill letters into the search box. Only if you leave the search box open and then you forget about it, you might run into the typical mode errors. So, the search box you are looking at is not modal. The search box you ignore IS modal. —Preceding unsigned comment added by 92.227.211.252 (talk) 20:57, 2 March 2009 (UTC)

Mobile phones aren't modal too? I believe it would be convenient to point out that the most ubiquitous device today, the mobile phone, has a modal interface (i.e. pressing twice the '1' key will dial '11' when making a call but will write a 'b' when writing a message as an easy example) but that was no problem to reach its present popularity. Ricardo Bravo

Go on, write it if you find a reference. I remember seeing some study about the problems that mobile keyboards bring to users, and is widely known how most of the functions available on phones are unused due to their difficulty. It would be good to include references to what science has to say about that. Diego (talk) 22:01, 23 December 2007 (UTC)

As I said above (the anonymous comment), the important thing about modes is that you are not aware of it. For instance, if you switch through different menus of your mobile, that is not really what Raskin would call 'modes'. You look at the mobile screen, you know where you are in the menu. The same with writing messages vs dialing: You are usually aware whether you are in dialing or message mode. But, for instance, I am often not aware which language is currently active for the message writing (I mostly use german, but for some of my friends I need to write in english). Or, I am not aware if I am in predictive text mode (T9) or in single-character mode. Things like this often run me into unexpected behaviour. -- anonymous person.. —Preceding unsigned comment added by 92.227.211.252 (talk) 21:08, 2 March 2009 (UTC)

Advantages?!

This article is very heavily biased against modal design. Attempts to add an admittedly imperfect advantages section have been completely undone.

An advantages section should be created, and Diego should help clean up submissions, as he's fond of doing, instead of completely preventing them for some reason. —Preceding unsigned comment added by 72.64.180.231 (talk) 04:59, 19 September 2010 (UTC)

That sounds good - it's strongly recommended, though, to have a reference, online or off-, for any advantage you cite, so that you're not engaging in original research. Korny O'Near (talk) 12:25, 21 September 2010 (UTC)

The reason I've reworked some of your edits, and eliminated some others, is because all them were unreferenced as well as quite bold, dubious claims. (Also some of them were related to modes in programming languages, not user interfaces). I'm the first who would love having some links to documents pointing out how modal interfaces should be used to create great interfaces that don't produce mode errors, but I've never seen any.

With respect to the Neutrality tag, an article is not biased if there exists only one viewpoint about the topic. Also I've tried my best to keep an impartial tone to preserve the Neutral Point of View. If you can find example sentences where this tone is lost, feel free to edit them. Diego Moya (talk) 13:04, 21 September 2010 (UTC)

I hope the latest additions will help to achieve a NPOV. Is there consensus about this dispute now? Diego Moya (talk) 09:57, 6 October 2010 (UTC)

Nope, I just read the article and completely agree that it reads with bias. We should add an advantages section. Some advantages to modal software and interfaces are obvious, regardless of the user's ability to take advantage of them. I think we need to distinguish between advantages of modality and the difficulty of using/learning modality. What do you think? Liberulo (talk) 07:49, 23 December 2010 (UTC)

I'm fine with adding that section as long as it's well referenced. I'd prefer to call it 'effects of modes' instead of advantages, or at least 'benefits'; 'advantages' implies that comparatively it provides some extra pay-off that can't be achieved in modeless interfaces, which is rarely true in my experience. So what are those obvious advantages? The only one I can think of is getting the user focused on a single shoehorned task, by making hard to escape from it. But I've haven't found references to support this usage. Diego Moya (talk) 09:16, 23 December 2010 (UTC)

G/Vi/m users rave about increased efficiency, and I can attest to that (this point would be easy to support from web, too). Also, in allowing mode switching you are multiplying the number of inputs to the device (IE a 26-key keyboard with a mode-switch key effectively becomes a 50-key keyboard), without requiring extras, which may otherwise include more hardware, menus, or keystroke combinations (depending on which level you view this). This would not need support, as it is fact and can be both stated and proven mathematically (not that support cannot be found, it's just, like I said before, obvious). I think comparatively speaking "advantages" is equivalent to "benefits," and I would support the addition of a section with either name. Modal tools (software and otherwise) definitely have both practical advantages and practical disadvantages; let's address some of these positives. Liberulo (talk) 07:40, 24 December 2010 (UTC)

Indeed modes can have those effects, thus the first name I suggest for the new section. What I dispute is that those effects are a unique advantage of modes, since the most prominent of them are also available with quasi-modes (modifiers and accelerators for keyboard, mouse chording and context menus for pointing devices) and direct manipulation techniques (drag and drop, halos). In Wikipedia such 'obvious' knowledge must still be referenced, because there's always someone with good reasons to challenge the obvious. Diego Moya (talk) 10:58, 24 December 2010 (UTC)

Modal editors like Vim encourage the user to avoid using pointing devices, the use of which is (I hope) obviously less efficient than using the keyboard, so things like context menus (or GUI menus in general) *do* have an inherent disadvantage in efficiency. As for quasi-modes I can see that they can provide several of the same benefits, themselves being a type of modal interface after all. We can put some of these things in an advantages section. Liberulo (talk) 16:07, 24 December 2010 (UTC)