The Inmates are Running the Asylum(P2)

Summary

Ch8 - An Obsolete Culture

The author criticizes the distance between visual designers and program developers in software citing that this is amajor problem for the end user.  He specifically takes several shots at Microsoft, specifically citing their Explorapedia project. He feels that programmers are incapable of designing correctly because they take too many short cuts that save them time instead of focusing on the end user. Also, because of Microsoft's success, others will try to implement it.

He also cites Sagent Technology as  problem riddled company.  Each person in the company tends to think the general customer is like the ones they interact with. Product management people think general customers need hand holding, senior developers think general customers are seasoned vets, etc. It's like the 3 blind men and the elephant story.

He goes on to say that the mentalities of today's programmers are obsolete as well, with focus on putting little strain on the processor at expense of the user not taking into account the vast advances in technology in the last few decades.

Part IV - Interaction Design is Good Business

Ch9 - Designing for Pleasure

In his company he implements a new way of thinking.  He has his teams think up personas for a typical end user. They imagine everything about the person and then design the software with them in mind calling them hypothetical archetypes. His view is that logic would tell us to design broadly to accomodate as many users as possible and that "Logic is wrong. You will have far greater success by designing for a single person." He states that software should be like cars in that there are several models of the same thing and the user picks which fits them best.

Also, we're to realize that no single user fits the "average" user definition or fits snuggly into categories of users. (ex. no one is really completely tech illiterate). Also, designing for a specific user puts an end to discussion about what features should or should not be implemented.

Projects should cater to fixed set of personas with one person being the main focus of the personas and having his needs take precedence over the others.

The case study was of Sony Trans Com's P@ssport which was an In-Flight Entertainment product that brought Video on Demand to TV's in the back of the seat in front of passengers. The interface required 6 clicks to get to a movie and then if you decided you didn't want it, it would require 6 clicks to get back up. Touch screen was an intuitive solution because the screen was at arms length but constant clicking and tapping would make the person in front of you angry with incessant tapping on the back of their head.

They created 4 passenger personas and 6 airline worker personas. The old crotchety passenger became their primary persona. As a result, a physical turn knob was instantiated that resembled a radio knob and was intuitive for Clevis.

Ch10 - Designing for Power
"The essence of good interaction design is to devise interactions that let users
achieve their practical goals without violating their personal goals."

Basically, don't make the user feel stupid. Also, don't confuse tasks and goals. If your goal is to rest, you must first finish all your homework. Goal is rest, task is homework. Goals stay the same, but tasks change with technology. Ex. getting home is the goal. In 1850 you would bring a gun and a wagon. In 2010 you get on a plane and leave the gun.  For both the goal is to get home, the tasks change. Goal is the end, task is the means.

The author pushes for goal directed design over task directed design.  Also, strive to satisfy personal goals before practical goals. Having the user not feel stupid and get a lot done should take precedence over providing the user with tons of features.

He differs between Personal goals(goals of the end user), Coporate goals(goals of the company), Practical goals(goals that bridge this gap), and False goals(goals that shouldn't be considered(easing software creation, saving memory, speed up data entry, etc).

Software should function somewhat like a human should toward other humans. It should be friendly and polite meaning that it should be forgiving of errors and serve when possible, demanding minimal sacrifice from the user.

Some examples are below:

Polite software is interested in me
Polite software is deferential to me
Polite software is forthcoming
Polite software has common sense
Polite software anticipates my needs
Polite software is responsive
Polite software is taciturn about its personal problems
Polite software is well informed
Polite software is perceptive
Polite software is self-confident
Polite software stays focused
Polite software is fudgable
Polite software gives instant gratification
Polite software is trustworthy

The case study for this chapter was Elemental Drumbeat, a software for creating dynamic, databased-back websites.  The problem was that their target audience was composed of two completely different personas, one that was very artsy and one that was techy.  As a result, the coders tended to code towards the techy guy's needs. Only a few companies had targeted the artsy type so the solution was to provide more power for the artsy type than they were familiar with, but this only meant that the artsy type would be more dependent on the techy type which was a turn off.  With advances in the web, it was necessary for both to work together so the program had two interfaces, one for the artsy webmaster and one for the techy programmer.

Ch11 - Designing for People

scenario - concise description of a persona using a software-based product to achieve a goal.

Scenarios
daily use - frequently performed
necessary use - must be performed but not frequently
edge case - anomalies(can usually be ignored but a lot of times isn't)

inflecting the interface - a technique for making a program easier to use but not sacrificing functionality
 - offering only the functions that are necessary when they are necessary

perpetual intermediates - most people are not beginners or experts but are perpetually in between


Part V - Getting Back into the Driver's Seat

Ch12 - Desperately Seeking Usability

Ch13 - A Managed Process

Ch14 - Power and Pleasure