Conceptual Models II

From CS 160 User Interfaces Sp10

Jump to: navigation, search

Slides

Contents

Readings

Mattkc7 - Feb 10, 2010 08:16:43 pm

Alexander Sydell - 2/7/2010 1:19:59

Two of the main points in this chapter, making products as modeless as possible and not providing too many user-configurable options, reminded me of Apple's approach to software and hardware design. In particular, the iPhone exemplifies both of these very well. The main "input device" is a finger, and the UI is very standardized so that pressing a particular element in just about every app has a predictable effect, making the interface nearly modeless. On the user preferences side, Apple implements a very bare set of options - gone are those such as default fonts for browsing and emails - which leave the user to focus on the task at hand instead of constantly fiddling with settings. The industry consensus seems to be that, due to these properties, Apple has created a product which is easier and more efficient to use. In turn, this has contributed to the iPhone's rapid growth in market share.

However, it would also be interesting to get more controlled user feedback on Apple's design. For example, would adding more options appeal to a broader user base, or, conversely, would removing some of the more confusing options help? Would allowing multitasking, which would contribute to a more modal system, be seen by the iPhone's users as a positive or a negative? Looking at the iPhone's success and recent reports that Windows Mobile 7 will be limiting multitasking, it appears that Raskin's ideas are in fact correct as they are being adopted more and more in the latest systems.


Matt Vaznaian - 2/8/2010 21:14:17

I think that the mac keyboard is a good example of a product with tons of invisible features attached to it. I am primarily a PC user and when I first began to use a mac, the first thing I attempted to do was try out all the shortcuts I knew from Windows to see what effects they had on a mac. Most still work, with the exception of using command instead of control. I was trying one day to do the forward delete and realized there was no key for it. I played around and, being the genius computer scientist that I am, realized that you do it using fn + delete. Then I thought, hmmm, there must be tons of other functions I don't know about... one for every key in combination with the fn key. But why make all these functions invisible? The manual that shows all these shortcuts was never shown off when I turned the computer on for the first time. The features just exist, and I'm sure millions of non-computer science majors have no idea they exist. I'd be curious to know the reason behind why they are so invisible.


Vidya Ramesh - 2/8/2010 22:43:36

Raskin argues for modelessness and monotony and claims that product that espouses these two ideas would become so habitual that it would be addicting to users. I would have to disagree with his conclusion slightly. While I agree that modes are incredibly confusing and poorly implemented in 99.99% of interfaces, the 0.01% of products where modes are well implemented make great use of the tactic to offer incredible amount of control and functionality to the user. Ruling out a type of interface design just because it is often not correctly used seems to be a bit premature and not fully thought through. A monotonous interface also lacks in usability for huge portions of users who either are not familiar the type of design chosen or who are uncomfortable with it. For example, a user with poor visibility or poor motor control would prefer a design based upon keyboard input rather than mouse input. Yet a monotonous interface would be either very tailored to this type of user (in the case where most of the inputs were keyboard inputs) or very difficult for the user to use. Perhaps the perfect average user would be extremely content with a monotonous and modeless interface, but the multitude of users who lie on the extremes in terms of preferences and abilities would probably reject any idea of even trying out the interface.


Annette Trujillo - 2/8/2010 23:22:29

Addressing the issue of the lock and unlock buttons: Let's say there is a lot going in an interface, and there are many buttons and icons on the screen for doing different things. A great way of being able to have a user understand what each button does is a hover functionality, that when a button is hovered, a short and concise description of what that button does pops up. This avoids the problem of putting full explanations or even short explanations besides each button or icon. I have seen this slightly implemented, but not many programs offer this functionality. This makes the interface easier to use, since the user does not have to keep referring to the documentation, as well as less cluttered, if some information must be present by the button or icon.


Tomomasa Terazaki - 2/9/2010 2:55:56

I agreed most of the things that were written in chapter 2 of this book but this time I had many places where I disagreed with the author. The first part is where he explains about short cut keys. He says Command + n (which is new folder/document) is too complicated so they should write Command↓n↓↑↑. To be completely honest, if I see in a manual to do that, I will be confused. He said that the problem is he thought he was suppose to press the “+” sign but if I see the arrow marks I will hold onto the arrow marks on my keyboard, so it will be the exact same problem. Also, he criticizes that the best form of interface is a one you do not need to change from beginner to expert modes, but I think this is not true. There are always people who learn how to use an application faster than others, so there should be two modes. The best idea will be for the interface to ask the user if he/she wants it to be in beginner or expert mode when you use it for the first time in few months, so the user has a choice to make.

However, I do agree in three fields. When the author explained the part about locking and unlocking a document, it is much easier if it is a checkbox (I had a similar problem before, ended up taking five minutes to understand). Also, fewer buttons do not mean that the device is better. Fewer buttons just means it looks simpler but each button has more than one job (everything is modal) so it makes it more complicated. The final point I agree is that BART ticket machine is horrible. I was so glad a person wrote a book about how inefficient that machine is because at least three tourists have asked me how to use that machine and I am tired of helping them.


David Zeng - 2/9/2010 17:51:36

I feel like that the author is too strong in his statements about modes. Although modes can cause errors in the user from time to time, the existence of modes does not necessarily mean an error in design. On the contrary, I feel like there are times when modes help the user and make events or actions more explicit. For the most part, users will be used to switching in and out of certain modes of operation as it becomes more habitual. Of course, the text does cite some places where a mistake in the UI could lead to something critical happening, but overall, the statement that UI should never have modes is much too harsh.

Another interesting part in the reading is the comparison between "new" and "expert" users. The text argues that building an interface that switches between the two has often lead to trouble. It is true that this often leads to an unnecessary and bloated UI, but there is definitely a need to differentiate between the two users and consider what is necessary for each group. For example, imagine if you threw a bunch of middle schoolers into a room and had them start using C or MIPS as their first programming language. It definitely would not as well as if you used a more user friendly language. Thus, there should be a consideration into integrating both user-friendly and sophisticated tools into a single UI.


Charlie Hsu - 2/9/2010 19:36:00

This chapter of Raskin rang very strongly to personal experiences with modal errors in my life. When the reading mentioned the Canon Cat's lack of a power switch (since a power switch can do certain things in different modes), I instantly recalled a personal problem I had with my new ASUS laptop. The laptop came with a bloatware application called Power4Gear, which managed certain power options/plans for the laptop. You could customize all sorts of preferences (another sin the reading mentions!!) for each power plan, including what certain buttons would do, and how much idle time it took for the computer to sleep/hibernate. There were also some strange keyboard shortcuts I was unaware of... so after painstakingly crafting a power plan that I hoped to use for all purposes, I somehow switched modes (with no feedback given by the system!), and found that my computer would turn off at unexpected times.

My eventual solution? One of the exact solutions proposed in the reading to combat modal errors: remove the modal options entirely. Uninstalling the bloatware solved the problem. The other solutions proposed in the reading (making sure mode changes were present in the locus of attention and in short-term memory) were not applicable for this useless feature. A power option is something that should be running in the background, certainly not something distracting at the user's short-term memory.

