Sketching and Storyboarding

From Cs160-sp08

Jump to: navigation, search

Lecture on Feb 14, 2008


Lecture Video: Windows Media Stream Downloadable .zip



Eric Cheung - Feb 12, 2008 10:35:44 pm

I tended to agree with much of Raskin said in Chapter 2, especially regarding his opinions on confirmation steps. There isn't much different between typing Y, hitting "yes", or typing a longer or random word as people tend to just ignore the corresponding text and search for the magic word that will get them to the next screen. I also agree with his mention of interference. I often find that it helps more to read the assigned readings for this class without anything going on in the background. It's more effective to do the reading first, then something else, otherwise I tend to read very slowly and carelessly.

In Chapter 3, there were a lot of useful suggestions for interface design. His point about duplicating items in an adaptive menu instead of removing them was valid, though the overall use of adaptive menus can sometimes hinder the user instead of helping them. For example, when Microsoft Office added those menus that sometimes hide less used options, it became very annoying to have to manually show all the hidden options. In this case, the supposedly "favored" items were chosen somewhat arbitrarily, making the adaptive menu not very useful.

Jonathan Chow - Feb 13, 2008 02:57:57 pm

I think Raskin makes a very good point about automation when working with an interface and also about the beginner/expert dichotomy. I found it surprising when I actually stopped to think about it how much of what I do on my computer is automated (for example, closing windows with ctrl+w). I also noticed how often I found myself making mistakes because I was used to some other convention presented by another system (like when I press apple+w, the apple button corresponds to alt on a PC). I think that Raskin has a good view on beginners and experts. A system designed for experts really doesn't have an excuse for making it less accessible to the general public. The difference is that some users just use certain features less than others, but that does not make them a beginner.

I did have a question about Raskin's view on modes. Since not every interface is perfectly designed, we become used to pressing certain buttons when we desire certain effects (automation). Yet, this could lead us to getting used to less "humane" interfaces. So the question becomes, when we design a system, do we try to create a new interface, or stick with the same old things that everyone is used to? Or, do we allow the user to switch between modes for both? An example of this would be inverting the controls for a flying/fps game. Some people feel inverting the y-axis is natural, others don't. I think most games currently allow the user to select between either mode. Is this a bad thing or maybe an acceptable use of modes? The fact remains that something is always comfortable to some people and uncomfortable to others. I don't think there's always (or ever) any clear way for a person to do something.

Bo Niu - Feb 13, 2008 04:20:34 pm

There was a great explanation on why we need things like typing out delete when irreversible tasks are going to be executed. The detailed presentation of how human mind switch from consciousness and unconsciousness was interesting and helpful, and the ways program can take advantage of the locus of attention was something new to me. Even though it seems that the designers are trying to fool the users with these tricks but i guess the users' satisfaction do go up with the tricks implemented such as the card snuffling noise makes the user feel less delay time. Actually Windows should play some back ground noise when loading.

Khoa Phung - Feb 13, 2008 05:47:49 pm

I liked the point in Chapter 2 that it describes in detail how our cognitive conscious and unconscious work as well as how to take advantage and avoid problems in the design of interfaces. The example with keyboard and mouse got my attention in that these interfaces have been around for so long and used so much that it is so repetitive to most users that they can actually point their locus of attention on the actual task rather. Also, by having the locus of attention from the user, we can virtually do behind the scene processing which is actually important. This reminds me of AJAX.

Chapter 3 has very interesting descriptions about modes. I believe that is why I personally do not like gaming consoles. You are given 8 buttons; 4 for directions and then 4 other ones that you can use in combination to make special moves. If you look at kids or myself, I usually just hit all buttons randomly because each game has different combinations. Also, when I find one button to jump and kick, then that’s all I will do for the rest of the game. The rest is very confusing and the funny thing is that they even call them mode buttons. I also agree that user customizable interfaces are not always a good concept. I prefer the standard default settings, because then I know that I can still use the software with ease on any other computer or just reinstall. Custom settings are good for experts, but once you reinstall your program, you never remember which your options were.

Hsiu-Fan Wang - Feb 13, 2008 07:19:32 pm

The reading was very topical and well presented. I found myself highlighting pretty much everything he said in italics, which if nothing else, implies that I at least feel strongly about the stuff he found important. Piggybacking on Eric's comment on Office, I think that Office 2007 was a particularly interesting illustration of issues that Raskin raises. For one, the application is very subtly modal, with certain menus appearing or disappearing based on the current cursor position, which I actually find very helpful and rarely a cause for confusion, but I could see how too much context-sensitivity (and the fact that menus appear and disappear seemingly at random) makes it difficult to make some actions habitual. At the same time, I remember reading about the Microsoft Office team researching how much users customized their menus and found that the feature was very rarely used; customization was usually a source of confusion and rarely delivered any improvements in usability, which meshes very well with what he says about presenting preferences. (I suppose this would be an appropriate time to point out that the KDE philosophy of "lets just make that a preference" is bad, even if Linus hates Gnome.)

As I read the chapters, I was actually amazed by the number of things that I find in applications that really seem to agree with the conclusions he draws. His son founded a company called Humanized, which has a number of applications I used, and their program launcher was actually my first introduction to the concept of "quasimodes", though the implementation is marred by the need to hold the "activator" key down while typing out commands (which is somewhat tricky) as well as a verb-noun command phrasing (which is changing in a recent beta).

Long story short, an amazing applicable reading.

PS: Did I miss something? He mentions duplicating items for adaptive menus, but he also supports monotony in design... aren't the two contradictory?

Scott Crawford - Feb 13, 2008 09:18:58 pm

I thought that the idea of quasimodes was a great distinction. However, it's not clear that this may just be a fuzzier version of the 'what is modal for someone might not be a modal for someone else.' In other words, the distinction would depend on whether one person thinks of pressing and holding a button as a mode, or as simply a longer part of a set sequence of button presses which performs the same no matter the state. With regards to the Canon Cat example, where the keys did the same thing regardless of the current state, I think that works quite nicely, but in certain contexts (not all interfaces; only in the ones for which it makes sense) you could make it function somewhat like the 'adaptive menu' and that might be better. For instance, on the first push, it would select the style you use selected last, but on the subsequent strokes would iterate through the list as usual.

Reid Hironaga - Feb 13, 2008 10:53:13 pm

Raskin presents a thorough overview of the topics he presents with appropriate side notes of relevant issues outside the scope of this particular analysis. His mention of the apparent separation of cognitive consciousness, subconscious, and physical presence brings a new layer of depth to the previous readings we have encountered. The response to stimulus that the human psyche undergoes can be analyzed to understand how to best implement tools to mesh with our various levels of existence. He makes an important note to not go too far in common metaphors for the human mind. For instance, we cannot multitask with the precision of a computer, yet our focus can be directed very well to the most important or urgent stimulus present. I was initially shocked by his statement "The ideal humane interface would reduce the interface component of a user's work to benign habituation." This is emphasizing the efficiency of habituation, and our background processing of tasks as a means of limited focus with efficient productivity. This further emphasizes his previous contrast between human systems and computers systems. While we have senses of urgency and focus, computers only process commands in a more linear fashion with less of a simulation of stimulus to alter "urgency".

Zhihui Zhang - Feb 13, 2008 10:57:29 pm

Raskin's discussion on formation of habit seemed particularly relevant to me. I've often found myself hitting yes on "are you sure you want to delete" dialogs only to realize seconds later that i did not in fact want to delete the file. But as he also touches upon, it is very difficult to regain a user's locus of attention once that user has developed a habitual response. For example, the first few times i formatted my hard drive, i paid attention to all the warning dialogs and always 'made sure' of my actions. but after the 3rd or 4th time, the responses simply became habitual.

