The Telerik Platform product is retired.Learn more

Application Usability

With Analytics you can pro-actively improve usability in a number of ways. You can for example:

  • Detect popular functionality and provide easy access to it
  • Examine the user’s workflow and eliminate road-bumps in their way
  • Improve efficiency and responsiveness of your application
  • Fit well into the environment on your user’s machine
  • Perform graceful error-handling

The remaining of this section will walk you through several examples of all of the above.

Most will be real examples taken from a product for which we have collected analytics data since 2008; the example we will show here is EQATEC Profiler, which is a performance code profiler for .NET applications. Its usability has been constantly improved by observing it via Analytics. Has that effort paid of? A resounding “yes” is the answer. Here are a few of many positive quotes:

“its really easy to use user interface, its super-intuitive and I got up and running in seconds”

“an amazing quality software, it was a real breeze to use”

“even without reading any documentation or paying any attention at all to what I am doing, I was able to successfully, from start to finish, profile an application. Usability is a wonderful thing.”

We are especially proud of that last one. There is abolutely no doubt that good usability is one of the major key features of our code profiler, and Analytics has played an important role in achieving that.

With Analytics you can easily track the user’s interactions: see how often they click buttons, select from menus, navigate, interact etc. You do so by manually inserting named track-points in your application at interesting places. The number of times a track-point is reached will then appear as a graph in the Analytics client.

Here is a real example from our EQATEC Profiler. It has an “Undo”-feature which we frankly thought nobody really used. But we were very wrong: it turned out 9% of all total button-clicks were Undo, making it the second-most clicked button in the entire app! We therefore made that functionality more apparent so users would not have to go hunt for it. We track those button-clicks using the API method TrackFeature, and the code for the Undo-button and the graph of all user-interactions in the profiler’s main area is shown below:


Tracking usage of "Undo Build" in EQATEC Profiler

Another example from the profiler reveals the user preferences. The profiler can profile all types of .NET applications and we wanted to find out what most users actually used it for. Again we used TrackFeature to add tracking using just a one-liner and got the graph below:

monitor.TrackFeature("AssemblyType." + type); // type is Exe, PureDLL, etc

Tracking usage of the assembly type in EQATEC Profiler

This show that most of our users profile “real” applications (61%). Some just profile libraries (32%) and even fewer profile ASP.NET and Silverlight apps. And very, very few will profile Windows .NET services. When we noticed this trend it prompted us to make two usability-decisions:

  1. Please the majority 61% by making it really easy to profile real applications
  2. Ignore the 0.17% users writing .NET services – do not pollute the GUI with service-related instructions

Here are some typical examples of improving ease-of-use:

  • TIP #1: Detect changes to default settings. Track the value of all settings to get an overview of what changes users make. If too many changes a certain setting then maybe you should consider making their choice the new default. If nobody ever changes a certain setting then maybe that setting should simply be cleaned out and removed.
  • TIP #2: Track clicks on buttons and menus etc, as in the undo-example. Then use that information to organize your GUI in a way that makes popular functions easy to get at. Likewise, this can be an opportunity to move rarely used functions out of the way or even remove it completely.
  • TIP #3: Track other user’s activities and preferences to optimize your application’s presentation. For instance, do users prefer to use your iPad app in landscape or portrait mode?

Eliminate road-bumps

One characteristics of good design is “design that doesn’t get in the way”. A well-designed object allow you to use it without really paying any attention to what you’re doing. It gives you a feeling that “it just works”.

But often it doesn’t. You operate it the wrong way. You become uncertain and hesitate. You have to make a choice you’re not really prepared for or care about. This creates a road-bump in the smooth flow your user was expecting.

Here is one simple example from the EQATEC Profiler. We added a mechanism to check for an error-situation and offer to fix it. Surely everybody would say “Yes, thank you very much” and click OK, right? Well, apparently not:

monitor.TrackFeature("CoreConFileRepairNotice." + (repair ? "OK" : "Cancel"));

Most users decline the repair-option in EQATEC Profiler

To our surprise more than half of all users click Cancel. We have not addressed this situation yet, but clearly our users are not behaving as we had expected. We really should improve this, by eg explaining the advantages of choosing OK better in the dialog.

Here is another example which we did improve. The profiler would sometimes have to ask the user where they kept a certain “signature” file. It would be better if it didn’t have to ask, so we added a detection mechanism to handle the situation without bothering the user if possible. Great! But – how do we know how well our automation actually works? Does it even work at all? We can find out by tracking its success:

if (wasAutoDetected)

It appears that the automatic detection works for about 1/3 of the time. We has hoped for better, but at least life has become easier for a third of our users. Without analytical data we would not have known if our efforts had an effect at all. Now, if we make a change to the algorithm we can easily see if it really is an improvement.

