Looking over last week's Workplace Themes and problem scenario, it looks like the PalmPilot is the best way to go that allows the most room for innovation. (As stated in Mission, we want to introduce a product only if adds something.)
Another interesting discovery was the "notepaper" style of task scheduling. (I have since added a scan of such a system to Assignment 2.) This is a promising area, since such a free-form style is currently poorly supported by common task schedulers. This calls for an refining of our Mission Statement:
Bob is a college student who rarely uses schedulers. He just bought a PalmPilot. He is using the new tasklist software, rather than a scrap of paper, to help keep track of those things he needs to get done. On the bus, he pulls out his PalmPilot. He turns it out, and opens the tasklist application. He inputs three task: "get a haircut", "finish Assignment 3", "call Mom." He groups "get a haircut" and "call Mom" together, separate from "finish Assignment 3". He turns off the PalmPilot.
At the end of the day, Bob gets his PalmPilot out again and turns it on. He checks his tasklist. He marks those tasks that he has completed. He turns it off again.
After a month of using his new task scheduler, Bob learns he can upload his tasks to his desktop. He does this. He enjoys being able to scroll through old tasks, which have automatically included their dates of creation and dates of completion. He is amused by how long it takes him to get certain things done. He also learns that he can keep track of how many hours he spends on current tasks, and to include links from those tasks to certain resources.
Name: | Inputting a task |
---|---|
Preconditions: | System is ready to accept input |
User Intentions | System Responsibilities |
Input task name | |
Record task | |
Postconditions: | Task is saved for later retrieval |
Name: | Removing a task |
---|---|
Preconditions: | System is ready to accept input |
User Intentions | System Responsibilities |
Show list of previously input tasks | |
Select task name to remove | |
Remove task | |
Postconditions: | Task purged from the system |
The activity scenario was what I had an urge to create during the last assignment. I can see that the ability to move between the different phases, rather than the current waterfall method, would greatly help.
I really like the claims. I would expand the claims to include a decision, though. I would list the advantages and disadvantages, and also whether and how to include it in the design. I suppose this is supposed to be accomplished by the scenario, but I'd rather have them together.
The scenarios are very concrete and helpful tools to sum up, but I still don't really like them very much. They're too specific somehow. What the system does in general and why gets hidden somehow by all the user details.
The essential use cases were helpful to figure out what exactly the system has to be capable of without introducing implementation. For example, my EUCs work for both paper and pencil and with a PalmPilot application. Yet this doesn't really tell us how to best go about accomplishing these tasks. Combined with claims, they could be a good tool.
Overall, were I to do this again, I would use a EUC to figure out what they system must be capable of doing. Then I would use claims to weigh the possible implementations in terms of their advantages and disadvantages, and then state which seems the best decision between the alternatives. The EUC shouldn't really change. The claims can be updated if new positives or negatives are discovered. Yet these are too vague for people not closely tied the whole design process. For presentations, I would gloss over the abstract details but then give a concrete scenario description to illustrate the points.
<--Assignment 2: Requirement Analysis | Assignment 4: Information and Interaction Design--> |
~ztomasze Index:
CIS: Assignment 3 http://www2.hawaii.edu/~ztomasze |
Last Edited: 17 Oct 2002 ©2002 by Z. Tomaszewski. |