The MindProber Reporting tool has multiple visualization options regarding the data collected during the study. The most problematic section in terms of performance was the Timeline Analysis, and that’s what we will cover on this post, what were the problems and how we manage to solve them.

Performance is crucial in order to create a great experience for the user and there’s no such thing as a single recipe to follow in order to achieve this. There are best practices to follow and the performance will essentially depend on the experience we want to deliver to our users. So, the first thing to do was defining a goal, the experience we want to deliver to our clients and then work around it in order to optimize the product. In our case, we want our clients to get a fluid interaction with the graphics (when doing things like zooming and panning, which are typical behavior of time-series exploration) when switching between the different graphics as well as when changing the segmentation variables, which determine which data is overlayed.

When we started to test extensive content (more than 1 hour of video, with second-wise resolution spread across multiple metrics) – it was panic all around! The reporting tool was too slow, it was almost impossible to switch between graphics (not impossible, but it would take a lot of time to process everything), the zoom was not fluid at all…nothing corresponded to our intended user experience goal. Someone suggested that maybe we should not show the 3 graphics and the video at the same time, but that was out of the question, because the layout of this section should be maintained since it was fundamental to do a complete analysis of the content. So, we started digging into our platform to find the source of this poor performance.

The problem: there were too many elements.
What we mean by “many elements” and how many is too many?
Imagine a content of an hour, with second to second granularity. We will have 60min * 60sec = 3600 seconds. That means that in each graphic we will have data for 3600 points.
In the Biometrics graphic that did not represent a big problem since there was only one element to create, a single line. But that wasn’t true for the declarative data, since the Likes & Dislikes graphic, as well as the Affective Space, made use of multiple elements per second. So, doing a simple math we quickly realized that we simply had to many elements to interact with and switch between, which wouldn’t happen if the graphics were static.Metrics-data-collection-dashboard

In order to solve these, we have adopted the following measures:

1. Removal of some animations that were slow down the rendering of the elements, such as transitions;

2.  In the declarative responses, particularly in the Likes & Dislikes graphic, instead of rendering individual bars we created areas (3600 elements were converted in one single one), giving the illusion of the bar plot we wanted our clients to see;

3.  In the Affective Footprint, instead of creating the circles with D3.js (individual elements created for each of the concentric circle on top of which the points are rendered) we created them with canvas (one single element to manage all the circles);

4.  Only create elements that are visible.

By adopting these measures, we are able to improve our performance for larger content, and at this point, the reporting tool is really fluid (ask for a demo account and test for yourself!). We are always looking for new solutions to improve our performance and as we go adding new features, we need to be cautious with how they impact it – and always learning from the past.