Design Decision: Controlling Data Submission
Not enough data
When we started, we only captured data from popular development tools like Microsoft Visual Studio and Eclipse. After about six months of market feedback, it became clear that we needed more. Developers spent a large amount of their time outside of development environments, and our customers felt that this void reduced the ability to take action on the data.
So we built web browser sensors and an operating system level sensor to ensure that we caught 100% of computer time. Problem solved.
Too much data
100% of computer time including 100% of web browsing time just amplified "big brother" objections. Many developers raised violent opposition to the product because it captures all time -- including personal activities. We already had the ability to obfuscate URLs, but it was limited. And there was no way to turn data collection off completely.
A fundamental rule we've lived by is that relying on human interaction is bad.
We didn't want to be plagued by the same challenges as traditional project management solutions. Our goal has always been to get out of the way and reliably collect data. We had many discussions on how to empower developers without becoming a burden.
Inspiring use case: The Independent Contractor
During the time we were designing this new feature area we contracted an individual to help us with a sensor. Of course, he installed our product. I could review his data and get a sense of where the time was being spent -- and even compare it to the bill. One constant challenge was dealing with his "windows media player time." Every night around 7PM, he played music, watched movies. I didn't want to see this. I didn't want to create rules to filter it out. I didn't want to customize reports to exclude it. I simply did not want it at all.
Our Solution
First, despite countless debates the general feeling is that there are times that people want to be completely private. There are instances where it is well known that all the activities on the computer have nothing to do with business. A good example is Private Browsing in Safari. In this case, having the ability to turn "off" data collection is important. The challenge is that folks can forget to turn it back on. Folks will forget to turn it back on. This of course is unacceptable. Therefore, we settled on defaulting the private mode to one hour ( typical lunch break ) and supporting up to four hours ( typical evening ) off.
The other primary use case involves removing known activities that are personal -- e.g. windows media player. This called for a light rules engine to exclude data based on a pattern. Of course, this requires us to have the mechanism to review the data to see which would even apply. Hence, Manual mode was born. Desktops in manual mode just collect data for review. Data can be excluded individually, or rules can be created to bulk exclude.
Once an individual is confident in the data collected and has established appropriate rules, he can switch to automatic mode which submits all non-excluded data every 10 minutes.
Design is about compromise
So we didn't implement a simple "off" button, but we feel we captured the intent of the request and addressed real user issues with this feature set while maintaining our key principles. To see more of this new feature check out the video here.
Previous Post:
Announcing Summer 2008 Release
Next Post:
Defusing Big Brother Fears: Putting Developers Back in Control