About the ProjectI am now working on a Hackystat related project call AmbientHackystat, which utilizes Hackystat with ambient device to show users some useful project states that indicated by data collected by Hackystat. For example, turn the ambient orb into red when a build fail and let the nabaztag(a bunny) tell you when new changes are committed to code repository. I am think of how will the thesis be if it is based on this.
The system is defined by a set of trigger action pairs, where trigger get data from Hackystat database and check it, then invoke some ambient devices' action when the data satisfy some defined condition, such as last build fail.
For the current moment, the functionality is quite simple. The orb can change color and pulse speed, and the bunny can only talk. There are only two triggers available: SensorData and Coverage. Though SensorData trigger is able to configure to monitor all kind of sensordata from Hackystat, sensordata is too low level that only a few type of data will be meaningful to be monitored. My partner is working on the bunny and it will be fully utilized soon hopefully. I still keep working on the triggers and more will be built in the future.
Thesis research point
There are two research point within this project:
1. What kind of trigger will be useful
This part is more like a data mining process. How to generate meaningful data for the thousands of raw data. What kind of information will be interesting to developers and project managers. How much detail should be provided, such as should it tell the number of coverage or just show if the coverage is within a certain level. It has to be careful when abstracting information, too much detail will make it verbose while too little detail will make it meaningless. However, this part is mostly similar to another project in my lab that call Boswell, which is a auto micro biographer that generate informative message and send it to all kinds of information platform such as twitter, email, text message or even facebook. The core parts of these two project are the same: abstract information from raw data of hackystat. So make be we should work together in this part for research.
2. How to present a project state/development event on ambient devices.
This part is much unique. How to present things is really a matter. It has to be noticeable enough to make people to be able to aware of it. But it should not be too distracting. People need to be focus on their work and don't want to be scared by ambient devices. Hence color and animation seem more fit this situation than sounds and speech. However, some particular events may do worth a vocal alarm, such as build fail may be one of them. These issues are needed to be settled.
Problems of research
The most important issue for this research is the user. We do need a group of user to really try this out to tell if a certain function is useful. It might be OK even if we are the users ourselves. But in order to evaluate the system, we have to be a group that working on a same project and work with some certain behaviors that will make these ambient devices useful. For example, we should have people working at the same time that they will not be too easy to have the whole view of their project, then we can evaluate if it is useful to let the ambient devices tell them if the build and test fail or if someone is opening/editing the same file his is working on.
At this moment, we only have 3 people working on this project. We usually work at different time. And I, the only one get easy access to these ambient device, is the one write most of the project. So I already know what is happening before the devices change their state. I hope we could have some real users to try this mechanism and provide feedback so that we can evaluate and improve. I think this will be an essential part of the thesis.