Philip Johnson wrote:
2. While all IDE sensors by convention will emit "statechange" Activity events in the same way in order to support the Active Time abstraction, they are free to generate other events for other purposes. There is no limit or constraint on what other types of Activity events an IDE sensor might decide to emit.
One could imagine a 'Busy' abstraction, which would represent the time interval during which any IDE event was detected indicating the user was doing something. The Jupiter code review sensor and associated Review Time analyses implement something similar to this, since during a review it is common for a user to spend significant time reading the contents of a file without editing it in any way.
Lorin replies:
If we wanted to implement such a 'Busy' abstraction at UMD, how much work do you think it would be? Let's say we just wanted to do it for Emacs. Would we need to modify:
- sensor-package.el? - sensorshell.jar? - server-side code?
My motivation is this: during an observational study I was doing, when the subject was debugging he spent a good chunk of time reading through code without modifying it. "Active time" didn't capture this, but I think that "Busy time" would have. We'd like to add this functionality to Hackystat before doing another observational study, but I've never mucked about with Hackystat internals before, so I'm not sure how much effort it would be.
Hi Lorin,
It depends. Although the Active Time abstraction only looks at statechange events, the Emacs sensor does record other activities of the user as well, such as file openings and closings. Furthermore, if you've installed the Emacs buffer transition sensor, then each time the user changes the active buffer, an event is recorded.
The way I would proceed is as follows:
I. Figure out what raw sensor data must be collected in order to obtain your 'busy' analysis.
a. First, take a look at the raw Activity sensor data collected from your subject (available on the Extras page). When you look at _all_ of the events, not just the statechange events, does that provide events sufficiently frequently for you to infer when they were 'busy' and when they were not? If so, good news, you've already got the raw data and you just need to add a server-side analysis.
b. If not (a), then the next step is to try installing the buffer transition sensor into Emacs and do a quick study to see if the addition of that sensor data results in a stream of events sufficient for your 'busy' analysis. In this case, you'll be checking the combination of the Activity sensor data type and the BuffTrans sensor data type. If it's the case that when your user 'reads' code, he is switching back and forth between different files fairly regularly, then this might be all the additional info you need.
c. If not (a) or (b), then you have to figure out what additional events to capture. This will involve watching the user to see what they do when they 'read' code.
II. Write a DailyAnalysis that shows, for each five minute interval, whether the user is 'busy' or not. You will model this on the MostActiveFile analysis, but it's easier: in this case, you're not worried about statechange processing, but rather as long as you see _any_ event occurring during a five minute interval, the user is 'busy'.
III. If you want telemetry, then you need to write a reduction function.
Let me know if this is enough to get you started. I can give you additional tips as you wade into the problem.
Cheers, Philip
