[...]benjismith.net » Blog Archive » Analytics GUI Mockup[...]…

It’s been a pretty big project (at least, much bigger than the original 30 to 90 days that I had planned).

Between the Java server, the embeddable client library (calling win32 functions, securely communicating with the server, and providing a seamless offline experience, buffering all data locally until the connection is restored), and the C# XAML charting GUI, it’s been a whole lot of work.

Also: economic conditions forced me back into the humdrum workforce from my previous candyland existence as a self-employed consultant. So my regular time commitment for this project has dwindled precipitously.

But I still believe in it, and I’m still working on it, though I can’t speculate about a delivery date right now :o(

Thanks for checking in on me!!

–benji

2. Absolutely. The ability to submit custom data is going to be a key feature. But…….again, not in the first version :)

2. Are you planning to include some kind of a plug-in system which allows the developers to collect custom data based on their specific domains? For example, perhaps I have 3D design app and I want to know how many nodes my customers are creating per project or something weird (and unpredictable on your part) like that.

Well, this particular mockup is purely a graphic-design artifact right now. Nearly everything you see here was designed in Adobe Illustrator, though the Vista frame, the reflection, and the shadow were all added in Adobe Photoshop.

Having said that, the actual application will use WPF/XAML in .Net 3.0 to deliver the GUI elements. I’ve done some preliminary GUI prototyping, just to get my feet wet with the framework, and I’m pretty confident that I’m operating within its realistic capabilities (download a prototype stock market charting application here).

Besides the WPF implementation, I’m not actually planning on using anyone else’s charting framework.

In my book, one of the most important principles of product development (software or otherwise) is “don’t outsource your core competencies”. And, since “gorgeous, detailed charts” is one of the most important differentiating factors of this software, all of the charting components will be the result of 100% in-house development.

I’m on exactly the same page as you, but it won’t be included in the first version.

Initially, the embedded client library will be a simple little thing that you’d invoke like this, at the beginning of your Main() method:

And then, upon application shutdown, you’d invoke:

With that minimal implementation (and no customization), it’ll be possible to report all sorts of interesting details about the local environment, session duration, start/end times, session frequency, etc.

In a future version, there will be something like this, allowing you to log feature usage:

Some of that code would have to be written by hand (since my library has no way of knowing the entry-points for each of your features), but some of it could be accomplished through bytecode instrumentation (depending on the platform of your host application). It’d certainly be possible to instrument every GUI OnFocus event to log the name of the GUI element.

The client library would, of course, buffer all those events, to minimize the number of HTTP requests made.

@Richie Hindle Says
“I see you allow annotations in the charts – excellent idea, especially where you have more than one person looking at the data (and you’ll be making that possible, right?)”

Yeah, the annotations will be user-authored notes. You might add an annotation saying “New adsense campaign launched today” or “Launched version 3.2 today”. An annotation could be “global”, appearing on any chart whose time-series included the annotation timestamp. Or an annotation could be bound to a specific variable (like “browser version”), and then the annotation bubble would only show up on charts that consumed that variable.

I’ve also been thinking about the idea of “automatic annotations”, where the system would identify points of interest in the data sequence (for example, 30-day high, 30-day low, trend reversal, sudden increase/decrease in slope, etc). The concept is still a little fuzzy in my mind, but the icon for an “automatic annotation” would be distinct from the icon for a “user-authored annotation”.

And, yeah, the annotations would be stored on the server, in their own table of the OLAP database. So anyone logged in could retrieve the same annotations (via the web service) and display them in their own charts. Of course, that begs the question of having “private annotations”, which further begs the question of “sharing annotations”.

But those are all enhancements for a future version :o)

That’s exactly what I intend to do.

The embedded client library will report data about the local environment, the start & stop times of the software session, and sequences of events that occur during that session.

A server component will listen for those events and store them in an OLAP database.

Another server component will provide a query API, where the user specifies which client-side variable to tally, as well as an aggregation interval (one day vs one week), and the server returns a resultant data stream.

The reporting server will always return its results as either a “time-series stream” or a “value distribution set”. (Time-series data can be transformed into a value distribution set, by providing a “bucketing configuration”. A good example of this would be tallying up the total number of user sessions on each day of the week.)

After issuing a query to the report server and getting the resultant data set back from the web service, the charting client will send the data stream to a “chart renderer”. There will be multiple types of renderers for each type of data set (for example, in this GUI mockup, the “User Sessions” chart uses a VerticalBarRenderer, a SolidLineRenderer, and two ShadedRegionRenderers).

There will be two types of distribution data as well (QuantitativeDistribution and QualitativeDistribution), and although they’ll share a few renderers (like the HorizontalBarRenderer), they’ll also have some distinct renderers.

In version 1.0, I’m not planning on exposing any custom chart layout tools, but in subsequent versions, users should be able to create custom chart layouts (using existing renderers), and at some point in the future, they should also be able to add their own renderers using a plugin API.

I was a little hesitant about the donut chart too. I’ve read the criticism of pie charts in general, especially when you can present a bar chart instead.

I spent a lot of time brainstorming, trying to figure out how to display a hierarchical decomposition of OS users. I wanted a chart that could convey the proportion of Windows users, while simultaneously showing the proportion of those users on various Windows flavors. This chart shows that 75% of users are on a Windows platform, that about 63% of Windows users are using WinXP, and that about 41% of those users are on WinXP Pro SP2.

It’s also important to note that I think this chart would be very difficult to comprehend without the listbox and the bar chart. Also, there are interactive elements that I think provide a lot of clarification. For example, right now the GUI shows a selected slice from the outer ring, which causes one row of the listbox to be selected. Selecting a slice from one of the inner rings would cause multiple rows of the listbox to be simultaneously selected, with a tooltip displaying a tally of the percentages for all leaf-node children of that selected slice.

You can’t see the intended interactivity with this static screenshot, but I think it’ll work well once the implementation is complete.

Nevertheless, I’ll continue experimenting with other ways of presenting that data (something I’m calling “hierarchical membership decomposition”). I might find a successful implementation with a “hierarchical histogram”, but for right now, I’m pretty happy with the concentric-donut.