The Inmates Are Running The Asylum- Chapter 1-2

The Inmates Are Running The Asylum: Alan Cooper


Summary
These chapters start off by giving an introduction to why interaction design is important. They list ~5 examples of where an existing physical system had a computer integrated into it, which subsequently lead to great heart break. It was a decent introduction to why this is important.

Chapter 2 felt like it ran off into the deep end with the constant "It isn't the users fault, it's all the programmers, those mean, evil, no-good programmers". More specifically, it felt like it was treading into a world of idealism, where programmers do have this magical ability to make wonderfully and remarkably usable software, and they choose not to because they enjoy a certain amount of challenge. Or because they're used to working with computers and don't quite see things the same way a user does. And how we're creating unemployable masses because the masses (of poor socio-economic status, thus making us elitists) can't figure out how to use Word.

Summary: Chapter 1 was nice, Chapter 2 felt like he was channeling Don in all of his reasonable and not-complaining-ness.

Discussion
1. Why is this paper interesting or significant?
It makes a case for segmenting the design of interactive (software) products into interaction design and program design, showing that the people who do program design don't necessarily think the same way a user does.

2. What are the faults of this work?

It comes off as combative, which if it's intended to sway the hearts and minds of programmers, probably isn't the best approach.

It makes a lot of statements as to potential job loss because a person can't use a computer to a half competent level... to which I question "What have you been doing these past few years?" For the past many years high schools have required courses in basic computer use, and before that were courses on type writers. I'd argue that the people who are actually employable (/would be useful at a job) can learn to suffer through the infuriating computers that we interact with on a daily basis. While I don't question that software as is today can be quite painful for the new folk, I do question the statement that we're reestablishing segregation.

