 | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
 |
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
- 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)
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 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)
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)
- Let's be clear: Quasi-modes are modes. Moreover there's nothing inherently worse about letting someone stay in another mode when they release a key, especially since, we assume (I think) that users pay attention to the program even if they aren't pros yet (Vim displays the current mode). I can imagine it being difficult to operate Vim in the same way if I had to keep my pinky anchored on a key everytime I wanted to enter command mode. I might as well go to Notepad if I have to use the mouse!
Liberulo (
talk) 16:11, 24 December 2010 (UTC)
- If you take the time to understand the article and read the references, you'll see that quasi-modes are not modes according to the formal definition provided in the literature (and included in the lead). But this distinction is academic, what matters is that 1) "the user paying attention to the state" is what makes modes hard and what produces mode errors - (for which Vim is also a prime example), even for expert users (so yes, there's "something inherently worse" and it's well referenced), and 2) all the advantages you cite can be achieved in modeless interfaces (quasimodes activated with the pinky are not the only way to avoid modes) so they can't be attributed to modes - they belong to the design as a whole, not the mode
per se.
- There's nothing inherently worse about it at all. The singular reference in this article (which I've read several times) simply says "modes are usually good to avoid" (talk about weasel words!), without reference. Perhaps we need to clarify our perspective; I am a Vi/m user. Not a tinkerer, not a neophyte, a user. If we want to talk about user errors, mode errors, and usability, let's talk about it from a user's perspective, not that of a newcomer. Vi has a learning curve, as I would expect does any modal tool. That doesn't make it "worse," except perhaps solely by the metric of counting the number and frequency of mistakes learners make, which does not provide any necessarily meaningful measure in the opinion of this author. Some tools take more learning than others, but provide greater reward. Also, quasimodes are modes. I can put quotes around that from the article itself if you want.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- No need to quote that sentence; I wrote the original definition which was "a modeless interaction that allows for the benefits of a mode without the cognitive burden", which was more precise but maybe less clear so it was changed later to the one you see. Quasimodes still don't match the formal definition; they're modes only in the informal sense that they can link several functions to the same key or button, not with respect to "the user's locus of attention" that produces mode errors. An interface with quasimodes is still modeless.
- The number and frequency of mistakes users made is one of the most important measures in usability; you're entitled to your opinion as whether less usability makes for a worse interface or not. Research has sown that modes induce errors also to expert users. IIRC experts learn to not care about mode errors they commit and to recover quickly from them. Diego Moya ( talk) 08:54, 26 December 2010 (UTC)
- There's nothing inherently worse about it at all. The singular reference in this article (which I've read several times) simply says "modes are usually good to avoid" (talk about weasel words!), without reference. Perhaps we need to clarify our perspective; I am a Vi/m user. Not a tinkerer, not a neophyte, a user. If we want to talk about user errors, mode errors, and usability, let's talk about it from a user's perspective, not that of a newcomer. Vi has a learning curve, as I would expect does any modal tool. That doesn't make it "worse," except perhaps solely by the metric of counting the number and frequency of mistakes learners make, which does not provide any necessarily meaningful measure in the opinion of this author. Some tools take more learning than others, but provide greater reward. Also, quasimodes are modes. I can put quotes around that from the article itself if you want.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- I'm now beginning to think that the perception on bias is due to the amount of negative information in the article, not its nature. Most of the content I added is about mode errors, which is giving undue weight to that in the context of modes as a whole. I suggest to re-create the
Mode error article that was once merged into this one; the concept of a mode error has enough notability on itself to qualify for a whole article, and it would solve the problem of undue weight. This way the lack of references for advantages specific to modes won't make this article unbalanced.
- I believe mode errors definitely merit a section. Mode errors are unique to modal software. People learning should be aware of them. It does feel undue, but it may be representatively undue. Not many people like modes. Most people probably don't at first, but modes do have advantages, and are used all over the place, and it becomes extremely easy to find examples when we stop talking strictly about text editors or software in general.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- By all means, please bring here those well referenced examples from reliable sources that you find so easy to find, since I've been unable to.
- Look, I understand why people may love vi, and that vi is heavy on modes, so it's easy to make the mistake to assume that the benefits of vi are due to its modes. The vi editor had its important place in the 70s and 80s (and now at legacy systems from that era) but now we can do much better design. Since you seem interested in the subject, I dare you ;-) to learn about the
Canon Cat and
Archy for an interface with the same benefits at editing as Vi, but which is
completelyextremely modeless (and easy to learn). Read The Humane Interface, analyze the design of Archy and you'll learn which features of vi are those that make it powerful (hint: they are not the modes) and which ones make it difficult to learn (hint: these are the modes). Diego Moya ( talk) 09:24, 26 December 2010 (UTC)
- I believe mode errors definitely merit a section. Mode errors are unique to modal software. People learning should be aware of them. It does feel undue, but it may be representatively undue. Not many people like modes. Most people probably don't at first, but modes do have advantages, and are used all over the place, and it becomes extremely easy to find examples when we stop talking strictly about text editors or software in general.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- Of course, you're welcome to write that suggested description of how modes are used in prominent applications like Vi. That would be a good addition. Diego Moya ( talk) 16:49, 24 December 2010 (UTC)
- If you take the time to understand the article and read the references, you'll see that quasi-modes are not modes according to the formal definition provided in the literature (and included in the lead). But this distinction is academic, what matters is that 1) "the user paying attention to the state" is what makes modes hard and what produces mode errors - (for which Vim is also a prime example), even for expert users (so yes, there's "something inherently worse" and it's well referenced), and 2) all the advantages you cite can be achieved in modeless interfaces (quasimodes activated with the pinky are not the only way to avoid modes) so they can't be attributed to modes - they belong to the design as a whole, not the mode
per se.
- Let's be clear: Quasi-modes are modes. Moreover there's nothing inherently worse about letting someone stay in another mode when they release a key, especially since, we assume (I think) that users pay attention to the program even if they aren't pros yet (Vim displays the current mode). I can imagine it being difficult to operate Vim in the same way if I had to keep my pinky anchored on a key everytime I wanted to enter command mode. I might as well go to Notepad if I have to use the mouse!
Liberulo (
talk) 16:11, 24 December 2010 (UTC)
I'll try to place all content regarding mode errors in the "mode errors" and "criticism" section. This way it won't be disseminated all over the article. Diego Moya ( talk) 18:52, 30 December 2010 (UTC)
- Done. Diego Moya ( talk) 19:23, 30 December 2010 (UTC)
Several people found an earlier version of this article to be biased against the use of modes. I believe that this perception was caused first because there isn't a developed description of modes and its effects, and the most detailed description is that of mode errors; and second because the content about errors was spread all over the article. Almost all content about mode errors is well referenced, but having it appear in every section gave an overall negative impression.
To address these problems I've concentrated all negative descriptions of modes in the Mode errors and Assessment sections; and I've added an "Expand section" tag to the Examples section. In my opinion this better qualifies the problem with this article than the POV tag. The WP:STRUCTURE section in NPOV policy advises us to keep a neutral presentation, which I think the new article structure achieves.
Several editors have expressed their opinions that modes have some specific benefits in interface design, but have consistently failed to find sources that prove this view, which seems to be based in applications with a good design that also happen to be modal. Without any evidence to support that those advantages are due to modes, and given the lack of articles praising modes in the literature, I claim that this view by those editors is not a relevant one and thus I'm removing the POV tag until proven wrong with reliable sources. Expanding the examples section to describe how modes work, and keeping all information about mode errors together should be enough to address their concerns. Diego Moya ( talk) 20:06, 30 December 2010 (UTC)
"Emacs - has a special mode for issuing commands, which is entered by pressing the control key plus a letter key." Eh? Even for the people who argue that quasimodes are modes, this should say "which is entered and then exited by..." since the result of typing the control-letter combination is not to enter a mode — the alleged mode is all finished as soon as the command finishes. But I'm not suggesting that wording; my point is that the language makes the absurdity of calling control-letter a mode obvious.
Is this a bending over backward to appear neutral in the emacs/vi wars? It's unnecessary; the bullet point goes on to mention Emacs's many real modes, many more than vi, I think. If this is going to devolve into an emacs/vi article, the important point is that Emacs's modes are long-term, usually not changing within the editing of a particular document, whereas the vi user is constantly popping in and out of command mode.
But in any case, if the world's population is still growing exponentially, surely the fraction of Wikipedia readers who care about emacs/vi wars must be tiny by now. I suggest that this article would be improved by eliminating all references to either of those editors, and instead focusing on the importance of the idea of modelessness in the development of the Macintosh (in which Tesler and Raskin were both major contributors) and thus in the acceptance of computers by the non-techie population at large. If we're going to introduce specific bad examples, how about Photoshop, a program still in widespread use, which is so riddled with modes that lay users can never get it to do what they want? Briankharvey ( talk) 23:47, 8 January 2011 (UTC)
- I wrote the current form of that bullet point, and I couldn't care less about sides in the vi/emacs wars. Emacs commands are *not* quasimodes: Ctrl+x+release starts a mode and the interface keeps waiting for more keypresses to complete the command, so the interface can be in that mode for an indefinite time (and cause mode errors). So "entered [and not exited] by pressing the control key plus a letter key" is the best and most accurate description I can get of the modal behavior of Emacs commands. They point is to illustrate that Emacs also has a short-lived command mode which is not a quasimode.
- Examples are important and we have very few, I'd work in expanding them instead of removing them. You're welcome to explain as many modes as you know in popular applications. Diego Moya ( talk) 07:45, 9 January 2011 (UTC)
I find it ironic that while adding a wiki link for "quasimodes" I ran into one of my most common mode errors: editing a wikipedia page without being logged in. I typically only notice my mistake when the "This is a minor edit" checkbox doesn't appear, then when I log in I lose my edits. Argh. Sorry for venting but the irony was too good to pass up. Atomota ( talk) 16:40, 6 November 2014 (UTC)
Hello fellow Wikipedians,
I have just modified 4 external links on Mode (computer interface). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20071022205105/http://www.usabilityfirst.com/glossary/term_321.txl to http://www.usabilityfirst.com/glossary/term_321.txl
- Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx
- Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx
- Added archive https://web.archive.org/web/20071022205105/http://www.usabilityfirst.com/glossary/term_321.txl to http://www.usabilityfirst.com/glossary/term_321.txl
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}} (last update: 18 January 2022).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.— InternetArchiveBot ( Report bug) 07:23, 3 February 2018 (UTC)
|
| This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
| ||||||||||||||
|
This article links to one or more target anchors that no longer exist.
Please help fix the broken anchors. You can remove this template after fixing the problems. |
Reporting errors |
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)
- 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)
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 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)
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)
- Let's be clear: Quasi-modes are modes. Moreover there's nothing inherently worse about letting someone stay in another mode when they release a key, especially since, we assume (I think) that users pay attention to the program even if they aren't pros yet (Vim displays the current mode). I can imagine it being difficult to operate Vim in the same way if I had to keep my pinky anchored on a key everytime I wanted to enter command mode. I might as well go to Notepad if I have to use the mouse!
Liberulo (
talk) 16:11, 24 December 2010 (UTC)
- If you take the time to understand the article and read the references, you'll see that quasi-modes are not modes according to the formal definition provided in the literature (and included in the lead). But this distinction is academic, what matters is that 1) "the user paying attention to the state" is what makes modes hard and what produces mode errors - (for which Vim is also a prime example), even for expert users (so yes, there's "something inherently worse" and it's well referenced), and 2) all the advantages you cite can be achieved in modeless interfaces (quasimodes activated with the pinky are not the only way to avoid modes) so they can't be attributed to modes - they belong to the design as a whole, not the mode
per se.
- There's nothing inherently worse about it at all. The singular reference in this article (which I've read several times) simply says "modes are usually good to avoid" (talk about weasel words!), without reference. Perhaps we need to clarify our perspective; I am a Vi/m user. Not a tinkerer, not a neophyte, a user. If we want to talk about user errors, mode errors, and usability, let's talk about it from a user's perspective, not that of a newcomer. Vi has a learning curve, as I would expect does any modal tool. That doesn't make it "worse," except perhaps solely by the metric of counting the number and frequency of mistakes learners make, which does not provide any necessarily meaningful measure in the opinion of this author. Some tools take more learning than others, but provide greater reward. Also, quasimodes are modes. I can put quotes around that from the article itself if you want.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- No need to quote that sentence; I wrote the original definition which was "a modeless interaction that allows for the benefits of a mode without the cognitive burden", which was more precise but maybe less clear so it was changed later to the one you see. Quasimodes still don't match the formal definition; they're modes only in the informal sense that they can link several functions to the same key or button, not with respect to "the user's locus of attention" that produces mode errors. An interface with quasimodes is still modeless.
- The number and frequency of mistakes users made is one of the most important measures in usability; you're entitled to your opinion as whether less usability makes for a worse interface or not. Research has sown that modes induce errors also to expert users. IIRC experts learn to not care about mode errors they commit and to recover quickly from them. Diego Moya ( talk) 08:54, 26 December 2010 (UTC)
- There's nothing inherently worse about it at all. The singular reference in this article (which I've read several times) simply says "modes are usually good to avoid" (talk about weasel words!), without reference. Perhaps we need to clarify our perspective; I am a Vi/m user. Not a tinkerer, not a neophyte, a user. If we want to talk about user errors, mode errors, and usability, let's talk about it from a user's perspective, not that of a newcomer. Vi has a learning curve, as I would expect does any modal tool. That doesn't make it "worse," except perhaps solely by the metric of counting the number and frequency of mistakes learners make, which does not provide any necessarily meaningful measure in the opinion of this author. Some tools take more learning than others, but provide greater reward. Also, quasimodes are modes. I can put quotes around that from the article itself if you want.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- I'm now beginning to think that the perception on bias is due to the amount of negative information in the article, not its nature. Most of the content I added is about mode errors, which is giving undue weight to that in the context of modes as a whole. I suggest to re-create the
Mode error article that was once merged into this one; the concept of a mode error has enough notability on itself to qualify for a whole article, and it would solve the problem of undue weight. This way the lack of references for advantages specific to modes won't make this article unbalanced.
- I believe mode errors definitely merit a section. Mode errors are unique to modal software. People learning should be aware of them. It does feel undue, but it may be representatively undue. Not many people like modes. Most people probably don't at first, but modes do have advantages, and are used all over the place, and it becomes extremely easy to find examples when we stop talking strictly about text editors or software in general.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- By all means, please bring here those well referenced examples from reliable sources that you find so easy to find, since I've been unable to.
- Look, I understand why people may love vi, and that vi is heavy on modes, so it's easy to make the mistake to assume that the benefits of vi are due to its modes. The vi editor had its important place in the 70s and 80s (and now at legacy systems from that era) but now we can do much better design. Since you seem interested in the subject, I dare you ;-) to learn about the
Canon Cat and
Archy for an interface with the same benefits at editing as Vi, but which is
completelyextremely modeless (and easy to learn). Read The Humane Interface, analyze the design of Archy and you'll learn which features of vi are those that make it powerful (hint: they are not the modes) and which ones make it difficult to learn (hint: these are the modes). Diego Moya ( talk) 09:24, 26 December 2010 (UTC)
- I believe mode errors definitely merit a section. Mode errors are unique to modal software. People learning should be aware of them. It does feel undue, but it may be representatively undue. Not many people like modes. Most people probably don't at first, but modes do have advantages, and are used all over the place, and it becomes extremely easy to find examples when we stop talking strictly about text editors or software in general.
Liberulo (
talk) 19:57, 24 December 2010 (UTC)
- Of course, you're welcome to write that suggested description of how modes are used in prominent applications like Vi. That would be a good addition. Diego Moya ( talk) 16:49, 24 December 2010 (UTC)
- If you take the time to understand the article and read the references, you'll see that quasi-modes are not modes according to the formal definition provided in the literature (and included in the lead). But this distinction is academic, what matters is that 1) "the user paying attention to the state" is what makes modes hard and what produces mode errors - (for which Vim is also a prime example), even for expert users (so yes, there's "something inherently worse" and it's well referenced), and 2) all the advantages you cite can be achieved in modeless interfaces (quasimodes activated with the pinky are not the only way to avoid modes) so they can't be attributed to modes - they belong to the design as a whole, not the mode
per se.
- Let's be clear: Quasi-modes are modes. Moreover there's nothing inherently worse about letting someone stay in another mode when they release a key, especially since, we assume (I think) that users pay attention to the program even if they aren't pros yet (Vim displays the current mode). I can imagine it being difficult to operate Vim in the same way if I had to keep my pinky anchored on a key everytime I wanted to enter command mode. I might as well go to Notepad if I have to use the mouse!
Liberulo (
talk) 16:11, 24 December 2010 (UTC)
I'll try to place all content regarding mode errors in the "mode errors" and "criticism" section. This way it won't be disseminated all over the article. Diego Moya ( talk) 18:52, 30 December 2010 (UTC)
- Done. Diego Moya ( talk) 19:23, 30 December 2010 (UTC)
Several people found an earlier version of this article to be biased against the use of modes. I believe that this perception was caused first because there isn't a developed description of modes and its effects, and the most detailed description is that of mode errors; and second because the content about errors was spread all over the article. Almost all content about mode errors is well referenced, but having it appear in every section gave an overall negative impression.
To address these problems I've concentrated all negative descriptions of modes in the Mode errors and Assessment sections; and I've added an "Expand section" tag to the Examples section. In my opinion this better qualifies the problem with this article than the POV tag. The WP:STRUCTURE section in NPOV policy advises us to keep a neutral presentation, which I think the new article structure achieves.
Several editors have expressed their opinions that modes have some specific benefits in interface design, but have consistently failed to find sources that prove this view, which seems to be based in applications with a good design that also happen to be modal. Without any evidence to support that those advantages are due to modes, and given the lack of articles praising modes in the literature, I claim that this view by those editors is not a relevant one and thus I'm removing the POV tag until proven wrong with reliable sources. Expanding the examples section to describe how modes work, and keeping all information about mode errors together should be enough to address their concerns. Diego Moya ( talk) 20:06, 30 December 2010 (UTC)
"Emacs - has a special mode for issuing commands, which is entered by pressing the control key plus a letter key." Eh? Even for the people who argue that quasimodes are modes, this should say "which is entered and then exited by..." since the result of typing the control-letter combination is not to enter a mode — the alleged mode is all finished as soon as the command finishes. But I'm not suggesting that wording; my point is that the language makes the absurdity of calling control-letter a mode obvious.
Is this a bending over backward to appear neutral in the emacs/vi wars? It's unnecessary; the bullet point goes on to mention Emacs's many real modes, many more than vi, I think. If this is going to devolve into an emacs/vi article, the important point is that Emacs's modes are long-term, usually not changing within the editing of a particular document, whereas the vi user is constantly popping in and out of command mode.
But in any case, if the world's population is still growing exponentially, surely the fraction of Wikipedia readers who care about emacs/vi wars must be tiny by now. I suggest that this article would be improved by eliminating all references to either of those editors, and instead focusing on the importance of the idea of modelessness in the development of the Macintosh (in which Tesler and Raskin were both major contributors) and thus in the acceptance of computers by the non-techie population at large. If we're going to introduce specific bad examples, how about Photoshop, a program still in widespread use, which is so riddled with modes that lay users can never get it to do what they want? Briankharvey ( talk) 23:47, 8 January 2011 (UTC)
- I wrote the current form of that bullet point, and I couldn't care less about sides in the vi/emacs wars. Emacs commands are *not* quasimodes: Ctrl+x+release starts a mode and the interface keeps waiting for more keypresses to complete the command, so the interface can be in that mode for an indefinite time (and cause mode errors). So "entered [and not exited] by pressing the control key plus a letter key" is the best and most accurate description I can get of the modal behavior of Emacs commands. They point is to illustrate that Emacs also has a short-lived command mode which is not a quasimode.
- Examples are important and we have very few, I'd work in expanding them instead of removing them. You're welcome to explain as many modes as you know in popular applications. Diego Moya ( talk) 07:45, 9 January 2011 (UTC)
I find it ironic that while adding a wiki link for "quasimodes" I ran into one of my most common mode errors: editing a wikipedia page without being logged in. I typically only notice my mistake when the "This is a minor edit" checkbox doesn't appear, then when I log in I lose my edits. Argh. Sorry for venting but the irony was too good to pass up. Atomota ( talk) 16:40, 6 November 2014 (UTC)
Hello fellow Wikipedians,
I have just modified 4 external links on Mode (computer interface). Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20071022205105/http://www.usabilityfirst.com/glossary/term_321.txl to http://www.usabilityfirst.com/glossary/term_321.txl
- Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx
- Added archive https://web.archive.org/web/20130506101851/http://quince.infragistics.com/Patterns/Modal%20Panel.aspx to http://quince.infragistics.com/Patterns/Modal%20Panel.aspx
- Added archive https://web.archive.org/web/20071022205105/http://www.usabilityfirst.com/glossary/term_321.txl to http://www.usabilityfirst.com/glossary/term_321.txl
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018.
After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than
regular verification using the archive tool instructions below. Editors
have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the
RfC before doing mass systematic removals. This message is updated dynamically through the template {{
source check}} (last update: 18 January 2022).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.— InternetArchiveBot ( Report bug) 07:23, 3 February 2018 (UTC)