However, there were some points in the reading I disagreed with. I do agree that monotony would be ideal in a perfect world, but sometimes the sacrifice of monotony can address mechanical limitations, such as screen size in the example of using cut-paste vs. drag-drop to move text. I think the tradeoff here favors two options instead of monotony. I also feel that the nomenclature Raskin used for keyboard shortcuts was convoluted and unnecessary. In my opinion, keyboard shortcuts should be kept short (3 keys at max) and be presented in a completely unambiguous way (Ctrl + . should not be placed in the context of a sentence). Even with only 3 keys, and one method of pressing them (hold-hold-hold-release all 3), there are at least a few hundred different key combinations possible, far more than any user could possibly need or hope to memorize for everyday use.



Daniel Ritchie - 2/9/2010 20:45:48

Raskin spends a good deal of this chapter building up an argument in favor of modeless interfaces, and it's hard to disagree with the pile of evidence he produces in support of his cause. In particular, he mentions one case of a Microsoft Word user accidentally striking the Control key in the middle of a sequence of key presses; this briefly puts the program in another mode and wreaks havoc on the user's document. This story brings to mind numerous similar experiences I've observed with Autodesk's Maya software, a professional-grade 3D authoring package and--in some circles, at least--laughing stock of interface design.

Maya has more modes than any other application I've ever used or seen used. It has at least five diferent modes for selecting objects in a scene. Many tools follow the maligned "verb/noun" paradigm and put the application in a different mode upon their selection. It even has modes which change which menus are visible. It's eminently customizable (another user interface "feature" which Raskin decries)--including its hotkeys, the accidental presses of which often lead to user frustration. I can't count how many times I've seen a new Maya user accidentally "disappear" an important menu or enter a selection mode they don't know how to get out of.

Since reading this chapter, I've wondered if it would be possible to construct a modeless application that does what Maya does, and I've come to the conclusion that it is not. This is not because modeless applications are some how fundamentally less powerful, though--it's because Maya, as it stands, tries to do too much; to be too many things at once. Rather than one feature-packed-yet-convoluted application, I would rather work with a suite of three or four different applications--one for modeling, one for animation, one for shading, one for lighting--that exchange data well between them. Each of these "mini-programs" could, conceivably, be made modeless. Some might argue that this approach is less desirable because users now have to learn four applications in place of one. I doubt that this holds true. Each one of those four applications would likely seem so much more straightforward to use that learning the four of them together would take less time than learning the old-school Maya.

In short, I'd like to Autodesk turn Maya into something like Adobe's Creative Suite or Microsoft's Office. Though, as we've seen, there are also problems with those applications. As with every issue in interface design, there seem to be no easy solutions--only steps in the right direction.


Richard Mar - 2/9/2010 22:25:32

Right after Raskin criticizes the notation of using '+' or '-' to separate keyboard operations, he uses arrows as notation. This notation is even more confusing, as it would then appear that the corresponding arrow key needs to be pressed. I think the '+' and '-' notations are just fine; if those keys are to be used in a sequence, an annotation should be sufficient for clarity.


Jeffrey Doker - 2/9/2010 22:31:13

All the discussion of modelessness made me think about how the iPhone fits into this discussion. In a way, the touch screen itself could be thought of a single button or a spectrum of infinitely many buttons (or touchable locations), and in this regard the interface could be thought of as being infinitely modal. But this isn't quite right, because in order to be modal the state of the interface cannot be in the user's locus of attention. For the iPhone, the state of the interface is indicated by the entirety of the touch screen display, and so the user's locus of attention is perpetually on the state indicator. Is this the right way to think about it? Even still, it is pleasing to me to ponder the idea that modality, when taken to the logical extreme, yields complete modelessness.


Kathryn Skorpil - 2/9/2010 23:07:48

When I think of a terrible interface, I always think of Maya. Maya is such a complicated software that it has a drop down menu just to choose the menu bar you need. This is perhaps ultimately what makes Maya complicated. The user interface is not very intuitive and it completely relies on keyboard shortcuts in order to perform basic tasks. Of course, Maya is complicated because it is a complex GUI for 3D graphics, however because of it's keyboard shortcuts and customizability, it makes it more complicated than perhaps it needs to be. At the same time, I could not imagine a better interface for Maya, and it obviously can be learned eventually.


Daniel Nguyen - 2/9/2010 23:33:49

The reading identifies interfaces with modes as an issue, citing the modality of the single button of the flashlight. However, I think that this completely ignores the benefit the interface gets from the simplicity of only having one button, as well as user expectation to have the single "on/off" button. Furthermore, the reading proposes that the complete lack of modes is the best way to avoid confusion for the user and says that the best form of mode is the quasimode. However, I feel that modes are beneficial, if not necessary, especially for very task specific applications that may require the prolonged use of a quasimode otherwise.


Jonathan Hirschberg - 2/10/2010 0:07:11

The idea that backward compatability is weakest and can lead to absurd interfaces that are an accumulation of incompatible methods is in direct contrast to the first reading of the course by Lewis and Rieman, which suggested that you leave generic features in new interfaces, even if they aren’t directly relevant to the functionality, so they can be used by those who are comfortable with the old system. I agree more with Raskin because I have witnessed a few occasions when software packages could not be changed substantially because of the need for backwards compatibility.


Mohsen Rezaei - 2/10/2010 0:27:47

One important thing that I believe was not really mentioned in this reading was that organization of the user interface along with their affordances really matter to a user. For example as we've been discussing so far using older models for our user interfaces would be a desirable idea for having users with no frustration. But the problem might be that user interface designers/companies sometimes try to make themselves popular by introducing new technologies that just turn people around from their products. This reading suggested that one good approach for introducing new interfaces would be gifting/prizing the users by, for example, giving them an expert interface instead of a beginner interface if the users once used the beginner's interface with no problem. On the other hand, one thing that was not mentioned, though, was that companies like Facebook, who change their interface often a lot, face difficulties and usually get bad feedbacks from their consumers. This happens because some people just cant adopt changes as much as a company want them to. Sometimes people have enough things to worry about in their life that they don't want to worry about things that might change that will force them to learn more newer and useless things. This is also shown in statistics for UI change and user adaptation in different research. Another thing that I thought would be worth mentioning in this reading would have been small percent of users that cannot adopt interfaces that only some users can. I believe if such most interfaces are in the middle and not at the extremes then most and maybe all the users of one interface would be happy with the product with that interface. This could be achieved by not only thinking about taking the UI design to the next level but by thinking about what user needs are.


Victoria Chiu - 2/10/2010 0:40:31

Although the author claims that having interface that can be personalized often just caused troubles, giving freedom to users is sometimes still necessary. Each user might be familiar to different kinds of interface and making interface customizable allows users to choose their most comfortable settings. In newer macs, when we want to see all windows laying out, we can press F3, which is on the left side of the keyboard, to get a view of all opened windows. This is a function that I use a lot, but I figured this setting is probably more convenient for right-handed users. If users are right-hand users, they tend to use the trackpad or the mouse by right hands. Therefore, when they want to see all the windows laying out, they can just use their free left hands to do so. However, for people who are used to using left hands for trackpad, they probably have to lift their left hands from the trackpad, press F3, and then put their left hands back to the trackpad (or having the right hands crossing the keyboard to reach F3). The differences between left/right-hand users is just an example of the necessity of customizable interface. Being able to save different preferences might help reducing the stress from not being able to recover to previous setting.