And at the risk of sounding repetitive (although I'm surprised no one has mentioned this yet) there's the example Vista's user permission dialogs . Raskin mentions that "any effective confirmation process is necessarily obnoxious because it prevents the user from forming a habitual response and from ever becoming comfortable with it." But for me at least, not only are vista's security dialogs obnoxious, but it has not prevented me from forming a habitual response. Even in Raskin's example of having the user type back a randomly generated word backwords as a confirmation, it would seem that the user would soon develop a habit of focusing the task of typing the word backwards rather than actually reestablishing the decision as the locus of attention. Obviously the notion of "undo" doesn't apply to many of the actions confirmation dialogs address, but for most cases, it seems like a good solution. (in fact, i sometimes find myself recovering documents out of the recycle bin in real life)

Ilya Landa - Feb 13, 2008 11:54:49 pm

This was much more applied reading than the previous one. And it would seem that one dial and 50 modes would be so modern! Instead of analyzing the reading, how about I talk about couple related examples from personal experience? I know, it’s a problem, but I’m into video games. How many of you have played a German space simulator X2? No one? Great game; hundreds of hours of mundane gameplay. However, the interface of this game is absolutely horrible. The creators of the game gave mouse just one function – steering; that’s right, no menu selection. And the menus are just lists and lists, nested in each other. Here is the sequence of actions needed to move freight between 2 ships docked at a same station: *Start inside a transfer-to ship. *Go to Station menu. *Select “Docked Ships”. *Select transfer-from ship from a list of all docked ships. *Select “Freight Transfer”. Select the freight name from the list of present goods, indicate the amount, and press Enter. *Tap Escape 6 times to return to cockpit view. All menus look identical and deviations from the sequence described above may result in arriving at a menu with some options hidden, character being transported to another ship, or actually finding the character actually floating outside his ship (thanks God, there is no toggle to put on/remove space suit). With its details and storyline the game is great, but why couldn’t its designer create a simple drag-and-drop menu, as is present in all RPG games? The only way to learn to play this game efficiently is to memorize “gestures” consisting of automatically going through all the game’s menus to achieve desired results. And, as it was pointed out in the reading, such “habits” are classical recipes for mode errors. And now, a counterexample: a Command Module of Apollo spacecraft had thousands on one-to-one mapped switches. Even though it was possible for a pilot to hit a wrong switch, such mapping eliminated mode errors. Now, 40 years later, a new spacecraft for reaching the Moon is in later design stages. Its controls differ as much from Apollo controls as controls on TNG Enterprise differ from the 60’s series. The new layout looks like this: pilots have steering joysticks in front of them, emergency switches on the ceiling, and all other controls are replaced by 3 or 4 large computer monitors. Thousands of switches and gauges transferred to several computer monitors – this system is built on modes. However, the designers decided that it would be an improvement over the old system. The pilots would be able to focus on important information without being distracted. And even though pilots would spend hundreds or thousands of hours in simulators, the actual trip would only take a week, so the sense of routine would not set in. The pilots would be constantly aware of the condition of the system, thus undermining one of two conditions necessary for a mode error. The moral? Software designers should avoid creating everyday software with the excess of modes. Users that use the same program for years are highly likely to find themselves in a mode error, given the opportunity. On the other hand, if it can be guaranteed that a device’s operator would be highly trained in using that device, and operating it would not become too routine or relaxed, the modes are acceptable as long it can be proven that they increase the device’s effectiveness and do not create too many new possibilities for errors.

Michelle Au - Feb 14, 2008 12:34:40 am

At first, I was very surprised at Raskin's use of the word "monotony" to describe a better interface. Normally, I think of "monotony" with a negative connotation, meaning boring or dull. However, after reading Raskin's explanation of a monotonous interface as one that only has one way to do a task, I can see his point. If the backwards compatible autopilot system was redesigned just to implement one autopilot interface, then it would decrease training time, confusion and opportunities for error, all important aspects of monotonous interfaces.

It makes sense that the more complex an interface gets with more features and ways of performing an action, the more difficult it is to learn the interface. Why is it that nowadays there are more products being advertised as all-in-one products with as many features packed into it as possible? Why does it sell so much when it only causes user frustration when learning the interface? Are people so focused on getting their money's worth of features that they're willing to sacrifice usability for a sense of value?

Gary Miguel - Feb 13, 2008 11:27:46 pm

A question this reading raises for me is: Why did I lose so many points for not having a detailed enough target user group in my brain storm assignment? Raskin seems to be saying, and I agree, that it is foolish to assume very much about a user's knowledge or skills. What is important is the task that needs to be completed. If an interface is made with human strengths and weaknesses in mind, it will be a humane one.

Also, modes are very interesting. I use modes a lot on my computer when switching between US and Chinese input methods to enter English or Chinese text. When I am in Chinese mode, a lot of stuff doesn't work as I would expect, so I definitely agree modes lead to errors and frustration. However, I can't immediately think of a better solution to the problem of inputting two languages with one keyboard than having modes. So my conclusion is that Raskin's ideas are important in that they focus on the strengths and weaknesses of common interface ideas, but there are some tasks that would be very difficult to implement in a fully mode-less and monotonous system.

David Jacobs - Feb 14, 2008 02:05:57 am

Am I the only person who thought that the recurring popping noise in lecture was set up as a demonstration the locus of attention? It seemed too appropriate to be a simple faulty microphone, but I'm not sure Maneesh is that good an actor (and that he would have wasted the pedantic value had it been designed). Whether it was pre-planned or some kind of incredibly well timed AV malfunction, it illustrates Raskin's distinction between the focus and locus perfectly. It wasn't hard to focus on the lecture during the first few times the pop sounded. After a couple minutes however, no matter how hard I tried to ignore it, the locus of my attention shifted to trying to figure out where the sound was coming from. It even seemed like the sound was increasing in frequency, which could be caused by some interesting perceptual artifact of the shifting locus (or maybe because it really was increasing in frequency...). In any case, I think it provides a good example of how the locus of attention can be moved via external sources, rather than changing internal goals.

Gordon Mei - Feb 14, 2008 03:13:02 am

Regarding the cognitive unconscious, the article brings up an example about a case of braking and acceleration pedals being swapped, where the driver adapts for a few blocks, but will ultimately slam on the original brake if a child were to dash out onto the street. We do not think about each step (engine, braking, etc.), for repetition in the task execution makes it automatic. Likewise, these habits developed from routine situations extends to the notebook computer keyboard. Across manufacturers, these keyboards vary slightly in layout - perhaps the backspace key is shorter such that the plus key is accidentally hit by those expecting to hit the left side of the backspace. Or perhaps the "fn" function key and Ctrl key are switched (sometimes, the "fn" can be on the left or right), causing mistakes by users who hit "fn" + C to copy because they were trained to remember the Ctrl key being the lower right corner key. This goes on and on, with the relocation of the "Windows" key, or the "tilde ~" key.

Similarly, in a prompt to delete files, a user might grow accustomed to hitting the left button in the prompt window for "Yes", but inconsistent programs swapping the ordering of buttons "Yes" or "No" or "Cancel" will yield more mistakes. Or the RPV crashes from having controllers with servo reversal switches is vaguely connected to the issue of people experiencing trouble with reversed mouse navigation (down is up) in areas like video gaming, simply because of acquired habit. It is therefore important for user interface designers to prevent situations where inefficient workflow habits can develop from a poor design.

With the locus of attention, it's easy for the users to grow so focused that they miss crucial feedback signals and indicators that the UI designer thought the user would not miss. However, as in the case with the pilot so concentrated on the landing process that he didn't notice the landing gear warning, consumer user workflow efficiency depends on this level of focus. And poor UI choices would distract the user from the ultimate task goal as he or she diverts resources to figuring out the interface quirks.

Concerning modes, the buttons that change functions at night in aircraft cockpits calls to mind the dynamically changing keyboard using OLED (organic light emitting diodes), where keys can be visually relabeled as keys are remapped. The problem, as the article highlights, is that legended buttons get obscured by fingers, and that users habitually expect the location of that prevous particular button to still be there, almost as though again through muscle memory.

Benjamin Sussman - Feb 14, 2008 03:30:55 am

I really appreciated Raskin's seemingly bulletproof argument against modes, however, after I was done reading the section I realized that when it comes to actual implementation it's not so simple. In non-touch screen cell phones, there is limited real estate to place buttons or to put lots of labels on the buttons. If we want the phone to do anything other than call (play music for example) we are then forced to reuse buttons in the new application. To do this, creating a modal interface is unavoidable which is clearly unsatisfactory. One solutions could be adding more buttons, (which Raskin seems not to mind in his glowing review of the Sony radio with 32 preset buttons) however this would make all of the buttons less readable and harder to press as well as make the primary task of the device (to call people) more difficult. In order to have a single interface allow for multiple functions which are not necessarily related there are very few non-modal solutions. I think Raskin has an extremely valid point, but his solutions left a bit to be desired, however it must be simply that it is a very hard problem, especially on constrained devices.

Henry Su - Feb 14, 2008 08:05:04 am

I find Raskin's Chapter 2 particularly interesting. Firstly, it contrasts a bit with last time's article, in that it advocates interfaces that are habit-forming. Last time's article, on the other hand, said that interfaces should be direct, and that while habit-forming can make some indirect interfaces easy to use for the experienced users, it is still not a good idea (the "non-GUI" vim is an example that today's article would approve, but the previous article would not). Secondly, I found the discussion about automatic deletion interesting, and I suppose that I may be one of the few who actually read the prompts and do not automatically click OK or Yes for everything. Though my habit of reading almost all prompts make unintended actions almost impossible, it also slows down productivity because I almost never caught myself ending up clicking Cancel or No.

