Open seanneumann opened 1 year ago
The future state section highlights the challenges faced by Dashboards in terms of usability, developer experience, and technical debt. The author identifies specific problems and proposes solutions, such as a complete end-to-end redesign, OUI compliance, and the consolidation of interfaces through an SDK. These initiatives aim to address usability issues, improve developer productivity, and reduce technical debt by adopting modern practices and technologies.
1. Introduction
Hello there, fellow contributors of the OpenSearch Dashboards community!
I've done a lot of thinking, writing, and talking about OpenSearch Dashboards with a lot of really smart people. I've been taking notes and want to share my thoughts. Let's be honest... it's time to update the look and feel and make it easier to develop and maintain. I would be genuinely thrilled to have the opportunity to collaborate with all of you on enhancing and modernizing Dashboards.
Before I delve into the details of this proposal, I want to emphasize that it is not intended to be an exhaustive roadmap of all development efforts I think are needed. I deeply appreciate the incredible contributions made by countless developers over the past decade, and my intention is to provide an honest evaluation of what I think our goals should be for the upcoming decade. Together, let's establish a strong foundation for a successful project, building upon the achievements of the past.
In this proposal, I present an opportunity to revamp OpenSearch Dashboards, or Dashboards for short. My primary objective is to create a user-centric experience that aligns with the evolving needs of the OpenSearch community. Here are three key areas that I believe need our attention:
Your individual input and contributions truly matter! As an active participant, I encourage you to engage with me and share your thoughts. If you feel that something is missing or have specific ideas you'd like to contribute, please don't hesitate to leave comments, raise issues, propose new features, or even contribute code.
2. Tenets and Goals
First and foremost, let's set the tone. What better way to do that than to agree on some tenets and goals. If you have better ones, please let me know.
2.1 Tenets
2.2 Product Goals
2.3 Platform Goals
3. Current State
Let's talk about the current state of Dashboards. Specifically, what I think are problems.
When I say Dashboards, I mean everything from the core platform (e.g. application chrome, data and saved objects APIs, etc), to native plugins (e.g. Home, Discover, Dev Tools, Stack Management, etc.) and feature plugins (e.g. Observability, AD, Maps, Alerting, etc.). Dashboards is assembled by the work in many repositories that have well over 1M+ lines of code. Dashboards suffers from systemic usability issues rooted in disjointed workflows, visual inconsistencies, and lack of getting started help. The developer experience is overly complex and has a high barrier of entry discouraging contributions. The technology under the hood is antiquated, fraught with technical debt, difficult to maintain, and requires us to constantly chase down emerging security issues.
3.1 Usability and Cohesion
Users express concerns with usability. They have highlighted the need to simplify the UX for users attempting to create a visualization, add it to a dashboard, and share it with their team. They noted broken menus, complex integrations, and unpredictability of what the UX would show.
The lack of cohesion is largely due to feature plugins being built differently than the native experiences forked from Apache 2.0 licensed Kibana 7.10. As you move between core experiences and feature plugins there are visual inconsistencies in the fonts, colors, layouts, workflows, and charts. Feature plugins are mostly siloed experiences, are not integrated into golden path user journeys, and render styles and visualizations in different ways.
Why is this? Impacting visual consistency, Dashboards offers multiple UI component frameworks and visualization rendering libraries with overlapping functionality each with their own authoring experiences and implementations. In other words, there is no standard way to develop a plugin. Impacting workstream integrations, plugins often don’t leverage existing core interfaces like
Saved Objects
to store UI-configured metadata orEmbeddables
to render their visualizations to co-exist on user dashboard pages. This is a remnant of the constraints in Open Distro where the plugins were separate products built for Kibana.3.2 Developer Experience
Developing cohesive experiences for Dashboards is challenging. The effort to bootstrap the plugin development process and get it bundled into the current version-coupled releases is far too high of a barrier. The multiple UI component frameworks, half a dozen visualization libraries, lack of an SDK with consolidated interfaces, and poor developer documentation creates high cognitive burden.
A major pain point for developers is the amount of time and work it takes to bootstrap the plugin development process. A developer must pull down the OpenSearch Dashboards codebase, gain some knowledge of it (which is not yet well documented), and build it, just to get started. This alone can be a daunting set of prerequisites. Secondly, plugins have a contract with Dashboards directly. As Dashboards evolves there is a high potential to break plugins because of the direct dependency. This means there is a lot of burden to constantly keep their plugins up to date which may not be sustainable.
3.3 Convoluted and Antiquated Technology
A lot has been learned from forking Kibana and maintaining Dashboards. The 11+ year old architecture inhibits rapid debugging and frequent enhancements. There are nearly 1.1 million lines of source code and over 8800 source files. Keeping up with security vulnerabilities and updates to nearly 2500 dependencies (over 265 direct dependencies and over 2215 indirect dependencies) is untenable. The technical debt is high, as we continue to use deprecated or abandoned packages from a decade ago.
Many of the dependencies are ancient; some were abandoned many years ago and some deprecated recently. Some cannot be upgraded without also upgrading several others and some need major rewriting to upgrade or replace. For example, the upgrade of Node.js from v10 to v14. This was a big, disruptive effort that required upgrading several other dependencies, coordinating with plugin developers, addressing a long list of breaking changes, and going through many rounds of testing. Once that effort was complete, 64 security issues were resolved immediately. There are many more dependencies that need upgrading with similar effort.
Another example is EUI (Elasticsearch User Interface), a UI component framework built by Elasticsearch. As part of iteratively improving Dashboards, EUI to be OUI (OpenSearch User Interface) was forked and refactored, closing over 200 security issues in the process. But even after all of that work, OUI is not as well supported or robust as design systems like Google Material Design System, an open source design library supported by hundreds of developers.
To render different types of visualizations, Dashboards uses six different charting libraries, some nearly a decade old. This use of many different charting technologies provides an inconsistent user experience and results in duplicative design and engineering effort. This has made it difficult to respond to community requests for new charting types.
The most urgent technical debt issue is AngularJS, the web framework Kibana was first built on. Long Term Support for AngularJS was discontinued in December of 2021. Staring in Kibana 6.0 (released in 2017), Elastic has iteratively been migrating their AngularJS code to their new React platform. As of Kibana 7.10, the last open source version, there were still large amounts of AngularJS code (144K/1.1M or 13%).
4. Future State
4.1 Look and Feel Redesign
Redesigning the Dashboards experience will require focused effort in several areas: (1) sharing a future vision of the application experience, (2) codifying design system guidance, (3) evolving the component library, and (of course) (4) heavy refactoring in core Dashboards and plugin codebases.
4.1.1 Future Vision of the Application Experience
@kgcreative just published #4298 as a companion to this document, a proposal for future vision of Dashboards. I'll let him walk through that.
4.1.2 Codify Design System Guidance
The OpenSearch Design System (OSDS) is a set of standards intended to manage design at scale using reusable components and patterns. It provides pattern guidance, branding information, and web components (via OUI) for visual consistency of fonts, colors, layouts, and interactions. It supports the OpenSearch Project themes of Ease of Adoption, Usability, Accessibility, Cohesion, i18N/Localization, and Developer Experience.
To set the project up for success, the following must be codified:
This is actively being worked on by @KrooshalUX and @kgcreative.
4.1.3 Evolve the Component Library (OUI)
The OpenSearch UI framework (OUI) is the component library is used at the OpenSearch Project to build projects that share our aesthetics. It distributes UI components and static assets for use in building web layouts. OUI should adhere to the guidance described in the design system (see 4.1.2).
Changes to OUI should start with updated styles, colors, and fonts to adhere to the design system. Once defined in design system, we can make changes to the Sass variables with updated styles for both dark and light modes. Sass (Syntactically Awesome Style Sheets) lets you assign a value to a variable and then refer to it whenever you need to use that value.
I'd like to modernize the CSS stack alongside web components and align on modern front-end practices. For example, I eventually want to move from SASS to CSS customer properties. This will let developers redefine the CSS via JavaScript, which will be useful for real time re-theming.
If there are new components that need to be made (e.g. a new data table or chat box), those will need to be built directly into OUI. Any application (including Dashboards and plugins) that want to leverage the components can consume the latest OUI via NPM.
For current documentation on OUI, please visit oui.opensearch.org
4.2 Refactor Dashboards and Plugins
I'd like to do a complete end-to-end redesign of Dashboards and Plugins. In order for this redesign to be scalable and consistent, it must leverage OUI.
4.2.1 OUI Compliance
Today, Dashboards and plugins don't always use OUI, or use it properly (as documented in the usage guidelines). There are many UI implementations that use overrides or custom styles or components. In order for theming updates to be applied correctly and consistently, a prerequisite is to remove any potentially conflicting styles and components from Dashboards and plugins. They must be made OUI Compliant. The goal is to make styling and component definition the sole responsibility of OUI. An idealized outcome would be to remove all custom inline styles, classes, and stylesheets from Dashboards and plugins.
Achieving and maintaining OUI compliance will have several work streams. You can track them and get involved via the Dashboards & Plugins OUI Compliance #4065 meta issue and the OUI Compliance project board
4.2.2 Applying the future Vision
As clarity around the future vision for Dashboards materializes, we'll need to continue iterating on OUI changes and refactoring Dashboards/Plugin pages with updated flows, layouts, etc. A “Future” Playground was setup that takes the latest main branch to show incremental and demonstrable progress. See Future at future.playground.opensearch.org.
4.3 Cohesive Plugin Experiences
4.3.1 Cohesion through Interfaces - OUI, V12i, and SDK
To bring cohesion to Dashboards we should consolidate and expose the most important interfaces through an SDK. Three areas to focus on: 1) OUI, for UI component and style consistency, 2) V12i, for a single charting visualization rendering interface backed by Vega-Lite, and 3) core interfaces, for plugin integration into golden path work streams.
Users Benefits
Developer Benefits
Consolidation of UI component and visualization rendering libraries into an SDK reduces maintenance and cognitive burden. We should introduce a configuration and template system and a style integrator so that common default preferences can be set once, instead of on every visualization. We should standardize and modularize configuration options so that UI components are consistent and saved visualizations are cross-compatible. We should clearly separate data source configurations and fetching from visualization configurations. We should define capabilities and behavior that visualizations should satisfy, so that it’s quicker and easier to build new visualization type definitions that are still fully featured.
For more information on V12i and SDK:
2819
4.3.2 SDK Docsite
As the list of interfaces required to support extensibility are identified, we should consolidate and rewrite poor developer documentation, like Saved Objects, Embeddables, Expressions, etc. This will help plugins to onboard to cohesive interfaces until an SDK is available. We should evolve the documentation for the SDK and make them available via a docsite.
4.4 Technology Modernization
4.4.1 Upgrade Node.js
Node.js 14 has ending support in April and will no longer receive security updates. An upgrade to Node with long-term support is required. As of Release 2.8, Dashboards now supports Node.js versions 14, 16, and 18. Users have the flexibility to choose from these versions to run the web application. Previous 2.x versions were distributed with Node.js version 14. OpenSearch 2.8.0 includes version 16.
4.4.2 Remove AngularJS Dependency
Dashboards has a direct dependency on AngularJS 1.8, a discontinued open source JavaScript-based web framework. Long Term Support for AngularJS was discontinued in December of 2021. This dependency must be removed. To achieve this systematic removal, refactoring, and replacing of major areas of the Dashboards codebase is required. This includes the Discover plugin (47K), Timeline (25K), opensearch_dashboards_legacy (17K), and parts of the Dashboard plugin.
1560
4216
4.4.3 Client Consolidation
Today, there are a half a dozen clients being used under the hood, including a legacy Elasticsearch client. To maintain backwards compatibility with OpenSearch, I propose moving to a single client, specifically the latest version of the OpenSearch JS client.
3900
4.4.4 Versioning: Decoupling the rigid dependency
When Dashboards is run, it compares its version with those of the configured OpenSearch instance and all plugins. If they are not within the same major.minor version, Dashboards is marked red and exceptions are thrown. This inhibits Dashboards from releasing independently and is a blocker for the OpenSearch Extensibility Technical Roadmap.
The rigid versioning dependency should be decoupled. Ultimately, the goal is for Dashboards to be backwards compatible with at least 2 major versions back of OpenSearch and for extensions to be supported by our SDK which will minimize the potential for breaking changes. Extensions should not need to be updated each time a new minor version of Dashboards is released.
3095
4.4.5 Ensure Backwards compatibility and Relax Version Checks
Today, when versions don’t match, Dashboards is marked red and/or exceptions get thrown. As backwards compatibility is better supported, I propose relaxing the version checks. Dashboards should ensure its backwards compatible with OpenSearch 1.3.x and relax those version checks.
3095
4.4.6 Define Major.Minor.Patch to be SemVer compliant
Item one of the SemVer specification is that “Software using Semantic Versioning MUST declare a public API. This API could be declared in the code itself or exist strictly in documentation. Which ever way it is done, it should be precise and comprehensive.” As Dashboards has never official declared an API, pretty much everything is considered a breaking change (e.g. Node 10 to 14 upgrade). The APIs declared will inform the interfaces prioritized for the SDK.
5. Feedback and Contributing
I welcome your thoughts in the comments below.
Additionally, you may communicate with me and the Dashboards dev community in the #dashboards Slack channel. Come say "hi!".
Thanks for reading!
6. Appendix: Dependencies to Consider Modernizing