views:

397

answers:

10
+4  Q: 

Instrumenting a UI

How are you instrumenting your UI's? In the past I've read that people have instrumented their user interfaces, but what I haven't found is examples or tips on how to instrument a UI.

By instrumenting, I mean collecting data regarding usage and performance of the system. A MSDN article on Instrumentation is http://msdn.microsoft.com/en-us/library/x5952w0c.aspx. I would like to capture which buttons users click on, what keyboard shortucts they use, what terms they use to search, etc.

  • How are you instrumenting your UI?
  • What format are you storing the instrumentation?
  • How are you processing the instrumented data?
  • How are you keeping your UI code clean with this instrumentation logic?

Specifically, I am implementing my UI in WPF, so this will provide extra challenges compared to instrumenting a web-based application. (i.e. need to transfer the instrumented data back to a central location, etc). That said, I feel the technology may provide an easier implementation of instrumentation via concepts like attached properties.

  • Have you instrumented a WPF application? Do you have any tips on how this can be achieved?


Edit: The following blog post presents an interesting solution: http://blog.pixelingene.com/?p=257

A: 

I have not yet developed using WPF.. But I would assume that its the same as most other applications in that you want to keep the UI code as light as possible.. A number of design patterns may be used in this such as the obvious MVC and Façade. I personally always try and keep the objects travelling between the UI and BL layers as light as possible, keeping them to primitives if I can.

This then helps me focus on improving the UI layer without the concerns of anything going on once I throw my (primitive) data back..

I hope I understood your question correctly, and sorry I cannot offer more contextual help with WPF.

Rob Cooper
A: 

@Brad, by instrumenting you mean collecting information on how the user uses the interface is that right? I'm not clear from the question exactly what you mean by instrumenting, but thats what I get out of your talking about transferring instrumented data to a remote location.

Sam Merrell
A: 

@Sam Merrell - Yes, I mean collecting data on how the user interface is used. I've modified my question to hopefully make that clearer.

@robcthegeek - Thank you for your comment, rob, but that isn't quite what I was looking for.

I really want to collect that information about how the user uses the system. What the click, type, etc inside the UI. Think the "Customer Experience Programs" for products like Office, SQL Server, etc.

Specifically, I want to implement this for a product, so technologies like WMI probably aren't suitable (if this were a corporate application in which I had access to that information, I would think WMI would be a suitable storage mechanism for this sort of information). I'm currently thinking of logging such things to a CSV file, compressing that file, and sending it to a web service. However, I really don't know if this is suitable.

Brad Leach
+1  A: 

You could consider log4net. It is a robust logging framework that exists in a single DLL. It is also done in a "non demanding" type mode so that if a critical process is going on, it won't log until resources are freed up a bit more.

You could easily setup a bunch of INFO level loggers and track all the user interaction you needed, and it wouldn't take a bug crash to send the file to yourself. You could also then log all your ERROR and FATAL code to seperate file that could easily be mailed to you for processing.

Dillie-O
+2  A: 

If you make use of WPF commands, each custom command could then log the Action taken. You can also log the way the command was initiated.

Brian Leahy
A: 

@Brian Leahy wrote: If you make use of WPF commands, each custom command could then log the Action taken. You can also log the way the command was initiated.

I like this idea a lot - one further question, how would you handle actions that may not have a command. i.e. a user checks a checkbox which is bound to some other widget and updates a business object property.

Brad Leach
A: 

Perhaps the Microsoft UI Automation for WPF can help out ? Its a framework for automating your UI, perhaps it can be used to log stuff for you...

We use the Automation Framework for auto-testing our UI in WPF.

Arcturus
A: 

I like the idea that Leon Bambrick posted on his blog. I'm a little surprised this isn't something that more people aren't writing about. I feel it would be a very useful to know more information about users using your UI.

@Arcturus - Thanks for the suggestion - I hadn't thought of using the Automation API in this way. Definitely something to look at.

Brad Leach
A: 

The following blog post gives quite a few good ideas for instrumenting a WPF application: Techniques for UI Auditing on WPF apps.

Brad Leach
A: 

Disclaimer: I work for the company that sells this product, not only that but I am a developer on this particular product :) .

If you are interested in a commercial product to provide this then Runtime Intelligence (a functional add on to Dotfuscator ) that injects usage tracking functionality into your .NET applications is available. We provide not only the actual implementation of the tracking functionality but the data collection, processing and reporting functionality as well.

There was recently a discussion on the Business of Software forum on this topic that I also posted in located here: http://discuss.joelonsoftware.com/default.asp?biz.5.680205.26 .

For a high level overview of our stuff see here: http://www.preemptive.com/runtime-intelligence-services.html .

In addition I am currently working on writing up some more technically oriented documentation as we realize that is an area we could definitely improve, please let me know if anyone is interested in being notified when I have completed it.

Joe Kuemerle