Roseanne Wincek - Feb 14, 2008 08:31:12 am

I thought that these readings were really interesting. I think consciousness and how are brain works are so cool. The author brings up good points when talking abot how we have two modes of thinking: the cognitive conscious and the cognitive unconscious. Really, as UI designers we have to cater to both. Especially once habits are formed and tasks go from decision-based branched processes to repetitive learned processes. I feel like those are the times when you lock your keys in your car, eventhough you realize your doing it as you shut the door. Or accepting a dialog box even though you know you don't want to delete the file.

Chris Myers - Feb 14, 2008 10:39:05 am

I think an important part mentioned in the text, related to contextual inquiry, is that users asked for a customizable GUI - and wouldn't use one unless it was customizable. The truth is, the best interface is one that is consistent. At least, a consistent interface is one that is best for getting things done. I suppose if all you use a computer for is tweaking the interface, a customizable interface would be best. That is why I use KDE. I don't want to do work, I just want to rearrange panels.

I've noticed most users leave everything the default setting and only change the background. The ability to change fonts and colors is rarely used by average users, but the changing of the desktop background seems to be universal. (Those who don't change the background are not aware that they can.) Raskin is right, if you are going to have a user preference, it needs to be subtle (like a background) and not modify the interface in a substantial way.

But I like playing with interfaces - so give me KDE!

Actually, I don't think KDE is a bad a people say. When it comes to consistency across all apps, no one has is like KDE. Keyboard shortcuts, event notifications, sounds, are all universal to KDE applications. Even though there are many preferences, the tasks by which to modify them are very consistent.

Jeffrey Wang - Feb 14, 2008 10:59:48 am

Raskin brought up some ideas that was not particularly apparent to me, even though the concepts themselves are quite simple. He begins by addressing that designing software requires an interface into our cognetics, rather physical qualities. This is can quite difficult because cognitive limitations are not as clear as physical limitations. Correlating with the previous readings, I believe this further emphasizes the need of contextual inquiry and user feedback. It is important to understand what others are thinking.

The article also brings up the concept of habits. The author suggests that we must design interfaces that take advantages of human habits. The user can soon find the interface straightforward and act accordingly without much thinking. One example that I have grown a habit of interacting with is logging into websites. To find the user and password text box has become a norm for me when visiting websites. I do not think of each step individually, but just quickly go through the process.

Another interesting point is that the article states we only have one locus of attention at a time. People may think there are simultaneous attentions, but are just shifting from to another in a linear fashion.

Katy Tsai - Feb 14, 2008 12:01:47 pm

Raskin brought up the fact that “any confirmation step that elicits a fixed response soon becomes useless.” When I first read that, I wondered what type of viable solution would remedy this. In my mind, the only way to elicit a conscious thought that avoids habit formation is to require a different response each time. When I read his “more effective strategy” of typing “backward the tenth word in this box”, I found it to be an absurd command. I think it’s interesting, yet challenging to adhere to the standards that many of us are used to, whether it is related to an interface or a certain action, while trying to avoid habit formation. By trying to break habits, we end up making the interface more challenging for the user by trying to break through intuition.

Tam La - Feb 14, 2008 12:17:19 pm

"We must master an ergonomics of the mind if we want to design interfaces that are likely to work well." "You cannot undo a habit by any single act of willpower; only a time-consuming training process can undo a habit." These are quotes that caught my attention while reading Chapter 2. They demonstrate the importance of understanding the human psyche and behavior. The notion of habit is especially important, because habits are easy to get but hard to replace. Habit is one of the reasons why people are reluctant to make a drastic change in UI in a short period of time.

Raskin suggests that we consider designing interfaces for individuals, not for a specific class of users, in Chapter 3. This way, we can come up with an interface that can easily be used the first time, and continue to be used in more expert-usage as you use it more often. This whole “expert” shortcuts is a nice affordance, but I think the challenge lies in determining which ones are for experts and which ones are not. I just noticed that my keyboard also has labels on the sides of the keys as in figure 3.9. It has a * on the ctrl key, and "* Save" under the S key, "* Find" under the F key, and so on. I just learned that "Ctrl-Y" is "Redo". But why is "Undo" "Ctrl-Z" and "Redo" "Ctrl-Y"? Why are they so far apart?

Richard Lo - Feb 14, 2008 12:11:56 pm

The subject of attention locus was fascinating to me. This is apparent in many tricks, such as the mentioned card shuffling sound or canon cat. Many people have seen the types of street magicians that invite an audience member on stage, and while distracting them with a simple game or task, they methodically and stealthily remove the person's wallet, keys, watch, and even tie from their neck, all while the audience cannot believe how the duped audience member isn't noticing. While someone seeing it for the first time may not believe it could be possible, its a great example of how a person's locus of attention can distract them from anything else that is going on.

Lita Cho - Feb 14, 2008 12:24:11 pm

Being a psychology minor, Raskin's thoughts on cognitive conscious and unconscious were very interesting. I found it awesome that such studies can become useful with designing a user interface. I also believe that Raskin's thoughts on the unconscious mind was influenced by Freud theories of pre-conscious. However, Raskin wrote that unconscious and conscious are a state of being. A person can be in a state of cognitive unconscious while reading then be at a state of conscious when a fire alarm goes off. This idea was dramatically different from many other theories from psychoanalysis that I have been studying. I also found it funny that Raskin tried to avoid making models of the mind while in psychology, most of the subject consists of making models of the mental state.

I also didn't even consider taking advantage of the single locus attention of a person. As a look at UIs now, a pop-window was a great way to shift your locus attention elsewhere. Wizards are also good ways of flowing the locus attention of a person.

Diane Ko - Feb 14, 2008 12:42:38 pm

One of points that Raskin brings up that caught my attention was about allowing for the easy formation of habits. There are certain things that you can do on a computer now that seem so second nature that really were quite difficult the first time around. While teaching a group of 7-10 year old children at a computer camp last summer, I had to show the students how to interact with the game creation interface. Some of the students had never really used a computer before. Even simple things such as double clicking on an object were not intuitive for the 7 year old student I taught. However, after a day or two of working with the interface, the 7-year-old managed to pick up most of the tasks that some of the older students then found second nature. A very good interface for a simple product, it seems, should be such that someone who has little to no experience with a computer should be able to pick up the basic functions after considerable interaction. I'm also reminded of how the switch for some people from typewriters to computers would most likely have been fairly straight forward seeing how the keyboard layout is the same. In this way, designers took advantage of what people were already familiar with to allow for easier habit formation. Related to this is the problem I generally have with some laptop keyboards. For my laptop, the layout is almost identical to that of a standard desktop keyboard. However, some of the laptops I've used change the ordering of certain keys in order to fit more keys in different places (especially if the laptop is a widescreen and the designer wanted to spread out the keys). Specifically, I've interacted with a keyboard where the delete key is right next to the left arrow key and the home key is right next to the right arrow key. You can then imagine the annoyance of accidentally hitting delete when you intended on hitting left. This interface did not take advantage of the habits formed by people who are accustomed to a particular layout of keyboards, emphasizing the basic ideas produced by Raskin in the book.

Yunfei Zong - Feb 14, 2008 12:53:38 pm

I hardly agree with the statement "allowing the user to change the interface design often results in choices that are not optimal." There are many instances where customization allows the user to have a much more useable and powerful system than the default setup. For example, in most first person shooter games, there are ways to map buttons to whatever key you wish. Players who wish to play as efficiently as possible will often bind their mouse side buttons (if they have them) to the grenade keys, since grenades generally need to be primed (by having the button held down). Since these keys are on the mouse as opposed to the keyboard, they do not restrict the keyboard-based character movement (W,A,S,D keys generally) which are arguably the most important keys in an fps game. There aren't really any disadvantages to customization either; most games nowadays have user profiles that can be saved on a usb stick and moved around with ease for portability. Obviously, the player would also have to change the hotkeys for every game, but that is much easier than learning a new keyset for each game.

Customization of interfaces is highly useful when knowledge of the interface is crucial. If they didn't allow customized hotkeys, and forced the grenade key to be G, it would be a nightmare to move around while holding a grenade, since your index finger would be on G and your character would not be able to move to the right (without contorting your fingers in some painful manner). This spells certain death in fps games, where skilled enemy players will know about these shortcomings and exploit them.

This applies more generally to large systems that can accomodate many users like Excel, which is designed to do pretty much everything. But in reality, users need only to know and use only a small fraction; having customized buttons is extremely useful especially since a user will not and need not use the entire system. Again, problems occur when other users are forced to use a customized interface, or an accustomed user is forced to use a standard interface. I can understand this as a problem years ago when it was one computer per many users, but this isn't really a problem nowadays when everyone has their own computer.

Cole Lodge - Feb 14, 2008 12:37:38 pm

Overall I enjoyed this reading, I felt that Raskin raised several good points, in particular about the beginner/expert paradigm. One thing I do not think was focussed on enough is the need to hide expert functions from a beginning user, even though I felt it was implied. A beginning user who is confronted with visual options that are too complex for their use will often be scared away from the program, even if the user had no need to use the complicated options.

As for chapter 3, I feel that we have to be careful about the use of adaptive interfaces, specifically with in menus. I know this example has been used several times within the comments, but an example of an adaptive interface that was taken too far would be Microsoft Office 2007. After years of using Word, I have come to expect menu options to be in a certain position within a menu; I do not like having to think about where the "show header/footer" option will be when I want to use it. My main point would be that if a menu is going to adapt. it should place options in the same place within a menu whenever the option is available.

JessicaFitzgerald - Feb 14, 2008 12:41:45 pm

I thought Raskin had an interesting approach toward user interface by applying ideas of cognition to assist with understanding. By understanding how the brain works both consciously and unconsciously, that helps to develop a more easily usable and effective user interface. I think it is very helpful how he analyzes traits of human nature and applies them to understand what a user interface should be, such as the trait of habit. By using an interface, or doing any other task often, one will perform it without even thinking. By creating a user interface where this habitual nature helps the user have a more productive time, then this identifies a trait of a good interface. His ideas have great insight, and i find them an interesting way to look at user interface.

Andrew Wan - Feb 14, 2008 12:56:58 pm

The formation of habits seems like both a tool and hinderence in user interface design. Right now, as more websites use dynamic Ajax or Flash for navigation, the "back" button's purpose has changed. People have become completely accustomed to navigating back with a browser button, but on newer sites this action takes the user to the last visited URL, not the last page of content viewed. As a result, it can take some time to get used to in-frame pages, i.e. the AdultSwim video site, where the interface does not behave as initially expected.

I found Raskin's discussion on the locus of attention useful. By keeping people focused on a single element in a user interface, the usage becomes clear and intuitive. I suppose this contributes greatly to the wide adoption of dialog boxes and alerts in software, since the creation of a new window on screen immediately attracts the user's attention. On mobiles, this approach may need to be rethought, just given the minimal interface and amount of screen real-estate. It seems like it would be better to have some kind of fade-in/slide-in notifier (like Growl) to convey simple information to people, instead of "popping up" a dialog which interrupts the current activity.

William tseng - Feb 14, 2008 08:28:05 am

In the reading from Chapter 2 I would like to comment on the section about habit formation and its importance in designing an interface. A good example of how a real world application applies itself in regards to the "deletion confirmation" example presented by Raskin is in certain applications or webpages where you have to physically type in "delete" or "yes" instead of just simply clicking on an okay button.

The author's point in Chapter 3 about "preference / option" menus potentially causing more difficulty with users and the example provided about auto-formatting in a word processing program is interesting because I believe this will be an issue that mobile applications should seek to avoid. Mobile applications are usually centered around specific services they provide to a user (making a call, sending a text, setting an alarm) there should not be too much variety / configureability allowed to the user to change how the interface can be presented to them. Even so I often find myself annoyed when my text messaging program gets stuck in "cap locks" or "numbers" mode and I have to spend extra effort to revert the change back.

Timothy Edgar - Feb 14, 2008 01:20:12 pm

The discussion of habits was quite interesting. A lot of times, I feel my eyesight is pretty good when I'm driving and can see all the relevant details. However, this is usually for areas that I already know and have habits for driving. In a new area without glasses, I strain to make out signs, even though when I'm in areas I know, somehow the the signs seem readable. However, if I take a closer look at a sign, I realize how blurry it might be. Habits do fill in a lot of detail mentally that you may not even see realistically, which can be true for UI and esp UI changes. It's probably the reason why Office has so positive and negative comments. Some just can't get adjusted since they get disrupted trying to find their functions, even though it may be logically presented in the ribbon. I think it presents a caution towards creating habits, but in the end they are inevitable. For me, the Ctrl-T means new tab, which bugs me everytime I have a pdf open in a browser and doesn't work.

The readings had such great points, where they were grounded in real examples, compared to the prior reading that was far to academic. The locus of attention and serialize mind creates an interesting case for multi-tasking. Often times we are pushed to multi-task or grown accustom to multitasking, however how much of it is really just habits running as a process in a background unconsciously.

Max Preston - Feb 14, 2008 01:17:28 pm

I thought that Raskin's articles were explained and presented very nicely. However, is it just me, or are all the things he said kind of obvious? Sure, the fact that performing tasks repeatedly makes you more adept at performing them unconsciously may not have been in my cognitive conscious, but it sure seems intuitive. Similarly, Raskin goes into great deal explaining how a person can only focus on one task at a time, and while I suppose this is important, it doesn't seem like something a person wouldn't already know or be able to deduce quickly. If humans could multi-task effectively, then more people would read novels while driving motor vehicles. Nevertheless, his points are still well articulated, and I suppose they are important to consider for user-interface development; at least it could help prevent catastrophe for a person who might have somehow never considered such points.

