This is the start of a series of blog posts describing the Usage Data Collector that is built into SharpDevelop 4.0. UDC as it is called for short is intended to help us better understand what features are being used, how developers found out about the feature (menu, toolbar, context menu, et cetera), how much time they spent using the feature, and if there were any issues (exceptions). The intention is to find out which features need to be surfaced differently so more people use them, which the popular features are (and thus should be given a higher priority) and a lot more.
Before diving into the topic of this blog post, one important piece of architecture information: UDC is not tied to SharpDevelop. We developed it to be reuseable in your applications. Including (a yet to be developed) analysis Web frontend. That's also why we intend to give you a good background on what we collect, how we collect it, how it is transferred - so you have a good understanding whether it is suitable for your userbase.
On its new start page, SharpDevelop 4.0 asks you to participate in the customer experience improvement program:
If a user wants to participate and clicks the "Save" button, we do send the initial usage data message - for two reasons: first, depending on firewall settings, the user might need to allow SharpDevelop to communicate with the Internet. Doing it right now and there allows the user to see why SharpDevelop wants Internet access. Secondly, we gather Session "0" - information about the version of SharpDevelop, and on top of what platform it is running.
In terms of actual data, this is a sample UDC signup message (line 1 has been truncated for xmlns elements):
1: <UsageDataMessage ...>
4: <EndTime i:nil="true" />
43: <Exceptions />
44: <FeatureUses />
Please note line #49: each client machine creates a GUID for itself. This GUID is used to map all sessions to a single user - so we can tell whether a single developer is using a feature heavily compared to say a hundred developers using the very same feature lightly.
As you can see, the initial message is very small. Once data is being gathered, the messages do increase in size, and contain more information (feature use, exceptions). We will look into those message in future blog posts, as well as how those messages are processed and analyzed.