Blog #7

I am not an I300 LOSER!!

- Rick D'Addario

Blog #7

I am not an I300 loser.

I am not an I300 loser!

- Marius Francu

Blog 7

I am NOT an I300 loser!
- Will Niethammer

Blog #7

I am not an I300 loser.

- Trenton Allen

Blog 7

I am not an I300 loser.

-Michael Jacobsmeyer

Blog 7

I am not an I300 loser.

Blog Assign. # 7

I am NOT and I300 loser!

Blog 07

I am not an I300 loser.

Blog 7

I am not an I300 loser!!

blog #7

I am not an I300 loser!

Blog 7

I am not an I300 loser

Week 07 Blog Assignment

This is a very easy assignment.

I want you to take a look at the way points are distributed for this course. See pages 8-9 of the syllabus. Look at your grades in the Oncourse gradebook and enter them into the Personal I300 Gradebook (it's an Excel file that you can download from Oncourse resources; it's at the bottom of the resource list of files).

If you think you’re in trouble, please make an appointment to see me. I will help you recover through the “Professor Siegel’s Academic Recovery Stimulus Package!” Note, however, that the stimulus package will not be available throughout the semester. This is a mid-semester correction. So take action now if your grades in this class need a bail-out.

If you’ve calculated your personal grade and decided if you need to make an appointment with me or not, then all you need to do to get 15 points on this blog assignment is to write a post simply with the words “I am not an I300 loser.” Feel free to say more, but this assignment only requires you to do this. That’s it!  

blog 6

I believe a technique that would be great to use for project 4 would be a help option on the interface. We all get confused with technology today and I do believe that this would benefit the user in understanding everything about the fridge. On the help menu screen. The user types in what problem they are having or chooses froma simple list of tasks that the refrigerator has to offer. And from there on it explains into detail what problem the user might be having and how to fix it. This screen will also help the user get organized if they lose track of what groceries are in the fridge or how old food is. We all forget these things and a user would benefit from the help screen. The help screen also has settings on it to help the user organize food, set temperatures and use emergency backup if something went wrong. I do believe this feauture would help a lot for the users of our fridge for project 4.

Blog 6

The site I chose was vimeo.com. As a new user, the site gives you useful, noticeable tips but without getting in your way. When on the site's main page as a new user you see at the top, in large letters, "Welcome, you're new, aren't you?" Then below it, in a font and color different from the rest of the page it describes the site and offers a way to sign up. Registration is simple (though it doesn't include default text in the name, email, etc boxes).

Once on your homepage, the site offers more tips at the top of the page, along with boxes that describe aspects of the site, like the Inbox, and also include a simple way to close them when you no long want to see them. Overall, the designers made it quite easy to get started on the site.

Blog 6

Gmail

Google does a great job of introducing new features to their arsenal, partly because they already have your attention in a variety of ways. They are able to reuse the welcome screen presented as their login page to notify their user base of new features, and direct them to its proper use. The way Gmail recently introduced their 'buzz' feature is a recent example of this. Using this technique, the welcome screen as a notification system, Google is able to spend less time bringing their users up to speed and focus more effort on speeding things up.

Blog #6

A technique explained by Hoekman called interface surgery is a technique that would greatly benefit my design for Project 4. Interface surgery is also called "instructive design." It is a technique were any application designer not only helps it's user with an "obvious" design but also helps them complete their task.

When looking at my final concept design for project 4 I now realize that the functionality of my "Key-Talk" design did not at first instruct the user on its functionality. Our Key-Talk design incorporated four interactive keys into one single device. One huge issue I just realized with this design is that how does the user know exactly what key they are selecting? Looking at my final concept sketch there is no icon or button to press to help the user select the appropriate key for the appropriate situation when he/she would like to speak to a particular key. Also, looking back when did incorporate a button that tells the user what to press when they do want to talk to the device but it doesn't let its user know whether it should hold the button or simply press it. All of these changes could have been applied with a little interface surgery or "instructive design."

-Trenton Allen

Blog #6

I am going to be refining my refrigerator design from Project 4 using the concept of up-to-speed aids. I am going to implement a start-up intro video and interactive first time use walkthrough. This will help a new user feel less overwhelmed by this new unfamiliar technology. Right from the start it will assist the initial user in creating the first profile. Next it shows an onscreen example of someone scanning the RFID label on the product. The computer will access an online database about nutrition and shelf life and then will store this information. A similar walkthrough will provide an example of how to enter in produce or unlabeled products. After the initial user has input the current stock of their fridge it will prompt for additional profiles if any are needed. The final phase of the introduction and walkthrough will show an example of someone accessing their profile and selecting a specific recipe to prepare in this section the consumption of groceries will be accounted for. Hopefully this built in tutorial will provide a solid foundation and basic understanding for the user’s initial interactions with the interface.

-- Will Niethammer

Week 6

The technique I have optioned to apply to my project 4 is the use of one-click interfaces. The current design for my key chain is close to a two click design already, but by eliminating the "are you sure" prompt that follows the call to voice commands the device can truly be a one click program (with the exception of the issued voice command). By applying a one click technique to the key chain it will allow for the device to be quickly accessible and less of a hassle for those users who want their results quickly, without being hassled by confirmation prompts.

Blog #6

A helpful technique from chapter 5 that i could apply to my design in project #4 would be providing a "help document" to the user. This will benefit the user because when confused with a certain feature, the help document will explain that feature. The help document would be designed with a concise description of each of the features available. For example, if the user was viewing the help feature, they would see a link for the Eating Out, Recipe, Nutrition, Capacity, and Menu features. After clicking on a link, the help document would navigate them to a page that describes all the functions and processes that this link can perform. It would also offer a quick visual tutorial about how to use each feature. I believe that user's, and not just experts, would take advantage of this documentation in order to better understand and use the design.

