Conceptual Models II
From CS160 User Interfaces Sp09
Lecture on Feb 18, 2009
Readings
- Meanings, Modes, Monotony and Myths. The Humane Interface. Chap 3. Raskin.
Shoeb Omar - Feb 13, 2009 02:44:17 pm
Raskin's readings so far have been interesting, and he definitely does bring up a few interesting points, but I got tired of this reading midway through as a diatribe and rant about things that he didn't understand and thus complained about. Although I appreciate examples that he provides, he often goes overboard and just gets annoying to read. That said, he brought up a few interesting points. One was the idea of modes, the most illuminating example of which was the flash light, which had a toggle switch for off/on. You couldn't easily tell which mode the flashlight was in and thus it was a bad UI choice. This led to the example of toggle switches and how he believes radio buttons are a better idea. I liked this because it made a lot of sense to me. Toggle switches are annoying and as he said, the toggling part of it is only stored in short term memory and quickly forgotten. However, after presenting this point I think Raskin got a little excited and went overboard. He talks about how the Canon Cat didn't have modes because it would come out of sleep mode when you touched any button and it would act just like you were normally using it. He calls this modeless and tells how all UIs should be made modeless but I disagree that any such idea or concept is fathomable. The Cat was in an "OFF" mode when it was in standby. If my mom walked up to it and was going to try and continue her work, she wouldn't reach for any key and assume it would light back on. She would reach for the power button and try and switch the machine back on because it looks like it is off. Thus, his example is flawed and in reality I think the idea of truly modeless systems is simply not possible.
Furthermore, when he talks of quasimodes, it made me think of the control key and how it's used as a quasimode for many functions such as copy and paste. Although it isn't clearly indicated on the keyboard as in the system he describes, the concept is still there. However, it violates his idea of monotonicity which he claims as the ideal to strive towards. I think having one way to perform an action is a terrible idea because different situations call for different ways to do things. For example if I am using a keyboard and want to open a new tab I hit Ctrl-T (I think his notation for keyboard presses was overly complicated btw). If I am using the mouse, I either hit the new tab button or double click the tab bar. I like having the options because different ones suit me at different times. I don't think it confuses the user because as novices having different ways to do things encourages being accessible to finding at least one of the ways to do things, and as experts, you appreciate having multiple ways to use as you feel convenient. On that point of a novice v. expert dichotomy I agree with Raskin. Two interfaces for two kinds of users is a dumb concept. A UI should be designed to fit both, with perhaps quasimodes inserted to facilitate experts. Two different UIs is just complicated for both users and developers and should be avoided at all costs.
Saung Li - Feb 14, 2009 05:03:27 pm
One interesting criticism this article has is on user preferences. To me, having user preferences seems like a great idea since novice users can simply use the default options while expert users can change them to suit their needs more efficiently. The article, however, claims that customizations reduce productivity. Of course, if a computer is shared by multiple users then customizations can cause problems when one user wants to change a certain setting and another user does not know that. However, I think that certain programs used by only one user can have customizations. For example, in Word, the user can customize the toolbar to add in shortcuts to use often. The user can still access the feature the long way if he forgets about the shortcut.
Have modeless designs seems like it would help the user perform actions more easily, but I do not think it is feasible. What if the program has many many features? A keyboard, for example, can only have a finite number of keys provided for a user to use well. Thus, the concept of monotony cannot be applied to programs that have too many features. Using quasimodes isn't a perfect solution since performing them requires the user to memorize how to do them and needs to use them often to remember. I agree with the article saying that a design shouldn't have different beginner and expert modes, since people used to beginner mode would feel frustrated encountering new features in the expert mode. Features should be designed for all people to quickly learn and use, and modelessness and monotony can help with this if applying those concepts to a certain program are feasible. Monotony can be better in some situations. If a program has many ways to do something, a user will usually pick one way and stick to it because the user will remember to do it that way better when using it often.
What are some examples of currently existing modeless and monotonous interface designs?
Jeffrey Patzer - Feb 14, 2009 07:09:39 pm
First Comment: This article was a long reading. I'm not going to complain, just saying its long.
Second Comment: I thought the most poignant part of the articles was the idea of monotony. The idea that only offering a single way to do something in a program is compelling, but i think unfounded. It is true that having only one way to do something will build a habit. However, whether or not this habit is a good one is left to be determined. I think that having menu bars that don't change and layouts that are always a certain amount of clicks are definitely helpful. But if I had to right click cut/copy and right click paste every time i wanted to move some text around I would hate that system. This brings up my main point that without other opportunities for doing things in different manners, the designer does not complement the working styles of different people. Also, what if the only monotonous way implemented sucks? Then what? The feature is a permanent piece of dog crap and the hoped for lauded productivity gets flushed down the drain. So as much as the idea that there is only one way of doing something seems to be a good thing, it could very easily backfire. It seems that as a user progresses through a system they adapt to the system better, essentially going from beginner to advanced. I think that if a feature is offered in only one way that it might only work well for beginners or advanced users, but maybe not both. In a country prided for its choices, this is kind of like saying you want to go back to shopping at a local store rather than Wal-mart. Yes, Wal-mart may be massive and require a while to learn what you want, but once you find it you can buy it (keep using that feature?) at a very low price.
David Burban - Feb 14, 2009 10:21:37 pm
The article by Jef Raskin brings up some points with which I disagree. On page 49 (10/21 in the PDF), the author mentions that Word 97/98 interface is dismal; I disagree. The interface is customizable, so if a person has a wide screen, they can drag their tool bars around and arrange to his or her liking. The interface persists only for the user's profile, so in any good company, every use has their own profile, so when someone completely changes the interface, everyone else is unaffected.
Modes, I think, are also useful in some sense. For instance, my phone (Nokia N95) has a couple of modes, two of which I will discuss. When the phone is compact and unlocked, I can press the power button on top and choose to lock the phone. However, in a different mode, when the phone is slid upwards and I press the power button, the lock keypad option disappears. This differentiation is useful because it will help you remember to close the phone and prevent damage to it.
However, the author does make a point. VIM is a text editor that is entirely based upon nodes. There is the Editor mode and the command mode. The way to differentiate between the two is to look at the bottom left hand of the window. If you get stuck in the wrong mode you end up being confused as to what is happening. Or if you are in command mode and press "i" by accident, then you end up typing everything after the character. However, an experienced user can edit text and/or code much more efficiently (than any other editor) after he or she gets used to the two distinct modes.
Rohan Dhaimade - Feb 15, 2009 07:44:05 pm
I have to disagree with the author on one major point. His emphasis on monotony. The fact is, a computer is a wide assortment of features. A mouse, a keyboard and nowadays there are even touch screen inputs. All of these inputs must be considered when creating an interface. Personally, there should be multiple paths to commands. If you want to cut and paste something, there should be a way to do it using menus and keyboard. The problem of having non-monotony is having multiple ways to do COMPLEX tasks. An example would be is the example they gave in the chapter about the autopilot program. There should be a unified way to set the autopilot, only one way to create the entire thing from point to point. But setting things inside the compelx task of an autopilot might have multiple methods. If it is graphical, there might be multiple way to scroll to and set locations. If it is purely textual, there might be multiple ways to move between fields for setting coordinates.
Another point is that there is a differentiation between beginners and experts I think in terms of guidance. Rather than about pure elements and design, I'm talking more about details on controls. An example would be video players, controlling on how the video player handles many things (such as codecs, speakers, and etc.) are usually pointless for most people. They start the video player, the sound should automatically go to any speakers plugged in, video starts playing. Done! No settings or features beyond that. But some people might want to set the bass and treble and other features on particular speakers at different settings, or mess around with codecs (buffering and etc). The UI on these advanced modes might change significantly (because of the more controls and options you need to modify).
Matthew Can - Feb 16, 2009 10:41:52 pm
Raskin brings up a valid point that modes are a big source of interface errors. For example, I use keyboard shortcuts in Firefox to open up new tabs or switch through tabs. I often enter the commands when Firefox is open but is not the active window. Although this is a problem, I disagree that the right way to solve it is to eliminate modes altogether. It doesn't seem at all sensible to me for my operating system to run in one mode where each gesture always has the same effect. It is much easier for me to think of things in terms of the tasks I perform with my computer. That is, it makes sense to be in a "Firefox" mode when I'm web browsing, a "Microsoft Word" mode when I'm writing a paper, a "MediaMonkey" mode when I'm listening to music, etc.
I also disagree that it is best for designers not to give users the option to customize their interfaces. Raskin's argument reminds me of the phrase "Freedom is Slavery", a slogan used by the totalitarian government in the novel 1984. He writes that users do not understand interfaces the way that designers do, so any interface customized by a user will lead to less efficiency than an interface made by the designer. Perhaps this is true, but an argument based on efficiency reduces humans to the level of machines. Not everything we do is about maximizing efficiency. In fact, a lot of human behavior isn't even rational. As designers we should think about the overall user experience, much of which is subjective. If users happen to derive more pleasure from writing in blue font than black, then designers should provide a means for them to write in blue, even if it doesn't make them better writers.
Stephanie Shih - Feb 17, 2009 03:54:26 am
Raskin pointed out how influential habit had in relation to mistakes or troubles when it comes to user interface. Both in the pilot example and also the usage of Word, habit and a minuscule outside change was all that was needed to cause trouble. Raskin says, "It is always safe to avoid interface designs that have modes," but while it is safe, it doesn't mean it is possible.
For example, Word '97 was pointed out as a bad user interface because of the aforementioned reasons, yet it was easy for me to use because it was similar to other interfaces - such as those of web browsers, or most other programs. There was a menu bar at the top, with other toolbar options beneath that I could change to suit my preferences. Therefore, I found the latest version of Word more difficult to use because it was unfamiliar. A user should be able to customize as much as they want, because the user knows best how things work for hir.
I do agree on Raskin's opinion on the beginner-expert mode; if anything, it should be separated between general users and those that wish to expend the effort to completely remodel the system to suit themselves. By separating it between a beginner and an expert, it implies that one has to learn how to work the interface, when the interface should be striving to be intuitive.
Ling Chen - Feb 17, 2009 04:44:23 am
I liked how the author took time to introduce some of the definitions and notations in the article. It would have been a pain to try to figure out if the terms mean different things and what those up and down arrows were.
The author made it seem like modes are such a bad idea, something we should avoid at all cost. At least that was the impression I got. He actually said, "modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces." While that might be true in some cases, I still think sometimes modes are necessary. Take the example of language input programs. I use a certain program that allows me to type in Chinese and switch to English mode while using it. So I don't need to turn off the program or do anything extra to type English again. I can also choose different modes of input method for typing just Chinese. I just don't see how that can be done without two different modes. Then again, like mentioned in the article, errors do happen sometimes.
I thought it was interesting when the author said that most users just want to get their jobs done and care not about what the preferences are. It's really true. When there are too many options and preferences, I could care less.Whenever I use Photoshop, I usually use default settings for the preferences (and even today, I still don't know what are the actual settings in default). I just wanted to do my photo editing and graphic designs. I never put much thought into my act of ignoring those settings. Now that I think about it, maybe they should have made that easier for me. I should probably also keep in mind that my users might run into the same kind of problem.
I like to customize things! However, I would have to agree with the author that "personalizing an interface in a shared environment is an invitation to disaster." I only love customization when no one else is allowed to mess with my settings. I can only imagine the frustrations the users could cause each other if everyone who uses the interface tries to customize it toward their own likings. Making our interface nearly optimal would probably solve the problem, but I still think we should allow some room of customization. What if you designed something for mostly right-handed people, but someone is left-handed? Hey, maybe then we should actually have two different modes?
Maybe a well-designed and humane interface would not need to split into beginner and expert subsystems, but sometimes it's nice to have. Especially when hot-keys are involved. Like in Photoshop, an expert would probably know that "control + T" on a selected object will allow you to transform an object freely. However, for a beginner, he will probably need to step through the menu of "Edit->Free Transform" to achieve the same effect until he learns the shortcut. If the designer take away the "Free Transform" option from the menu, beginners might just assume such option doesn't exist.
Overall, this has been an informative piece.
Denise Ngai - Feb 17, 2009 12:50:03 pm
Raskin states, "The more monotony an interface has for a given task space, the easier it is for the user to develop automaticity, which, after all, is fostered by not having to make decisions about what method to use."
He has a good point. Some people, when given choices, get more confused. However, I personally like having more options when executing a task. For example, on my OS, I have the option to right-click-delete a file or just click on the file and hit the delete button the keyboard. Having choices allows for people to choose which mode of execution they prefer. A highly monotonous interface would force people to do the same action for executing a task. This may become an annoyance to those who have difficulty doing such an action.
I do agree that users shouldn't have TOO many options for executing a task, but they should still be given options. Therefore, more monotony is not necessarily better, but rather, a good balance of monotony or NEAR monotony would be the best for an interface -- offering users a good number of options yet not overloading them with too many or hindering them from finding what they feel comfortable using.
Jason Lo - Feb 17, 2009 03:56:38 pm
I disagree with his idea that there should be on gesture per command. There are times when I want to browse the internet using the almost exclusively the keyboard or only the mouse, and Firefox needs gestures for both the keyboard and the mouse. I disagree with the idea that modes are a bad idea because it helps convey the idea that each mode has a specific purpose exclusive of the others.
I agree that user preferences can sometimes overwhelm people and waste people's time. When I first start using a program I often look through the preferences (which can be extensive) to see if there is anything I want to change and what is the space of changes I can make. This is a waste of time; however, I think putting in preferences is preferable to putting tons of checkboxes or selection boxes across the interface that make it difficult to find a setting when u just know u need to change something. The centralization and organization of preferences is important, which annoys me when some programs have a tools>settings and preferences. It seems user preferences are here to stay.
On the idea that setting a well made interface and not allowing customization. I disagree, often skinning happens for aesthetic reasons. Firefox enables a lot of customization through setting the config file which I use to obtain the look I desire that is very different from the default look.
I think beginner-expert modes are fine, beginner mode shoudl be able to access all the expert commands if necessary (say through a more convoluted manner such as clicking through menus). It requires careful design to make sure the beginner design helps to progress to expert in enough time.
Jason Lo - Feb 17, 2009 03:56:38 pm
I disagree with his idea that there should be on gesture per command. There are times when I want to browse the internet using the almost exclusively the keyboard or only the mouse, and Firefox needs gestures for both the keyboard and the mouse. I disagree with the idea that modes are a bad idea because it helps convey the idea that each mode has a specific purpose exclusive of the others.
I agree that user preferences can sometimes overwhelm people and waste people's time. When I first start using a program I often look through the preferences (which can be extensive) to see if there is anything I want to change and what is the space of changes I can make. This is a waste of time; however, I think putting in preferences is preferable to putting tons of checkboxes or selection boxes across the interface that make it difficult to find a setting when u just know u need to change something. The centralization and organization of preferences is important, which annoys me when some programs have a tools>settings and preferences. It seems user preferences are here to stay.
On the idea that setting a well made interface and not allowing customization. I disagree, often skinning happens for aesthetic reasons. Firefox enables a lot of customization through setting the config file which I use to obtain the look I desire that is very different from the default look.
I think beginner-expert modes are fine, beginner mode shoudl be able to access all the expert commands if necessary (say through a more convoluted manner such as clicking through menus). It requires careful design to make sure the beginner design helps to progress to expert in enough time.
Chunwei Lai - Feb 17, 2009 05:20:02 pm
I particularly liked how the author refers to everyone to being blind "to the world outside of our locus of attention" and how a habituating feature allows the 'blind' to use the interface methods. The difference in the starting point makes a great impact as to how one formulates a habit (same starting point regardless of current position or starting with current position). It may seem to be a minor nuisance but can quickly become a (good or bad) habit over time.
Another point brought up is the number of buttons on an interface and how it relates to the learning curve. The author noted some interfaces with few button but were difficult to use and learn as well as interface that had numerous buttons but had an easy learning curve. The use of color-coding to aid the user in quickly making judgments and simplifying the interface.
In addition, the author also paid particular attention to transition and seems to prefer a seamless transition (the Canon Cat going to sleep in 5 minutes and turning on without delay when used). Needless transitions from state to state or mode to mode can complicate the process for a user but if the interface was designed such that the transition was not visible to the user, it can simplify any process regardless of the number of states or modes.
Anjana Dasu - Feb 17, 2009 05:02:59 pm
I would use the term monotonous, tongue completely in cheek, to describe this article...
Okay, got that out of my system.
I just couldn't bring myself to agree with or even be convinced by many points in this article.
- MONOTONY: At the risk of repeating many previous comments, I'll just give the example of keyboard shortcuts. If monotony was the accepted best practice and users could only do Edit->Copy, life would be very slow. Similarly, if users could only do ctrl-C or cmd-C, how would they get to know of the shortcut? I am sure most people learn of the keyboard counterpart by seeing it in the menu next to the Copy choice. As another example, take the tab button. Suppose I were filling in a multiple-field form online that I could either send immediately or save and come back to for sending at a later time. If I were going to fill out the whole form at once, I would use the keyboard entirely- I'd type in each answer, using the tab button to move to the next field and finally use enter to submit the form. On the other hand, if I were filling out only parts of the form, I might fill out the first field, use the mouse to scroll down to some field lower down on the page, and then scroll down some more to click on the save button. If the system were monotonous as per Raskin's definition, the process would become literally monotonous. In the first scenario, if I had to click to move to each field, this would be irritating, and in the second scenario, if I had to do several tabs to reach the field I wanted to fill, this would be equally irritating.
- BEGINNER-EXPERT DICHOTOMY: I agree with the author when he says that a system should not arbitrarily switch between a beginner and an expert mode. However, I don't agree with him when he says that there should be no differentiation between beginners and experts. Let me take for example, (the severely outdated) Yahoo PageBuilder (or for a more up-to-date tool, Dreamweaver). In pagebuilder, there are two clearly delineated modes, which correspond to beginner and expert. A beginner uses templates and WYSIWYG interface, but an expert can compose their own html. I think having a division between the two systems is appropriate and at the outset, the user can choose their preferred mode. Dreamweaver is even better because a user can work in WYSIWYG and an expert can then switch to html-editing mode.
- CUSTOMIZATION: I didn't like how Raskin was so down on customization. I think to some degree customization is desirable. Take for example the dock on macs. Not all users have the same applications on the doc and they are not in any standard order; however, a mac is usually a personal computer, so it makes sense for a user to be allowed preferences. If someone else uses your computer, they might be disoriented for a minute because your order of application is different than their own, but it is still standardized because the icons are still consistent. I think personalization is a feature that should not be ruled out entirely-- especially on the premise that we are the "competent user interface designers" who make "nearly optimal" interfaces and "personalizations can only make the interface worse." I think we should be careful about what we allow a user to customize-- i.e. a user shouldn't be able to, as Raskin says, turn a red button blue, but he should be able to hide a menu that he hardly uses.
Sean Hansen - Feb 17, 2009 06:50:00 pm
This guy has taken an unjustified stance on customization. It may very well be that there's some sort of optimal user interface for all users for a certain application; however, we have no idea if there is. So, when he makes the argument that customization is a cop-out for on the ui designer's part because he can't reach this optimal interface, he's saying that designers are failing for being unable to finding an unknowable path to a theoretical interface. While it's true that not all customization options are necessary or are themselves well designed, there are still going to be aspects of the interface where a designer has to say "I don't know what you want, but you do."
There are also the cases where complete customizability is the desired feature, the most prominent example of which is mmorpgs. If you do a search for game screens on google image for any mmorpg that caters to ui tinkerers, you'll find that the vast majority of users arrange their screens in completely different ways. You could argue that this implies that the users don't really know what they want and are groping for the "optimal" interface, but I would say that each user is simply creating an interface where they know exactly where everything is because they have some kind of explicit/implicit ordering system that makes the placement of every feature logical (i.e. something tells them that that specific button should be there). As a result, they reduce modality errors as much as possible in their own use of the game.
Anatol Tsang - Feb 17, 2009 08:58:07 pm
I agree with the article's comments about customization. Although customization can be made convenient, it sometimes makes it difficult to learn new things, such as learning how to do something simple (like access files) on your friend's computer. I think that in order to have command customized, there must be some sort of framework for the customization. An example would be the macro commands of certain RPG games: there is a menu at the bottom of the screen that you can put hotkeys for spells and skills so that you can access them easily.
As for the mythological difference between beginners and experts, I do not know whether or not it is true. Logically, having the same commands for beginning and expert users would not make that much difference, but this leads to different modes corresponding to the same action. I guess this is acceptable if the "expert" action is hidden so that beginners would not be confused by the multiple ways you can do things. This is why I do not agree with monotony with a certain extent: having extra functionality for beginners that would not clutter the expert user can be useful for the learnability of the systme. An example is hotkeys and shortcuts. Beginners can access functions through menus and pull-downs, but experts can learn how to access the same functions using hotkeys and shortcuts.
Colin Downs-Razouk - Feb 17, 2009 07:03:41 pm
I did not think that this chapter was a worthwhile read. Most of what was said in the chapter could be lumped in to two groups: things I already understood and things that I disagree with. One exception to this rule was the discussion of Noun-verb vs Verb-noun actions. I do agree that noun-verb actions are generally more useful than verb-noun actions. I also think that the reason for this is that most actions in the physical world are noun-verb. Things like picking up food and eating it, or opening the computer and writing an e-mail. There are some exceptions, and these are usually related to tools. You pick up a tool and you fix something. In this case, you are picking up the verb essentially. The reason palettes are verb-noun form is because the palette options are tools, and it is natural to pick up a tool before the object you are going to use the tool on. It is interesting that Raskin says that there is no noun-verb solution to this problem, because a noun-verb solution would, in my opinion, make an interface less interactive.
Yin-Zen "Johnny" Hwang - Feb 17, 2009 10:07:49 pm
it seems like most of the readings we've done explicitly identifies many design problems that some of us have already internalized. for example, the mode idea is pretty much internalized by most of us. we know that while designing interfaces that it's a very bad idea to overload ctrl keys with functions different than what's already used in other interfaces.
reminds me of the aircraft idea. those controls are really counter-intuitive for first time users, including on flight simulators. kk push joystick up WTF AIRPLANE GOES DOWN?!? yep. excuse my brevity, i'm running a really high fever right now =((
Alan Young - Feb 17, 2009 09:27:46 pm
I feel that this article provides the terminology and technical descriptions that are necessary in describing some user interfaces concepts in a clear and precise way. A lot of the concepts were intuitive and were readily familiar to me but it was interesting to see Raskin describe them so academically and unambiguously. I thought that his convention of holding/releasing keys was clear but too tedious and exact. I think most users today, of both Mac OS and Windows, have become accustomed to the convention of seeing shortcuts just listing the keys that need to be pressed and we have automatically filled in the extra steps that don't need to be explicit.
The elaboration on modes can be essentially boiled down to the fact that modes add unnecessary variables that users have to worry about and so by eliminating them, users can expect the same thing based on habit. The preference for noun-verb actions over verb-noun actions is also clear from experience and it makes sense because it takes less effort to determine first what i want to act on before determining the action. Monotony essentially takes modelessness one step further by specifying one-to-one mapping between gestures and results and makes sense because if every gesture is mapped to a unique result, the user has less confusion and can always trust that performing one action will always result in desired effect, or at least some effect that the user knows will never change.
Kevin Huey - Feb 17, 2009 11:00:34 pm
The section about monotony was a bit disturbing to me. Yes, sometimes it's a good idea to limit the number of ways to get from State A to State B, but I think that having more than one method for the same action is better. Users can pick the most convenient method and remember just that one way. Of course, in the airplane example, pilots must learn all the methods since they are required to be wary of each button, but afterward the pilot can simply pick his/her favorite method for doing things and use that method each time. If one of the buttons fails, then the pilot can use a different way. If designers monotonize these methods and a button fails, what's a pilot to do? Simply make a distress call and die?
Also, the book's method for showing how to enact commands through pressing, holding, and releasing buttons seems more frustrating than the interface they're trying to replace. All those up and down arrows are too compact into a small space, and it takes me forever to read the whole command, especially if it's some form such as d down up f down up g down up ctl down shift down l down up up up .... I find that I understand the old interface faster than figuring out these compact arrows (that don't have white-spaces in-between each held or released button).
Cuong Ngo - Feb 17, 2009 11:52:33 pm
The radio example from the chapter reminds me of my in-car CD player. It looks pretty much the same as the radio. It has about 10 buttons and a knob like the ones of that radio. I find it extremely hard to switch between CD and radio mode. The texts on the buttons are not descriptive. I can't tell what a button does what. Going from one mode to another takes 5 to 6 taps, not to mention I have to tap the buttons in some order. It'd be nice if it had beginner and expert modes like most of today's applications, which I think is a good idea by the way. Novice users can learn to use the application quickly whereas power users can easily switch to expert mode with all the advanced settings they need. For example, I don't have to click on the "Advanced" button to change the character encoding that my Firefox is using since I only visit English websites. I don't want to change the font settings either. The interface is therefore much cleaner and easier to use.
Szu-Chun Mao - Feb 18, 2009 12:28:36 am
I have to say that I disagree with most of the author’s suggestions in this chapter. “Modes are a significant source of errors, confusion, unnecessary restrictions, and complexity in interfaces.” Is that always the case? He then uses the flashlight as an example to illustrate how radio button is better than toggles. His reasoning seems to make sense as I read it, however in reality, you should already know whether your flashlight deep in a duffel bag is on or off before you reach in. The light coming from the flashlight is already a good indicator of its current state of mode. I do agree that in general, radio buttons tend to be more clear and easy to use than toggle systems. But it’s not always true as in our flashlight example.
Moreover, I do not agree that a monotonous interface is necessary a better design for users. The key to create a personalized interface for users is by allowing customization. I think a good balance between monotony and customization is a better solution for interface design. Let’s take Amazon, the most successful online shopping store, for example, it uses fixed layout and design for their menus on the left, however devotes the center of their page to a personalized layout in order to maximizing their sales. Another good example is Google. Google has a simple design as the biggest search engine on the internet, however still offers a way to let you customize and create your own personal iGoogle page. Designs can get boring when simply no customization is allowed.
Ian Hildreth - Feb 18, 2009 12:38:26 am
This article has a lot of good points about the design of systems, but several I do not agree with as well. He describes at length a notation for keystrokes using up and down arrows to designate whether or not the button should be held or not, to make it as intuitive as possible. However, this causes clutter. For example, tapping a key once requires the key name, such as "k", and then two more arrows denoting down and then up. Looking at a number of these key combinations is tedious and confusing, with too many arrows to decipher quickly. I think it would be much better to only add an arrow if something is to be held down for length, or something even simpler than an arrow, such as a dot proceeding the letter. One thing that he pointed out that has been a remarkable advancement is the switches on the planes. They must be pulled out before they can be flipped. What a subtle change to make something error-proof! Not something thought about normally, but now that I know i appreciate it more. Also, I like how he compared having fewer and more buttons on a layout, and the advantages of both.
Carol Chen - Feb 18, 2009 12:58:53 am
I was surprised as to the dismissal of interfaces with personalization in the Raskin reading. While one could take the position that the task of personalization is a time waster, I wouldn't go so far as to say it is something that 'burdens' the user. In my experience, personalization has been an opt-in feature, completely optional and not at all required. When the user has the time and inclination to do so, they will personalize the interface.
I found myself agreeing with the rule of thumb that system guidance should be provided modelessly, without taking control away from the user. If the user remains control of as much of the system as possible, the system is providing a benefit to the user, rather than putting up roadblocks and constricting the user.
Timothy Yung - Feb 17, 2009 11:49:48 pm
Raskin's discussion on modes, noun-verb vs. verb-noun constructions, visibility, and monotony were very interesting to me. I found the read to be very informative. As I read the other discussion comments, I agree that many of the concepts were either already internalized or disagreeable concepts, but I think that setting in place the notations for the internalized beliefs allow us to communicate and improve on interface designs. If anything, this paper affirmed the internalized beliefs with explanations and source citations. As for the disagreeable concepts, they should be approached with an open mind as many of the ideas presented in the article were not applicable to all scenarios (as often stated in the article itself).
I won't list everything there is to discuss about the article, but I found the discussion on modes and monotony to be very interesting. The concept of mapping gestures to actions in a one-to-one ratio was novel. Of course, I take the design advice with grains of salt, but Raskin makes very good points about modes and their faults. Although I do not agree entirely with the reasons for monotony, I think it hits the right points when it stresses the simplification of interfaces and the avoidance of accumulating interface designs to preserve backward compatibility. Also, the argument that the beginner-expert dichotomy should be avoided was new to me but made much sense.
Kevin Nakahara - Feb 17, 2009 11:49:43 pm
I've got to say I totally disagree with the premise of the reading, which is Raskin's diatribe against modes. Because I personally enjoy customization a lot, I have no problem with the ability to toggle certain options on and off in order to suit my user tastes. Raskin's complaint seems to go against the ability to customize, and the idea of individuality itself. Maybe in his perfect world, everyone wear gray jumpsuits, uses the same computers, and eats at the same time, but not mine. I find that the choice to select something to my choosing, no matter how insignificant, helps reflect my personal identity and separates myself from others, and I think many other people appreciate that choice as well. Many of the examples Raskin uses often create more good than harm. Caps Lock is criticized for the possibility of its accidental implementation, but I can think of more hours that caps lock has saved me than minutes it has cost me. Maybe this is just an attempt by Raskin to justify why he can't master the interface intentions of all people, but I would gladly take a world with modes and options (which I like, a lot) than his world of human automata.
Mark Dhillon - Feb 18, 2009 02:06:35 am
I have to say that this was a pretty dry reading. Consider this ultimatum: If you design a modal interface, users will make mode errors except when the value of the state that is controlled by the mode is the user's locus of attention and is visible to the user or is in the user's short term memory. Is that really the best way to say that? I understand what he's saying about safe interface design and modes, but he's got to consider his audience next time he writes a paper.
Dwij Garg - Feb 18, 2009 02:22:21 am
It is interesting to note the argument Raskin brings up about fewer buttons not always being better. He gives us an example of two radios: one in his truck, and the other a portable radio in his home. The one in the truck can have 18 preset stations that are sorted between 6 buttons. Other buttons (other than the 6) have to be pressed in order to get to all the station presets. This is a very clean interface. However, on his home radio, there are 32 presets available, all of which have separate buttons. This interface, although very messy, is easier to use, and thus has less modes than the cleaner, truck interface! This clearly shows that it is not always satisfactory to only look at the modes and a clean interface in each design. The designer should also consider ease of use and functionality when choosing the right design for the product.
Moonway Lin - Feb 18, 2009 02:27:36 am
I disagree with Raskin's comments regarding verb-noun and noun-verb constructions. There are many important everyday functions that are verb-noun. For example, backing up a car. The driver must shift the stick to either R/Return or D/Drive ("Verb") to set up the mode first.
When you have to repeat a function several times (for example, using the paintbrush tool in photoshop on a number of different images), it becomes much more efficient to select the tool first ("verb") and then applying it directly on all the images ("noun"), as opposed to highlighting each image one-by-one and then selecting the tool in the noun-verb order.
Fortunately, a large portion of UIs support both noun-verb and verb-noun order, which allows the user to decide which is easier to use depending on the application.
Nalditya Kusuma - Feb 18, 2009 03:31:19 am
Some points that Raskin wants to pass out: 1. Either make all application use the same modes or not at all. 2. Modes can be vicious--cause problems because they make habitual actions have unexpected outcomes 3. Modes can put the computer--instead of users in charge of the application. 4. Adding customization certainly makes a system more complex and more difficult to learn. ((I totally disagree with this--some applications such as games need this!!!))
Derek Liu - Feb 18, 2009 03:25:08 am
The main purpose of this article, I felt, was to tell us that no matter how we design an interface people are going to make mistakes. It's mainly our job to minimize the mistakes made by people by learning from mistakes people have made in the past. However, no matter what, new problems will arise as an interface design, like all things, can never be perfect.
The article brings up a good point right from the start with the Control + . example. This example is indeed ambiguous and I myself has made the same mistake of typing Control and the + key instead of the Control and the period key. I have not actually checked to see if Control + + exists but this is indeed a problem that is still present in many instructions today.
Like the previous comments before, I disagree with Raskin's comments about adding customizable systems. Indeed it does make things a bit more complicated sometimes, however, I enjoy a customizable system much more than when I have to adhere to the system's rules of how I input things. Video games for example, without customization a player would not be able to switch his button configurations or invert his Y-axis when looking up and down (A few games have had this problem where I could not invert my axis and it was extremely annoying).
Phiroath Chan - Feb 18, 2009 04:17:18 am
"Time spent in leaning and operating the personalization features is time mostly wasted from the task at hand."
The agree strongly with the sentence above. I would be cool and fun to customize your features, but the more customization that is added to an interface the more complex and difficult to understand it is. That in itself is contradictory because the purpose of adding customization features is for the user to feel comfortable using the interface, but in the end it's just adding more things for the user to learn so is it really helping? I mean a user would have to learn how the interface works before discovering something to dislike about the interface, takes up learning time. Then the user will then figure out how to customize it to his/her liking, which will also take additional learning time so is it really worth it in the end?
Adit Dalvi - Feb 18, 2009 05:20:01 am
I disagree with the author on his ideas about modes. I think modes are essential to any UI, because people need options; this is true especially when there are different kinds of people using the same interface. Everyone has a different way of using interfaces, and if an interface needs to be successful by catering to many preferences, it needs to be allowed to work in different modes. After a while, people habituate to their current mode of usage and by providing more modes in an interface, it can be easily used by more people. I also think that modes are necessary for differentiating the usage of an interface for novices and experts. How else are you going to create an interface that works well for both these sets of target users?
Salman Rahman - Feb 18, 2009 05:33:30 am
This reading was extremely boring and monotonous <--- irony.
The author spent the first page describing terms like click and tap. These terms were familiar and understandable to me - until I read Raskin's disambiguation. I think that's pretty sad. In attempting to formalize to a ridiculous extent common and intuitive terms like clicking and tapping, I feel Raskin was being extremely pretentious and annoying, not to mention confusing. I did understand his need to define a notation for keystrokes because current forms as laid out in the literature can be nebulous. However, it was completely unnecessary that he spend so much text and so many examples describing it. That seems to be the theme with our readings: verbosity.
I really disagreed with the point about how customization hampers productivity. If you use the same settings for expert users as for novice users, people who are experienced will be slowed down by unnecessary actions. For example, if there was only one way to copy and paste, such as via the mouse, people who could copy/paste much faster using keyboard shortcuts would get jacked. The author seems to love the idea that having only one avenue of performing an action is the best way to go but I think he is wrong.
Along those lines, I disagree with Piroth Chan's comment about how customization is another thing for the user to learn. Only expert users will be customizing, and they would be customizing to options that they are already familiar with (otherwise it would serve them no purpose to customize and they would leave things as default). For example, let's say you are doing just fine in your room with your books arranged a certain way. Would you rearrange your books just for kicks so that you have a harder time finding them? NO! You would be a moron to do that. It only makes sense that you should rearrange your books so it makes things faster for you. Now imagine you are in some 'effed nightmarish country where all the books are arranged by the middle name of the author's great grandfather's next-door neighbor. Wouldn't you wish you could perhaps rearrange the books by title? But you can't. Because you are in Raskin's communist police state where books can't be rearranged. You are totally screwed.
Meiying Li - Feb 18, 2009 05:28:40 am
I personally have problems with switching between modes. That's why I don't like using a school computer to do anything. Being very familiar with the Windows' way to copy and paste, I have a hard time switching to Linux. Windows is being criticized for many aspects, but I like their idea of coming up with a new command line shell (Windows PowerShell) that supports both Linux and dos command syntax.
Also, I highly doubt that if not using different modes anywhere is a doable suggestion. Not all machines can be turned on and react to the user's input in just a second.
In the Noun-verb or Verb-noun design discussion, I will vote for Verb-noun in the MS paint's case. Picking a pen and a color before you draw - this is the exact way you would draw in reality.
Chao Michael Zhang - Feb 18, 2009 04:21:42 am
One of the things I noticed when going through this reading was the figure on page 39. It's labeled Figure 3.1, and depicts a pair of radio buttons with Locked and Unlocked as options. Though the reading says that "Confusion is unlikely", I think a new user who is unfamiliar with radio button designs could easily be confused regarding which radio button style indicates a selected option and which indicates the non-selected option. For example, in the picture on the left, we know the Locked option is chosen because the caption tells us that the chosen option has a dot in the circle. The fact that the caption needs to tell us this indicates that confusion is likely had it not. Thus, the caption contradicts the actual Figure. If I was a new user who had no idea how radio buttons should work, I would be confused as to which of the options was actually selected, since the circle with a black dot actually looks like an empty hole, and the one without a dot looks like it's protruding, as if it were filled in. What do you think?
Shendy Kurnia - Feb 18, 2009 06:36:23 am
Interesting reading. I am most interested in the passage that says it is better to let human adapt to computer's limitation rather than to design a computer that satisfies human's needs. Also, I think the basic point behind those many words of reading is a suggestion addressed by Raskin: an interface should be habituating; to make an interface habituating, it should be modeless and monotonous.
Sum Sum Wong - Feb 18, 2009 07:00:36 am
I agree with the author that "personalizing an interface in a shared environment is an invitation to disaster, as it means that interface can change without notice"(.49) However, this statement cannot be used to negate all advantages brought by customizable applications(e.g. Word97/98 in the reading). Computers are so wide-spread nowadays that I believe most of the people are working on their own computer rather than on a shared(public) computer. So customization can definitely make things easier for users and would not cause any "disaster" since any changes to the interface are known(and probably done) by the primary user of the application. (and admins of public computers can block the customize functions anyways). Also, customization is totally optional and no programs will force users to customize anything. So I cannot see any point that supports the "customization is bad" idea.
William Cho - Feb 18, 2009 07:07:45 am
I thought about all the times I was confused by not-so-clear gestures and modes. Usually, it was a small annoyance that I could easily fix by merely clicking the other option and not give a second thought. But in reality, that is a bad design. Anyways, Raskin brings up the point that user-customizable interfaces is not a good idea, because users are usually not knowledgeable in user interface design and will probably make bad choices in their customization of key mappings or settings or whatnot. For me, however, there is merit in letting users customize an application, even though it may take time to tailor the system to the user's own needs. There is the danger that one user may not be able to translate over to another user's customization, or that the documentation is no longer always true .... An option used in some programs is to let the user define macros, or a string of basic commands that can be executed with one macro command. This allows the user to customize their own macros that they may find useful for their workflow; plus, they can share it with other people. Random thought.
Sean Ahrens - Feb 18, 2009 07:50:13 am
I found this reading to be rather long and overly dry on technicals. I agree with the authors ideas mostly, however I do have a few disagreements. Raskin's insistence on monotony as the cornerstone of good interface design is one where I don't completely agree. I actually think that because there is usually such a diverse set of people using programs now, it follows that there are many tasks that users ask out of systems that the system was not originally designed for. If we insist on monotony when we develop systems then, we do not allow our program flexibility to meet the demands of changing customers. By designing a system with multiple ways to do things, we leave it to the users to determine which works best for their workflow, rather than the designer (who cannot possibly know all the potential users.
One point I strongly agree with Raskin on though is that personalization of programs should not be allowed on a shared environment. This, in fact, could be absolute havoc. Imagine if you went to your Google homepage tomorrow and it was someone else's. You wouldn't know where anything is -- your previous mappings become useless. In fact, customization on a shared environment does the exact opposite of what it is intended to do: to allow a user to personalize their software to be familiar, and thus more productive (low gulfs of evaluation and execution anyone?).
Sean Kim - Feb 18, 2009 09:39:11 am
In the user interfaces, the interpretation from a gulf of evaluation is important to develop and use an interfaces. Jef Raskin said, in his book “The Humane Interface”, that modes are a significant source of errors, confusion, unnecessary restrictions, and complicity in interfaces. That is, one of evaluation process, modes by improper interpretation can lead to bad result. In addition, there are trade-off between the modes that is capable to lead a incorrect evaluation and less request such as fewer buttons or simple controls. In addition, Jef mentioned about the difference between the noun-verb and verb-noun paradigm. He insisted that two paradigm is not symmetrical and their order can be considered as most important point for usability
Alexander Cho - Feb 18, 2009 10:24:21 am
This reading was quite interesting in highlighting the subtlety in common UI features and their advantages and disadvantages. It was also helpful seeing how they solved problems with the UI by taking advantage of the theory of the locus of attention in humans as previously mentioned in the case study of choosing a department to ship to. The balance of choice/ability and usability is quite easy to get wrong and very often hard to get exactly right. I also found the meticulous notation for keystroke instructions very agreeable, having experienced confusion on keystroke commands (especially those used for UNIX commands).
David Jiang - Feb 18, 2009 10:20:50 am
Though this article was really long, I did find it quite interesting. Starting with descriptions of shortcut keys I realized that sometimes even I get confuse on the the shortcut key combinations. I think the method where the author uses arrows to denote whether a key is being pressed is a very good way on displaying it. Although initially it may seem very complicated, readers quickly notices that the notation used is very informative.
Alexei Baboulevitch - Feb 18, 2009 10:34:58 am
The author's notation for overlapping keystrokes is interesting, but I fear it's far more difficult for me to understand than simply Shift+Ctrl+whatever.
"Modes" are certainly an interesting concept that brings me right back to finite state machines in CS61C. I always have a lot of trouble with stupidly-labeled toggle buttons; it's nice to finally have the reason spelled out in such concrete terms. I don't think I quite understand the author's reasoning behind disavowing interface customization. Different people use different tools; is it really that far of a stretch to say that some might benefit from rearranging their workspace? The discussion of "quasimodes" is a curious insight into human psychology. Why do people get confused by "real" modes, but not when modifiers are applied to normal keys? Do we view them as a new, imaginary set of keys?
The author's perfect system seems very similar to a functional procedure: no "states", one input one output.
Michael Cohen - Feb 18, 2009 10:38:16 am
Like many of the other commenters, I strongly disagree with the concept of monotony. The article in general seems to take the approach that the UI designer, or computer, should be in total control of the experience, taking all responsibility from the user. This may be fine for many purposes, very simple systems or systems designed for simple people. However, there is no way a designer can anticipate every need of every user. Thus, to make software that is useful for a range of people, a designer needs to let the user have some level of control. For instance, it would be horrible if there were a completely standardized, uncustomizible IDE.
Back to monotony, different ways of accomplishing a task are useful at different times for different people. I want to be able to set my firewall via the GUI, the command line, via scripting languages, and may be interested in different tasks each time. I also want to be able to toggle it on and off, in the GUI when I am configuring my network, as well as when I am configuring my security settings. While providing a single way to turn on the firewall may make it easier for my grandmother to have a firewall, crippling the system is not a great payoff. If necessary, software should just include a grandmother mode, where all buttons are large, simple, and colorful, and let the users who like messing with their computers continue to do so.
Siddharth Shah - Feb 18, 2009 10:53:55 am
Let me start off by saying that this reading was really long. Actually I don't mind that it was long; I mind that it was long and could easily have been condensed into something more reasonable. It WAS interesting, though. I found it intriguing that he advocates letting the human users get accustomed to the UIs rather than attempting to design a UI that matches up perfectly with the users' likes and needs. I also liked his examples, though some of them could have been trimmed down substantially.
Oh, and I'm coming down on the side of Verb-noun in general; it just seems more natural :)
Also, I feel that customization is a GOOD thing for productivity; power users can rearrange things just to their liking. Like he says earlier, no UI is going to be perfect for humans, and it's certainly not going to perfect for ALL humans; I say let them customize away.
Aaron Hong - Feb 18, 2009 11:05:19 am
The section on toggle buttons are pretty interesting. I've actually run into situations where labeling a toggle button can be confusing, and can see why he recommends that we avoid them. But I think that toggle buttons are not all bad news or just a ugly piece of history.
There are other ways to label such a button or indicate what is happening with the button. A common thing is having the button labeled one thing like "locked" and when it is pressed, the button looks like it is pushed in, while the label does not change. In this respect, it is like the check box where you are not exactly sure what the "other option" is, but in the case where it is obvious--if it is not "locked," then it is "unlocked"-- then I would say they are perfectly fine, if not preferable. Things like symbols can help also. Probably one of the most widely used toggle buttons is the "play" and "pause" toggle.
So yes, I agree there are plenty of unreasonable situations to use a toggle button. But I disagree on completely avoiding the toggle, there are also plenty of reasonable situations to use one. Just go on youtube or any other site with embedded video... there's one staring right at you.
Prahalika Reddy - Feb 19, 2009 12:51:32 am
It seems that the ideas pitched in the beginning section of the reading would have been good ideas many years ago. Nowadays, people are accustomed to the format that Raskin is against. If his new format with the arrows were to be used now, more people would be confused than helped.
I don't like the new format he proposes to for representing keystrokes. It seems overly tedious and cluttered to have the arrows for both press and release. It's also harder to decipher which sequence of keys are for one process and which are for another. With the current format used today, all the keys for one command are combined with '+' signs, and separate commands are separated by ','.
The section of the reading on modes was also something I didn't fully agree with. I can see where modes are a bad idea, and how they can cause huge errors. However, I feel it's necessary to have modes. Without modes, everything on a certain product would have to be done in one state. Each button can only have one feature and vice versa. To me, it seems this is not an efficient way of designing products. It makes more sense to me if buttons and other similar keys have multiple features to minimize the number of different keys that are necessary for any product.
