Reading Assignment: Laurel, pp. 103-111, 155-160
Reading Assignment: Laurel, pp. 405-416, 467-479
First of all, let me apologize for being a week later with this assignment than I had intended; I was trying to get as many of the 4 credit students as possible ready for the next step, but I should have said something on the class list about the delay. I figured you'd be kept reasonably busy giving Brett feedback on the library page, however.
Your major job for the next few weeks is, of course, working on your projects. Beyond that, however, I want to give you all some additional experience with iterative design in a programming project,
Therefore, the next few class assignments are designed to give you some experience with the process of analyzing and constructively critiquing user interface prototypes. Right now, as a result of work done so far this semester, we have TWELVE prototypes of a simple grocery store inventory program. Of course none of these are perfect -- no program ever is -- and some of them still explicitly lack some desired functionality. But they're all ready to begin to iterate on the basic details of the interface. Your next few assignments will involve working with the authors of a couple of these programs, using constructive criticism to try to produce a series of versions of the program that get better and better in terms of usability.
Critiquing a prototype is a tricky business. As the person doing the critique, you need to do a couple of non-obvious things:
-- You need to consciously and explicitly put yourself in the role of the intended user of the program. If the user is a child, your criticism should reflect your best efforts to see the program the way a child would see it. In the case of the grocer store inventory program, your criticism should be based on the assumption of a real grocery store manager, probably a bit harried and not very technical by nature, trying to use this program to get a real world job done as quickly as possible.
-- You need to be sensitive to the way the author of the program will perceive your sugestions/criticisms. Each of these programs reflects a fair amount of effort, blood, sweat, and perhaps even tears. It is only human nature to dislike criticism and to tend to react defensively. The person who critiques the prototype needs to remember that he is on the same "side" as the program author, that they share the same goal (producing the best program possible), and that the program author is a human being with feelings that can in fact be hurt. Thus, offering the critique is also a political/social exercise, and should be approached as such. Imagine, for example, that you want the author to change the interface so that instead of choosing a fruit from a list and then pressing the "select" button, all the user has to do is double-click on the fruit name itself. Here are two approaches to making that suggestion (both of them, in my experience, realistically reflecting the way some people actually make such suggestions):
1. "The fruit-selection interface is lousy because it's really inefficient to require two steps, clicking on both the fruit name and the select button. It would be much better to just let people double click on the fruit name."
2. "The interface with which you select a fruit from the list is very clean visually, and it certainly does the job. But it seems to me you could streamline the process for the user by allowing him to simply double click on the fruit name instead of clicking once on the fruit name and then once on the 'select' button."
These two comments both make the same point, but the first coment is pejorative, and more likely to make the programmer either defensive or depressed, neither of which is your goal. The second kind of comment tends to work better for a number of reasons. It isn't 100% negative -- it finds something nice to say about the item being criticized -- and it couches the improvement as a *suggestion* rather than a command or a statement of bare fact about what is "best".
-- Especially if you're a non-programmer, you have to make a a special effort to empathize with the fact that some things are harder than others. In this class, for example, most of the programmers probably have no idea, at this point, how to implement a "double-click" mechanism, so you shouldn't assume that they did it a different way out of stupidity or laziness! Often, a suggestion can best be couched in terms such as "how hard would it be to change the program so that....." Ultimately, if you make the programmer dislike hearing from you, your criticisms are going to be less effective.
-- Along the same lines: if you find things that are just plain bugs or missing features -- and you will -- make a special effort to be pleasant in the way you point it out, because the programmer may already well be painfully aware of the problem if it isn't a *design* problem.
-- If you're the programmer, you need to bear in mind that most people making criticisms haven't read or internalized any of the advice I've just given above, and they're likely to give you really unconstructive, hostile-sounding suggestions. Your job is to have as thick a skin as possible, and remember that even the most boorish and unfriendly of critics will sometimes make a good point.
So, anyway, here's what I want you to do:
FOUR CREDIT STUDENTS:
I know your programs aren't perfect yet; those of you who've asked me for help have, I hope, all gotten some. But all of you who've turned in a program have turned in something that is, I think, ready for critique. Swallow your pride, try not to think of all the things you still want to improve, and do the following:
1. Put a "stable" copy of your store inventory program in a location where anyone in the class can get at it (e.g. on newton).
2. Write a short (~two paragraph) description of how to get and run your program, and email it to all the people who are listed below as critics for YOUR program. Please get this email out to them by WEDNESDAY, April 14.
3. Continue with the assignment as described under "TWO CREDIT STUDENTS" (you'll have fewer programs to critique, though).
4. When the comments get back to you, you'll have at least a week to produce an improved version of your program, with a deadline of Monday, April 26, and then we'll do it all again.
5. If you beat these deadlines, you'll get to complete more cycles of iterations, and you'll end up with a better program.
TWO CREDIT STUDENTS:
1. By Wednesday, you should get mail from each of the people whose program you are criticizing, telling you how to find and run it.
2. You will have until Monday, April 19, to make suggestions on each of their programs. I strongly urge you to send them multiple messages with suggestions and criticisms, rather than waiting until Monday and sending them all your comments at once. this will give them a chance to ask you for clarifications, etc., and will make the act of sending out a comment less "heavyweight" -- basically, you want to send out a "casual" suggestion every time you think of one.
3. For each such comment/suggestion, email it to the program's author, and CC me at firstname.lastname@example.org. (Ideally, I'd like to be CC'ed on the whole discussion between the author and critic.)
4. If you beat these deadlines, you'll get to complete more cycles of iterations, and you'll end up with a better program.
Each 2-credit student will criticize 3 programs; each 4-credit student will criticize 2 programs other than his own. This means that each program will be critized by 5 or 6 people. Here are the matchups:
Ben Coakley: Bonath, Corvino, Gaswick, Ghaffar, Hand
Omar Ghaffar: Harris, Holloway, Lesh, Hand, Kensler
Jack Hand: Ma, McRitchie, Salter, Kensler, Luebke
Andrew Kensler: Sitaula, White, Yin, Luebke, Nangalia
Sarah Luebke: Routh, Bonath, Corvino, White, Nangalia, Nashel
Amit Nangalia: Gaswick, Harris, Holloway, Nashel, Pearson
Andrew Nashel: Lesh, Ma, McRitchie, Pearson, Rogers
Amartey Pearson: Salter, Sitaula, White, Rogers, Smith
Jamal Rogers: Yin, Routh, Bonath, Harris, Smith, Vick
Brian Smith: Corvino, Gaswick, Yin, Vick, Yohay
Andrew Vick: Holloway, Lesh, Ma, Routh, Yohay, Coakley
Michael Yohay: McRitchie, Salter, Sitaula, Coakley, Ghaffar
So, to summarize: Each programmer should put a copy of his program up in a public space at Grinnell and tell his or her critics where to find it and how to run it, by WEDNESDAY. Each critic should get comments back to the author by MONDAY. We'll iterate from there.
First of all, when I met with you all about your projects last week, I told some of you to try to get me certain additional writeups either right before or right after break. You know who you are!
Second, I'm not going to assign any more readings until after break. However, I want to assign you all some preparatory work for a design exercise that we'll get to after the break. There is nothing you have to hand in for this assignment, but I want you to be prepared to discuss it intelligently after break:
Design Exercise: Look at the Grinnell College Library web pages. Imagine that you have been given the task of completely redesigning them from scratch. How would you go about the task? Basically, I want you to get sufficiently familiar with the current web site, and to think enough about its structure, that you'll be ready to "jump start" another group design exercise.
Otherwise, keep working on your projects, and have a great break! -- NSB
Hey, gang, I'm BACK! We'll actually be having class meetings three times this week, 11 AM on M/W/F. Since we haven't had class for weeks, I will feel relatively free to keep you beyond the official 11:50 end time, but I *will* try to let you out in time to grab a quick lunch at the cafeteria if that's your preference -- otherwise, please feel free to bring food with you to class.
The main focus of the week will be discussions of your projects, but this will take place in private meetings -- please make sure to sign up for a block of time with me! (Those of you in a group project should work together and sign up for a time you can all make it.) The signup sheet is outside of Mr. Flynt's office in Science Hall, but will move to my office (Steiner 100, basement) when I arrive on Sunday. The meetings will also take place in my Steiner office.
I don't want you to view the meeting with me as a major ordeal to be endured; I won't bite. Rather, what I want is a chance to talk with you, to understand where you are on your projects (yes, I know it's still early!), and to be helpful in any way that I can. To structure the discussion, I recommend that you (and you partners, if you're in a group project) come prepared to answer a few basic questions:
In addition, we'll be having normal class meetings, and so of course there are new reading assignments:
Those of you taking the +2 should have just completed program #3 (see February 26). There will be no new programming assignment this week, but I'll try to give you feedback on that program and to help any of you who are struggling with Tcl.
In addition, there are specific reading assignments for each day:
Reading assignment: Finish Heckel.
Work on projects.
Four credit students:
Reading assignment: Heckel, pp. 1-101.
Design assignment: At first glance, the notion of "printing a file" sounds very simple. One can imagine a number of extremely simple user interfaces for it:
Perhaps surprisingly, there can be a lot more to it than that. On UNIX, for example, there is a program` at the other extreme, "enscript," which may be the world's most complex user interface for the simple task of "printing a file". It turns out there are a lot of different options that one *might* want in the course of printing a file.
An obvious question is whether or not there is any kind of "middle ground" between the simple interface that just does one thing, and the mind-bogglingly complex interface that enscript uses to empower the user with lots of additional capabilities. However, I don't want to leap straight into an attempt to design such a middle ground. First, I want us to understand the task space better. Before we can design a user interface for a complex set of tasks, we need to actually understand that set of tasks.
Your assignment: Read the "enscript" man page carefully. (This can be gotten online as a postscript file from http://guppylake.com/~nsb/enscript.ps.) Try to identify the different kinds of functionality that the program implements well enough to *taxonomize* the task set. By this, what I mean is that I want you to divide the various enscript features into categories, hierarchies, or other groupings, in a manner that you regard as "natural" -- i.e., to find a natural grouping of the various pieces of functionality offered by enscript. (I know that some of the options are *very* obscure -- if you can't figure out what they do, you may omit them from your taxonomy.)
The briefer and more succinctly you can taxonomize the design space, the better; you may write a textual description, create visual representations, or use some combination thereof. YOU ARE ENCOURAGED TO WORK IN GROUPS IF YOU PREFER. To turn in this assignment: Email it (with a list of all the people in your group, if you didn't work alone) to email@example.com. If you prefer to work on paper, that's fine too - you may fax your assignment to me at 734-994-7442.
Reading assignment: Finish Don Norman's "The Design of Everyday Things".
Write a one-page (less than 500 words) description of what you are going to do for your project. Turn in this assignment by email to firstname.lastname@example.org.
Four credit students:
Reading assignment: Don Norman's "The Design of Everyday Things", chapters 1-3.
Call (toll free) 888-573-8255 and ask every question you can think of about the weather. Try to find flaws in the system with which you are interacting, and note the nature of any flaws that you find (or any other interesting observations you can make about its design). I'm not looking for an essay here, just a short list of any key points you've noticed, to stimulate some on-line discussion. Send your observations to the class mailing list email@example.com
Four credit students: Look at example 3.3.7-2 on page 61 of the Flynt text. This program has hardwired values for apples and pears, but supports no other groceries. Write a program that provides a textual user interface for a store manager to add new inventory items (i.e. allowing the manager to define the cost of a peach, or a six-back of Bell's Amber, or to update the inventory to reflect current stock). You are encouraged to be creative in the design of this interface; you will be evaluated on the ease of use for the store manager, not the quality of your code. To turn in this assignment: Email the code to firstname.lastname@example.org.
Read Chris Schmandt's "Illusion in the Interface", pp. 335- 343 in the Laurel book.
FOUR CREDIT STUDENTS: Finish reading Flynt chapters 1-3, run the interpreter, bring questions!
In your daily interactions with technology, look for examples of what you think is particularly good or bad user interface design. Choose one example each of really good design and really bad design, and write a brief description (one-paragraph) description of them which you are prepared to share with the class.
To turn in this assignment: Email it to email@example.com.
ALL CS 295 STUDENTS:
I debated long and hard about having you read my own book, but I finally decided that if you all read it over break, then I would know in advance that you've all heard most of my old stories, and that would force me to come up with some new ones.
(*****) I intend to bring atonement pizza to the first class. Is Pagliai's still the best place to get it? Please mail me your vote!