Desktop Analytics Platforms: Version 1
Thanks, everyone, for your feedback about the Desktop Analytics software.
I’ve made the following platform choices:
Initially, the embeddable client library will strictly provide a C interface for Windows. In future versions, I’ll also provide wrappers in popular high-level languages, starting with C# and Java. At some point, the library will also be available for Linux and Mac OS X.
The server will be developed as a standalone Java server (i.e., without requiring Tomcat or JBoss or anything like that) with a MySQL backend. Future versions will enable more database choices (probably starting with SQL Server), though I won’t develop a non-Java version.
In a subsequent version, I’ll also release a “reflector” module in PHP/MySQL. The reflector will be a dumb server component that listens for events from the embedded client library and stuffs them into a database. Periodically, it will connect to the main server and send a batch of data. The purpose of the reflector module will be for developers who don’t want their users to see an outgoing HTTP request to an unfamiliar domain, but who don’t want to actually host the main server themselves. At some point, the reflector will probably also serve as a load-balancer and/or a failover mechanism.
The reporting client, with all the fancy charts, will be developed in C# using the .Net 3.5 framework, for maximum WPF goodness.
Thanks again for your help in choosing platforms!
June 20th, 2008 at 5:42 am
Good luck with your product.
I’m curious, have you done any market research as to whether this product is viable? I mean, do you have an estimate of whether people will want to use it?
June 20th, 2008 at 7:00 pm
As others have done, you could have also chosen to use a web service for the desktop apps to use but I think people would be very pissed if their desktop app hit the network for every operation so I think in the end your choice is a good one.
June 22nd, 2008 at 8:51 am
Our customers utilize a Win32 (C++) application that we provide…it’s distributed to about 2000 desktops around the country. Because our application already communicates back to our servers to perform its work, we have some of this kind analytics built in. For example, each login provides us with a couple of dozen stats like OS, memory, CPU, browser info (just like you are intending) and several other ‘accumulation’ stats like the number of times a specific function has been executed or option has been chosen. While we have found this info to be valuable, MORE valuable was a feature our lead developer added that we call the FDR (flight data recorder). As our application runs, we produce a binary logfile of each action the user performed (and every action each worker thread performs including local database calls). Upon a client crash, the latest FDR file(s) are uploaded to our server where they can be viewed with a special viewer (with filters to isolate just UI interactions or specific worker threads specific threads or database layer). These FDR logs have become INVALUABLE to troubleshooting exactly what steps took place that led up to an issue (much more valuable than a stack trace).
I think that providing simple API hooks to allow for that level of logging would greatly enhance your product offering….
That kind of functionality has allowed us to track down many obscure and rare bugs that would otherwise have gone unresolved.
Good luck with your product!!