Thursday, April 1, 2004
Contents:
Quiz 2 (Monday, April 5) will focus on L11-20, but MDDs and OMs are fair game. Remember that the quiz review session is on Sunday, April 4.
Final project information will be released Friday, April 2.
PS6 is due on Tuesday, April 6:
Anyone with an ill-formed group should contact the staff immediately, if they have not already done so.
test.out: Be sure you have corrected any errors in ps3, ps4, and ps5. It's important the modules you are building off work correctly.
Traffic Monitors: A number of students are confused by these. It might be helpful to explain ways to do this, either by pushing the data out from the lanes/intersections to the monitors or pulling the data from the lanes/intersections into the monitors. Listeners aren't necessary; observer methods are fine.
Q&A: TAs, hold a short round of Q&A. This could allow some common questions to be answered for the entire class.
Perceptual Fusion: Two stimuli within the same "perceptual processor" cycle (around 100ms) appear fused. One good example of this is Microsoft Windows' solution to menu bars. A common problem is users accidentally move out of the menu bar; they don't want it to change, but they stray. To combat this problem, the Microsoft engineers delayed the response time of changing menu bars. If a user moves out of the highlighted region, there is a +100ms delay to switching, so that if the user corrects the mouse position, no switch occurs. The problem with this solution is it frustrates users that do want to switch menu bars. The user will move to the next menu bar, but the delay is long enough for the perceptual fusion to be broken. Users are annoyed on a subconscious or conscious level, and might just think their computer is running slow.
Fitt's Law: The time T to move your hand to a target of size S at distance D away is T = a + log (D/S + .5). In general terms, it means as the target gets smaller and/or farther away, the time to hit it with a mouse pointer takes longer. To jab at Windows again, it takes an approach to the menu bar that doesn't play well with this Law. When users overshoot the menu bar, they must backtrack to reach the target. Users think this error is their fault, but it's just poor user design by Microsoft. On the other hand, Apple gets it right by putting the menu bar for every application at the top of the screen, so that you can't overshoot.
Windows:
Apple:
Low-Fidelity Prototypes: How many students considered prototyping their Traffick GUI first on paper? It would have helped you think through what exactly was required of your GUI. A number of students coded up a GUI before thinking through what they wanted out of it, and later had to change some significant aspects. Think of it as the design process for the user interface, which is just as necessary as the design process for the rest of your implementation. We strongly urge you to do user interface prototyping for your final projects.
There are two important themes in this course: correctness and communication. Correctness is obviously one of our goals; we want bug-free code without wasting a significant amount of time debugging. However, communication is a subtler goal. If we just wanted to talk to the computer, we wouldn't write AFs, RIs, or specifications. But we need to talk to other developers and non-developers. We need to convey our requirements and our high-level design, etc.
Waterfall Model: one of the first well-articulated design processes. There are six stages to the model: requirements analysis, design, coding, testing, release, maintenance. It's a good start and does reflect a close approximation to what we want, but it has some shortcomings. Most importantly, it's a one-way process, and software development is not one-way. Anyone who has taken 6.033 or has heard of Brooks' "The Mythical Man-Month" knows that you only know how to really design your system after you've already finished it.
Spiral Model: an iterative approach. Prof Miller touched on this model in his Usability lecture. It begins with a thorough requirements analysis and design, but instead of coding next, you prototype, evaluate, and repeat, moving from low-fidelity prototypes (paper) to higher-fidelity ones (like minimally-spec'd code) to the highest-fidelity one (production-quality, well-documented code). One caveat is prototypes are intended to be thrown away, not reused (no matter how much you want to).
Final project thoughts: Here are some thoughts on your final projects.
TAs: a good way to give the students perspective on their final projects is a reflection on your own 6.170 success/debacle.