UX: Dashboard framework vision (issue)
View options
UX: Dashboard framework vision (issue)
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 (GitLab Dashboard Foundations Vision & Roadmap (&13801)).
See source comment.
Dashboards that exist in GitLab
Dashboards panel audit compiled by @jiaan
- Analytics dashboards - currently matches the proposed panel designs
- Kubernetes dashboards - uses basic panels.
- Runner fleet dashboards - uses basic panels.
- Value stream analytics - lacks panels, but would be easy to add.
- Contributor analytics - lacks panels, but would be easy to add.
- DevOps Adoption - overview lacks panels, but would be easy to add.
- Issue analytics - lacks panels, but would be easy to add.
- Vulnerability Report - basic panels.
- Admin usage trends - basic panels.
- Admin System information - basic panels.
Dashboards that will require more effort to migrate / support:
- Environments dashboard - uses a card like panel with buttons.
- Operations dashboard - uses a card like panel with buttons.
- Productivity analytics - needs panel-level filters.
- Repositories Analytics - uses a card like panel with buttons.
- Security dashboard - requires panel-level filters.
- Admin area dashboard - some panels use are card like with buttons.
Proposal
This issue will focus on exploring the following areas of the dashboard framework based on established conventions.
- Configuration and onboarding:
- How can we enable users to add/remove tiles, visualizations, filters, date ranges, titles...in the UI instead of via YML? (Remove the need for visualization files from an... (#497577 - closed))
-
📺 First draft thinking 2024.12.05 (recommended: watch at 1.5 speed) 💻 Prototype
-
Filtering (separate issue):
- 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?
- 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.
- Data explore updates (aka Visualization designer)
- Define where in the flow of using / setting up a dashboard does Data explorer live
- BONUS: Visual design
- How can we increase the "eye candy" sentiment on the dashboards? Right now, they are not very interactive and not visually appealing.
Progress checklist
-
Do an audit of existing GitLab dashboards
- Visual, UI patterns (Figma)
- Use cases and data related (https://gitlab.com/gitlab-com/gitlab-OKRs/-/work_items/9952+) In progress...
- Do an audit of third-party dashboards and established conventions (See internal thread)
- Create a holistic design proposal/prototype using the AI Impact dashboard and or the Value Stream Analytics dashboards as starting points example
- Solicit feedback on designs
- Refine designs
- Share out latest design thinking with UX/Product
- Conduct solution validation if needed
- Identify gaps between vision and current state dashboard framework
- Work with PM, EM and cross stage team members on workflowplanning breakdown