Aneesh Goel - 2/10/2010 0:55:00

The reading seems to alternate between insightful notes and overgeneralized commentary that limit it to being a guide to starting analysis of a system, not an actual set of suggestions for the system itself. I've had my own concerns about the Lock/Unlock problem, most often because of inconsistency in pause/unpause buttons which have only a symbol that could be a state or a command; also, making alternatives clear via radio buttons is a good solution to ambiguous check boxes. However, making Locked/Unlocked a radio button seems to be useless; describing the state rather than using a verb makes it clear what state a system is in, and in this case that state is visibly a Boolean toggle. If it were labeled "Locked with user-defined password" then it would be nice to know whether the alternative meant the system would do behind the scenes locking I should trust or the system is unlocked, but in in this case it seems to be a pretty clear situation. Furthermore, the proposed notation for keystrokes is horribly unwieldy. Yes, users need to learn that ctrl+. means hold ctrl and press period, not press ctrl and press +, but the users would need to learn downstroke and upstroke don't mean arrow-down and arrow-up in the same way. Meanwhile, once you've learned those things, a simple notation (and one that we have keys for) is offered by ctrl+. that isn't offered by ctrl\downarrow .\downarrow \uparrow \uparrow. Yes, we have no way to denote holding shift and pressing n, then holding control and pressing k, then releasing shift but continuing to hold control while you press w; however, any system that requires a command like that is already flawed.


Wei Wu - 2/10/2010 0:56:27

Raskin's view of customization as a deterrent of productivity and usability does not fairly weigh the benefits that user-specific options can provide an interface. Despite what he says about optimizing an interface for the largest, general group of people, there are still differences in preferences between individuals that a good interface should consider. It is fully possible for a setting to not make a task any more "usable" or "learnable" objectively, as he says it, but for such settings to better match the thought process for an individual user so that his experience operating the interface is more streamlined. At the very least, customizable "themes" for an interface has the potential to make a user's experience that much more enjoyable, which may in turn make them more productive.


Jungmin Yun - 2/10/2010 1:11:10

This reading was really long, but it was pretty interesting. I mostly agree with author's ideas, however I have some points that I do not agree with. First, I do not agree with the author's idea of monotony. I think that there are a lot of different people who are using programs, so users might ask different tasks for systems that the systems are not designed to. If we follow what the author says, our programs are not flexible enough to satisfy the demands of changing users. We need to leave it to the users to determine which works best for their needs to make system to be able to do things in multiple ways because the designer cannot know all the users' needs. Secondly, I also do not agree with the concept of customization because of the similar reason as above. Let's have window's start menu as one example. Not all users need to have the same applications on the start menu because they use different applications depending on their hobby, job, etc. Therefore, they change it a lot of times to make it convenient for them. I think customization is a feature that should not controlled completely. However, I think we have to be careful what we need to allow users to customize.


Jessica Cen - 2/10/2010 1:56:43

I agree with Karla Jenning’s quotation on page 37 of The Humane Interface. It is ironic that we become a prisoner trapped by the computer, which is supposed to aid us in our work. Because I was introduced to a computer at a young age, I was able to adapt to it and I got used to being its prisoner. However, older people have a harder time using a computer for the first time because they have been living their lives without a machine instructing them what to do. I believe that some older people refuse to learn how to use a computer because the computer cannot hear them, and they refuse to learn how to communicate with it since they know that they will be trapped if they do.

I also agree with Raskin when he says that "a well-designed and humane interface does not have to be split into beginner and expert subsystems." I believe that a good interface should try to be easy and simple to use for beginners and easy to remember how it is used when people stop using it for a long time. Like the Sony 2010 short-wave radio, a good interface can have many buttons but they must also have a "fast readily learned operation," (p54).


Jason Wu - 2/10/2010 1:59:34

I strongly agree with Raskin's assertion that fewer buttons and simpler-looking controls, and I find it irksome that many product designers are sacrificing ease of use in order to make an interface sleeker and more aesthetically pleasing. The phone with only digit buttons and an R button pictured in The Psychology of Everyday Things and the BMW iDrive shown in class are examples of this - what's the point of having a simple-looking interface if it ends up being a nightmare to use? Another example is the newest iPod shuffle, which I recently received as a gift. At first glance, it is certainly very minimalist and sleek, as it only has one physical button on the device itself and three buttons on the headphones. However, after using it for several weeks, I find the interface absolutely horrible. In order to perform functions are each mapped to a physical button on most music players, a user of the iPod shuffle must remember various sequences for a single button: clicking the button once plays or pauses, clicking twice skips a track, clicking twice and holding the button down fast forwards, triple clicking the button goes to the previous track, and so on...

On the other hand, I disagree with him about monotony, as I feel that giving users a reasonable number of choices for performing certain tasks can be quite convenient for users, allowing them to choose a method that best suits them. For example, Firefox allows users to manipulate the browser in several ways. When I use a desktop PC, I prefer to use mouse gestures to open/close tabs, go backwards or forwards a page, etc. However, when I use a laptop, the trackpad is not as convenient to use for gestures as a mouse, so I usually either click the buttons on the interface or use keyboard shortcuts. Without choice, a user might be stuck employing a method that they are not comfortable with using. Perhaps a better user interface choice is to allow the user to enable/disable methods to do a particular task (of course, Raskin would probably complain that users should not be allowed to customize the interface).


Owen Lin - 2/10/2010 2:47:06

I disagree with the author's one-sided bashing on modes. I think that many times, modes are necessary in a system to simplify the task at hand. Rather than keeping every function in a single, non-changing interface, you would indeed have a general, stream-lined interface, but it would be rather clunky since you would not be able to "shift" or "focus" into a different mode that might carry out your specific task better. For example, in Microsoft Paint, if you wanted to draw a rectangle, you'd click on the draw-a-rectangle function and it'll change the mode so that every time you click and drag, you'd be drawing a rectangle. The author, who supports modeless interfaces, would argue that this would be a bad approach. I think that as long as you keep indicators that tell the user that he is in a rectangle-drawing mode, and that you can readily undo actions, interfaces with modes can be simple and intuitive.


Yu Li - 2/10/2010 3:31:00

According to the chapter, in UI design often times less is more. Contrary to popular belief, user specified preferences and custom options are actually detrimental for accomplishing the user's task. Logically speaking this makes sense. By adding additional bells and whistles, the graphical interface can confuse instead of help the user. The more modes and buttons an interface has, the longer it will take the user to learn the functions (an example would be the Photoshop program). By allowing preferences, we end up burdening the users with extraneous information. However, this is not intuitive for customers purchasing products at a store. When I go into a store to buy something, most of the time I will make my decision based on how many functions or tasks the product can be used for (with the assumption that the more options the better, because I can do more things with my purchase). Nonetheless, it never occurs to me that buying a more complicated product can actually make my life harder, which means good UI designers must walk a fine line between giving the user too much freedom and giving them just enough tools to accomplish their goal.


Dan Lynch - 2/10/2010 11:45:18

On the topic of modes, the author does have a point. Modes can be confusing and cause what I would call a learning curve to become steep. However, when he mentions that he "will never learn" to catch when he is in a certain mode to me is a personal issue. For example, I grew up switching between what I would call modes with personal computers, as well as everyone else in today's society: when on a mac, on a linux machine, or windows, we have emulated modes where we have different keyboard commands. At first, I always had to remind myself I was on a mac or on windows, etc., but after a while, it becomes engrained. If this author had read the last reading (that our class read), he would realize that with repetition, these modes will become engrained. And what is the benefit? More functionality.

I have to disagree with the author in respect to the topic of modes. For example, a simple text-editor within a terminal could have almost no function whatsoever without modes. Modes are in fact what gives the text-editor, such as vi, its power. The terminal has only one method of input---the keyboard. Thus, if a text-editor within a terminal has only one mode, it would be only typing and deleting text. That means no searching, deleting multiple lines, or running scripts on your code or compiling while editing. The absence of modes is a much bigger catastrophe than the problem that the author poses is as a result of having modes.

Now, I do have to give some credit to the author---there are cases where modes aer not as useful. My example of the terminal I admit is limited, so lets consider when we have more than one input keyboard, and augment that with a mouse. Now an application could have the same functionality without modes. Menus could be clicked, and options can be selected to perform functions. Now, here is the downside of not having modes even in this situation. Modes would allow a user to perform shortcuts to these menu clicks, without substantial clicking. So I argue, that expertise and modes are correlated, whereas for the layman using some text editor with a GUI for example, clicking perfectly suffices and no modes are entered. In that sense, I suggest a combination of modes and not modes for advanced and novice users respectively.

I have to also state, that there are definitely cases where modes are required. I have a brain teaser if I am wrong: suppose you are modeling in a 3D program generating a model. What is the easiest way (on some high-level without implementation details) to allow a user to edit points on a geometry that already exists, and if you must have the invariant that a user is also able to augment the scene and build other geometry objects?

My conclusion is this: modes do not restrict, but liberate. However, they must be used correctly and for expert users. The baseline of a program should have defaults such that modes are not required, and customizing the interface requires knowledge of the given application. This logically seems like the best situation for all users since experts will be limited without modes and novices are limited with modes.


Linsey Hansen - 2/10/2010 13:52:08

