First, let me encourage everyone to send me the URL of their CSE 271 homepage, and also (short) email comments that enrich discussions on these pages (of course, there's no guarantee to publish all contributions, but they may help the participation component of your grade).
Chapter 4 doesn't give enough detail on various methods to make clear what must be done, but it does give an overview, showing that such methods are needed, why they are needed, and (to an extent) how to choose among them. A more detailed overview and comparison of certain methods is given in Techniques for Requirements Elicitation.
For expert reviews, it is important to clarify what kind of expert you have: domain experts will be useful in a completely different way than interface design experts. For example, expert cognitive walkthroughs may have little value in evaluating how new users will respond. But this can still be a useful method.
Usability labs are exceptional facilities not available for most projects. The thinking aloud method has serious problems with tacit knowledge, and also produces unnatural discourse that can be hard to analyze (see Techniques for Requirements Elicitation for details; here this method is called "protocol analysis"). Videotaping is hard work but can be worth while for some problems if it is done well. Paper mockups are usually a good idea, because they are so easy. The limitations of usability testing mentioned on p.132 are important.
The advice on surveys is good but too vague, and the suggested questions on p.133 are also too vague; Table 4.1 is better. As Shneiderman admits, "If precise - as opposed to general - questions are used in surveys, then there is a greater chance that the results will provide useful guidance for taking action" (p.134). Statistics should really be used to analyze the results of surveys, and this requires rather sophisticated knowledge. Acceptance tests are really part of the contracting process, but user interface professionals may become involved in their design.
Interviews and focus groups are highly recommended (at least by me). Continuous data logging raises serious privacy issues; moreover, the information you really want may not be available from such a source. Bulletin boards, newsletters, online help, etc. can be extremely important. As Shneiderman says, "Every technical system is also a social system that needs to be encouraged and nurtured" p.149). Controlled psychological experiments are a lot of trouble and unlikely to be very useful in most cases. Maybe the sentence on p.150, "If you are not measuring, you are not doing human factors!" is left over from a previous edition, as there is little in this book that argues for the value of measurement. Anyway, we are not doing human factors.
The rapid pace of change on the Internet is stimulated by the easy sharing of code and the capacity to build quickly on top of the work of other programmers. The frenzy is sometimes alarming, but is usually irresistible.
Latour says people and machines should be treated as equal, in ways that may be surprising. For example, he says we have to negotiate with machines just as with people (p.57), and he uses the neutral word actor (elsewhere in his work called "actants") to refer to both. What do you think of this? See also the discussion of relations among actors on pp.71-72, including the important notion of ally. Frankenstein comes into the story on p.74 - I hope you've read the book.
Latour uses the word technogram for a diagram of nonhuman actor's "interests and attachments" (p.58), parallel to the word sociogram already established in sociology to do the same for humans. (I wish he had given us some examples of such diagrams.)
I think the dialog on p.59 is hilarious. The ensuing discussion of the use of human metaphors for machines is thought provoking: he says words like authorize, notify, etc. should be taken literally not metaphorically (p.62). Of course, this is opposite to what most philosophers (and ordinary people too) think. What do you think?
The theological dialog pp.62-64 is also hilarious, but I'm afraid that not many of you will not know about Liebnitz's theory of "monads". Maybe wanting to laugh at things like this will motivate you to learn a little philosophy :-). I also enjoyed the discussion of project phases on pp.67-68; experienced engineers already know this, but often find it hard to admit.
The failsafe problem is a key technical issue for Aramis, and as it turns out, also a key political issue; see the distinction between intrinsic and probabilistic security on pp.68-69. Can you see why what applies to aircraft might not apply to metropolitan transport?
The idea that only in successful projects can you figure out what happened is perhaps a bit shocking. Does objectivity really only exist for successful projects? Symmetry of explanations is a key principle (p.78). What does this mean? Is Latour crazy? Some more of Latour's key words appear on p.81, especially mobilize and delegate. What do they mean?
Can you figure out who is talking in each of the passages on pp.81-83?
We began by going over the lecture of the previous meeting, and then over the Ackerman piece yet again - one sentence at a time! This took some time. I then distinguished between "push" and "pull" web technologies, and we again discussed the browser wars; I noted that such wars often involve fights about standards. We discussed body "torque" as another example of nuance; examples were given from the classroom. Then there was further discussion of speech acts. Finally, there were some brief comments on semiotics, the science of signs; these now appear in the notes on fifth meeting.