- Rick D'Addario

Blog Assign. # 6

I have chosen to explore how "integrating preferences" from chapter 5 in our book could be applied to project #4. I see this being useful for setting the weather and news and basic local information that the fridge can provide you by asking you one time your location. And using that to gather the weather and news. That way you will only need to enter that info once instead of multiple times allowing you to get into the applications and start exploring how they work. Maybe even the fridge could be equipped with GPS capabilities and can find your location on its own and set this setting. It would also be important to include the option for users to change any or all the location preferences at all times, or maybe add another one that you can view in addition to your original(current) location. All in all integrating preferences would save the user set up time and give them more time to begin using.

Blog 6

For this blog I have chosen an update to project 4 refridgerator design. I believe adding a help menu as an instructive design could be very beneficial to first time users. The help menu would be simple, informative, and directly to the point. For example, if a user is attempting to update their grocery stock using the touch screen and scanner this may not be as simple as it looks. The instruction menu would provide a step by step process on how to update the groceries.
Welcome to the step by step guide to updating your groceries stock.
Step 1: Enter today's date.
Step 2: Select the item you wish to put into the automated system, if the item is not scannable or listed under a specific category, then simply press other and type in the name.
Step 3: Select the done option and you will be prompted with the screen "Groceries added."
Step 4: Repeat steps two and three until all groceries have been entered into the list.
The new help menu should make it easy for users to operate the functions of the refridgerator and eliminate any confusion that may be caused due to inexperience of the technology.

Blog 6

The website I chose for this post is http://signups.myspace.com/index.cfm?fuseaction=signup which is the sign up form for Myspace. The technique that was used effectively in the design of this specific form was 'Instructive Design'. For each section of information that you have to enter the web page gives you brief but detailed instructions on exactly what you need to type into the box. Also, when it comes to whether or not which information box is required, the form is cleverly designed to give immediate feedback to the user if something isn't quite right. Say the user skips a box in which they needed to enter information, then the required box that was skipped will be outlined in red. Since red is a good indication there's a problem, I believe it draws the users attention immediately. But, if you just so happen to be color blind, a dialog box appears right next to the spot where information is needed, and the dialog box tells you exactly what's wrong. Finally, if you try to submit your form before you finish, all the required boxes will light up in red for you to see where you missed entering something. Also, another thing that makes this last part effective is the fact that the page isn't refreshed and you won't have to re-enter any previously entered information.

-Jordan Hines

Blog #6

The website I have choose for this assignment was https://www.dropbox.com/ . This is website where you can put all of your files onto a website and log on to retrieve them. It is basically like a travel drive on the internet. It is a very easy website to use because of the simplicity that is used. They provide a perfect welcome screen that is obvious to use. You can start out by watching a video of how the website is used or you can download it right away. There should be know confusion because the options are so limited. Once you are logged in there is an option named Getting started. This takes you through the website step by step and ensures that there will be no confusion. Providing such a welcome screen makes the users life much easier.

Adam Brandvein

Blog 06

One technique I could apply to Project 4 and the keys our group designed is to give the user instructive hints or apply a little instructive design. When conducting our usability test for the project, our group noticed that the test subjects were hesitant about what was required of them to make the design or application function to its full potential. Hoekman describes three cases where instructive design (or hints) would be applicable. These cases are such: 1) When a form field requires a specific data type and it is potentially unclear to users what needs to be entered, 2) When users are expected to enter a value in a specific format, and 3) When it is unclear what the result of an action will be or how to perform an action. Our keys require users to be a certain distance from the door they wish to open, and if they were not already told what distance that was then the use of the keys would be hindered by the third case Hoekman describes. In giving instructive hints, the user would feel less lost about the use of the application and would be on their way in turning from a beginner to an intermediate user immediately.

- Mikhil Patel

Blog #6

A technique that could be applied to my project 4 design of the keys is the one-click interfaces. On the keys, however, wouldn't be one-click, it would be telling the keys a task using a single word instead of a phrase. For example, the user would say "reminder" instead of "i want to set a reminder". Designing the Obvious gives the example of Amazon's one click option to buy and says that the advantage with the one-click system is how quickly user's can purchase something. This would be an advantage for those using the keys because they're most likely users who are in a rush and also, your keys would always be on you so every time you need to make a reminder or change something, it can be done immediately. 

-Matthew Richichi

Blog #6

Something I could implement on my refrigerator from reading chapter 5 in Designing the Obvious would fall under the category of using an Up-to-speed aid. In our usability test we found that the user had trouble knowing what to do because there were no written instructions on the machine. Using a Getting Started guide for new users would be a near perfect solution to this problem. Our refrigerator boasts a touch screen monitor on the door so a video for new users would be extremely easy to add. Our machine also comprehends certain commands so by a user telling the machine that it was a new user could invoke the Getting Started video/walkthrough. This video would explain the basic features of the fridge and help the user on first time occaisions and hopefully eliminate possible confusions.

Jordan Stevens

Blog 6

http://www.facebook.com/profile.php?id=1413960063

