2014-04-14 Goals of End User Experience - Workshop

These are the results of the initial workshop on End-User Experience Monitoring. We set the goal of the workshop to get a better understanding of what we expect of End-User Monitoring in inspectIT. We wanted to identify the topics that we need to address and prioritize them. The workshop was done from 13.04.2014 to 14.04.2014. Matthias, Ivan and Stefan were present.

The document will divide in several sections that main topic groups that were discussed. In each of these sections the concrete ideas and functionality will be presented with the prioritized number. Since for each "feature" we voted with 0, 2 and 5 points, the priority number can span from 0-15.

Trace

The trace section relates on how should the different end-user monitoring metrics be grouped and organized. Here we recognized three main "containers":

  1. User interaction - As we defined it a user interaction is group of events (JS, AJAX calls, HTTP requests, resource loading, etc) that occurred after user has made an interaction as mouse click or key pressed. One user interaction contains all events that happened until the next interaction occurs. Here is important to define that we would like to have a duration of user interaction defined as the time spent from initializing the interaction until all the events have finished. Time spend from all events finished till the next interaction can be in some way called "user think time", but we did not defined if we would like to use this at all for something.
  2. Session - This is basically one user session. It contains several user interactions.
  3. Visit - Visit is a collection of several sessions performed by the same user. Here user is not defined by the session ID, but with username, e-mail details or something else. 

In addition we want to have the trace of all the things happening in the browser (for example JS1() functions calls JS2() and afterwards loads two images).

FeaturePoints
Trace Prioritization
User interactions 
Time user has to wait until all events after an interaction have been done12
Ability to logically name interaction (as click on "OK" on "Log-in" page)9
Interaction events 
  • Click on element
15
  • Selection (Combo-box, Radio)
9
  • Enter string
4
  • Other (Slider, right-click)
0
Browser Trace 
  • Have tracing of JS functions, AJAX calls, so trees of function executions in browser
12
  • JavaScript "un-optimization", problem understanding the JS optimized code
2
Correlate each HTTP request with a server invocation sequence12
Session - All interaction of user within same session should be grouped12
Visit concept2

Metrics

In this group we want to define what kind of metrics we would like to collect. We recognized two main groups:

  1. Timing metrics or events - events that influence the time spend
  2. Demographics metrics - metric that give us more information about the user and environment
FeaturePoints
Metrics
Timing / Event 
Page - Render, Load, First Impression15
JavaScript execution time15
AJAX calls15
  • Return of AJAX calls
0
HTTP Requests15
Resource loading (img, css, js)12
Third-Party content (FB, Twitter, etc)4
Network times (DNS look-up)2
Correlation between time spent on server and client12
Errors on the client time7
  • Session continue on Error information (or was the error fatal for user visit)
0
Demographic (bounded to Session)  
Browser Type4
Location4

Diagnosis

Diagnosis should serve as a possibility to explore in more detail a possible performance problem. Here we defined that we would like to have the navigation possibilities and to be able to aggregate and filter the set of information. One example here was finding a slow JS function in a user session, navigating to aggregated information about same function and then for example aggregating on the Browser Type bases, so that we can maybe check if it s slow in all browsers or only one. Or if we have slow HTTP request, check if there is difference in from which location was the request fired.

FeaturePoints
Diagnosis
Navigate from "event" in session/user interaction to aggregated data about same event4
Navigate from a single event to a session where it happened4
Filter aggregated data based on demographic metrics (ex. include only requests from Germany)4
Split aggregated data based on demographic metrics (ex. show me times worldwide) 4

Monitoring

We also discussed on basic monitoring support that we would like to have. The main discussion here was going in the direction that to support monitoring we need to store data long-term. We also discussed what would be most important to monitor and what opportunities should be given to the user.

FeaturePoints
Monitoring
User interactions monitoring6
Server vs Client time4
Errors0
Automatically store complete session if criteria is met (like error was raised, interaction took too long, etc)2

Analytics 

The commercial tools have additionally possibility to do do business related analytic with the help of the end-user monitoring. We concluded that this is not of greatest interest to us and should not have the high priority. Still we selected two topics that are nice to have:

  1. Business section - we defined this as a critical part of work user has to do on the application, like for example the check-out process. These sections are usually the same. It would consist of one or more user-interactions, but does not have to be big as the complete session, but more just one part of it.
  2. Conversion rate - Possibility to define when user is converted. Like reached the page offerProcessed.html or clicked on "Register for Newsletter". 
FeaturePoints
Analytics
Business section0
Conversion rate0

Expert knowledge

Expert knowledge is imaged as the place where we could suggest the user what should be improved and how much time could be saved. This is mainly taken from the Ajax Edition of Dynatrace.

FeaturePoints
Expert knowledge
Resource optimization (JS, CSS, combining files and images, etc)2
Resource caching2