Yang Wang - Feb 14, 2008 01:36:20 pm

Customization is always the important thing I looking for into any software I use. I hate to adapt to different styles, I'd rather make my own and stick with it. As many already mentioned, gaming is a good example for customization. Be able to configure key binding differently is very important in gaming world. The looking direction in many 3D games, no matter in normal or inversed, has its own user group. If you make configuration that is hardly ever be changed by user, guess what, the opposite people will be angered. I am not sure if I am the only one who hates iTunes so badly, not only they forced you to use it with apple device, the synchronizing system not just once removed wanted files from my iPhone or iPod. If there is any choice to rearrange or customize how we access to those devices I will jump right into it. Cut long thing short, yes, a great default configuration is very important. But its target should be common users, just like the car seat, it can fits 95% of people. However, I think in software design view, you can always allow a more free customization to satisfy the rest 5%. There is defiantly a reason why hot key bindings remained same through systems. It is probably the same reason why Sony kept PS3 system menu insanely similar to what PSP had. Making some strange new configuration will not sell your product. Restrict users into one pattern without giving them freedom of customization will never make advanced users happy.

Edward Chen - Feb 14, 2008 01:46:23 pm

One thing that really stood out to me was Raskin talking about the CAD package Vellum. The author talked about his locus of attention was never on the cursor so he had difficult distinguishing between the modes, but instead recommended that the package revert to a normal state after the use of the tool. I feel that this idea has changed over the time since the article has been written. Many programs use the idea of indicating mode on the cursor, and nowadays, hardly anyone confuses themselves on what mode they are because they can just merely look at the cursor.

One example of a program that extensively uses the cursor to indicate the mode is Adobe Photoshop. Because there are so many tools and repetitive tasks that you want to do, it would be more annoying for the program to always switch back to the normal (move) editing tool and having to reselect the mode again on the toolbar. I have, however, used a program that does and it's actually the most annoying thing to have to repeatedly go back to the toolbar to reselect the mode because you want to repeat your task.

Brian Taylor - Feb 14, 2008 01:32:09 pm

Although projects are specifically designed for a target user group, it was interesting to see that the readings focused a lot on making sure that a general interface was usable for all people. Instead of differentiating between various users and groups, the readings tell us about how people are humans first, and experts or greenhorns later. I found the short piece about the web application that switched from beginner to expert mode particularly laughable, yet at the same time, at least it did not ask the user:

"how long does it take you to forget something you've learned? Please enter time in days, hours, minutes, or seconds (of your choosing): ________ and we'll switch our program to beginner mode after that time period has expired"

So, at least it was monotonous in the sense that only one time period was used (a constant of 6 months). For the most part, such a system is rather ridiculous (particularly for a web application on the internet that many people would probably use). For the most part, the interface should be rather static, so that users may habitually grow accustomed to executing a task in a certain manner. Although it would seem that options are a good idea, so that the user may be able to customize their program, the readings bring up a good point about how often such customization is bothersome, difficult to use, and merely boosts the difficulty of using the interface. On the other extreme is forcing a single interface, and perhaps as Raskin suggested, discovering a highly profitable market in interfaces as people become psychologically attached to your interface designs and too attached to switch to others.

Johnny Tran - Feb 14, 2008 12:54:43 pm

The points that Raskin brought up in the reading, such as modelessness and monotonicity, seem very thought-out and reasonable. While I find that these points were fairly applicable to most interfaces, Raskin seems to imply that violations of modelessness or monotonicity are always sub-optimal.

One instance is with modelessness, and the dangers of user customization. His argument is that if one designs the best interface possible, then any change will be a decrease in usability. However, the flaw is that the best interface for one person may be completely unusable for another. Of course, the default interface should be as usable as possible for as many people as possible, but I find it hard to believe that a person could not improve it even further based on his/her needs. Yes, users are not interface designers, but they also know more than interface designers do about their needs. While time spent customizing is time spent not working, I do not believe it is a waste of time; rather, it can result in many hours of time and effort saved later on.

Monotonicity is a related point. While having different ways to perform the same action may be confusing, Raskin does acknowledge that in some cases, it can be a convenience. For instance, if I just selected a block of text with my mouse, then I would not want to take my hand off the mouse to perform a keyboard shortcut; I would rather use a menu command. On the other hand, if I've selected something with the keyboard, then the opposite is true.

While modelessness and monotonicity are good guidelines to go by, I feel that they are by no means hard-and-fast rules that must be obeyed at all times.

Benjamin Lau - Feb 14, 2008 01:39:09 pm

One example I really liked was the file deletion confirmation with "yes" or "no." I've always wondered why Macs never asked if I wanted to delete the file, and now I can see the rationale for it due to habit formation. If you want the file back, you should be able to undo the action anyway. This occasional task isn't very much work, compared to always having to click yes or type 'y' for every file deletion. One of my friends I was talking to brought up that this wasn't sufficient because in some operating systems you can delete the file permanently from the hard drive and so a confirmation is necessary but I disagree, that just means the operating system was poorly designed and shouldn't have allowed the deletion in the first place. In some ways this philosophy reminds me of how databases operate with the "no-force, steal" idea. This kind of setup is much more efficient for memory, and one of its only penalties is that you must support undo operations.

Some people said that the ideas in the readings are obvious but I'm not sure this is really the case. At the end of chapter 2 they have a section on resuming interrupted work. It wasn't until Opera (AFAIK) that browsers began to open with the last page the user last browsed, rather than going to the home page.

Daniel Gallagher - Feb 14, 2008 01:44:06 pm

I found Raskin's description of the conscious/unconscious really interesting and a lot clearer than other places where I've run across the terms. It seems like it's very tempting for authors to throw in lots of digressions when writing on the topics, but Raskin's goal in discussing pychology was relatively clear. Especially interesting was how some tasks are relegated to the unconscious because of repetition- that's much of what martial arts teachers are pushing for their students (which is where I have more background than psychology). To be able to fight successfully takes practicing basic blocks and responses to the point that during sparring an incoming attack will be dealt with by a nearly-unconscious block or sidestep rather than making the conscious decision "now that's interesting- I'm going to get hit. Let me review my options..."*POW*. One thing Raskin did not pick out that I hear all the time in martial arts is "muscle memory", which I think could be a useful distinction to his brain-centric 'unconsciousness' idea especially when it comes to user input devices. I felt like his description of modes was pretty clear and convinced me, but then I started thinking that there some times when modes are unavoidable or even useful... What I'll take from the chapter is more along the lines of "think really carefully & clearly" similar to how his logic was laid out.

Megan Marquardt - Feb 14, 2008 01:55:54 pm

The discussion of the conscious versus the unconscious was very interesting, in particular the discussion of the locus of attention. When using the computer, I always finding myself completely immersed in the virtual world, such that it is very hard for any other unconscious concept to enter into the conscious realm. This means for interface design that there are several different aspects of how the unconscious can be taken into consideration. Within a single program, there can be instructions, tasks, images, etc, that can move certain feelings, ideas, and thoughts into the conscious realm. Looking at when the user is using multiple programs, there are distractions away from the locus of attention on a given single program. Then for the computer users, unlike myself, that interact with the world while using their computers, the world also offers distractions to bring other thoughts from the unconscious to the conscious. I guess what I'm trying to say is there there are different levels of unconsciousness that the interface designers have to deal with. Especially for the cell phone application, the locus of attention is rarely on the phone, since people are walking around, chatting with other people, simultaneously running different applications on the phone. This means the design must not rely on a stable locus of attention for extended periods of time.

Harendra Guturu - Feb 14, 2008 01:34:07 pm