The web application that I have chosen for this assignment is Facebook. Of all the techniques explained throughout the chapter, the primary two that came to mind initially with this social networking site is the "welcome screen" and the tips implemented in the interface. When a user first signs up with Facebook, the interface is very basic. It starts off rather plain, but informative nonetheless. The goal that the design team has in mind when a new user enters the site is to provide helpful insight to all of the basic features necessary to get the user up and running with his/her own profile. This technique of a "welcome screen" is useful for beginners because Facebook can be overwhelming with all of the features located on one's page. The welcome screen brings tips to the user for several different purposes: a quick explanation of the basic features, location of these features, and concise insight on how they can be used. However, as time progresses and the beginner develops a better understanding of the Facebook features, the welcome screen and most of the tips begin to diminish from the user's page. This is a positive attribute of the interface set up as any intermediate or expert level user would not appreciate this unnecessary clutter. Additionally, the "welcome screen" with tips is useful for the future for any user level because as the Facebook interface alters on occasion and new features and functions are available at the user's disposal, there is essentially a "mini welcome screen" that briefly describes the changes that were made. Again, these tips will soon disappear after the user becomes aware of the changes made. In short, these two elements of the Facebook interface delivers the user a great start up experience with helpful insight on the basic features, while at the same time recognizing that after a certain period of time it's no longer necessary to place this help on the main interface as the user is most likely more experienced with the site.

-Michael Jacobsmeyer

Blog 6

A technique for turning beginner users into intermediate ones immediately from Chapter 5 that could be applied to the personality infused refrigerator from Project #4 is a welcome screen. This screen would appear upon first use of the touchscreen interface or upon first activation of the finger-print recognition handle, as well as appear once the 'add new user' button is selected. The welcome screen that would appear for the different first uses of the refrigerator could be designed to allow the user to 'play around' with the available options while providing contextual information that correlates to each page at the top of the screen to explain how to perform tasks without getting in the users way of using it. The welcome screen would need to be designed so that it was optional so that there was the option of keeping it running for the next use or optionally choosing to disable it before next use.

Week 06 Blog Assignment

This has been a busy week with a major project due and the first exam. But we need to keep moving forward in our book, Designing the Obvious. I hope you’re enjoying it and that you agree it’s better than reading most textbooks. Please let me know!

For this week, we turn to Chapter 5, “Turn Beginners Into Intermediates, Immediately.” It’s an interesting topic with a number of challenges. A user can be naive about a new application but an expert in something else. Or a user can be naive in general about technology.

For this assignment, select one of the techniques in Chapter 5 and show how it might be applied to your Project #4. OR… if you’re tired with Project #4 (!), find an online application (tell us what it is and provide a link) and explain how one or more of the techniques are used effectively in that site. (Do not choose one of the examples in the chapter.)

Blog 5

The user's mental model is what the user see's or what the user thinks is going on. A lot of people used the emptying of a trashcan for the the user to "think he successfully deleted an object. I will use the entire interface of the computer for example. To the user the computer screen is a bunch of icons, windows, and possibly programs. They dn't see how a simple mouseclick on a screen is in fact a bunch of codes that operating to do what the user perceives. I like to think that the images on the screen is a play( the user's mental model) while what really is going on with code and transitions is behind the scenes.

Programmer's know exactly what is going on "behind the scenes" so to speak. They have to implement ways in which the user perceives what is happening (user interaction) and the big blocks of code they right. The actual interworkings of the task at hand.
JS

Blog 5

The mental model in a users mind is how they perceive an object to work, sometimes not how it actually works, but sometimes how it should fulfill their needs as a user themself. Hoekman states about the mental model is what we believe to be true, bassed on our experiences. So based off past experience, a mental model of a user will be different for everyone in how they interact with an object.

A implementation model is what we think about something that has been designed. Implementation models have no regard for a system's users and are focus more so from technological advances. It serves the purpose more for the designer rather than the actual needs for the user.

Blog 5

A user’s mental model is their personal understanding of how a product or technology works based on their interactions with it and other tools. More often than not most technologies or applications are viewed as a magical black box. A user manipulates the software and something different happens on the screen without them actually knowing what caused this change behind the curtain. The user is then left to fill in the gaps with the knowledge they have. In contrast to the user’s mental model we have the programmer’s implementation model. The implementation model is a design by the programmers for the programmers; they can see the fine details of the technology or program but lose usability and “obvious” design. These are two very different perspectives because one is made to be interacted with on an almost personal level and the other is made to be viewed by creators.

- Will Niethammer

Blog Post #5

If an object has a personality, a user's mental model of the interaction may also attribute an identity to the object with its own unique feelings and thoughts. This greatly affects how the user interacts with it, being polite in return to a set of keys with good manners or giving sass back to a fridge with a loose tongue. Whether or not this interaction affects the objects mood or feelings is a consideration that the user might make that in all actuality has nothing to do with the end result.

The programmer may not have implemented separate responses for a user in conflicting moods with the object. Leading to a frustrating interactions with the objects expected to being able to react to human personalities and mood swings. How sensitive do we want our objects to be, how sensitive can we expect our objects to be?

Blog 5

A user's mental model is their understanding of how something works. In an application the user will draw parallels to things in the real world. For instance we have discussed the trash can example, where the user believes that what goes into the trash can is gone because that is how they view a real trash can. But in reality, that data is not gone, they just can no longer see it.

An implementation model on the other hand is more programmer oriented. It shows the inner workings of a program, which makes things easier for the programmer, but is much more difficult for end users. Using a mental model rather than an implementation model is critical to the usability and success of an application.

Week 5

A user's mental model regarding an object's personality and surrounding interactions is the way in which a person would expect for something to work. In regards to project 4 the person would expect for the object's personality and interactions to be like those of a person, since the user probably hasn't interacted with anything with a personality that isn't a person. The user only has experience with interacting with people on this level thus the user would expect the object to interact as a person would.

This mental model may contrast with the programmers implementation model since the user is envisioning a humanistic interaction with this object while the designer is constructing a program. The user would expect the object to act as a human would act, yet for this type of interaction to take place the designer would have to develope something on the scale of artificial intelligence, which I doubt they intend to do for a key chain or refridgerator.

Blog assignment 5