So, I cannot say that I agree with Raskin's comment about how allowing users to personalize an interface means that the designer did a bad job. I mean, in some cases, the user might have a slightly different task than what the program was specifically meant for, and while the program can accomplish this task, the standard interface does not favor it. Or it could be that the user is part of the target user group, but just doesn't need some of the interfaces emphasized functions and would like to remove them from their immediate view. Looking at something like photoshop, which I am guessing was just originally meant for image editing while illustrator was meant for image creation, a lot of artists use photoshop over illustrator for their work (even when they aren't trying to go over a scanned pencil sketch). I guess this example isn't all that great, since a designer's job is just to meet the needs of their target user group, but I personally don't see how allowing personalization of an interface means weakness on the designer's part.


Esther Cho - 2/10/2010 14:37:01

This is the first time I've seen anyone suggest that customization is bad for an interface. The article delivers valid points however it seems a software with a more personal usage would benefit in customization, not just for the freedom but for the migration to a new software. As our first reading pointed out, implementing a faster way of entering a form might not be a good thing if it counteracts a habit a user has already obtained from another software. I think for professional use or community use (interface shared among many users) customization might not be beneficial in the overall objective, but I don't think it should be done away with in all cases.


Geoffrey Wing - 2/10/2010 14:46:51

I mentioned in my last response that people like choices, so I thought an interface with multiple ways of doing things would be good. After this reading, my view has changed somewhat. In some situations, multiple ways of doing things is not a bad idea. To delete files in Windows, I find myself both using the delete key and dragging items to the Recycling Bin. In addition, users often use computers in unconventional positions or may be working on other tasks. I could only have one hand to use for the computer at a certain instance, so using the mouse to delete files would probably the easiest choice. However, I do see the reason behind trying to reduce overlap. In my work in technical support, I have seen instances where the multiple methods have confused users.


Wei Yeh - 2/10/2010 14:47:25

I found Raskin's point about modes, and their related gestures being ambiguous and confusing, very interesting. I would like to bring up two examples of this I experience on a daily basis.

The first is the play/pause button on my iPod touch's music player UI -- the pause button is shown when a song is playing, and the play button is shown when the song is paused. Although I mostly don't have trouble figuring this out, occasionally I have to pause for a second to think about what I should do (when ambient sound dominates the music that's playing).

Second, table view column headers used for sorting are often ambiguous. Sometimes the down arrow means sorting in a descending order, and other times it means sorting in an ascending order. I always get mixed up over this. For instance, compare Thunderbird's table view vs. Mail's.

Both of these illustrates the point that modes are difficult to represent, like the Lock vs. Unlock controls Raskin brought up.


jonathanbeard - 2/10/2010 14:49:54

I find it interesting that although "we can only pay attention to only one cursor at a time" (Raskin 34), we still dream of computers with multiple touch input (not the multi-touch gestures, but the multi-touch cursors). Like in movies, such as Minority Report, users are using both hands to do simultaneous tasks. I think it will be interesting to see in the future if we are ever able to really do this.

Isn't an arrow just as likely to be mixed up with the arrow keys on the keyboard as the plus sign was for Raskin (35)? I think users just have to learn what the usual notation is. The English language isn't perfect, but we don't try to change it.

Maybe the best (although messy) way to present these commands is written fully out. That is how Raskin is conveying them without misinterpretation. Only when we try to abbreviate them do they cause confusion.

Just a side thought: I wonder why our keyboards allow us to use auto-repeat on letters? How often do we need to type "aaaaaaaaaaaaaaaaa"? It would be nice if this could be turned off. I never hold the 'f' key 200 ms to type 'off' (36).

I think adding a question mark, '?', to the end of 'Lock' or 'Unlock' would possibly make for sense (39). It seems that a lot of these problems are created when we try to simplify something, most likely to save screen space. Displaying 'Locked' and 'Unlocked' would only become more confusing to the user upon simplification.

Maybe the 'caps-lock' key could be supplemented by a window that shows up on the screen for a second that says 'caps-lock', similar in the way that Apple computers display the volume as it is adjusted.

I think Rankin's criticism of customization is very relevant to the iPhone operating system (49). Apple doesn't allow but very little customization and that's what everyone seems to complain about, but it ensures that their system works always. Apple defines what the iPhone is and isn't capable of and within that realm it works perfectly. It doesn't multi-task, which many non-iPhone users complain about, but if it did, the battery wouldn't last quite as long. And if Apple had allowed multi-tasking, notifications might not be as prevalent as they are today.

A final comment on modes, I find that I have move issues finding out a mode for something I want to do than remember them or misreading them. I guess that I can't assume that all computer users are as computer-savvy as college students who grew up with computers. My issue is more of a visibility issue. When I use PhotoShop, I don't know where to find all the keyboard commands for all the items on the pallet, which would help me finish projects faster.

The autopilot unit example mentioned by Raskin (67) doesn't seem to take into account the full details of remodeling the autopilot completely, making his argument no so persuasive.


Bryan Trinh - 2/10/2010 14:54:44

Raskin's concepts of modes helped demystify the somewhat elusive notion of simplistic design. Mode confusion is one of the main reasons why I prefer to use smaller modularized software as opposed to large packages that have substantial functionality. For example sketchbook pro is a digital sketching software I open up many times more than photoshop because of its single mode design. The simpler design made learning the program easier and I was able to receive much more functionality despite having less functions in total.

What was initially surprising was the expert vs beginner dichotomy did not justify the use of separate modes. At first this didn't make sense because typically expert users want more functionality than the beginner user, so how does the designer create a design to fit both needs. The command line idea proposed earlier in the article is probably the best solution to this. In a program called Rhino3d the command line lets the expert user access all the functionality in an indexed. This gave the expert user more functionality without changing the mode.


Raymond Lee - 2/10/2010 14:57:55

This reading made me think critically of many programs I've used in the past. Emacs is definitely a highly modal, non-monotonous behemoth of a text editor with so many quasimodes and key combinations that I'd imagine would draw some criticism from this author.

Firefox deals with Expert/Beginner gap by leaving eccentric advanced features (which sometimes unlocks additional UI features) in an about:config hidden registry. But for 90% of users, firefox is a single interface rather than an interface with a split expert/beginner mode, with just enough customization , such that beginners are not confused/bogged down.


bobbylee - 2/10/2010 15:35:21

The author complains in the user-preference settings chapter that allowing users to personalize their interface will make it more complex and difficult to use. But I support that tailored interface would increase efficiency for users albeit I understood his concern, which customizing an interface would pose a disaster on a shared computer. However, I believe it is avoidable and can be improved. For example, while we are enjoying having a customized interface/preference, we can also have a button for changing all the commands and buttons to default state. Such that when a new user comes to an unfamiliar interface, he/she can make the interface to default by one button. And even more, the system can store different customized interfaces for different users. On top of that, we can make the personalized interface portable, which means I can load my personal interface/preference to a totally new machine to me. So for the user's point of view, there is always only a mode, which they are used to, to an application.


Nathaniel Baldwin - 2/10/2010 15:49:20

I don't think I can tell you how angry this reading made me without resorting to obscenity, which I'd like to avoid. I suppose that it should have been a tip off early in the reading, when the author mentioned that "The rationale for the one-button mouse is discussed in Appendix A." Listen, even Apple has finally (semi) admitted that two buttons on a mouse is a useful feature - their new Magic Mouse lets you use two buttons. If you configure that in the preferences. Oops! That must be wrong too!

I don't want to sit here and rant about this article, section-by-section. I get that modal interfaces are to be avoided at possible, and the argument for that made sense and was fairly clear. Unfortunately, with that, like the rest of the chapter, the author came off to me as both absolutist and pompous. I remain steadfastly unconvinced that, for example, preferences and keyboard shortcuts are bad. Oh, and power buttons.

Maybe my "favorite" thing about this reading was how the author proudly told about 'solving' a requisitioning UI by changing from a "verb-noun" to a "noun-verb" interface, as he puts it. One not-so-subtle problem - his 'fix' made it such that the FINAL step in placing an order was selecting a choice from a list. I can only speak for myself, but I fairly regularly pick something next to what I actually intend to pick from a list. If that action makes a purchase and sends it somewhere other than where I am, well . . . maybe that's not the best solution, is it? Maybe that one button that the interface eliminated - the confirmation button at the end - served a purpose after all.

Grr.


Arpad Kovacs - 2/10/2010 16:04:12

Raskin raises many valid criticisms of modal systems in which the action executed by the interface depends on the system's current state; however I disagree with his assertion that all modal systems should be eliminated if possible. In situations such as tutorials, it is often beneficial to abstract away the most complex and generally unused features of an interface, even if there is a miniscule minority of users whose locus of attention may be focused on finding these particular features. As long as the modality is clearly indicated (eg with a pair of radio buttons: simplified interface / show advanced features), the benefit of fewer attention-diverting distractions for the vast majority of remaining users is worth the inconvenience to these very few oddball users. Furthermore, if there are too many options available in the interface, then modeless access to all features (eg through quasimodes) may be impractical, since the combination of shortcut keys required to access the feature may be too long to remember.


Sally Ahn - 2/10/2010 16:04:51

The section on the "Myth of the Beginner-Expert Dichotomy" caught my attention because although I agree with Raskin in that an adaptive interface is "ill-advised," I hesitant to disregard the notion of a "beginner" and "expert" user altogether. It seems to me that a system that switches between beginner and expert modes *automatically* is counterproductive because the switch itself forces the user to learn the unfamiliar aspects of the expert mode; in a sense, the system forces the user to become a beginner (of the expert mode) again. However, I don't think this necessarily means that we should reject the notions of a "beginner" and "expert" user altogether. For example, simplicity of the interface is important for beginners, but preserving this simplicity may limit the functionalities the application can offer. Current applications often provide an option for viewing more "advanced" features, and I think this is successful in minimizing the disorientation that automated beginner-expert mode switch may cause while still providing the user with all the functionalities the application can offer. Perhaps providing the user the option of gradually adding expert-level functionalities may further ease this transition.


Saba Khalilnaji - 2/10/2010 16:06:22

It was interesting to read the example about the modes on an RVP remote. I had a very similar experience in high school when I used to fly planes and I let my friend fly a plane and he reversed a servo. As I took over the plane quickly crashed. This example can apply to modes as well as interface personalization. If the interface had just applied the standard there would have been no crash. However with more complex user interfaces there's the possibility of personalization leading to improvements that the designer did not consider. Specifically to the visibility of certain features in the interface. Perhaps the most common buttons are not visible on the toolbar by default, changing such things can improve the interface.


Spencer Fang - 2/10/2010 16:19:30

The text mentions that the soft keys F1 to F12 on many computers are a poor interface to the user because it is unmnemonic, and may have their functions change when the mode changes. I think this less true for the original design of the F1-F12 soft keys. I remember reading the documentation for a Unix terminal UI library, and learning that those soft keys used to be placed on a row beneath the CRT screen. The bottom of the CRT would display a text label above each of the keys. This makes their functionality identical to the text's example about the airplane control panel with buttons that change based on the current mode. I think the point here is that even good design features from one interface environment might lose their good qualities when placed in a different environment for compatibility reasons.

Perhaps the best examples of the modal vs modeless interface designs can be seen in the text editors Vi and Emacs. Vi lets users switch between command and insert modes, which interpret keyboard characters either as text and cursor manipulation commands, or as entered text. The '^' character is interpreted as a command to go the beginning of the line when the editor is in command mode, and simply inserts a '^' character next to the cursor when in insert mode. Emacs on the other hand uses a combination of modes and quasi-modes. It seems that these modes are very subtle compared to Vi's ('^' always inserts a '^'), but they are still different modes. There are modes that tell the Editor what kind of file is open, so the "Tab" key might insert a tab character in a plain text file, but instead set the current line to the auto-detected indent level in a C source file. Instead of having a command mode, Emacs has many quasi-modes that involve pressing combinations of Control, Alt, and Shift. However, neither editor has a good interface based on the reading's criteria, because so much of their functionality is hidden from view. There is no way for a new user to figure out how to use the editors just by looking at their interface.


Alexis He - 2/10/2010 16:20:19

On monotony, I'm surprised the author brought up the example of the Operating Systems and how you can do things more than one way. The book claims that allowing more than one interface with which to perform a task would lead to too much time spent making the decision (like deciding whether to use the GUI or keyboard shortcut). But from first hand experience learning the MAC OS this semester, I feel having the two do not inhibit my use. Rather, allowing me to learn the new keyboard commands make navigation a lot easier and faster, whereas if I was only limited to the GUI, I'd feel extremely handicapped and slow (like I did on the first day). By hiding most keyboard shortcuts, this would allow a friendlier interface to GUI users, but still contain the faster features. I think OS interface is a bad example for monotony because keyboard shortcuts are hidden from first time users.

However, airplane autopilot control is a good example for monotony because, the way the book describes it, there's more complication in learning and seeing all the knobs and buttons for the same task rather than just learning one. I think the difference is perceived visibility for doing something more than one way.


Divya Banesh - 2/10/2010 16:26:17

In Chapter 3 of his book, Raskin gives some excellent examples of where user interfaces have created troubles for the users. For example, he notes toggles that change the label from "Lock" to "Unlock" and the changing of the cursor in Vellum. I found these examples interesting because, these examples show a lack of use of the design cycle. If the interface designer had iterated though the design-prototype-evaluate design cycle (or any other similar design cycle) and had tested the product on users, I feel these mistakes could have easily been detected and fixed. I feel like the interface designers didn't check their programs (or even prototypes) against users or these problems would have been found early in the development process.


Eric Fung - 2/10/2010 16:31:36

This reading suggests that modes for control are secondary to content delivery. This is definitely a significant factor in what makes Vim have a steep learning curve. Starting the program as a beginner, you would assume the default mode would be for inserting text, but it's one of five control modes, where there is little feedback for what each keypress does. I've also found myself accidentally in a different mode, with no idea what caused it or how to undo it.

But the author vouches for programs to be as monotone as possible, with which I disagree. I like having the ability to scroll pages across programs (Firefox and Adobe Reader) with either the arrows, mouse wheel, space bar, or Page Up/Down. Whichever function I use at the moment depends on where I want to keep my hands and the amount I need to scroll.


Conor McLaughlin - 2/10/2010 16:32:25

I actually feel bad about lambasting the reading for last lecture a little bit, as within the context of this new chapter it makes a lot more sense why the issues were important at the time. I really enjoyed and supported the notion of visibility (as already discussed with the Norton reading) and monotony. I know even as an expert I have suffered from the burden of habit when dealing with an interface, and when multiple modes are involved the situation has only been exacerbated. This has been especially prevalent with my use of the new Macs. I know they're, as the author supports in the appendix apparently, supposed to be easier to navigate with the one-button mouse, but if you have to hold ctrl to do a secondary click, it seems to be only adding complexity between the interchange of command and ctrl. Having the second mouse button makes use of more than one finger, just as we do with multiple fingers, while not going against the understanding that the mind can only operate on one task at a time. I feel this supports the idea of modelessness, while actually going against the author's own belief on the mouse subject.


Long Do - 2/10/2010 16:35:18

I think that modes are important even if they are sometimes too complex and troublesome. Remote controls are often filled with so many different buttons but because each button usually controls a distinct function, a user can remember the position whenever he needs to access that same button again and can do so without having to look at the remote (such as increasing the volume or turning the power on/off). If one must make a remote control that is aesthetically pleasing, I would suggest having very commonly used buttons on the remote, as well as a series of buttons that can be user-defined. This allows the user to customize some often-used buttons to their own liking and allow them the ability to remember the placement through habitual use. The rest of the functions that are more obscure and rarely used should be accessed through a touch-screen menu. The book discourages screens and switches that have multiple use because one might hit a button thinking that it was going to do a different function, but that is only if the button was used habitually, which the functions relegated to the touch screen shouldn't be. This saves space by not having a button for every function, and it allows the users locus of attention to be on the remote, which is important when he wants to find these specific functions.


Richard Heng - 2/10/2010 17:00:25

For this passage, what stuck me as most interesting was the author's dislike for customizable user interfaces. Personally, I find customizable interfaces to be much more effient at times. For instance, in Adobe Illustrator, the user can customize the toolbox placesments and visibility settings. I find this much more useful than having a static interface. There will be tools in a program that will not be relevant to all tasks, and should be capable of being hidden relative to the user's needs. One of the arguments of the author was that it breaks documentation. This can be remedied with a simple "Restore Defaults" function, and a "Revert to previous settings" button. Overall, I see far more advantages to a modular, customizable interface.


Michael Cao - 2/10/2010 17:00:54

In the reading, Norman lists a couple ways to minimize mode errors. The first suggestion is to not have modes. While this would eliminate mode errors completely, I feel that for some systems this would be not only very difficult to do, but having multiple modes would be extremely beneficial. Take the flashlight example near the beginning of the reading. It talks about how a flashlight has two modes, on and off. Clearly a flashlight with only one mode would not work very well. So while one might want to remove all modes, there will probably be a trade off between having multiple modes and having just one.


Chris Wood - 2/10/2010 17:01:41

This week's reading made me much more aware of the menial processes that all computer users are subjected to. I learned about how things such as how mouse clicks clicks work and how to better implement and describe keyboard commands. I learned what modes are and the problems that arise from modal interfaces, and I can say that I have experienced first hand a lot of problems with modal CAPS LOCK and INSERT keys on the keyboard. Preventing these types of problems is an issue I until now had not considered very important.


Peter So - 2/10/2010 17:06:36

I support Raskin’s opinion that the number of buttons isn’t what defines the ease of usability of the device but rather the visibility of the functions of the buttons. However, when looking at newer re-configurable controllers like the universal remote controls or even touchOSC for the iPhone I think the structure of the buttons take on the personality of the user’s preferences and that there is no single optimal design for button layout. Each user will have a different background experience that will affect the way they interact with your user interface. With this in mind, I believe it is better to make the results of the buttons as obvious as possible so that it can be understood by more people rather than concentrating on trying to create the optimal interface with the optimum amount of buttons.


Jeffrey Bair - 2/10/2010 17:19:58

The idea that customizable interfaces are a bad thing is interesting to me as a user who constantly likes to customize his programs. Whether it be for a game or a typing program, giving a sense of freedom for the user is something that I feel is important for the user to enjoy. What Raskin mentions in his article on modes is that this is often counterproductive since we, the user, are not as experienced with user interface design. However, I believe that users can often make improvements on user interface design as we can see through many open source projects where user input is greatly appreciated and added as functionality and can make the experience much better. A better solution than just outright taking out customizable features is to have saved profiles so that whenever you want the default user interface there should be a button to change back to the default and subsequently a button to change back to the saved profile.


Calvin Lin - 2/10/2010 17:23:56

Raskin argues that modes can cause harm in that it puts the computer in charge of the interaction and not the user. He asserts that it is better for the system to not restrict the user from having the freedom to perform other tasks instead of following a guided sequence. However, I would argue that today’s web culture and design philosophy has progressed towards providing the simplest, most natural, and thus guided user experience. This concept actually fits Raskin’s arguments about reducing user customization of interfaces. With most consumers being limited in tech literacy, average users do not want to deal with complexity. Interfaces with too many options or too much clutter are viewed as confusing. Instead, users have gravitated towards interfaces that are clean and aesthetically pleasing, and where the gestures necessary to perform the desired tasks are obvious and not complex. Touch screen interfaces have been immensely successful because it further simplifies input gestures – just point at and touch the object. Perhaps more importantly, users want to use devices that require the least amount of learning. In a sense, having the computer be in charge of the interaction has become desirable. It is the more tech-y people such as developers and computer enthusiasts who tend to prefer openness and flexibility. If everyone wanted this, platforms such as Linux and Android would be more popular than Apple’s, but this has not been the case.


Vinson Chuong - 2/10/2010 17:30:43

Many of the concepts discussed in this reading are pretty unfamiliar to me. I can't really imagine using a mode-less or monotonic interface for any of the tasks I do on my computer.

For me, customization is a huge boon in that I can easily change an interface to meet my specific needs. After all, interfaces cannot simultaneously meet the exact needs of every user.

Also, I can't recall making mode-errors with any of the applications that I have used. Perhaps this is due to my bias towards simple software that only do one thing and thus only have one mode. Software applications have been moving away from the all-in-one-package (AOL, Netscape, Microsoft Works, etc.) and towards more simple applications that do a specific type of task.

In discussing these concepts in class, I believe that many examples will be needed for I am having some trouble in seeing their concepts in my daily experience.


Hugh Oh - 2/10/2010 17:30:59

Affordance places its emphasis on accommodating visibility for the user to easily learn and use the system. However, affordance ignores the frequency at which the application is used and the fact that users, over time, will be able to adapt to an interface. Over time, affordance will actually cause inefficiencies. For example, without hidden shortcuts, dragging an icon over the screen into a trashcan can become extremely inefficient if the user has to do this task frequently.


Mikhail Shashkov - 2/10/2010 17:31:22

I disagree with the notion that UI systems should only have 1 mode. In particular, the claim on page 46 that "A fully humane interface would consist of exactly one range". Besides the fact that this is simply not possible for most complicated systems (coding interfaces etc..), I don't think it is humane at all.

I say this because, thinking abstractly for a moment, the human mind certainly works in modes. Having to bind each individual action to some sort of mental process (think key-stroke), is simply impossible given then number of neurons and connections in the brain. Chunking is the obvious solution; for example, chunking actions into scenarios; you achieve the sample result in different ways in different scenarios.

Likewise, I think it is wrong to conclude that a perfect human to computer interaction would employ only one mode.


Brandon Liu - 2/10/2010 17:35:56

I found Raskin's take on the "beginner vs expert" dichotomy really interesting. I definitely was in the opposite camp before reading the article. I wanted more elaboration on this issue so I thought about the multiple reasons why interfaces would be split:

1. experts know what they are doing beforehand and need to do it faster. 2. beginners might accidentally do something "too powerful" 3. beginners wouldn't know where to start learning.

In the context of both this reading and the one last time, all three of these reasons are false. for 1), beginners and experts should have the same mental model of what they are trying to do, and the interface should thus treat them equally. for 2) the previous reading made a good argument for reversible actions. for 3) I guess that having a difficult to learn interface at the get go is still better than having users start with one actions to accomplish a task, and then switching it later. Tutorial systems in computer programs are the best way to accomplish this task if they introduce new commands gradually.


