Schedule and Homework ===================== When I designed the course, I was expecting only about 5 people taking it for credit, so the second homework was going to be entirely based on an in-class presentation. Unfortunately, as we discovered in the last session, we really don't have time for everyone to make an in-class presentation, so I feel I have to turn homework 2 into a written homework, which will be handed out on Monday, and due the following Monday. ** However, I would like a few people (say 4 or 5) to volunteer to demonstrate to the class some examples of GOOD and BAD user interfaces. I will demonstrate the Macintosh Map control panel (bad) and Quicken (good) on a Mac. The demonstrators can either show the programs live using either a Mac or a PC, which I will have in the class, or else use overheads. The presentations should be about 5 to 10 minutes, and can show one or more features of a program that are particularly good or bad. The presenters should reference the usability guidelines in explaining WHY the features are good or bad. Last year, I made the 4 PhD students in the class do the presentations, but this year the class is more diverse, so if there are volunteers, I won't coerce anyone. The presenters will get extra credit. Last year, the students presented PC Solitaire (good), PC Mile Bornes (bad), NeXTStep UI (good), the AIX Info Program (bad), and Tabs in Framemaker (bad). Benchmarks ========== I was very happy overall with the benchmarks. Almost everyone followed the instructions and created a useful and interesting benchmark. However, I would like to have a smaller number of benchmarks, so that more than one person can (independently!) implement each one. This will help to show whether the benchmarks are any good for finding out about the quality of the toolkits. Also, a number of the benchmarks were quite similar in domain, and a few were not appropriate. What I propose is that we create 6 benchmarks out of the 14 submitted. I discuss below the categories and how I think the benchmarks should be reorganized. What I hope will happen is that: * all the people who created a benchmark in the same category will meet to discuss how to implement the changes I recommend. In most cases, one of the designs is closest to the recommended final benchmark, and I hope that author will agree to modify the benchmark as described in consultation with the other students. * I hope that people will be willing to switch categories so there will be at least 2 people in each category. Remember: * The final benchmark should be fully specified so that on a particular platform, the implementation looks essentially identical independent of who implements it -- i.e., the implementer should not have to make many choices. * The benchmarks should be implementable by an expert on the tools in less than 8 hours, preferably in about 2 hours, and be less than 500 lines of code. Remember, you are going to have to implement this 4 times, and it takes a long time to learn the toolkits, so you don't want to be spending a lot of time on programming. * But the benchmarks should NOT be implementable by just using built-in widgets. * The benchmarks should be representative of typical tasks for a certain class of programs. * It would be great if the benchmarks were a fun program to do. 1. Animated Graphical Objects -------------------------- Neal Altman Animated Target Khalil Amiri Algorithm Animation Herb Derby Animated battle game Zhenyu Wang Trek game Comments: While the Trek game would be fun, it is much too hard to be a benchmark. The Algorithm Animation is OK, but probably also involves a lot of programming that isn't part of the UI. Therefore, I propose to combine the best features of Herb's and Neal's, which are quite similar in the parts of a toolkit they test, and I think either one would be a good starting point for the final benchmark. I don't see any need for the staged approach (multiple tasks) of Neal's. I like the editable name and Z data that move around with the icons. However, having the specified trajectories might be too hard. Maybe just use the arrow keys for speed like in Herb's. Maybe the "Z" display could instead show the health of the icon, and it goes down by 1 every Nth of a second and disappears when 0? 2. Multimedia (Video, Audio) ------------------------- Matthew Centurion Kiosk This is essentially fine. My main concern is how to keep the implementers from spending a lot of time getting or making the videos and the map, or converting among different formats. Maybe we should create a few sample video files in all the popular formats. Does anyone know how to do this? 3. Forms and Dialog boxes ---------------------- Fay Chang Address book Rich Kaylor Print dialog box Ralph Melton (not presented in class) The ideal benchmark in this category would have a lot of dependencies among fields: * filling in one field would cause others to - grey out or become available (like in Rich's) - change the available choices (like in Fay's) - change the default value for a field which hasn't been filled in yet I really like Ralph's idea of testing the re-usability and flow control among the dialog boxes. Overall, I think Fay's might be too hard for a benchmark, Rich's too easy and Ralph's too unspecified. Maybe y'all can get together on a joint design? The interruptibility testing is also neat, even though it isn't really specific to forms, but it might be included somehow. Is this really more of test of whether the underlying programming environment supports multiple processes? 4. Text Editing ------------ Chienhao Chen Multiple documents Matthew Tarpy Drag and drop on text I think it is important to include editing features that are not part of the standard text editing widget, since otherwise it is too easy, and it doesn't really test the case where the designer has some custom kind of text editing in mind. Therefore, I liked the drag and drop features of Matthew's. The final benchmark needs a more complete specification of which operations to support. 5. Paint Program ------------- John Huebner selecting regions Konur Unyelioglu paint and erase lines I liked John's paint benchmark, but remember that most toolkits have almost NO support for painting, so maybe make it simpler. 6. Basic Direct Manipulation ------------------------- Randon Warner Drawing Program Robert O'Callahan Solitaire cards I like the solitaire game, but I am worried that implementers will spend all their time on drawing the pretty pictures. ALSO: ===== I am concerned that none of the benchmarks really test creating NEW objects, since many toolkits (e.g., Visual Basic) make this much more difficult than manipulating existing objects. Another feature in my original DM benchmark (passed out in the first class) is constraints on the locations of objects, where the lines stay attached to the boxes. Is there any way to get these concepts represented in one or more of the benchmarks? Can you think of anything else we forgot?