Skip to content

UX: Dashboard framework vision

Problem

Up to this point, we've been designing ad-hoc tiles for specialized purposes. Taken together as a collection, they don't really follow the logic or rules of a generic dashboarding framework, which is one of our long-term goals (Cross-stage Dashboards Vision & Roadmap to foun... (&13801)).

See source comment.

Dashboards that exist in GitLab

Dashboards panel audit compiled by @jiaan

Dashboards that will require more effort to migrate / support:

Proposal

This issue will focus on exploring the following areas of the dashboard framework based on established conventions.

  1. Configuration and onboarding:
  2. Filtering:
    • Should a dashboard be controlled by a single date range filter or should each tile get its own filters and date range selection?
    • What controls should we surface for aggregation ranges (e.g. hour, day, week, month, quarter, ...) and should these be on a per-tile or dashboard-wide level?
    • Filtering by event meta-data (project, group, attributes, ...)
    • How we expect the in-panel filters to look across different visualization types?
    • Do we want to have default date range options working across all dashboards? Or would we want to be able to have different options for different dashboards?
  3. Drill down/up interactions:
    • What are some standard interaction models dashboards should support for things like drilling down into a subset of data/items? Customers are frequently left asking questions about what events/objects contributed to a specific metric on a dashboard.
  4. Visual design
    • How can we increase the "eye candy" sentiment on the dashboards? Right now, they are not very interactive and not visually appealing.
  5. BONUS: Data explore updates (aka Visualization designer)
    • Define where in the flow of using / setting up a dashboard does Data explorer live

Progress checklist

Design source

❖ Figma project →

Resources

Edited by Libor Vanc