-
Notifications
You must be signed in to change notification settings - Fork 916
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Spike] Research how to persist agg data when switching Vis Types for Vis Builder #2900
Comments
All vis types define the data they can display as schemas. Each schema definition defines the Open questions:
|
Add artifacts (design doc) and timeline @abbyhu2000 |
Aggregation Persistence in Vis Builder Design DocProblem StatementIn Vis Builder, when a user creates a visualization, all the fields value and aggregations they added will be cleared after they switch between different visualization types. After implementing global query persistence and app persistence, Vis Builder should also be able to persist values across compatible visualization types, and ideally between incompatible visualizations to a possible degree. BackgroundCurrently, all visualization types define the data they can display as schemas. Each schema definition defines the group, aggFilters , min and max number of values that the field is allowed to contain. Each field that is already selected in the previous visualization has a schema group and aggregation property set. The current five visualization types with their schemas:Here are the schema information for each visualization type with more details and an example:
Schema ExampleEach schema field is defined with 7 properties:
Visualization schema render flow:Possible Approaches1. Strict MappingOne simple solution is to simply define a mapping that maps each aggregated fields to the closest available schema for every single visualization type combination. If a field cannot be mapped to a schema, it will be dropped. A proposed mapping is shown below: metric/Y-axis → metric/Y-axis | metric/Metric | bucket/split rows | group/split group Implementation idea:A draft PR that implements the mappings among Area, Line and Histogram: #3158 Pros:
Cons:
Update schema to group similar visualization types, then strict mappings within each groupSince approach one works well among similar visualization types but it is not scalable, another solution is to update the schema for each visualization type to include a group property. Each group have their unique identifier, and only similar visualization types belong to the same group. When there is new visualization type added, we should determine and assign the new type to a specific group as developers. Within each group, the schemas of those visualization types should be fairly similar so that a direct mapping among the aggregations will return us a new visualization that makes sense. If the new visualization type is too different from any other existing types, we could also have a group where it just won’t persist any aggregations. Implementation idea:For example, we can assign Area, Line and Histogram to the same group, Metric and Table Vis to another group. We can update their schema as:
Pros:
Cons:
###X axis to X axis, Y axis to Y axis from expression Implementation IdeaThe X axis and Y axis information are stored in ‘expression’. Expression contains everything that is needed to render that specific visualization and it is obtained by calling function toExpression(). It is then being passed into component to render onto the workspace canvas. Expression is in a format of string, and here is an example expression for a visualization with one field on X-axis and one field on Y-axis. As shown below, the expression contains a lot of information for every single field. For example, order date is the field on X-axis, and it also contains other properties such as format id, param pattern, param intervalEsValue and intervalEsUnit, min and max bound, format and aggType. Since each field can have different aggregation properties, and the expression string can get really nested if we add more fields to the visualization, the attempt of mapping X-axis and Y-axis directly from the expression might be complicated.
Pros:
Cons:
###Metric data to metric data, bucket data to bucket data Implementation IdeaSince each schema field has a property group, and it will either be AggGroupNames.Metrics or AggGroupNames.Buckets . We can collect a list of aggregation that belongs to metrics group and another list of bucket group, and map them to the new visualization type’s metrics group and bucket group.
Pros:
Cons:
No MappingAnother option is to not introduce any persistence on the aggregations when switching visualization types. User experience for Vis Builder remains the same. Pros:
Cons:
Determine the best fit visualization type based on existing aggregations (Out of scope)The most ideal solution is that based on the existing aggregations selected by the users, Vis Builder automatically determines and recommends the visualization types that can best illustrate the aggregations. It shows users all the options and user can simply just choose the illustration that best fits their needs. Pros:
Cons:
ProposalsTo avoid over-engineering and introducing confusing user flow, I propose that we should keep the mapping rule simple and scalable, with the addition of giving users option to either have this aggregation persistence feature or not. UI/UX proposal:
Mapping proposal:For the mapping rules, I propose that we use approach #4 which is simply mapping all the metric group to metric group, bucket group to bucket group. Since metric field is mostly for displaying numerical data, and bucket field is mostly for separating data into groups depending on how a visualization graph can be split up, i think it makes sense to map the aggregations to the fields according to their functionalities. For the ones that previously in a metric group, the user’s intent is probably to just display those data against some type of units. So if we map them into a new metric group in another visualization type, those data will still be displayed but just in a different format. For the ones that previously in a bucket group, the user’s intent is probably to break the global data into separate groups and observe if there will be any patterns existing in each group. If we map those into a new bucket group, we are still following the user’s intent of separating global data into groups. Here are the mapping rules:
Questions & Concerns
Reference
|
This task will be broken into smaller tasks:
The text was updated successfully, but these errors were encountered: