Open KrooshalUX opened 1 year ago
Firstly, love the idea. A few things i want to make sure we keep in mind. We already have 2 types of Visualizations that we can register here:
On the UI right now there is no way to distinguish between the two and I think thats for the good. So now the challenge becomes, how do we add more to this list while still being able to group them is a meaningful way.
One approach that i can think of is to add group
and priority
to the API. By default all Visualizations that dont have this will behave like they do today and be grouped as such, but you should be able to add any visualization type to either a predefined set of groups or no groups. And the new UI should be able to handle a variable set of visualizations.
I'm excited we're now ready to tackle this UX flow. There are a couple of different lenses to view the problem:
For question 1, current state is that users must either:
Of course, in reality, it's hard for any but the most experienced users to understand that the UI is mixing all of the above into a single interface. In addition, despite all their differences. In https://github.com/opensearch-project/oui/issues/637, the new visualization types don't necessarily even fit into the 4 categories above, because they're primarily distinguished by the data query language.
From the technical end, I have a few suggestions that I think may help us navigate the near future where we still have a heterogeneous mix of visualization creation experiences
Let's get a mock ux for this in place. Even if it's a napkin mock for clarity
Mocks are on our radar, but @anirudha , it would help to hear your thoughts and some of the needs from your team before we produce that.
Is your feature request related to a problem? Please describe.
The current UI for 'new visualization' is not scalable to account for different visualization building interfaces. Currently, it is designed to accommodate individual visualization types (bar, area, pie, etc). Until there is one unified build experience that encompasses different data sources and/or query langauges, we will need to address this when presenting users with a menu of choices within the UI (what are you trying to build and how do you want to build it (index pattern or PPL query or SQL, etc). VisBuilder is the first change to this menu, but there are more coming with deep links into Observability visualization build methods.
Describe the solution you'd like
A redesign of the New visualization modal that clearly communicates 1) build method and potentially 2) visualization output. I put emphasis on potentially because the bonus challenge here is that VisBuilder and Observability visualization methods allow the user to swap between visualization types within the experience. Ideally we would survey some users on what they might expect to see when clicking "Create visualization" - do they already have a chart type in mind? do they want to see what best represents the data they are querying? I think some of this may have been investigated as part of VisBuilder previously.
Note - as stated above, my long term desire/recommendation would be to provide users with one UI for building visualizations regardless of data source/ query language.
Additional context
I would like to hear from @anirudha @joshuarrrr @ashwin-pc specifically about requirements around this potential redesign from their perspectives