Joe Cadena - 2/10/2010 17:44:09

From the reading, I’ve come to understand the importance of adapting functionality from other similar applications in order to prevent a disastrous user experience. I’ve also noticed products that try to “simplify” their design by cramming functionality actually produce a more difficult interface. The sense I get is to keep functionality as visible as possible and to label everything.


Kyle Conroy - 2/10/2010 17:44:45

   Adobe Photoshop exemplifies a program which switches between verb-noun and noun-verb actions, creating a confusing modal interface. Many actions in Photoshop can only be accessed on a object. Rotation, scaling, and manipulation of on-screen objects usually requires that said object is first selected. However, many tools, such as the paint brush, marque tool, and color picker represent the verb-noun metaphor. While a paint brush makes sense to be a tool, such tools as boolean operations on paths do not fall into the verb-noun or noun-verb category. Photoshop also presents many modes to the user, in the form of different commands based on the current selection or the current tool. The contextual menu at the top of the program is constantly changing, meaning controls that are visible with one tool are not visible with the next. Such menus can be great more providing detailed information, but create a problem when a user wants to access a function hidden in a contextual menu because they currently do not have the right tool open. It is therefore necessary for the user to remember the location of many options, and the specific application state required for such options to be visible.


Andrey Lukatsky - 2/10/2010 17:47:17

