[Discussion] Should the query designer be generic or bespoke per use case?
Problem to solve
As we open up the dashboards listing to the wider analytics space, we need to consider how the query designer will be used, and the flow users should take to adding new dashboards to their listing.
Existing process
Within ~"Category:Product Analytics" the current process (before we started sharing) would have been that an Add dashboard
button would be shown on the listing. The button would take the user to a new blank dashboard in which the user can begin adding panels via the query designer interface. Upon filling out the dashboard, the user would then commit the dashboard to the product_analytics/dashboards
directory in their repo.
Concepts
Multiple query designers
This approach would take a common query designer interface but the panels available would be restricted to the "type" of dashboard being built. This would entail having multiple different "types" of query designer that target a specific category of data (product analytics, developer analytics, ops analytics etc).
Benefits:
- Allow more targeted UI for each "type".
- Engineers don't need to work within the contraints of existing "types".
- Reduce possible user confusion around the UI when creating and using dashboards.
Side-effects:
- Could lead to very different experiences on each "type" of query designer.
- Increases the complexity of maintainance of each "type".
- Restricts the potential power of custom dashboards combining with different categories of data.
One generic query designer
This approach provides a singular location to build dashboards from irrespective of the category of data. The YAML definitions being generated already allow this to happen.
Benefits:
- Gives full freedom for users to create dashboards combining with different categories of data.
- Gives a clear singular location for all query designing needs.
- Restricts engineers to a specific way of working within the UI.
Side-effects:
- Increased UI complexity as not all categories of data would work with every type of visualization.
- Increased possible user confusion when targeting specific user personas.
Proposed outcomes of discussion
- Decide on a multi or generic query designer model.
- If a multi query designer model, determine what changes about the existing process to allow specific query designers to be picked in the shared analytics listing environment.