Here are some examples of enhancing the workflow:

  • TIP #4: Detect dead-ends in the GUI. If too many users press Cancel in a dialog then maybe it is leading them on down the wrong path? Maybe they expected something else down this road since they bailed out? You can track this by using TrackFeature-calls on all relevant actions in your dialog and flows.
  • TIP #5: Detect requests for help. This is straightforward: if the user asks for help then it clearly indicates a weak spot in your application where there’s apparently some confusion and need for clarification.
  • TIP #6: Detect how well your automation works, like the signature-example above. Wherever your application can do something automatically, but also fail, you should track your success rate. If you do music-matching then track how often it works. If you do automatic recovery of network connections then track how often that succeeds. Once again: if you don’t track how well your clever code works, you really have no idea.
  • TIP #7: Track user choices. Every time you ask the user something, track the response.
  • TIP #8: Perform timing of important user tasks. How long does the user “hesitate” at certain places, e.g. when buying something? Use the TrackFeatureStart and TrackFeatureStop calls to track that. You can even apply a “usage-count” filter in the analytics client to see the difference in behavior between beginners and experienced users.

Improve efficiency and responsiveness

To many users, performance is a feature. Your application must be fast.

With Analytics you can perform timing of every kind of feature you want in a very simple manner. This is especially essential if you have SLA (Service-Level Agreements) requirements to live up to, such as “operation x must be performed within time t”. Timing is started by the TrackFeatureStart API-call and completed or cancelled by TrackFeatureStop and TrackFeatureCancel.

As an example, we measure the startup-time in EQATEC Profiler. We name the timer EQATECProfiler.GUIStart. Just two lines is needed for that, which is shown below along with the graph:

monitor.TrackFeatureStart("EQATECProfiler.GUIStart"); // at start-up
monitor.TrackFeatureStop("EQATECProfiler.GUIStart"); // when GUI is shown

Tracking GUI startup time for EQATEC Profiler

The graph shows that two-thirds of all users experience a startup-time of 4,3 seconds or less. Based on this we have confidence that our startup-code performs quite well, irrespective of what the application is loading at startup. We have therefore e.g. decided not to show a splash-screen.

Apart from speed, you may also be concerned about the use of resources.

The profiler, for instance, produce timing-reports as files that can be arbitrarily big. But how big are they really, out in the real world? Do they grow too big to handle? Should we be concerned or not? We use the API-call TrackFeatureValue to measure the size of the produced reports. Here is the one-liner code and produced graph:

monitor.TrackFeatureValue("EQATECProfiler.ReportSize", size);

Tracking size of profiling-reports generated by EQATEC Profiler

Out of 207138 measured reports the average size turns out to be only 155KB and over half of the produced reports are less than 100KB big, as shown in the first column. That’s not much – we’ve seen other profilers produce reports in the 100MB-range so this assures us we have no reason for concern.

Gather data to improve your optimization effort

A different angle on efficiency-optimization is using gathered analytical data to learn how to improve your current efforts in some area. Let’s look at an example, which admittedly is a bit technical:

Our profiler measure methods in NET applications. But measuring all methods slows the investigated application down and we want it to slow down as little as possible. The profiler has therefore been coded to ignore small and “irrelevant” method calls. But what is irrelevant? We have identified about 20 such pieces (like “return a constant”, which can never be a bottleneck in itself) and ignoring such methods really speeded up the application. So the idea was sound, but surely there are other code-sequences fit for being ignored beyond the 20 we thought up. But how do we find out? The solution was to use Analytics: if the profiler encounters a method of max 5 instructions that is not fit for being ignored, it will record that instruction-sequence using TrackFeature. We discovered some really good pieces of “ignorable code” that way which further improved the performance of the profiled application. This is what our “code-instruction sequence” graph looks like now:

Optimizing EQATEC Profiler by tracking the nature of profiled bytecode

Now the code-instruction sequence “Ldarg_0 Call Ret” (blue line, 35%) is the most often occurring sequence that we are not ignoring. However, it is a call into another method (the argument 0) so it should not be ignored, and the others are similar. So right now this part has been optimized to its fullest, based on real data from the field.

Here are examples of improving efficiency and responsiveness:

  • TIP #9: Use TrackFeatureStart and TrackFeatureStop to measure processing time when your application does some work or at startup. Maybe it is not as fast as you expect or have promised.
  • TIP #10: If your application uses sparse or expensive resources then use TrackFeatureValue to detect how much it actually uses. How much network traffic does your mobile application generate, for instance?
  • TIP #11: If your application is optimized for certain expected scenarios then verify your assumptions. If, for instance, some data form for historical reasons has a 10-line long “Additional Notes”-field then use TrackFeatureValue to measure how many lines of texts your users actually writes. If 98% write one-liners or nothing at all then maybe you should reconsider your form layout to adjust your application to match the real usage.

Adapt to the environment

The better you know the surroundings of your application, the better you can make the user exerience – just ask anybody who has a web-application and is using some sort of web-analytics to track browser capabilities.

The same holds true for desktop and mobile applications. For instance, what OS do your users have? What .NET framework are installed? What is their screen resolution? Their screen DPI? Language? Memory? CPUs? Country?

