-
Notifications
You must be signed in to change notification settings - Fork 19
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
[FEATURE] Visualization Catalog #33
Comments
Some open questions:
|
@Swiddis u'r proposition make perfect sense, and they correlate to the idea behind the composition of the fields into dedicated functions: Each file may have a corresponding visual representation in a form of a dashboard / visualization / views Currently each mapping fields set (component mapping) has a dictionary file which describes the fields and their relationships if such exist: Using this perspective, the visualization folder is organized in the same (similar) way the schema folder is arranged to reflect this correspondence. After this folder is created and each component is associated with its visual elements, it will be possible to construct the integration in the following steps:
This will remove many obstacles for non UX experts and allow fast and efficient creation of integrations for any type of resources. In the case the schema is incomplete - the process is much harder since the integration needs to actually define and create a new schema component which must be validated and consolidated with the following:
|
I agree with applying this when the visualization is restricted to one component, but I'm not sure it's so simple when the visualization references multiple components. A visualization correlating |
Is your feature request related to a problem?
As we develop more integrations using standard SS4O, we will likely encounter a lot of overlap between visualization functionality. In particular, visualizations that may be commonly applicable in multiple contexts. Most integrations involving an
http
component might get value out of a "Status codes over time" visualization. An example of this is already present in the Nginx integration, which is being reduplicated for the upcoming Apache integration. If we don't have visualizations shared in one place, it can lead to a lot of reduplication of effort as functionality is reinvented.What solution would you like?
The solution to this problem is to collect visualizations in one central location, which I'll call the "Visualization Catalog". This will organize visualizations within one location, so that integration developers can directly find tools that are useful for their own data, and have a better way to share their tools with others. The main problem with this is organization, and making it discoverable by developers. The catalog itself can just live as a directory on this repository, I don't think it needs to be implemented as a full API, as long as we provide an index and instructions for searching it.
For organizing these visualizations, the most important feature to know is what fields they need access to in order to run. In #31 (implemented via #32), we introduce a tool that is able to look at actual sample data records and use that to determine which fields are required. With some extra work, this tool might be extended to visualizations, to determine what components the visualization requires as well, and to connect the data and visualizations at one common schema in the middle. Adding some level of search functionality to the tool can be very helpful in giving useful results.
A basic implementation plan:
These steps are not intended to all be done at once, I think just the first 3 steps will be enough to get started. But if we find more demand and the project is becoming unwieldy, then steps 4-6 can be natural extensions.
What alternatives have you considered?
Do you have any additional context?
The text was updated successfully, but these errors were encountered: