Assignment 3

Activity Design, by Zach Tomaszewski

for ICS 667, Fall 2002, taught by Dr. Dan Suthers


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.)

Using a palm pilot scheduler
+somewhat portable
+digital, so can introduce new innovations over paper
+upload or backup to a computer, giving access to benefits of Internet access and other stored data/applications
+medium includes many more portable applications
-must turn it on before use
-expensive for breakage, loss, or theft
-must have batteries
-biggish (don't really fit in a palm or a pocket)
-small screen/possibly cramped interface
-requires certain user input skills

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:

Mission (Refined)
To create a free-form, transportable, digital task scheduler
  free-form: to appeal to a new class of users
  transportable: to be usable during the day
  digital: to allow innovations and interaction with other digital applications

Scenario-based Activity Design

Activity Claims

free-form input and information structure (like using a piece of paper)
+good for mission, since existing task schedulers are usually rather structured
+supports unscheduled users
+doesn't force an hour/day/deadline framework
+quick and easy to input
+familiar system of recording tasks for many users
+points towards a more simple, general design
-very hard to implement, especially input
-may alienate some users who expect more structure
-may not translate to a structured format in order to interface with other applications
interfacing with other applications (the point of going digital)
+can backup/save with no further physical space
+allows higher organization and interconnnection (ie, tasks could be linked with a time tracker for each task, with resources needed, with completed documents, with more traditional or collaborative time managers, etc)
-inherits all the complications of digital life--need for power, expense, tied to the machine, etc.
-some structure will likely have to be created or later encoded to allow integration with other applications, which opposes the free-form ideal.
completed tasks are erased
+usually don't want to see tasks again once their done (that's why people throw away their old schedulers) +frees up more space on interface -by notepaper metaphor, they aren't removed, merely checked off -some people might like to see old tasks

Activity Scenarios

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.

Essential Use Cases

Name:Inputting a task
Preconditions:System is ready to accept input
User IntentionsSystem 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 IntentionsSystem Responsibilities
 Show list of previously input tasks
Select task name to remove 
 Remove task
Postconditions:Task purged from the system

Comments and Conclusions

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.