We don’t have any code examples for all of the above examples, because it is not necessary: all this, and more, will be collected automatically simply by running the monitor in your app. So let us start by looking at a few very basic examples of what it can be used for.

First, here is the highest version of the .NET framework that users of our EQATEC Profiler has installed:

EQATEC Profiler users has this .NET framework installed

We have so far refrained from relying on .NET 4.0 to spare users from having to upgrade to that version. It seems like we could move onto .NET 4.0 now without bothering too many people.

Here is another somewhat surprising example. The profiler can display one “report” which take up most of a screen. How about adding support to show two or more reports at once, maybe on multiple monitors? Probably a silly idea because most users still only have one monitor, right? Let’s take a look:

Many EQATEC Profiler users have more than one screen

Apparently, a high number of our target users (software developers) actually have multiple monitors. Knowing this is really valuable when we prioritize adding better support for multi-monitor users.

It can also be useful to know your users’ language even if you don’t plan on translating the application. For instance, our profiler is very popular in Japan. That is an incentive to at least make sure it doesn’t have some obvious visual “bugs” when displaying japanese characters. In the two screenshots below you can see the application’s country and their language:

EQATEC Profiler is quite popular in Japan

EQATEC Profiler is quite popular in Japan

In one last example we go beyond the built-in statistics. Our profiler presents some long numbers, like e.g. 1000000, and they can be hard to read easily. We therefore added a thousand-separator, but learned that some users mistook it for a decimal point. Oops. We therefore started using a character called “thin space” as thousand-separator, so our numbers would look like this: “1000 000 ”. While visually pleasing it turned out that the character was not universally supported, so as a fall-back we use no separator at all if thin space is not available.

So, how well does this solution work these days? Let’s take a look at how we measure it and what the result is:

string thinspace = "\u2009";
if (IsInvisible(thinspace))
  m_culture.NumberFormat.NumberGroupSeparator = thinspace;
  m_culture.NumberFormat.NumberGroupSeparator = "";

No all EQATEC Profiler users have the thinspace character in their font

Good news: support for this “thin space”-character is becoming more widespread over the years, so we are confident that we format those numbers in a pleasing manner to the majority of users.

Here are some examples of how knowledge of the users’ environment can improve usability:

  • TIP #12: Know with confidence what the lowest screen resolution you need to design for.
  • TIP #13: Make informed decisions on when to make to new technologies. When is it okay to assume your users have moved to Java 7? Or MacOS X Lion? And do you really still have to support Windows 95?
  • TIP #14: Discover opportunities, like we did in the multi-monitor example.

Perform graceful error-handling

An application that crashes or misbehaves is no good, no matter how fast or well-designed it may be. Graceful handling of error conditions will score you good usability points.

The most basic step is, of course, to log errors in your application. To log an exception you just need one line of code, show below along with an example report.

Monitor.TrackException(ex, "More info about what you were doing");

From a usability point of view there is, however, other interesting aspects than simply tracking errors.

For instance, by observing error scenarios in more detail you can add specialized handling for common problems that you did not know about during development, and handle the situation better.

Here is an example. The EQATEC Profiler can encounter an exception while deploying a profiled app to a handheld device. We catch the exception but also track the error code inside:

catch (SmartDeviceException ex)
  if (ex.ErrorCode != 0x80070005U) // 0x80070005=AccessDenied
    monitor.TrackException(ex, "NetCF deploy failed; error="+ex.ErrorCode);
    // present an "unexpected error x" to the user
  } else
    // present friendly "not allowed to overwrite the file"-message

By tracking the error code along with the exception itself we have discovered that the by far most likely error is “Access Denied” and have therefore devote special attention to handling that case, instead of presenting all errors alike in an unfriendly manner like “An error occurred, errorcode=x”.

The big problem during development is that you simply don’t know what error conditions your application will be likely to encounter. But once you do know that, it’s really easy to handle those cases much more gracefully, and your users will have a better experience even in error scenarios.

Here are some usability improvements related to error handling:

  • TIP #15: Improve usability simply by discovering and fixing bugs that would normally go unnoticed.
  • TIP #16: Make your application better at offering the user assistance by logging the root cause of error conditions, and then subsequently add code to either handle that situation better or provide better information about it to the user.


In the beginning of this chapter we stated that Analytics can assist you in improving usability in many ways.

We have shown many actual examples of this from the EQATEC Profiler. Hopefully many will serve as inspiration in making your own application even easier to use.

The easiest way to get started is to simply add the Analytics component to your application and do nothing more. This alone will bring you statistics for the user’s environment. Showing how Analytics can enlighten you with indisputable, hard data about your application users can then typically be a good starting point for an engaged discussion about what exactly to track next.

Contact us: +1-888-365-2779
Copyright © 2016-2018, Progress Software Corporation and/or its subsidiaries or affiliates. All Rights Reserved.