Everything below was used as planning, and should mostly be put into that PDF, except in a much nicer, neater format. For the actual report, please click the link to the right.

From the CDMP:

A final report of your research project that summarizes your work for the summer. This is a technical paper describing your research project. It should provide a technical description of the project and the results you obtained. It should include a scholarly review of the related prior work, including citations to the relevant literature. The writing style and technical level should be similar to that of a paper in a technical conference in the research area.

Various images of other applications

Ideas picked up: main menu (iconified), windows, tabbed windows, ways to present information (such as a cartoon face for emotions)

Top

From the twiki:

User Types
The following list describes the types of users expected to be utilizing the haptic creature editor. The tool need not address each user type completely; however, it helps to keep them all in mind during the design. Also, each user type is not mutually exclusive. That is to say , a developer can also be an experimentor as well as a demonstrator. Therefore, it may be more helpful simply to think of the user types as roles.

• Developer: This user will be actively developing the software and hardware for the haptic creature platform. S/he will need the ability to make changes to the underlying platform then verify that these changes produce the desired results. These changes can be very small, low-level ones such as removal of a paricular sensor. However, these could also be larger, higher-level modifications, such as the addition of a new emotion model, which require a broader check to be performed.
• Tester: Effectively the same type of user as the developer; however, does not have the ability to directly modify the creature platform. This user may wish to repeatedly perform a sequence of operations on the device, perhaps with (usually small) adjustments to values upon each iteration. The major difference between the tasks of the developer and the tester is that the tester is expected to be exercising the device in a variety of ways for an extended period of time while the developer mainly wants to make changes to code/hardware and test the changes in isolation.
• Experimenter: This user will be using the haptic creature for the purposes of running an experiment.
• Demonstrator: This user will demo the haptic creature to interested parties. This person may have little knowledge of the internals of the platform. Rather, s/he would run the creature through some higher-level canned operations. For example, have the device display a upset emotion, or have the device respond as if it had been petted gently.

Task Descriptions
The following list enumerates the various tasks that may be accomplished via the haptic creature editor. Note that some of the functionality for the tasks will be available from the underlying architecture; the editor simply needs to communicate with the underlying component. One example of this would be the task for saving a data stream: the editor simply communicates with the component(s) of interest that their data should be saved while the component(s) actually handle the work.

• In general, visualize and edit properties of any component on the system. Some components may be view only, while others may be view/edit
• Visualize if the software and hardware components interact properly with one another---i.e. the application displays the correct values for what the sensors and actuators ought to be set, or if anything is being sent between components and software at all
• Visualize the data values as they flow through from sensors to the different parts of the software and out to the actuators
• User wants to figure out what each value means, i.e. instead of just seeing a number, see what the value's intensity is (how strong of a sensor reading, etc)
• Selectively enable/disable components of the system. For example, turn off a single sensor or enable a previously disabled actuator
• Directly modify the value of a sensor or actuator by setting its current value to something else. An example would be similar to a calibration or a zeroing of the hardware
• Change value of an actuator so that a different outcome occurs with the current sensor readings
• Change value of sensor, either manually or through a stream of pre-recorded values
• Capture the current settings of the creature's current values, so as to freeze in a point of time, or for configuration purposes
• Capture a stream of data for the various components of the system
• Load a configuration file for the creature

  Other things we decided were a good idea: keeping the application simple and modular, to allow for flexibility in exact function.

  Top

  
  
  

After looking at different examples, figuring out some ideas for the application, and keeping in mind the five different parts of the haptic creature, I came up with a sheet of images depicting different ideas, which Steve and I went over. We eventually decided to go with the master panel idea, where the main part of the application is a single window, which can bring up other windows for each of the five sections of the creature. Multiple separate windows would maintain the modularity of the application, more so than creating a tabbed window where more coding would be involved both to create and deconstruct the application. Also, tabbed windows would not allow different sets (i.e. sensors and actuators) to be viewed at the same time, meaning more switching would be involved. Tabbed browsing, which works well in the internet browser context, we felt would not be the best choice for now.

Top

Mmm... Swing.

The Frame.NORMAL saga

What's currently set up: a main panel pops up when the application is run, and has five buttons. Each of the buttons creates a new frame, which then connects to the appropriate panel. As none of the panels are currently implemented, except for a very basic sensor panel, each button is set to create a new frame with the same panel. This was so that I could get all the functionality into it that I could. I've tried to use javadoc comments where I can, so I am hoping to have the docs available for reference.

Top

Played with the accelerometer, the RFID reader, and the IFK.

Looked at example code in different languages, downloaded from Phidget web site. Got phidgets to work in Java, built small Swing interface for them, working with the Phidget web service

Top

Top

User Interface Design and Evaluation (Stone, Jarrett, Woodroffe, Minocha)

Java Swing (O'Reilly)

Java API

Top