Header Extension – Timer Revisited

As some of you may remember, we investigated a Header Extension to creating timing information about the use of the interview. This was a long time ago. It looked something like this:

Header Extension

It was an opportunity to demonstrate using the Header Extension to load code that we intended to use all through the interview. Well, lots of things have changed since that extension was created. So we thought it would be nice to revisit it and point out some of the problems, and hopefully come up with some solutions to the aforementioned issues.

Issue number one, was the fact that the thing only really worked if you navigated in a linear fashion. If you enabled the Allow Navigation in any order option, it sort of went, well, haywire. Secondly the maths to calculate the duration wasn’t very good either. And finally, there was not much granularity to the data. What about the “entry” and “exit” times of a Screen as well as the duration? What about some idea of why someone was navigating?

This kind of timing exercise is particularly interesting, because with it we are able to begin analysing usage patterns. It’s not just about knowing that a user spent 45 seconds on a specific screen; but what if I told you they spent 45 seconds but that the 45 seconds were consumed in 5 separate visits to that Screen during the Interview session? That tells me much more about my interview and the behaviour of the user!

So we took the opportunity to revisit the extension and change a few things:

  1. We can now use the On Event extensions to handle most of the timing
  2. The exception being the initial Screen that is shown at the start of the interview. In this case no event that is monitorable with the Extensions is available.
  3. The Header therefore is a suitable alternative location for code looking to trap the first Screen being displayed
  4. Entry and Exit times are captured for each Screen with multiple Entry and Exit times logged if needed.
  5. The Allow Navigation in any order option is handled – in a real browser or the Debugger. The only thing that is not handled is moving from Screen to Screen using the Debugger Tree on the left of the Debugger.
  6. The data is displayed as a nested table for each Screen.
  7. A chart is provided in the example project, powered by the data and displayed in a primitive timeline.

The new version looks like this:

The primitive timeline graph (using a very old version of D3 and a simple plugin is added in for those who want to consider how to go a little further and display some of the output. The code is fairly transportable since it can be plugged in to any project with not too much extra work.
video
play-sharp-fill

Richard Napier

Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Intelligent Advisor IT Consulting Serving Customers Worldwide
Hide picture