|
|
PitA-Board Meta-Design Project
(We are in the process of constantly refining our exact specifications. To this end, we have already met with Hal Eden and we expect to closely work with him even further in order to accurately define some of the aspects of this idea that are still vague.)
Team Description:
1. Statement of Problem
Currently the projects that can run on the PitA-Board use only run-time information input by the users. e.g. during bus route planning, the user profiles are created at run-time and are not saved for future use. There is no provision to carry out a demonstration at a later time based on the profile data entered earlier. Hence, users of the PitA-Board have to spend some time whenever they run their cognitive experiments or other EDC exercises.
Our aim is to provide a central repository and a simple interface to retrieve and store data that the user has input for any particular instance of their experiment. The project will deal with doing an analysis of the application and coming up with a design that is generic enough to support different kinds of data that are input by the various types of projects done with the PitA-Board. Examples of such data include maps, user profiles, image files etc
The elements that we currently anticipate to work on include:
a. A central database
b. Points of access in the current application
c. Interface between the application and the repository
2. Rationale
The idea behind this project is to minimize the time that users currently spend in setting up their environment before they embark on their actual exercise around the table. This time is even greater for new users who bring different individual learning curves with them. This was observed during the bus route design exercise. Furthermore if the users are different each time the exercise is done, then we have to contend with the repetition of the data input process.
It is these problems that we would attempt to solve and thereby provide an environment that is more conducive to EDC. The new system would also help in situations where remote access to all the experiment data is needed e.g. making presentations from a remote site.
In due course of this project, we expect to gain an understanding of the kind of concerns that drive design and implementation decisions for developing such systems. We will be using the existing implementation of the PitA-Board. In modifying the source code and making our own additions, we will have a chance to see some of the design strategies that were initially adopted. This in turn would guide our design strategy and the choice of implementation constructs.
3. Technical Approach
The current system is implemented using the Squeak variant of the Smalltalk programming language. We intend to carry out our development in the same environment. We consider this to be a favorable approach since...
a. our project will eventually have to be integrated into the current system, and
b. the current system also serves as a test-bed for our application.
Although this seems to the best approach, any alternative approaches that come our way during the analysis will certainly be weighed against this approach.
Implementation Plan:
- Defining the components to be developed (database, interface, etc. mentioned in (1) above)
- Defining the exact specifications of these components
- Familiarization with the existing source code (and programming in Smalltalk!)
- Identifying points of concern where our code will interface with existing structures
- Implementation of a prototype that serves as proof of concept as well
- Testing of our implementation
We expect to further evolve our strategy in conjunction with Hal.
4. References
1. http://l3dswiki.cs.colorado.edu:8888/PitAPB/
2. "A Task Analysis Approach to the Visualization of Geographic Data", Dissertation of Loey Kathleen Knapp, Department of Geography, University of Colorado at Boulder in 1994
(A complete list of references will be provided as our research and implementation evolves.)
|
|