Robert Hoekman describes a mental model as what we believe to be true based on our experiences and how we assimilate new things into our existing knowledge. For example, when using an application or program the functionality of it should be as simple as possible, so that if a user does not know what is going on behind the scenes from a technical perspective, he or she still understands how to control and operate the basic functions to complete a task. The difference between a mental model and the implementation model is that the mental model is meant to be easier to understand and use for the users. The implementation model is usually designed for “technical experts” or as Hoekman puts it “the geeks” who create the software/products instead of the individuals who end up purchasing the products. This model is from a technological perspective and not for users who just want to get a task done as easy as possible, because using the implementation model causes the user to be more technologically skilled.

Blog #5

As designers, we must understand the way that our users perceive and understand our programs. A user's "mental model" is their idea of the way an application does the tasks it's designed to do. This understanding is formed from the user's past experiences, and the way they incorporate new ideas into their already existing knowledge. The example used in class was of the "trash can" on a user's desktop, and how it's used to get rid of files that a user doesn't want, similar to throwing away trash in real life. The user knows the function of a "trash can" from previous life experiences, however doesn't know how the application actually works. On the other hand, as designers see an applications "implementation model."

In contrast, an implementaion model is designed to reflect the details of how a program is actually used, with no regard for the people who will actually be using it. Usually, its only understood by the programers and designers that built it. It's design is not related to our previous knowledge and experiences, however is built to reflect the underlying functionality of the program.

- Rick D'Addario

Blog 5

• A mental model is what we think to be true about a particular product and it's solely supported by our experiences and the way we digest new ideas and concepts into our own understanding of the way things work. Although, it would be nice if everyone knew exactly how everything worked, but the problem is that this is never true. What really matters is that we have the ability to use whatever it is we're trying to use, and not so much understand every fine detail and calculation that goes on behind the scenes.
• The implementation model on the other hand is very technologically deterministic. The primary focus is on the technology itself, and the progression of the technology. It's the way the technology works down to its finest detail. In contrast, users aren't considered all that important mainly because the designers are initially concerned with the technology. Basically, it's a model that heavily favors the designers vision first, while the users are a very distant second.

Blog 5

According to Robert Hoekman, A mental model "is what we believe to be true, generally based on our own experiences, and how we assimilate new things into our existing knowledge". A user is not going to enjoy an application if they do not understand how it works. We want them to understand how it works in the simplest way possible. For the user, the reasoning behind how the object works will not be accurate. This does not matter as long as the way it is suppose to be used makes sense to them.

The implementation model is something that has no meaning to the user. It reflects how the system works and only makes sense to the programmers. So since the implementation model looks like a foreign language to most users, it has no significant importance to what they are trying to accomplish.

-Adam Brandvein

Blog #5

We, as society, tend to assume how objects, or applications, work using our own experiences. This idea is Hoekman's definition of a mental model. For example, a user of a Windows computer is used to clicking the "x" to close the program so they're understanding of the "x" button is that the program closes. But, if that user used a Mac, clicking the "x" would simply just close the window instead of closing the program. As programmers, we try to simplify things so the user can understand how the application works based on their own usage. 

The implementation model, however, is the opposite. It tells the user how the application was designed to function and how it's supposed to be used. Unfortunately, implementation models aren't usually user-friendly and sometimes can lead to bad feedback from the users. 

-Matthew Richichi

Blog #5

A user's mental model is a representation of an object based on what the user has experienced in real life. So, when a user starts to use an object or application they base how they interact with it off of experiences they have either witnessed or been a part of. For example, Hoekman gave us an example of when a user deletes a document by throwing it in the recycling bin. But, what really happens isn't what we think it is. The document is still there, even though we believe that we deleted it; just because we "threw it away" doesn't mean that the particular document is gone for good, it is actually still on the hard drive. So, when we design for an object with a particular interaction in mind, we better make sure that our design accomplishes what people believe it will. So, when we want to "throw away" a document we don't need anymore, we should be sure that our trash can does precisely that.

The implementation model on the other hand simply lays out an object or application the way that the creators want it to. This way, it is the easiest for them to understand and get the results they want out of the design; it is not intended towards the users whatsoever. This was given in an example of the "tree view" in Microsoft's operating systems when looking for a certain document. Basically, an implementation model can confuse it's users and is not at all an "obvious" design. It is made by the programmers, for the programmers.

-Trenton Allen

Blog 5

One of the primary aspects of the mental model is the user's perception of how an object, application, etc, simply works. The user doesn't necessarily have to understand the key components that drive that particular object or application, but if the user can grasp a general sense as to what the purpose is that is set forth of that object or application, that is usually sufficient. Furthermore, the user doesn't even have to be correct in his/her own perception of what the purpose is. As long as the user is able to perform the necessary functions, it is irrelevant as to whether the user can understand anything outside of this. When dealing with an object's personality, the mental model can come into play. For example, if an object's personality is peaceful, it is not necessary that the user understands why the object is that way, or how the object came about developing that personality. It is also unimportant if the perception is accurate with what the programmer intended the understanding to be, but rather this mental model is utilized as a unique tool for the user to complete the necessary functions of the object in his/her own fashion. In short, the mental model is for the user.

The mental model for an object's personality and its interaction with its surroundings can differ immensely when comparing it to the model of the programmer. When programmers construct applications and programs, there is certainly a different mindset when deciding how certain objects are to work and relate to one another. The frame of mind of a programmer can be complex and technical from the user's point of view. The mental model can virtually consist of anything without any degree of accuracy, as long as the user is able to perform the necessary functions of the application or program. With programmers, the model can be compared to a strict recipe of directions with a specific purpose for each ingredient and task.

-Michael Jacobsmeyer

Blog 5

