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:
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:
- We can now use the On Event extensions to handle most of the timing
- 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.
- The Header therefore is a suitable alternative location for code looking to trap the first Screen being displayed
- Entry and Exit times are captured for each Screen with multiple Entry and Exit times logged if needed.
- 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.
- The data is displayed as a nested table for each Screen.
- A chart is provided in the example project, powered by the data and displayed in a primitive timeline.
The new version looks like this: