A look at the user experience visualizing historical data with varying levels of granularity.

Introduction
In the world of rich internet applications a very common goal is taking not easily accessible or multi-point data and outputting reports and visualizations. One thing that rich internet applications do very well is to display data across a period of time, and allowing the user to select ranges of time. Usually the output consists of a numerical report grid and some accompanying visualization. Most if not all, reporting applications focus around this capability.

Recently I had the opportunity to work on a Search Engine Optimization application that is designed to accept analytical and keyword data, then output reports and visualizations. In addition, the application will guide the user in creating keyword segments, and in turn produce personas. These activities will ease the management of campaign by managing segments and personas rather than the possible tens of thousands of keywords. At this time, let’s focus on the first phase of the reporting business process.

The user will upload data to the application and then the application will output reports and visualizations. As we dove deeper we discovered that the analytical SEO Data could be made available to the user on daily, weekly, or monthly basis depending on the client’s business objectives or processes. Thus, the user could upload daily data or summary data for weeks or months at a time. The Keyword data would remain largely unchanged, unless completely new campaigns were created, or drastic changes were made.
The client’s business requirement for this phase is to have a flexible application to allow the user to upload any range of data, at any time.

Design Approach
Keeping in mind the client’s business requirements for flexible data importing and reporting, our design focused around a date range slider to control this reporting interaction. Sliders are intuitive to use and we have successfully implemented them in many of our solutions. We coupled the slider with a report granularity selector for daily, weekly, and monthly reporting. The image below is an example of date range slider:

At first glance, it seemed like a straightforward objective and we did not see any issues with the process nor our approach, but the following is a narrative of the events that took place during 2 days of working through this business requirement, and the use scenarios that resulted from it.

Discovery
As I began to lay all this out, I started to see that the interaction between the data available and the date range slider would be critical. At first I saw two options:
The first option, the date range slider would drive how the data was to be reported, but the data available would drive what reporting options are available to the user. The user could only select by the period the data is available.
The second option was to have all reporting options available regardless of what data is available and normalize the data when applicable. For example, if the user selected to report by day, but the only data available is by week, the application would average the values by day.
To help us through this exercise, we developed a series of user scenarios to test both approaches and weigh the pros and cons of each.

We used this data import condition for all user scenarios:
The user will import 7 daily files, then 3 weekly files for the next 21 days for the first month, and a monthly file for the next.

Visually represented the data would look like this:

User Scenario 1:
The user wishes to view daily, weekly, and monthly data.
We set up this scenario as starting point based on a fairly complex data import. The objective here was to see how the slider would behave for simple reporting requests.

The Issue(s):
How should weekly and monthly reporting options be displayed, if the user selects report by day? The user knows daily, weekly, and monthly data are available.

Our Response – Limit the Reporting Granularity:
We responded to this issue by limiting the reporting granularity selector with daily, weekly, and monthly options based on the data available. Therefore if the user selected daily data only the purple 7 data points would be available as shown in the image below. The same would apply for weekly and monthly data.

We could play around with some visual elements to either ghost the remaining selections, to show the data’s availability but will not be displayed based on the reporting granularity selected. This corresponds to possibly large amounts of data not being available based on the user’s selection. We felt this was a very limiting experience, and not a viable option.

User Scenario 2:
The user selects a period from the middle of the first of the first week to the middle of the next week. There is a mix of daily and week data.

The Issue:
How does the application visualize data with different levels of data granularity?

Our Response – Normalization:
If the user selected a reporting granularity lower than what is included in the data set, the application will average, where applicable, to normalize the data for the block of less granular data.

The image below shows the normalization for the weekly data based on the selected range for by day reporting. A simplified view is available on the right. If the user selected to report by week, the values would be normalized across the entire reporting period and look like the red block of week data.

This would allow the user to see all data in all granularities over the entire reporting period. If we display the previous slider rule as mentioned in user scenario 1 with the normalization options outlined in user scenario 2, the image below displays all the reporting options with and without normalization, which we may allow the user to toggle on and off. The image below displays the possible options.

As a result some charting would require a good amount of normalization and mislead the user in their evaluation. If we refer back to the supporting image for user scenario 1, days 4 through 7 may not be an accurate representation of that period. We felt normalization is a transformation of data, and does not lend itself to good user experience.  We did not feel comfortable proceeding with this option, and dismissed it.

Final Solution and Lesson Learnt – Trade Flexibility for Data Integrity
We found that to deliver a consistent experience, we need to limit some of the options presented to the user. So much of the UI will be driven by the data, and that any amount of data could be available, at any granularity. The primary issue is not adjusting or implementing new user interactions, we needed to address the primary issue of “garbage in/garbage out”. We saw finally that by allowing the user to import inconsistent data, we were trying to control the user experience, rather than fix the root cause.

The Final Solution
We felt that an adjustment to the data import business rule would get the user in the right direction. We concluded by only allowing the user to import data in one granularity and for one calendar period at a time. This means the user has to find one granularity and stick to that. In addition, the user’s import would have to complete a calendar period. The sweet spot is probably a weekly import, but our user interview also points to monthly uploads being common place. By implementing this rule, we would certainly address all the issues listed above but at the price of flexibility and user experience. Sure our application would not be able to bend over backwards to allow all permutations of data and thus report that back out, but it would be consistent and deliver value.

Author Acknowledgments
I would like to acknowledge Gaurishankar Krishnanan and the SEO team for the time and effort during this exercise.