A design answer: What do you do with inaccurate data?

time to read 3 min | 416 words

I got a lot of replies for my question about this issue. I intentionally didn’t specify what the problem was, because I wanted to get your input about the basic concept.

The problem is related to NH Prof filtering, in particular, filtering is done on the front end of NH Prof, which present some unique problems in one particular area, marked in red in the image:


The issue is that statistical data that is calculated on the backend in a very efficient manner is now potentially invalid.

Now, we could just remove all the data, but that would really be annoying and a hindrance for using filters. What we did was to show this warning for every session where the statistics were calculated on the backend without filtering.

The problem is that this open up some really nasty UI bugs (for example, the Session #1 has two statements associated with it, but it isn’t shown here) and even nastier UX issues:


This thing just make me go Yuck! This is a good application of the law of unintended consequences, this feature was actually created before I posted the question, but it follow the same logic that most of the people suggested.

Instead of going with this route, I decided that I would rather take the hit in performance (and optimize for that) so the next step was to remove this feature, bringing us back to this:


This shows information that may be inaccurate, but it is far more relevant. The next step was a bit more complex, but it basically involved making the backend aware of the filtering just for session stats, and then making the front end always go to the backend to ask for details about session stats.

Once that was done, presto, it works!

There is some implication for performance, but I don’t believe that we are likely to ever have a problem from that end, it is all basically in memory filtering more than anything else, and all communication are method calls not remote calls.