We have new experiences and we interact with objects every day. Over time we think we are building an understanding of how things work. A file isn't there anymore after we delete it, so most people assume it is gone forever. A graphical user interface with large buttons and icons is what even a first time user will feel comfortable with. You don't need to know how to read to use a mouse and point at what you want. As far as the user's mental model goes, with respect to an object's personality and surrounding interactions, the designers need to make sure things behave as users expect them to. A fridge shouldn't expose all the functionality of the hardware, just the bits that users expect it to have.

Programmers try to include every bell and whistle. If something can be done, they will try to implement it. Anyone who is familiar with the terminal or the command line knows they are capable of things far beyond what normal graphical browsers can do. If it were not for the mental model, all our computer interactions would still be text based. We wouldn't even need a mouse, let alone track pads capable of recognizing multiple simultaneous inputs.

- Marius Francu

Blog 5

The user's mental model of what an object does is simply just based on what it's done as far as our experience with it in the real world. This experience-based model is exemplified in MAC OS X's trash can. The user easily assumes that this is the place where they can put files when they don't want them anymore. Their total understanding of what actually occurs when they drop a file into the trash can icon may not be totally right, however as long as the user can accomplish their goals with this potentially faulty understanding it's OK.

The user-oriented mental model is contrasted with the detail and usually programmer-oriented implementation model. The implementation model reflects the underlying details of the system, usually then calling for more knowledge in the technology behind a given task rather than just allowing the user to easily complete it. Implementation model designs should be avoided and mental models should be designed in their place.

Blog 05