I'm also forced to question the realism of some of his suggestions. While they aren't bad (having a file system specific to word so you don't misplace files, etc), they seem to require a redesign of the computer itself as we know it- documents need to be shared between applications (emailed off to the PR department), and that level of interaction, to be useful, would need to be integrated across most of the programs the user uses every day. To an extent you can these in the new mobile platforms (iPad), but to see it in the desktop world you'd need to re-implement and integrate on the order of every program your computer-illiterate staff use.

3. What is the possible future work extending from this work?

Reading on further to see what other fun and enjoyable things he has to say about programmers.

XP Installed- Chapter 19-21

Bugs happen, schedules slip, no need to over react.

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson

Summary
Today's XP reading is ostensibly on steering. Steering go-carts, iterations, and releases. Primarily it says that "Steering feels good", "Estimation and Steering go hand in hand", "Estimation is important". It feels like a retreading, again, of the chapter(s) on estimation, delving into the role of the person that keeps track of how poorly the team is performing. 


Discussion

1. Why is this paper interesting or significant?

It discusses some empirical evidence for what does and doesn't work for tracking, including "the exercise is kind of useless if the folk aren't honest, so the tracker needs to be non-intimidating"; mentioning the people issues is a rather important step. 

2. What are the faults of this work?

I feel like it puts too much emphasis on reaction to slipped estimates... "OHH DEAR GOD!!! YOU'RE GOING TO BE 30 MINUTES LATE? THE HORROR!!! WE MUST GET OUR BEST MINDS HERE TO FIGURE THIS OUT!" It feels like a violation of the "estimates are just estimates" principle, and the reaction seems like something that's inherently threatening/intimidating. Sure, at some point someone should ask "would you like an extra set of eyes?", but to make it SOP is going to far. So says I.

3. What is the possible future work extending from this work?

I shall steer our project to the moon, hit the stars, and then lacking sufficient thrust to escape the gravity well our project shall splatter impressively into either a star or the ground, whichever comes first.

XP Installed- Chapter 16-18

XP Installed, Ron Jeffries; Ann Anderson; Chet Hendrickson


Summary
Today's XP reading covers "Do's and Don't's", "Experience Improves Estimates", and "Resources, Scope, Quality, Time". 


"Do's and Don't's" is a bulleted list of "do this", "don't do this", with some minor justification for each item. It's kind of a summarization of the important points of the previous chapters- do things that have immediate effect, don't do things that are useless. 


"Experience Improves Estimates" retreads a previous chapter in that it basically says "the more you estimate things, the broader an experience set you have by which to compare and estimate new tasks". It's nothing new. However, I was glad to see that they brought up "not all tasks can be compared- a database fix and a javascript issue may both come out to 4 hours, but that doesn't mean that by doing the JS issue you can estimate a different DB change, which I was going to pounce on and tear them apart for on reading the first paragraph of the chapter.


"Resources, Scope, Quality, Time" is a chapter that basically talks about "How do I present what I'm doing to the employer", making it one of the worst named chapters yet. The chapter gives a large number of example graphs and when you'd use them (use this towards the end of a project, this can be informative mid way), and ends with the advice "don't get too deep into metrics- while interesting, they don't contribute to the bottom line."


Discussion

1. Why is this paper interesting or significant?

16+17+18-(19-10) = 42, a significant result. It also has that last bit of advice on "Don't get too deep into metrics... we know you're a computer sciencey guy that likes numbers, but, really, you'll get lost". That seems interesting and useful.

2. What are the faults of this work?

I disagree with their statements on "Don't build for tomorrow". While they do have a point, there's a point where you cross from reasonable future-fore-thought to YAGNI violation- before that point you're decreasing future work, and after that point you're spinning you're spinning your wheels in the mud. But, the statements "It's almost always easier to add in later" is just... painfully, wrong. There are a few times where in it doesn't matter, but in general I've found that 'nice simple design' doesn't meld well with 'simple design for complex app'. Logic ends up in the wrong place, or in the wrong conceptual map, such that work is increased. Not to mention, failure to look forward also introduces compatibility issues. In my line of work, we're continuously releasing control software, but we don't make breaking changes to certain things for fear of losing reverse compatibility, meaning at design time we needed to ask "What do we expect to see". 

3. What is the possible future work extending from this work?

I shall makes charts about how well received our progress charts are received by the customer.

The Design of Future Things: Chapter 6

Feel that rattle? I don't think
it's supposed to feel like that...

The Design of Future Things, Donald A. Norman

Hip-hip-hurrah, hip-hip-hurray, my oh my what a wonderful THANK YE FLUFFY GODS THAT IT'S FINALLY OVER.

Also Dann, los geht's!

Summary:

Todays reading looks at communication between human and device, looking more at feedback from machine to man. At the core, he states that good machine communication means "seen but not heard", if I don't want to talk to my machine, I should know its alive, not dieing, and I shouldn't need to stare at it and open a dialog to determine these things. He restates for the fifth or sixth time that many devices are designed with non-natural indicators, and that when an error occurs, it's generally the poor hapless device that is blamed. He then details a few interesting occurrences within the field of handwriting recognition where-in people actually learned to blame themselves (and hopefully modify their behavior), rather then the technology, because they had a sense of "okay, this is why the machine isn't understanding me". He talks about natural mappings and cars. Which I won't go into again. Then he summarizes with the six rules that you should have learned from the previous 2000 lines or so worth of reading:

1. Provide rich, complex, natural signals
2. Be predictable
3. Provide a half decent conceptual model
4. Make the output understandable
5. Provide continual awareness, without annoyance
6. Exploit natural mappings to make interaction understandable and effective.

That is the book, summarized into 6 sentence fragments. I would have much preferred this with 10-20 pages of meaningful expansion. But that's me, and I'm not the professor.

Discussion:

1. Why is this paper interesting or significant?

It's the last one! It also gives a concrete example of where erroneous output leads to an implicit modification of user behavior- because that systems errors are based more closely on a drawing space then statistical inference, the user can see "Hmm, my g's look like m's, I should fix that". Which is an intriguing case study.

2. What are the faults of this work?

Early on Norman discusses lights as an arbitrary indicator of whether or not a machine is working, citing the fundamental disconnect between light and machine state (requiring a manual to determine meaning), as opposed to naturally generated sounds coming from mechanical machines. The problem with this is, when you're first exposed to a device, you have no earthly idea what any of the sounds mean either. You can say "ohh, hey, it's doing something noisy now, that means its working", but when first introduced to a device, you learn what the sounds mean. You do the same thing when introduced to a device with light feedback, "I plug it in, ohh, hey, a red LED, that must be some sort of power or charging light; I press a button and a light comes on and, after a minute shuts off. But Look! My ramen noodles are now edible. That light must indicate the magicy machine is making things edible". You learn what the indicators mean by interacting with the device, same as you always would.

He says at one point "People need to be kept in the loop" but never really specifies why. If a machine breaks that the person is responsible for, why yes, that person needs to be in the loop. If that machine is expensive and its breaking could cost lives, then yes, really, that persons need to understand it inside and out. If it's a coffee machine, or an upload, all I really want to know is "is it done", and maybe "is it even working", and that's the extent of how far I want to be in the loop. Which is to say, there are locales of where these things are and are not important.

Basically, at the core he ignores "different situations call for different thinking", and part of this stems from the fact that he never specifies a domain for his advice- clearly it's all coming from his need for smarter cars, but when it's applied to coffee makers, web sites, and factory control systems, the advice falls a bit flat.

3. What is the possible future work extending from this work?

Implementing the driver-less highway system. If for no other reason then to get rid of people driving cars, and thus implicitly, this book. 

(Sorry Don, but it's too wordy and repetitious for me)