Skip to content

Select the data time window in the Group Security Dashboard chart

Problem to solve

In the Group Security Dashboard chart, users can see the history for vulnerabilities in the chart.

The MVC has a fixed time window for that data, but it could be useful to allow different windows, so users can have a better understanding of their vulnerabilities over time.

It will not affect selection of data, but only the range of the data points shown in the charts.

Proposal

Allow users to select Day, Week, Month (or other meaningful values) for the charts. When selected, the chart will reflect the desired window.

Design:

Group Dashboard with date range selection
30** days (DEFAULT) **
30-days
The same as what we have today
60 days
60-days
This depends on how our charting library outputs this data. The line can have no dots to reduce noise and the dates at the bottom can be laid out in a linear fashion to give the user a better sense of time when looking over the data.
90 days
90-days
Similar to 60 days with more distance between the date increments. Points should also be removed to reduce noise in the chart
Details
**Hover - on 60 and 90 days views **
Hover_state
Hovering on a point should still be allowed even if we don't have points shown.
Button-toggle group
Button_group_detail
The button-toggle group is only allowed to have one selection at a time.
Loading state
When a new date range is selected, we should show a loading state when necessary.
Loading_state

Design Specs

See Sketch Measure Spec Previews here

  • Does the design solve the problem?
  • Does this need an empty state?
  • Does this need a skeleton loader?
  • Have I considered all the edge cases?
  • Have I provided the specs?
  • Have I linked to documentation (if applicable)?
  • Are error states, loading states and messages accounted for?
  • Have Sketch Measure Specs been added in description.

What does success look like, and how can we measure that?

How many clicks the timeframe switch receives.

This should be collected via Snowplow for GitLab.com users, and eventually in some other way for self-managed instances.

Edited by Andy Volpe