Chapter 2's discussion of how the unconscious and conscious parts of the mind interact was very interesting. I especially found the idea of how "Automaticity" due to habits can be problematic when using new interfaces. One similar example that has bothered me is the use of highlighting/middle click for copy/paste in Unix machines which is not applicable in Windows. After using one system for a while, I sometimes try to use the incorrect shortcuts. Also I have found that if certain tasks are implemented such that they require some level of activation of consciousness (such as confirm dialogs for delete) are repeated a few times, clicking yes on the confirmation dialog becomes a reflex. This unfortunate "Automaticity" can be problematic in situations were the tasks are repetitive but close examination of ever case is vital.

On another note, I would just like to say the modes aren't always bad are they? I mean Vi seems to work great with them. ;)

Randy Pang - Feb 14, 2008 02:04:39 pm

Overall I thought Raskin provided a solid framework for basic principles of UI design (though, unlike many others, I didn't find most of the reading particularly interesting, I felt like most of the ideas were already firmly planted in my unconscious). The item that caught my most attention during the readings was Raskin's dismissive lecture on modes. While I do understand his points, I feel that modes are still a very important part of UI design. Raskin never seems to take the time to explain why modes have become so prevalent in the first place, the reason being that they simply multiply the amount of inputs you have by the number of modes you can access. Now, one may think this is a bad thing, why have so many inputs/commands in the first place? Well, because they're useful (not to everyone, as is the case with every begginer/expert paradigm, but to those who use them, they are often invaluable). Then one might ask, well, why don't you just simplify them to separate commands. This can be a good idea, for example, I can't remember ever using caps lock, shift + letter is so much more convenient because capital letters only come up once in awhile. In my opinion, however, this can also be a terrible idea. The thing that immediately came to my mind when Raskin started to talk about modes was vim (modal) vs. emacs (multi-gesture commands). Being a vim man, the modes have always come extremely natural to me and everything just makes sense. Some commands (like regex search and replace) are far easier (in terms of keystrokes) in vim than in emacs. This is because the modes reduce the average number of keystrokes per command (they also make a lot of commands more logical in my opinion, because they get put in context with similar commands). I do think that visual cues are important to distinguish different modes (vim has a few subtle ones) but I think one of the important things is a simple way to get back to the default mode. When I'm using vim, I almost never check what mode I am, because I know I can always get to the mode I currently want by pressing esc then mode (and this fact is burned in my unconscious). This was not the case with MS word where it's hard to get back to the default mode (one of the biggest usability elements with the iPhone was the fact that it had a single button to bring you back to the default or home mode, android has similarly followed in this useful practice). So I think the lesson should be, modes can be useful, just be careful with them.

Bruno Mehech - Feb 14, 2008 02:09:50 pm

Raskin's explanation of how people's minds work has made me realize why it is that some interfaces that I always found inconvenient are so cumbersome to use. Most of these interfaces that I've had trouble with are due to the interface having modes. One such interface is the alt-tab function of Microsoft Windows. At first I couldn't figure out how it worked until one day I realized that the processes changed order depending on which window had current;y had the focus and which windows had the focus in the past. But even knowing how it works I still have trouble using it because when I'm working on something I'm not concentrating on which window has the focus and which window had the focus before but on the owrk I'm doing. I think that it would make much more sense if the order for the alt-tab menu never changed that way users would eventually get used to the order and would no longer have to think about it anymore and would just hit alt-tab the right number of times without really thinking about it, which Raskin mentions at the end of chapter three as a way that functions that cycle through different options should work.

Jonathan Wu Liu - Feb 14, 2008 02:24:32 pm

I think we should combine this week's reading of creating habitual interfaces and last week's reading of making direct interfaces. They kind of feed off of each other in a sort of positive feedback loop. As we are more inclined to use and master direct interfaces, we will tend to use it more often. As a result of using it more often, it slowly becomes more habitual. The fact that it is direct then does not hinder the habit to develop. Another quote I appreciated was "Having multiple options can shift your locus of attention from the task to the choice of method." If we have too many choices, users will simply not choose and walk away from the interface. Simplicity is the key to directness, and also is the key to creating habits.

Robert Glickman - Feb 14, 2008 02:27:40 pm

I did enjoy the way Raskin enumerated all the important physiological/psychological details which are crucial to consider when discussing user interface design. His discussion of the unconscious vs. the conscious and locus of attention was elementary, but an important concept to bring to the foreground. After all, most of us are unconsiously aware of human nature when designing the user interface in what needs to be a conscious effort to adapt an interface to make human interaction easy. This doesn't work and Raskin does a good job of bringing this to consciousness. In particular, the plane example was particularly disturbing in that from reading what happened, I felt like this (supposedly intelligent) flight crew was a part of a 3 Stooges episode. Now, the point of this anecdote was that it wasn't entirely their fault (although how the autopilot gets shut off baffles me). This just goes to show how important every detail of user interface design is. In addition, chapter 3 went into some detail of some concepts we had already touched on, but are very important. Sometimes, less is more. Other times, more is more. Less buttons are typically better, except when it leads to complex and arbitrary operations to accomplish simple tasks (read: the phone systems example from a past reading).

Andry Jong - Feb 14, 2008 02:29:18 pm

Raskin's argument about conscious and unconscious part of mind was interesting. Moreover, when he talks about locus of attention; how things that people never pay attention to, can be very significant when we stop and think about it. I believe even though this factor is very important in building a new user interface design, it is very hard to make one that fits for everybody still. It's just like what some of my peers have said, some people would love using VIM rather than emacs while some others might argue differently.

Gerard Sunga - Feb 14, 2008 02:15:37 pm

The articles were fairly interesting, but as Max Preston said, some of what was stated seems painfully obvious (entering commands, tapping, etc.). One of the more interesting parts in the article I found was the entire discussion about the interface schemes, which was highly reminiscent of our discussion of phone key layouts during lecture. The discussion of buttons mapping to multiple functions especially reminded me of our discussion, with complexity for various devices, especially car radios, hindering productivity.

The discussion of variable buttons was also quite interesting, especially in exposing the human reliance on habits to accomplish tasks. Another interesting part within the same section was the discussion of customization and the what the degree of control should be given to the users. I personally like the large degree of freedom offered with various desktop environments and software (i.e. Fluxbox/Blackbox, mutt, and conky) and this freedom allows greater productivity.

Adam Singer - Feb 14, 2008 02:43:38 pm

This reading was particularly interesting, as it provided useful insights into the psychological basis for why certain interface elements help productivity, and why some (sometimes severely) impede. The most interesting thing I drew from this reading was Raskin's discussion of habituation and the use of modes. In my own experience, when a certain habitual path I am executing is broken (by an unexpected result from a command, or an unusual error message), I can be frustrated to the point of forgetting what I was previously trying to accomplish. Adobe Photoshop and Microsoft Word are the biggest culprits in this realm. I can't count how many times I've tried to take an action on an object only to have my computer beep at me as a result of not having pressed the Return key after resizing an object. It is little annoyances like these that impede my thought flow and make my work take much longer to complete. With the discussion of the psychological basis for these annoyances, I can now develop my own user interfaces that correctly work with our own human tendencies. Tendencies such as habituation, one locus of attention, and our limited short-term memory will be good things to keep in mind when we are designing our user interfaces for our group project.

Brandon Lewis - Feb 14, 2008 02:33:02 pm

Well, didn't have time to read this as closely as I'd like, in skimming the text I could see a lot of ideas I agreed with. With this reading we are finally getting to the crux of why some interfaces are frustratingly difficult, while others are pleasant and enjoyable. I feel compelled to show this to friends of mine who praise linux while decrying the macintosh. Yes! Humans have limits which affect their ability to handle new systems. No, confirmation is not sufficient to prevent users from doing innapropriate things. Overuse insults the user, and trains them to automatically confirm actions they may not wish to complete. Confirmation should be used sparingly, so that it does not interrupt the user frequently (thereby increasing their frustration). It should only be used when interrupting the user's thought process can be advantageous in forcing them to reconsider their actions. Providing robust UNDO support, for example would be a good choice for a drawing program in which deleting objects are routine. However you might wish to ask the user for confirmation to complete an action that would not be un-doable.

Glen Wong - Feb 14, 2008 02:46:34 pm

I found the two readings to be very interesting. I think Raskin's discussion of unconscious and conscious space to be interesting. I never thought of the human mind of being separated in such a way and being able to perform multiple unconscious activities and only a single conscious activity. The example of the airliner crashing because the crew was trying to replace a lightbulb was quite alarming. Raskin's discussion of modal user interfaces was also interesting because I can personally identify with struggling with toggling lock/unlock buttons. Overall, I think these two readings provided good insight into the things to keep in mind when designing a UI. I think too many of the programs that I have used end up distracting the user from the task at hand with buried menus and cryptic error messages.

Kai Man Jim - Feb 14, 2008 02:44:41 pm

The articles made some good connection and comments on how human mind should connect to a computer, or the way that computer works. A lot of information that I saw in the article was what I learned in my cog sci 100 and 101. Attention is a good one, when people are working on something, they will only focus on the certain thing that they are working on, and will ignore the change int the surrounding environment. This is why a program design should be more friendly to users, like when users accidental press a wrong key and all of a sudden, his/her work is gone, this is something that most people would afraid to see. Something that they are not pay attention to/not focus on will make them a big trouble. How would we help ourselves? The "Undo" feature is a good way, and I think it is much more people prefer would do since people always think they will not make mistake if time can really go back. Therefore, the Undo feature can really save them from making a big mistake. Overall, these articles are great, and I am so agree to what the authors said.

Alex Choy - Feb 14, 2008 02:49:47 pm

Raskin mentions that we need to design interfaces that take advantage of user's habits and the ability to form habits. I can relate to the example of pressing Y or N when deleting a file because I have actually deleted some files quickly before based on habit only to find that I was not supposed to delete that particular file. It was interesting that Raskin mentioned switching the brake and accelerator pedals. After thinking about it, I would probably not be an effective driver had this been the case because my old habits would remain. In Chapter 3, Raskin mentions many different modes and how they can be a problem for people. He also talks about monotony. Raskin says that a modeless and monotonous interface "would be extraordinarily pleasant to use." While this is the case with certain applications, I feel like it is not always the best solution, especially in gaming. As he mentions in Chapter 3, different users will prefer one interface over another interface. I find this relevant when I play certain games. Different buttons can have different meanings and perform different actions depending on the user's preferences. Therefore, while the idea of a monotonous interface is appealing, I believe that many things will continue to have a nonmonotonous design in order to account for user variability. Of course, monotony is good when considering habituation.

Raymond Planthold - Feb 14, 2008 02:28:22 pm

The redefinition of "monotony" bugged me. Yeah, I can see what he meant by it, but it's still an existing word that means something else. It's not as if we're going to run out of new words any time soon. (He just made "monotony" modal!)

The requisition form example brings to mind another pitfall. The solution included changing the department selection checkboxes so that simply clicking one of them places the order. But users generally expect a form submission to result from clicking a button, not a checkbox. Even in environments with "instant apply" preference panels (i.e. Mac and GNOME), the action can be easily undone by clicking the checkbox again. In chapter 2, Raskin advocates making all actions "undo"-able, but this is not mentioned at all here.

Mike Ross - Feb 14, 2008 02:47:17 pm

I'm glad someone recognizes the near uselessnes of a "are you sure you want to delete?" dialog. Like Raskin says, this is the sort of thing that _sounds_ completely logical, but the much smarter thing to do is simply notify the user something has been deleted and make it undoable. This of course brings up the whole "Well they might not see it, like the autopilot light," but in this case, I think a momentary tooltip or something letting you know you deleted file would be fine, so long as the user is able to undo the file deletion.

Regarding modes, I understand the antagonism towards modes, but I disagree that allowing the user to remap keys is flawed because users are generally bad. It completely depends on what you're developing. You're not always developing for the masses; sometimes your target audience is comprised of power users who absolutely need ctrl-shift-L to be Insert Edge Loop Tool. In this case, it's not the user being confused about which way to do something, it's a way of letting the user decide what the best mapping because he doesn't like the available mappings as much. Just my 2 cents.

Siyu Song - Feb 14, 2008 03:02:28 pm

The first article was especially enlightening. When I first started using Vista, I liked the feature that asked me if I was sure I wanted to open Firefox after I clicked on it. After a while I would just automatically move the cursor from the Firefox icon to the center of the screen where the confirmation dialog would pop up. It is now just annoying and does not serve any purpose.

I thought it was really interesting how the mental processes such as 'chunking' (in the section about gestures) and when activities become habits are really counter productive when designing UIs. How in psych class we learned that they were mental adaptations to help with memorizing things and adapting to frequently done activities. It seems like designs can be made better by matching the responses they illicit to goals that those processes were evolutionarily adapted for.

Jeremy Syn - Feb 14, 2008 03:00:57 pm

I like the way Raskin creating his own style of performing keyboard function instructions to put in manuals. I'm sure we all use these certain hotkey combinations and sometimes it can be very ambiguous when we look at the sequence. He made it so it so you would be able to clearly distinguish how the function is to be performed. Another thing I noted is the issue of toggles. I like to be aware of what setting a device is on and so would like to see some kind of verification. Having a light indictaor or some kind of check box is really useful in informing the user on the state of the device.

Michael So - Feb 14, 2008 02:36:13 pm

The habit forming thing made sense. Like about the example about when deleting a file or whatever, the computer will ask for a yes or no confirmation; it's true that if you most of the type click "Yes" or "Ok", it will eventually be automatic and the whole purpose of asking for confirmation would be useless. The chapter didn't seem to have solution for a method of confirming content because it says that no method of confirming intent is perfect. I think the author feels that there is no perfect method because you have to consider ease of use and how people form habits.

In chapter 3, the comment about user preferences and customization being bad I think is interesting. He points out that often the user's changes to the interface design are not optimal because users aren't experts at interface design. He seems to think that the designers of the interface should make the interface as optimal as can be and not allow customization because allowing the user to customize will only make the interface worse. He does bring up the exception that if the interface is sucky to begin with, then user customization can make improvements. But I guess his point is that the best thing to do is to make the interface so awesome that customization will be unnecessary. I think the option of customizing would still be good because it'd be nice for those certain users who like to do things a certain unique way. What's optimal to one person isn't necessarily optimal to someone else I think.

Maxwell Pretzlav - Feb 14, 2008 03:08:54 pm

I found Raskin's comments on user prompts and habit forming really interesting. I myself have noticed how automatic typing sudo and typing my password -- so many processes require administrator access that sometimes I even run applications that don't need it with administrator access. The same goes for OS X's dialogs -- I imagine a virus could easy take over someone's system by simply prompting for a password with the normal UI -- so many users are used to typing their password for so many applications they probably wouldn't even realize it was a malicious program until it was too late. While Raskin's solution of a completely undo-able filesystem works well for rm -rf types of instances, it seems some other more well-thought out user feedback system is necessary when malicious software is taken into account.

Brian Trong Tran - Feb 14, 2008 03:07:50 pm

Much of chapter 2 has focused on material already covered in class. I really liked the discussion on the locus. I found it quite humorous on how the Cannon Cat would be used to distract users while the program was loading. It makes me think of all the video games with pretty visuals or music to distract us from the long load times. Players have complained about these load times less often in the past few years. All this time, I have just thought that technology advanced to minimize load times when a major reason was that music was continuously playing or an image would appear on the screen that would make the wait seem shorter. Great thinking on their part!

Joe Cancilla - Feb 14, 2008 02:55:56 pm

One point which Raskin makes that I found particularly interesting is the resumption of interrupted work. In this section he critiques the desktop interface for forcing the user to navigate when they want to switch from one activity to another. I completely agree with this idea, but I find it difficult to imagine how a user would be able to switch tasks without some form of navigation. The computer would have to be able to predict what task you wanted to preform. I wish he had given an example of an interface where the user would not have to navigate to a different task because I am having difficulty thinking of one. Actually one thing I thought of is where multiple applications are open side by side, but even then you have to turn your locus of attention from one area of the screen to another. Without somekind of powerful predictive powers on the computer's part, I think it might make more sense to talk about navigation between tasks in terms of degrees. Looking from one part of a screen to another, is faster than Alt-tabbing between layered windows, which is faster than selecting an item on the taskbar, which is faster than finding a program in the main menu... etc. I totally agree with his belief that programs should start up from where you left off. I've set my Firefox browser to do this, and can't imagine life before it.

Nir Ackner - Feb 14, 2008 03:18:15 pm

One thing that Raskin seems to suggest is that if it is necessary to use a warning dialog, it makes sense to NOT have a unifying theme for all warning boxes. This is contrary to almost all design mentality, but makes sense, since the whole point it is to jar the user. I found this concept very interesting, but I think it would be a lot better to design the interface with undo capabilities, as Raskin suggests. But, as many other posters have commented, the undo mentality and dropping of a feature are not always feasible. However, anytime an action is done often enough, there should be ways to disable the jarring effects, which distract from experts who know what they are doing.

Jiahan Jiang - Feb 14, 2008 03:19:19 pm

I enjoyed Chapter 2 a lot! The cognitive analysis part is very interesting and got me thinking about user interactions in new ways. I particularly enjoyed the discussion on people doing several jobs simultaneously and the effect on productivity depending on whether these tasks are "automatic" or not. Chapter 3 was a little dry, but it is useful to learn the "official" terms for some things.

Jeff Bowman - Feb 14, 2008 03:12:32 pm

While reading the article, I kept getting distracted; my locus of attention repeatedly jumped to the obnoxious reminder that my Symantec firewall was no longer within subscription, and that RealPlayer had exciting new messages for me. Facebook's Mozilla plugin repeatedly notified me about my friends' latest endeavors, and my friends kept signing in and out of AOL Instant Messenger.

That those things didn't bother me before is a perfect indication of Raskin's distinction between conscious and unconscious thought; the notifications had been happening for so long, I had grown mostly used to them. I believe they do not distract me on normal days, but as Raskin notes, it is impossible to objectively observe your locus of attention because doing so requires your locus of attention.

The proliferation of system tray icons and pop-up notifications seems well-intentioned, ostensibly to allow the user to be notified without distracting him or her from their current task. However, a better execution may be the devices carried by The Sharper Image and Brookstone, known as Ambient Devices. (Ambient Devices pride themselves on making information instantly accessible and ignorable; their hallmark Ambient Orb can be programmed to glow a subtle green or red based on the weather, stock market, unread email, and a multitude of other devices, updated instantly and wirelessly. They also produce an umbrella, that has a handle that glows when rain is forecast.) I would be interested to see Raskin thinks of the current status of my system tray (or, for that matter, my parents' system tray on their computer at home; the rather disturbing statistics that Raskin notes in Chapter 2 seem to indicate that he would see Ambient Devices as a very humane way of presenting information.

Pavel Borokhov - Feb 14, 2008 02:20:15 pm

I think Raskin's discussion of the locus of attention is very poignant. A lot of us, for some strange reason, have a perception that we can can "multi-task" and do many things at once. Perhaps we would like to believe that we are somehow superior to others due to these multi-tasking abilities, or we like tricking ourselves into thinking that we can accomplish more things in a shorter amount of time. Regardless, nothing could be further from the truth. I have caught myself trying to pay attention to multiple things at once and failing miserably at it. The closest that we can ever get to attaining fully-conscious multi-tasking, it seems, is by rapidly alternating between two (or more) different tasks to the point where our execution of each one seems almost continuous. A trick similar to this in principle is used my movies, of course, who only show us 30 frames per second and yet give us the impression of a continuously moving picture. However, in the case of combining tasks, such "perceived" continuity, because it's not real, might actually be catastrophic as a detail is missed (or the mind gets too caught up in the act of multitasking itself as opposed to the tasks being performed).

Relating this to interface design, we as designers must remember two important things. First and foremost, the interface must be designed in such a way that it does not require the user to change their locus of attention frequently (if at all). For example, performing an action should not involve dialog boxes that are in opposite corners of the screen, as this could force the user to divide their attention between the two screen parts. Second, and this is especially relevant for mobile devices, we must account for the fact that a user's locus of attention can be moved away from performing the current action at any time by some external distraction. Therefore, the interface must gracefully allow for quick resumption of whatever task they were doing before the interruption. In this light, a time-out for some confirmation dialog, for example, is probably not a very good idea. Similarly, if a user gets an email alert, a good application would allow immediate resumption of its last state after the user finished reading the email, so that if the user was in the process of creating a new event, the information that was entered into the dialog, but not yet saved, would not be lost. This latter interface feature seems to be scarily absent in a lot of mobile devices.

Jason Wu - Feb 14, 2008 03:27:30 pm

The attention locus concept is something that seems to be worth noting at all times designing an interface. If our locus changes too often, we become disoriented and the UI is tiresome. Other anecdotes like the Canon Cat were amusing in demonstrating the principle too.

The distinction between conscious and unconscious thought was also interesting, and certainly a manner of thinking that I wouldn't have come up with. I haven't considered before how many tasks I can do unconsciously/consciously at a time, though it seems true that multitasking drops a user's efficiency a lot more than usually thought.

Zhou Li - Feb 14, 2008 03:04:11 pm

After reading about cognitive conscious, cognitive unconscious and the argument that there is only one locus of attention for each person, I realized multitasking might not be as efficient as I thought. Since it requires extra stimulus just to switch among different tasks if they are more than a few seconds apart. In the case of interface design, I agree with Raskin that the user should be able to have his/her locus of attention on the specific task he/she tries to accomplish instead of switching back and forth between the task and interface control. It was mentioned in the reading that having multiple options of executing the same operation through the interface might also force the user to shift his/her locus of attention to decide which option to use, therefore creating an interruption and slowing down the process. From personal experience I think that is true, it requires less thinking if the interface only provides one or two easy ways of executing an operation. That way, after the user repetitively performs the operation, it becomes habitual, which means he/she can then can do the task under cognitive unconscious state. An interface design can also result in bad habit for the users. As mentioned in the reading, the “yes or no” confirmation dialog has totally lost its purpose for most frequent computer users. So a well designed interface should either disallow, permits redo option (which can be very hard to implement in some cases) or shift the user’s locus of attention to the warning by altering the format randomly.

Paul Mans - Feb 14, 2008 03:16:32 pm

Like every "anthro-science" HCI eventually defaults to applied neuropsychology. While this of course makes sense because the brain is involved in every human activity, human neurological processes are so complex that often conclusions drawn about the way the human brain causes us to interact with the world simply seem like speculation. I think Raskin acknowledges this and thus commits to using only directly empirical studies of the brain to guide his insights into computer interface design. Furthermore, I appreciated how he explained his decision not to use MRIs or PET scans (despite them being highly empirical), because he felt that the results they provide cannot yet be sufficiently interpreted. That being said I found his discussion on the affect to users of different modes in the interface to follow quite nicely from the system of experiment and observation he described him using for his study in the first reading.

[add comment]
Personal tools