3

There are several products for tracking the usage of your application. I know at least 10 offers. They tell you which features were used more often than others. Thus, you can identify features that may not make into new versions.

While with Google Analytics, or similar tools, this a standard tool for the web at the "page-level". I just wonder who is already using this analysis for desktop applications?

Big companies like Microsoft of course do it, but do ISVs and small vendors (perhaps < 50 employees) use such tools?

I currently don't know anybody, so I'm really curious about it: Is Usage Tracking esoteric or state of the art?

Thomas Owens
  • 79,623
  • 18
  • 192
  • 283
andreas
  • 231
  • 1
  • 5
  • Esoteric and state-of-the-art aren't necessarily mutually exclusive. The question you should be asking yourself is "what problem will this solve for me?" – Blrfl Jan 22 '12 at 15:25
  • Can you give some information about the more than 10 offers you found? I am researching tools like that and did not find that much... thanks in advance – user375251 Jul 30 '14 at 17:26

4 Answers4

3

Usage tracking is far more popular on web applications for a variety of reasons:

  1. Web applications share a common client side, mostly made out of standard technologies (HTML, CSS, Javascript). It is a lot easier to build analysis tools, when what you are analyzing is pretty much standardized and publicly available.
  2. Evolutionary prototyping is a fairly standard approach in web development, and usage tracking is especially helpful.
  3. Feature bloat hurts more on web applications. A feature that requires a 40K Javascript library hurts every user's experience, and it's fairly important to know how many of your users actually use it.

That said, usage tracking is or should be important to every application, but is not as easy to implement, or valuable, on desktop applications. An example of traditional usage tracking is Firefox's TestPilot add on.

What's a bit more interesting though, is an emerging set of technologies that are grouped under the buzzword Runtime Intelligence:

The term runtime intelligence (RI) refers to technologies, managed services and practices for the collection, integration, analysis, and presentation of application usage levels, patterns and practices. RI is a discipline within both business intelligence (BI) and software development lifecycle (SDLC) management that focuses on precision method-level monitoring within applications and macro-level monitoring across populations of applications, platforms and domains.

And the most representative example I know of is the feature level application monitoring of Dotfuscator Software Services CE:

Beyond Obfuscation

Dotfuscator CE combines its trusted obfuscation technology with injection technology to provide near real-time views into application deployment, stability, and usage. In addition to obfuscation, Dotfuscator CE offers a new category of detective control to better monitor, manage, and protect your applications. Dotfuscator CE can:

  • Provide a near real-time view into application integrity and activity at runtime.
  • Instrument applications to detect if they have been tampered with and if so, optionally send a message to the Runtime Intelligence Service.
  • Instrument applications with expiration, de-activation, and notification logic that reacts to application expiration by exiting the application and/or sending a Runtime Intelligence Services message.

In this instance, the runtime serves as the common ground, in similar manner as the common client side of web applications.

In any case, usage tracking is not a replacement of requirements specification, it's role is complementary. If it shows that you are getting it wrong more times than you are getting it right, then the problem is deeper...

yannis
  • 39,547
  • 40
  • 183
  • 216
  • This a very good answer. So I would conclude that it is still rather esoteric, because not so many see the value in it or maybe what I supect - just don't know of the good and simple products available. (there are more than Dotfuscator) – andreas Jan 22 '12 at 20:45
  • I wouldn't say esoteric, we reserve the term for stuff like [Whitespace](http://compsoc.dur.ac.uk/whitespace/). But definitely not as popular as in the web world... – yannis Jan 22 '12 at 20:47
1

It is not state of the art, since it is seldom needed:

If you have developed a certain functionality, why should you remove it, even if it is rarely used? Maybe your menus are too big, making it hard to find the often used things? But then you have several opportunities, like enabling some options only via a config file, let the user switch to an expert mode, where he can unhide some options.

Sometimes, the options might increase the complexity, so that you have to maintain many things, and with 4 options of type A, and 3 options of type B, you end in 3*4 functions to write, while 3*3 or 3*2 functions would be much less code.

But you have to be aware, that many functions might be used rarely, but can be important nonetheless. Maybe you have 100 users, which all use 90 functions. And every user uses one more function, for which he is the only user. But removing this function might render the whole program useless.

If your concern isn't so much the cost of development, or the user experience, but the size your program occupies in RAM, you might use plugins and lazy initialization to reduce it.

If big parts can be used independently of others, you could extract the rarely used parts, and provide 2 or more programs, each one smaller as the combination of both.

user unknown
  • 797
  • 7
  • 14
  • 1
    All good, but it doesn't _really answer the question_. You should point out that you think usage tracking on desktop applications is a bit esoteric first, and then explain why. – yannis Jan 22 '12 at 13:42
  • Thanks, you're right. I (think I) added an clarifying headline. – user unknown Jan 22 '12 at 13:54
  • I'm shocked by that answer, but thank you very much for your opinion which is maybe widely spread (which I wanted to know). But: There are so many products with feature bloat and that adds huge maintainance and regression testing costs. But your point is definitely right - a seldom used feature can still be usefull. You still have to use your brain instead of trusting the statistics blindly – andreas Jan 22 '12 at 14:11
  • @andreas bloat doesn't cost as much on a desktop application as it does on a web application. – yannis Jan 22 '12 at 14:18
  • 1
    "There is nothing so useless as doing efficiently that which should not be done at all." –Peter Drucker, That quote is from "Eliminate Waste" & Lean Development. How do you know you created something useless without measuring it? – andreas Jan 22 '12 at 14:28
  • @andreas Usage tracking is not about measuring if a feature is useless or not. If you actually found out that your feature is useless, your process failed long before you started building it. For example, if only 10% of your users like your new feature, that comes with a 40k javascript download for everyone, then it makes sense to eliminate it (or optimize/scale down the hell out of it). But that doesn't make it useless. – yannis Jan 22 '12 at 14:39
  • Good thing Microsoft didn't use this philosophy with the Office Assistant Clippy. – JeffO Jan 23 '12 at 00:26
1

I would add that on mobile application (not mobile web app) usage tracking is also very important because:

  • It can help to have a view on what number of instance of your software is running

  • it give you visibility on which os these app are running on. This is key to know on which OS software version you want to maintain is

  • it can help you to understand usage pattern , conversion rate, etc...

Much of these feature are only available since rencently (less than 5 years) thanks to the availability of affordable data plans and of course to the deployment of the iphone, even if it was available before

Flurry does a very good job in this area

thomas landspurg
  • 11
  • 1
1

Logging can be used to help track problems and queried as a way to analyze feature usage. You can gather samples and analyze over time, but I wouldn't go so far as collectiing all of them from every installation (Unless you don't have that many.).

If you feel there are functions no one wants to use, start working on your methodology for gathering user requirements and determine why you're wasting your time adding them in the first place. You'll never be perfect. Needs change over time in very domain.

Make sure you have an open dialogue with your users. You'll learn a lot.

I recall working at a software company where a young dev was so proud of the report he created (not part of the specs) with a worthless pie chart on it. The owner looked at it and told the young dev, "Go back to your computer and make something I can sell."

JeffO
  • 36,816
  • 2
  • 57
  • 124