Project Bamboo

Navigation:
Documentation
Archive


Page Tree:

Child pages
  • SchNar-0005 - A History Mechanism

This wiki space contains archival documentation of Project Bamboo, April 2008 - March 2013.

Skip to end of metadata
Go to start of metadata

A History Mechanism

Collection Date: January 6, 2009
Scholar #1 Info:

  • Name:
  • Email:
  • Title:
  • Institution/Organization:
  • Field of Study/Creative Endeavor:

Collector Info (can be the same as "Scholar" above):

  • Name: Stan Ruecker, Geoffrey Rockwell, Maureen Engel
  • Email:
  • Title:
  • Institution/Organization:

Notes on Methodology:

Collected via the Workshop III Needs Statement Activity

Scope

Keywords

1. Was this story collected for a particular Bamboo working group?  If so, please include, as keywords, the appropriate group(s).

2. Suggested keywords: Does this story contain elements that could be mapped to these keywords?  If so, please indicate which ones and briefly describe the mapping.  Add any additional keywords in #3. (These are global keywords from this page keywords)

3. Please list additional keywords here:

4. Related Stories: Are there parts of the story that relate to other collected stories? Please provide title(s) and link to the story page. 

Story

Bamboo: a History Mechanism

  • WHAT: a short description of a small portion/subset of your work around which you would like technology support and any "need to know" relationships between this subset of work and your larger research/teaching efforts,
  • HOW: the tasks you currently perform to achieve this portion of your work and any required order of these tasks (i.e. "x" must be done before "y")
  • HELPS: any tools or collaborations you currently use to help complete your tasks, and
  • NEED: a description of your specific technology need or your best guess at the technology support you want

What I would like to have readily available is a method for tracking the history of user activities within any given system. If I have a customizable way to store whatever someone does that changes state, ideally grouped by minor and major state changes, I can use it for three things:
providing the user with an un-do/re-do, or else a forward/back mechanism;
providing the user with a way to share state with other users;
providing the researcher with a log mechanism.

Since we do usability studies of our prototypes, the last option is particularly useful to use. I have had one of these components built for one of our prototypes. It worked very well for logging but was a custom component. It would be useful to have a robust generic one that could be plugged in to new projects.

Other Comments:


Link

Notes