EnterpriseLog, usage-logging

Most development work contains some type of logging.  Usually, it's to a local log file or an email, for exception tracking at the most.

Recently, I decided to throw together an EnterpriseLog table.  We tossed our logging bits into a central library... I don't know why it took so long to centralize this particular functionality, but I'm glad we did it.

Our EnterpriseLog table is providing useful data, as well as helping us answer some good questions:
- What applications are people using?
- Tracking ClickOnce downloads, system updates made by clickonce apps, etc.
- What terms are people searching for?
- Exceptions
- Usage

Usage Logging
Usage logging is has been very interesting so far.  An immediate benefit we have found is keeping track of how formatted information is being entered in unexpected ways.  It is amazing how many different ways there are to enter a phone number!  With a quick look at EnterpriseLog usage data for an application, we are able to recognize, learn, and accommodate actual usage patterns.  Continuing with the phone # topic:

With any phone number, a quick regex levels the playing field by stripping out all non-digit characters:
string nums = Regex.Replace(textBox.Text, @"[^\d]", "");

If the result string is 10 chars (in the US), format appropriately for area code and exchange.  If it is 7 characters, try to infer the area code from the exchange.  If it is only 4 characters, assume it is an extension and build the real number from there if possible.

In this case, usage logging helped me to skip the annoying validation and instructions and let my users do what they do.  We have been able to identify actual usage, throw assumptions out the window, and help them arrive at the appropriate result invisibly:
textBox.Text = String.Format("({0}) {1}-{2}", areaCode, exch, num);

Most of us base our UI development on assumptions about our users, past experience, and hopefully a book or two.  It is the assumptions part I have trouble with.  I'm a data guy.  I prefer to question the assumptions, set up some auditing and collect some data, and turn the assumptions into concrete UI features that keep the user in the flow. 

Print | posted on Tuesday, April 01, 2008 6:03 PM


No comments posted yet.
Email (never displayed)
Please add 8 and 2 and type the answer here: