3

I need to create 2 types of charts:

  1. Represents change over time
  2. Represents difference at a specific time

For chart 1 I have a simple basic line chart which seems to work pretty well, but I'm having trouble with chart 2 (bar). Both charts have the same wrapping container, though it seems a bit out of context for chart 2.

An important requirement is:

The user should be able to switch between the two modes

Well I'm kinda stuck... these are some unanswered questions that popped into my head while trying to design this:

  1. How can I relate (switch) between the 2 modes?
  2. Are the selection boxes needed in chart 2?
  3. How can I select a specific point in time, for chart 2, in a non frustrating way (try pick a point in a touch device...)

Here are some mock-ups with notes (I hope they're clear enough)

Chart 1 - Represents change over time

enter image description here

Chart 2 - Represents difference at a specific time

enter image description here

Any help would be greatly appreciated.

1

You could give users both views at the same time without making them switch. Keep the box selector in the sparkline ("master chart") a default view that corresponds with the selected time period (tab buttons on top), and the single data point selector an ancillary one that appears on click/tap, so that user can drag it around the screen.

Additional/precise info can be shown in the tooltip that appears when the point selector is called.

enter image description here

0

Switching between two modes

  1. The most obvious solution is to have toggle buttons, a dropdown, or a View menu item the switches between the two modes. This is especially preferred if the two modes tend to be used by two different user groups, rather than each user tending to switch among modes. Preserve the mode selection between sessions and the average user only has to select the mode once in a long time. The default date for one mode can be a date from the other mode, the exact value being determined by user research. For example, you may find that users usually need to see a bar graph for the latest date from the detail line graph, so that becomes your default date for the bar chart.

  2. On the other hand, maybe users usually want to see both a detail line graph and a bar graph in a single session. If users generally want to see a bar graph for a specific spot in the detail line graph that looks interesting, then let users select that point on the detail line graph, which then pages them to the bar graph; that is, users “drill down” from the detail line graph to the bar graph. A Back button returns the user to the detail line graph.

  3. User research may show that the order of use of the two graphs is not so clear cut. If that’s the case, then rather than making users switch between modes, show both the detail line graph and bar graph at the same time in two frames above the master chart. Unless you have cases where there are many variables tracked (which would make your line graphs unreadable), the bar graph can be quite narrow, so you should be able to steal a little real estate from the detail line graph and put the bar graph beside it. As dictated by user research, the bar graph may always show the latest date (or earliest date or midpoint date) of the detail line graph, or it has its own user-specified date –maybe even going outside of the range of time depicted in the detail line graph.

  4. To save both real estate and UI complexity, considering combining the line graph and bar graph functionality into a single mode and frame. Maybe when the user enters the same date for Start and End for the detail line graph, the detail graph switches to a bar graph. Or, for visual consistency, the line graph shrinks to become a “dot graph” with a vertical stack of dots representing the values of the variables, which has the same information as a bar graph. Come to think of it, why do users need a bar graph at all? The line graphs already show the differences in the variables at a specific (every) time. Dig beneath the requirement, and you may find that what users really want is the precise absolute variable values for a precise point in time. Maybe what you really want is to numerically show the variable values for a user selected time point, perhaps super imposed over the detail line graph, or perhaps in a small table to the side, perhaps integrated with the legend.

Selection box for the bar graph

I’d guess you do need a text box for the bar graph date. I’d expect user research will tell you that users want a very precise date for the bar graph and thus need to see (and possibly adjust) the date it represents. However, I'd also show the bar graph’s date as a vertical line (with more contrast that you’re showing) on the line graph(s) to visually relate the graphs.

Select the bar graph date

I’d include the ability to select dates by clicking/touching a spot on a line graph (or dragging a vertical line, if a direct click/touch is used for something else). To allow greater precision, consider having the user select the bar graph date from the detail line graph (i.e., “drilling down” as in Option 2, or making the table/bar graph a detail of the detail line graph for Option 3 or 4).

User research will probably show that users tend to want “round” dates (e.g., first of the month, end of the week). If so, then let the click/touch “snap” to the nearest round date. If there are often cases when users don't want a round date (e.g., they want to select a peak in one varible), then snap-to can be mode to turn on and off with the menu, and/or a meta-mode (e.g., Alt-clicking has no snap-to).

With or without snap-to, for a mouse interface, you can highlight (with a vertical line) the date the mouse is hovering over so the users see what they're about to select. This shows what snap-to will snap to, so users won't make errors, and, with snap-to off, users can more easily point precisely to that peak in Variable A before selecting. In any case, let the user hold the mouse button down and drag a little to finely adjust the date (provide graphic and numeric feedback), "overriding" any snap-to.

In a touch interface, you may be able to let the user adjust the precise date by the user holding the finger on the line graph and "rocking" the finger left or right to increment the selected date up or down, providing feedback graphically and numerically. I imagine that would be pretty intuitive, but it should be tested.

Beyond that, include an editable text box for any date so users can always type in exactly what they want or select it from a calendar control. You may also want to include spinner buttons so users can make fine adjustments (e.g., incrementing by day) for whatever they select from the line graph. That should have better discoverability than "micro-drags" or "rocking" or meta-modes. A dropdown for the bar graph with common choices (like you helpfully have for the detail line graph), may also be worth the added clutter.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.