Talk:Mode (user interface)

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 92.227.211.252 (talk) at 20:57, 2 March 2009 (→‎Modes are generally frowned upon in interface design). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

WikiProject iconComputing Unassessed
WikiProject iconThis article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
???This article has not yet received a rating on Wikipedia's content assessment scale.
???This article has not yet received a rating on the project's importance scale.

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)[reply]
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)[reply]
@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.

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)[reply]