The author strongly argues against grouping users in beginner/expert categories. Although, generally speaking, I agree with him, I do feel that there can be some important benefits for doing this. Primarily, offering a simplified user interface for beginners who only need a small set of features will greatly enhance this user group's ease of use. For example, a calculator application could have a beginner interface for simple operations, and a second interface for more difficult arithmetic. (In fact, this is done on a lot of calc apps) In such a situation, the majority of users won't become "experts" anytime soon (as they will only use the basic features), and the beginner interface will make their lives a lot easier.


Wilson Chau - 2/10/2010 17:50:45

One of the main things that I got from the reading is the idea of affordance. We talked about this in class for a little and affordance is when the function and operation something is apparent. This is very important because it uses peoples natural intuition to help them through the interface. It also shows what happens when an interface doesn't have affordance, like in the case of the BART ticketing system. The system didn't seem to make much sense and was very arbitrary in its design, this made it very difficult to use and also very frustrating for the user. The user expects the system to have a certain level of affordance and when it doesn't it can lead to a very bad user experience.


Brian Chin - 2/10/2010 17:51:53

One part of the reading talks about modes and how they create mode errors, which can annoy a user. It talks about how expert users do things, often automatically, and because of this, mode errors occur for them, and how beginners make mode errors because they don't know any better. They go further and say that the only way to eliminate mode errors are to eliminate modes entirely. I think that this goes too far and is a bit biased. Modes do create errors, but they also make things simpler. If there were no modes, you would need to do something unique for each operation, and for a complex system, this would become impossible to manage. This would be like having a different hot-key combination for each action and each program. Also, the reading makes a big deal about an issue that causes minor annoyances, usually. Finally, even they admit that it would probably be impossible to completely eliminate modes.


Jordan Klink - 2/10/2010 17:53:25

Even though most of my responses have been critiques, I must say that I disagreed with the reading more than usual. The author claims that modes should always be avoided. In many cases, I agree with him and I can't remember how many times I've accidentally triggered overwrite in Microsoft Word. However, as a developer, the option of having different modes are often invaluable. Imagine having to type something in all capital letters without having the caps lock key. Or imagine having to find an error in a 100,000 line piece of software in an IDE that doesn't have a debug mode. I know this is an extreme case, but it is still valid. When I look at a program in debug mode it is in the locus of my attention because I know that I'm debugging the program. The mode in this case is not obtrusive, and is in fact, extremely helpful.

On the other hand, his claim that customization in a program should be avoided is ridiculous. Sure, you don't want to be able to accidentally change the configuration of your environment, but if a new version of a program comes out and you can customize it to be more like the older version that you're familiar with (or a different program altogether), then why wouldn't you? Why would you bother with painfully attempting to relearn everything about the program if you're already familiar with something else? A new user wouldn't even have to worry about the customizable features and could simply become familiar with the default. Hence the new users would be unaffected while those familiar with previous version would be largely benefited.


sean lyons - 2/10/2010 17:56:02