Hoekman describes a mental model as what we believe to be true based on our general experiences and how we assimilate new things into our existing knowledge. A user's mental model, with respect to an object's personality and surrounding interactions, should correspond to the item itself (a frig should act like a frig and a key act like a key) and should benefit or help the user in a way that allows the user to complete a task or to take care of the item (slamming the frig door shut...frig says 'ouch'... don't slam the frig door). If the object is helpful to the user then the user feels it's working for them. Hoekman also characterizes the mental model as not having to be the truth, "it just has to settle in our heads well enough to let us sleep at night." A user may not be using the object to its full potential, or even using it "right", but as long as the user is OK and content with it then it works.

Implementation models, according to Hoekman, is something that has been designed to reflect the underlying details of a system. The implementation model differs/contrasts with the mental model in that the mental model is much simpler and easier to use for users. Users, in line with their mental model, feel that they understand the object perfectly. Many implementation models have no regard for the system's users. As Hoekman puts it, "They aim, usually, to please the geeks that create them," and not the end users actually using them.


- Mikhil Patel

Week 05 Blog Assignment

First, let me say that most of you responded with insight to Week 04’s blog assignment. I appreciate that you took the assignment seriously! Well done!

For this week, we turn to Chapter 4, “Support the User’s Mental Model.”

As you begin to think about project #4, what is the user’s mental model with respect to an object's personality and surrounding interactions? 

How might this mental model contrast with the implementation model of the programmers? (Don’t get too involved with this one.) 

A short answer (a few sentences) for each question should suffice. (Obviously you can read the answers of other people and paraphrase what they wrote, but that doesn't help your understanding very much. TRY to answer these questions before looking at the responses of your peers.

Blog 4

One of the primary conflicts that a designer will experience is how to determine the consumer needs. Of course, every consumer is different than the next and the needs of these consumers will differ as well. Receiving feedback from the consumer can help the designer decipher what the consumer wants. However, it can be difficult at times to draw the line between the necessary elements of the project and the little things that may be nice to have, but we could all mostly do without. Gathering input from the consumer is absolutely valuable, but it is far from being a sufficient primary source of feedback. User feedback can be a great starting point for any design or redesign, but it is the designer's responsibility to "take the reigns", so to speak, and make decisions based on what is best for the entire targeted audience, not just a handful of consumers. As designers are usually on rather tight time constraints for projects already, what is most important is developing the absolute necessities for a particular project, as opposed to devoting more energy and focus on the "luxuries." People enjoy using applications that simply get the job completed quickly and effectively. The more features that the user can do away with without compromising their routine for performing whatever action it is that they perform, the better.

With regards to my design in project 2, there is one main thing that I would eliminate: the amount of buttons on the panel. When stepping on the treadmill, it is almost as if the user is looking down at a large keyboard with a plethora of options for a workout. As most of the treadmill users are not looking for a headache when deciding what kind of workout to choose from, it is clear that the primary aspect of the panel that was rather weak was the amount of choices and buttons that the user could select from. During my testing, this weakness was reinforced as my user became puzzled at times as to how to actually operate the machine. Overall, I think that if the panel became simpler and refrained from attempting at making a treadmill run more complicated on the user than any other task in the gym, it prove to be more efficient and easier to accomplish a workout.

-Michael Jacobsmeyer

Blog 4

When designing something, the user should be listened to very carefully, and most things that come from what a user wants should be considered. But I also do believe that there comes a certain point where the user isn't always right, and sometimes they get into such detail they don't even know what they want beyond a certain value they want in a product. Hoekman basically states that going about designing an application should only go into 20% of the essential feautures to make it less complicated. I agree with this because once you start getting into detail of everything a user wants, sometimes it's too much and can ruin the overall performance or conception of the users wants.


On project 2 we used the bicycle as our ours, and personally I would elminate half of the buttons on the interface. Most confused me, and I'm sure confuse others as well. I also would elminate the mode where when you stop pedaling it turns the machine off. There are plenty of people who are going to want a break, and if they stop pedaling, they will want to resume where they left off, not have it all deleted.

Blog #4

The user ultimately decides whether or not a product will sink or swim. If they don't use it, whats the point of designing it? There is a line, however, that the developer must draw when giving into these demands. Is what's best for one user, best for all users? Also, is a particular feature satisfying the majority, minority, or both percetages of users. It is a good business decision to consider only those functions that satisfy the bulk of your users' needs as essential.

As for the interface of the upright bike sketched for project 2, I would eliminate all buttons excluding:

• Change Display
• The number pad
• 6 Workout Type Buttons

The user is able to sit down and start pedaling immediately. Change the workout type easily upfront, and then input weight, height, and other data on the fly after the workout is in session.

-Robert Durkin

Blog 4

When designing an application, it is important to listen to your users, but you must be careful about how you go about using the suggestions and feedback you are given. Like Hoekman previously mentioned, people will often ask for features that they won't really ever use, perhaps just because it seems like a cool idea. As a designer you need to be able to differentiate between the core features that make a successful application and the flashy, excess features that most, if not all users won't care about or even notice.

In project 2, much of what we did was removing unnecessary buttons and rearranging what was left. But it could be possible to remove some of buttons for very specific functions that may not be used as often.

Blog #4

When designing a new product, the user is always right when it comes to the features of a product and the job that it will perform. However, we know as designers that a user's idea of a good product might not actually be best. As designers, we must know what they want and how they use web-based products, but then focus on designing the application for the specific activity that it is supposed to perform. Just because 1 user asked for a specific feature doesn't mean it should be provided. A few users may benefit from a specific feature, however 80% of your users will not use it. The 80/20 rule also tells us to design for 20% of our original proposed design by weeding out the unnecessary features. Once the product is designed and being used by real users, then the focus becomes more on the way they use the application.

For project 2, my partner and I actually added a few features to our machine that we thought would help the user. After reading the section on "Interface Surgery" i realise that all these features would just confuse the user more. After looking at it again i would remove the following...

- The figure showing what muscles are being worked

- The program description screen

I would remove both these features because they are not essential for the machine to do it's job. I would also simplify the graphics screen because the user doesn't need to see a bar-graph representation of the workout they're performing, they really only need to know if they're burning calories and how long they've been working out.

Rick D'Addario

Blog #4

First off as Hoekman has stated many times over, the customer is not always right, and I agree with him on that idea. I think that if designers were to provide for every request made by every user then the end product would be undesirable, even towards those users who had an input. I think this would happen because everyone would have different ideas as to what would make the product "cooler", thus creating a product with a labyrinth of accessories and applications. It is therefore the responsibility of the designer to filter out all the unnecessary garbage and provide only what the user needs to get the job done. The exception to the users always being wrong is if there is a massive demand from a majority of users for something, then it may be a good idea for the designer to address the demand.
After reading up on interface surgery I realized how much stuff was unnecessary in my bike design. My design was more compact and sleek in comparison to the original, but after performing some interface surgery upon my own design I was able to make it even more compact. To perform it's job the bike really just needed pedals and a wheel, no control panel. However, to be a little less modest, a control panel with a start, stop, and difficulty dial would be all that's necessary for the bike to perform on the level needed for the majority of users. No preplanned courses, no calorie counter, no timer, just some pedals and a device to increase or decrease the difficulty. I wish I had done this interface surgery my first time around, because I prefer the model without all the bells and whistles, I probably would have added a timer, along with the difficulty dial, but that's about it.

Blog Assign. # 4

The Project Runway prom dress design episode really helped me understand that it isn't always the job of the designer to give the client exact what they say they want. Because the client might not necessarily know what they want. The important part is to listen to them and distinguish the things they need and prioritize them based on your design ideals.

In regards to less is more for our redesign of the treadmill, something I would eliminate would be the column on the right of our design that was just a sticker list of health things that was a component of the original design. I found it unnecessary on the device, it could have been better utilized by filling it with more options that gave the user more control over the treadmill.

--Britni Posthuma--

Blog #4

The biggest part for a designer in designing a user based product is to be professional. Hoekman stresses more is not always better. "Stick to what's truly essential..." (pg. 60). The designer needs to decide what is most important and implement those things in an effective way. On deciding what new features and changes need to be made, I tend to be utilitarianistic. Successful designers should not act on every suggestion that is made but only those that benefit the majority of the population. New ideas are not always better. On our second project, my partner and I wanted to declutter the dashboard while offering more options. We succeeded in proving the "Less is More" example that Hoekman also stated, but kept our ideas too broad. We needed to zero in on one aspect of the machine and its usability instead of changing a lot of different things. You need to take desiging one step at a time.
-JS

Blog #4

When creating something you design for the user, but to what extend do you listen to that particular user? You are the designer and it is your job to bridge the gap between what the user wants and the efficiency of the product your creating. Is the user always right? No, but they do have a grasp on how you approach your design. It is true that you design for them, but when designing for the user you simply have to incorporate their wishes into what is best for them and the use of your product. Today, no application or product isn't without extra features; it seems that some things are simply sold off of their extra features and the actual functionality of the product is forgotten. In today's day and age it seems that new features are necessary to some, but not all. I do not believe that extra features are necessary because some users ask for them. Like the 80-20 rule, 80% of what you develop only consistutes about 20% of the application. The users are purchasing/using your product based on it's functionality, not what extras are there. I believe Hoekman really proved a point using this rule, that when you get down to it and look at what you consider to be your "final design" there is still something there that is unneccesary. It really is essential to look at what is ONLY necessary for those using your application.

Our final design for project #2 was slightly less cluttered than the original design of the machine. However, after reading the chapter I believe that all we really did was throw away a few buttons and line things up so that it looked "cleaner." Looking back now I would have to say that we would remove the following:

• the entire middle graphic
• program/workout legend
• program/workout selection

I believe that reducing those aspects of the design of the machine and it's interface would allow users to still have that customization of their workout based on their weight and time. However, there workout would be theirs to choose, and not a predetermined one by a machine.

- Trenton Allen

Blog #4

It is important to pay attention to the user's NEEDS, not what the user thinks they need or what they want. Most computer users will say they want their computer or device to be able to do 't anything and everything. They don't realize this could be the primary source of all the frustrations they suffer while using this technology. This "featuritis" as Hoekman calls it clutters up the interface and provides more opportunities for something to fail, spreading out the attention of the programmers and troubleshooters. Just because a handful of consumers want a feature doesn't mean it is necessary, they key is simplicity; we should work on simply addressing the issues everyone has in common. To do so we need to eliminate the space fillers and the fluff applications and focus our abilities on improving the main tools of our product.


Interface Surgery:
The first thing I would do is eliminate the list of program types and put them all in one screen that you can scroll through with an up and down button. This eliminates most of the text on the interface of the machine and cleans up the overall look. I would also eliminate the numerical key pad the user can arrow up and down to their desired level just as easily. A potential solutino I would like to work into this equipment if at all possible would be a universal up/down arrow with a single button for each of the different systems, one for the fan, another for programs, another for vital stats etc.

Will Niethammer

Blog 04

The world of design does not always boil down to the classic retail slogan of "the consumer is always right". Of course the user is important and their ideas should be heard, but chapter 3 of Hoekman's book advises us to listen to the user wants and needs and then to promptly forget or ignore them when designing an application or tool. Users have an idea of features and gizmos they want, but not all features/gizmos should be included in a tool or application simply because the user thinks its cool or nice-to-have. Hoekman also introduces the idea that only 20% of an application is used while the other 80% is laid to waste. This extra 80%, in most cases, proves to be unnecessary and often contains features that are not particularly important to the main function of an application. The larger "user-centered" focus that Hoekman advocates is that the focus of design should not be on features, "the focus should be on focus. An obvious application is a focused application" (pg. 54). In other words, the simpler and more refined an application is to the task it is to complete is what user-centered focus should be about.

My redesign for project two focused on changing the button placement to better suit the "jogger" on the treadmill. However, a few more things could have been done to simplify the design. For starters, there are numerous different types of programs that a user can select from. Thus, if a simply survey or study was conducted on the most frequently used programs, those would be the ones to stay and the less used ones would be rid of. Also, toggling the start and stop buttons similar to an on/off switch would require less buttons and less clutter. Another possible idea would be to have voice communication built into the treadmill. The user could say something along the lines of "speed up" and the treadmill would go faster (although this may seem a bit far-fetched if numerous treadmills are side-by-side and everyone is yelling a different command). Overall my interface surgery would include reducing the amount of buttons on the panel and eliminating the clutter of unused programs.

Blog #4

After reading this chapter and watching project runway today, I agree with the statement that the user is not always correct. As a designer, there is no way to satisfy every user and it is crucial to narrow down what is important. If the user is suggesting features that will not improve your design, you must disregard it one hundred percent without being rude. A design will not be successful if there is a bunch of unnecessary features that will result in other users getting confused. Hoekman is more concerned about having applications that are essential for the design. If the feature is just "nice to have" he believes that it is not worth it.

Going back to project 2, there are a couple things that I would totally eliminate from the design. One feature that was nice to have was descriptions of each workout on the screen. Sure it is great to know the real workout, but it would probably distract the user from actually working out. Lastly I would change how you turn on and off the machine. I would not want the user to lose all of its activity if they happened to leave there workout for any particular reasons. So I really learned that simplify is extremely key for the user.

-Adam Brandvein

Blog #4

Obviously, when designing something, the user's needs are always very important and need to be taken into consideration for the final product. But, do all of the user's needs need to be granted? Is the user always correct in what they want? Some demands made may be impractical because the user may not know exactly what they want or how they want it. So, does the designer always need to meet all of the requirements of the user just based on what they ask for? Some features may be included into the final design just to please the user, even if they don't make sense with the rest of the product. Unfortunately, it seems like the user is always right and the designer is always at fault when a demand by the user isn't included.

In my final design for the treadmill in project 2, I didn't eliminate any features, I rearranged the buttons to reduce clutter and prioritize them. However, maybe some features need to be eliminated because the original design may have had options that were only included to meet a specific user. Since the display was larger on my re-design, maybe some of the buttons can be physically taken off and added into the display as options. 

-Matthew Richichi

Blog 4

One key point that makes me believe the user isn't always correct is the fact that in most applications only 20% of the entire thing is used, and the other 80% sits there cluttering and complicating the essentials. Sometimes this is because of the designers wanting to pump up there applications with as many features as possible, but it also has to do with users begging for more and more features that just aren't necessary in accordance with the primary task of a particular application. This takes me to the next topic, designers should not always provide new features just because a few users want them. You could take a very simple application and ruin it by filling it with nonsense that most people won't use to begin with. It's a waste of time as well as resources. The larger "user-centered" focus I believe that Hoekman advocates is 'simplicity'. Make a product or application that does a specific task, and focus on maximizing its performance. Focus on the essentials so the user can do what needs to be done and get on with life, without being further encumbered by the 80% of uselessness that gets put in most designs.

My final design for project 2 was pretty simple. But, it could have been further simplified by combining the start and stop button into one single button, which would be simply labeled "Start/Stop". Furthermore, instead of having the two buttons that increase and decrease speed, and the two buttons that increase and decrease the level of incline on the treadmill, I could merely remove them altogether, and replace them with a dial each. (Also, removing the incline options entirely could be another idea becuase most people dont use that anyways.) By making these changes, I've decreases the total number of objects on the interface that you can interact with down to three. But, the remaining objects are still sufficient in order to get the job done.

-Jordan Hines

Blog 4

Chapter 3 not only provided information on how the user isn't always correct, but also on how, often times, the designer initially may not be either. Both groups can often be misguided by what features they think might be "nice to have" in any given application or design, however most of what falls under that category is often unnecessary and ultimately detrimental to both the user in their use of the application and the designer in the extra time it takes to develop and support unnecessary bells and whistles. The designer should focus on the essential features, those that will benefit most users, most of the time. That's essentially in itself the user-centered focus Hoekman advocates- to recognize what will be essential for the user, regardless of what they or you as the designer might think would be "nice", and use only those features that ultimately will benefit both parties.

In light of Chapter 3's guidelines, some elements of the already simplified redesigned interface developed in Project #2 could still be eliminated in congruence with the idea of less being more. In practice, the elliptical only really needs a motion activated start to allow the user to workout at a set resistance level for however long they want. However, a few other features make the machine more user-friendly and are helpful in the basic use above just a one-gear workout. Still, the different workout programs may not really be necessary if the user can easily change the resistance themselves with the resistance button according to how hard they want to work or how fast they want to go. The calorie counter also may not really be practical on this machine since it doesn't gauge the calories by weight and age like more advanced machines do and seems like more of a "nice" user feature than a necessary or even 'good' one. Beyond that, the redesign of the machine and even the machine in it's original state is relatively simple and free of many of the "bells and whistles" that some other machines may feature.

Week 04 Blog Assignment

Chapter 3 of Designing the Obvious may appear to be contradicting what we’ve been saying about users and paying attention to user needs. Is the user always correct? Should the designer always provide new features because one or more users ask for them? Is there a larger “user-centered” focus that Hoekman advocates? Address these questions in your own words. There are many good ways to address these questions.

Then think about Project #2 (the project where you needed to redesign the work-out machine). Perform “interface surgery” on that device. What might you eliminate and why? Do not re-sketch the device, just provide a small list of what you might eliminate and justify your list in light of the guidelines presented in chapter 3, where “less is more.”

[Addition: Focus on your redesign vs. the original design. That is, say what you would eliminate from your redesign.]

Blog 3

In blog 2, I chose the website www.google.com . On some websites, it sometimes asked the user before the actual homepage to take a survey before they enter the website, to help the people who developed the website make it better. I believe this to be a good technique to considering all the users thoughts and advice on how to make a website better. Since google is used almost all the time by users who use search engines, it would be in the best interest for google to convey surveys. I think that google should have a survery before each user actually uses the search engine, and after they take the survey, make it so they do not have to see they survey again. I believe this will be affective in making it so google knows how users feel about using their search engine and also can develop better aspects to the website to make it better. Because google has so many apects to it, it's wouldn't be that difficult to make some of these aspects better. Users I'm sure have their own opinons and why not hear them out. I feel that a survey with 10 questions or so, then a comment box at the end having the user state any other opinion or advice would make a great asset to the designers of google in making the website better and more to the demand of users online.

-Andrew Schroyer

Blog 3

Continuing analysis of CBS News

In order to best serve the users who frequent CBS's site, the most relevant stories to their interest must be delivered. One way to determine these interests, is to ask them! A short survey could provide a wealth of insight, given that the right questions are asked and in an unbias way.
Questions such as:

From the past week...

What articles stick out in your mind?
What articles did you find not worth the time it took to read them?

On any given day...

How many headlines do you read, how many articles do you read?
Do you stop reading articles because you are disinterested, out of time, or both?

The link to this survey could easily be placed under the search bar, opposite the login link, where all users could see. And where frequent must pass closely by.

Blog Assignment 3

For blog assignment 3 I am doing google.com
The technique I selected is using a survey. I chose a survey to get a better understanding of what features are complicated to use and how users feel about the accuracy of their search results when using Google search. I would implement this survey on the homepage of the site, either above or below the Google search bar. A couple questions on the survey may include:
1.) How often do you use google.com to search for items of interest?
2.) When using Google search, on a scale of 1-5 how often do you find what you are looking for? (1 = never find, 2 = find sometimes, 3 = half & half, find 4 = normally find 5 = always find)
3.) What features would you like to change, if any, on Google’s website?
Question 1 is for designers to know how often each user who fills out the survey uses google.com to search. This will allow designers to get an idea of the multiple groups who use Google and how to judge responses from the surveys. (e.g. Never use, sometimes use, or use on a regular basis) more focus on those who use the site more often
Question 2 is to help understand if the current search results are getting the job done or does there need to be a new categorical or hierarchal method of prioritizing search results. (e.g. Ranking the results in terms of websites, subjects, images, etc. to fit the criteria of what the user is looking for)
Question 3 is to get feedback from the users to find out what he or she would like to see change or if anything with the site is causing them problems (e.g. Navigating through pages & links).
Overall using a survey can help get variety of inputs, to better assess what changes need to be made if any. That way if designers see a common problem between numerous users, then maybe these problems can be addressed in the next designs of the site.

Blog #3

The website I have selected to use is Drummerwolrd, a website aimed at drummers.

In researching the users of this site I believe that shadowing would be the best means of better understanding the users. Given that most of the users of this site are probably drummers, I would shadow several members of the drumming comunity that use the site. Preferably drummers of different calibers, a beginner, a studio drummer, instructor, maybe even someone on the site if I'm lucky. During the shadowing I would ask for different tasks to be preformed on the site and observe how the users go about accomplishing their given tasks. While they go about their tasks i would take not of the amount of time and effort it takes them to accomplish the different tasks. Once they finished the tasks I would ask the user their input on the design and structure on the site and for any suggestions for improvement. This method would work best because the users are all mostly of the same occupation, either a professional or recreational drummer, thus we could accurately select those to shadow. Given that those being shadowed most likely know something about drums, even though they may have no experience with computers, and may have helpful inputs for the site once they browse through it.