Raskin goes into great detail explaining the mechanisms, import and dynamics of various usability modes, toggles, and customization, and how each of these things can work orthogonally to similar controls for similar features in similar exnvironments. Competitiveness aside, would it be objectively better to have single, cohesive, design decisions made towards a unified viewpoint in a given environment, or to attempt to have all similar functions in similar applications all have the same terminology, with as similar interfaces and icons as possible?


Kevin Tham - 2/10/2010 17:56:34

The take away message of this article is for users to express monotony in their tasks. Particularly, it is choosing between "easy" and "advanced" modes of user interfaces. This article reminds me of my own personal decision to choose a representation of file management on my laptop computer. The article says that most people would choose the "easy" and longer way to accomplish a task because they are use to it over more "advanced" ways of accomplishing a task because they are not all the time intuitive. For example, clicking the "paste" button in Word, or using the keystroke "command v". In this case, the keystroke is not that complicated to remember, so most people after being exposed to the shortcut would use that over clicking the button. Now, moving on, would you use a text based evocation for programs, or button/menu based evocation? (the program is using Quicksilver, or using the Dock/Finder) For those familiar, with Quicksilver, its a keystroke based program that can launch programs. While this may theoretically boost launch speeds since typing is faster than navigating with mouse pointers, it takes adaptation. The advantage sometimes when choosing more advanced modes can be great, but there is a learning curve that we most overcome. For me, I wasn't appealed by Quicksilver. For most people, they tend to stick with things that work for them rather than choose new alternatives that could be more efficient and maybe sometimes more intuitive. Take for example on windows systems, the transition from Microsoft Word 2003 to version 2007. There was a new "ribbon" based GUI. Many initially hated it. In my experience I shared that same feeling. But overtime, I liked it more and realized it really was more efficient, intuitive, and more organized GUI, ultimately superior. The reason is, I (and many others) were use to the old interface that we have been using so long. Whenever there is a new GUI that is introduced, we should not be all that surprised by initial negativity. Also, when we design better UI's, we must correct problems, and try to minimize new problems, but there are also tradeoffs usually. Ultimately, human physiology allows us to adapt. The excerpt states that although we can adapt, we should ultimately aim to create a UI that can be used in the long run, which I too also agree. Designing a UI for each type of user as well is not a good idea either. Personally, minimalist, efficient, is good. Complicated, and unintuitive is bad even at the cost of speed because we have to initially learn to use it. I think that is a very important factor in designing UI's.


Darren Kwong - 2/10/2010 17:57:54

A modal, non-monotonous system offers convenience, especially in situations in which the user has limited access over controls. If one mode is not afforded by present resources, a different one can allow the user to accomplish his or her tasks. Taking advantage of affordances and meeting expectations of the affordances makes switching between modes and operating with them easier. However, it can be frustrating if the options and features are hidden and given low or no visibility. For example, a person might be familiar with an old system, and a new system might have the same features. The old features are affordances that are hidden from utilization. The new system emphasizes new features while making the old features difficult to access and setup. Why would the designer do this?


Richard Lan - 2/10/2010 17:58:22

The main problem with having multiple modes in a user interface is that it makes the system more complex by by overloading commands. When an interface responds in different ways to the same command, the user will become confused. Therefore, it is better to minimize the number of modes an interface uses, which will result in more regularity and continuity in the ways that the interface responds to inputs. Sometimes, this situation results from the fact that programmers keep all of the system's old functions while adding new ones on top of the old. This practice would probably be more intuitive for people who used the old systems, because all of the functions they are familiar with would be implemented. However, the added complexity and number of modes that must be supported serves as an argument to limit the amount of functionality that a system supports.

As systems become larger, the number of functions they support must also grow. Therefore, with the limited input choices afforded by the keyboard and mouse, programmer may be forced to increase the number of modes a system uses. However, another solution would be to specialize the system, so that it supports a limited functionality, but allows the user content to be much more specific, rather than general. This is, in a sense, what we are doing with the iphone apps. Because we have a very specific target user group, we are not required to implement multiple modes into our applications and only include functionality that is specific and useful to our user group. Indeed, on an iphone, it would be cumbersome to add several modes in the same application, given the limited options for user input.


Long Chen - 2/10/2010 17:59:02

The section at the beginning about graphical input device hits right on with a group of application ideas during our group brainstorm. Why isn't the iPhone used as a mouse or touchpad input device for the PC? Using the built-in bluetooth connectivity, the smartphone would move into the decent sized wireless input market. We decided not to pursue those ideas because the target group was too broad, but I still believe this is a big potential app idea.

I feel that this chapter really explains the idea modes introduce potential errors really well and in depth. These ideas and studies on design are really the drivers behind the simplification and reduction in features. The new designs that are resonating with consumers these days really focus on elegance and cleanness rather than bulky devices loaded with numerous features and modes that could lead to more errors.

The analysis of the old BART ticket booth made me chuckle since we also talked about in class together. Although our current system is much better than the version discussed in the book, the problems are still there. The input sections are not clustered together for some unknown reason, and money output is only in the form of quarters. What this case study suggests is that design will only continue to evolve and design is really about constantly making improvements.


Angela Juang - 2/10/2010 18:04:37

Having multiple modes can be confusing for the user, but at the same time, it's often a tradeoff that makes other parts of the interface easier for users. For example, digital cameras often have multiple modes that users can access by holding down a combination of buttons, and in these modes the buttons on the camera perform different functions. This combination is usually difficult to remember and not labeled in any way on the actual camera. However, the advantage of having these different modes is that they reuse the same buttons for different functions. Since cameras are small had have limited space for buttons, this is a reasonable choice to make because it can't physically accommodate enough buttons to cover all the functions without having to switch modes. Because of this, I think modes are often a very practical interface choice to make; there are ways to help the users keep track of which mode they are in and what buttons will do in this mode (for example, keeping color coded labels on the buttons with colors corresponding to different modes).


Weizhi Li - 2/10/2010 18:05:58

This chapter goes into particular and concrete analysis about the way users think and how information is processing should affect computer user interface design. The two key concepts are the nature of the human locus of attention, and the human ability to habituate behavior. The author details how he would design a whole new way of interacting with computers to take advantage of these two key concepts, and gives some particular instance such as Apple Macintosh and Canon Cat, which gives a practical guide for how to improve your own design.

Boaz Avital - 2/10/2010 3:55:41

The reading argues that you should make your program modeless, and dismisses that some programs are too complicated for that. I can't imagine something like Adobe Photoshop, which it's unbelievable amount of tools, doing the same thing every time you click in the same place. However, it would be a really interesting exercise to design Photoshop in a modeless fashion, and if you did well it may be revolutionary.

I see his argument about monotony but I think that if you're familiar with the different ways to do the same command, it can be useful. Take cutting and pasting: If you the text I want to move is short and I'm moving it a short distance, I'll select and drag. If it's long or I'm moving it a longer page distance, I'll cut and paste. If my hands are resting on the keyboard, I'll select using the keyboard and not the mouse. These are ways that make the program, to me, more pleasant to use. If you only want to use one then only use one.

Finally, I reluctantly agree with him on the point of interfaces that change to meet the user. I have for a while been interested in how you can use AI to adapt an interface to the user, but his points are too valid for me to think that's a good idea.



[add comment]
Personal tools