vikansal
commented
1 year ago Project settings seem like a static system defined settings to be done at deployment. But when the Dashboards needs to operate as a service and/or support per user customization, the operator would need support of permissions to be used at runtime to show or block the tools. For example, a role 'analyst' should not see dev tools, or role 'compliance-auditor' shouldnt see 'dashboards/visualization/query'. It would help to support Project Settings as features that can have authorization and enablement controls at runtime.
kgcreative
xluo-aws
HungryHowies
davidlago
Background
The primary objective of this RFC is to solicit feedback for the ongoing initiatives to modernize the look and feel of OpenSearch Dashboards, and to set the stage for some of the technology modernization (#4306) efforts. Please consider this and all sections below to be work-in-progress, living documents, and early concept designs. Input received will help with prioritization of work streams, and make sure the right things are being built that will deliver value both short-and long-term.
Goals
I anchored this proposal on some high level goals and principles. As long as we have alignment on these, they should guide us in making “directionally correct” decisions, and help us make incremental progress. These goals have been anchored from discussions with OpenSearch partners, and users* (through the forum, github, community meetings, and via UX research sessions). In no particular order, these are:
1. Feedback - Improve our ability to proactively identify the needs of our users, and innovate on their behalf and with the community. 2. Organization & collaboration - Make it easier for users to share, collaborate, and organize their work. 3. Usability - Allow users to gain insights rapidly and accurately, with minimal information overload. (The right information, with the right fidelity, at the right time) 4. Extensibility - Make it easier to contribute to the project by building platform tools to facilitate extending functionality and enriching the user experience. 5. Intuitive - Make it easier to reason about your systems, and understand how things are organized 6. Differentiation - Differentiate OpenSearch from other tools and establish a clear brand identity 7. Customization - Make it easier for users, partners and builders to customize & re-brand the application
Focus Areas:
Modernized look and feel - Since the fork, incremental updates have been delivered to the OpenSearch Dashboards features, plugins, and functionality. However, there are opportunities to modernize. We’ve started exploring what a modernized look and feel could look like, trying to balance what’s achievable with our current stack, vs what would require breaking changes. This initial pass is a future vision free of the constraints of the current architecture, with the goal of gathering early feedback on the north star.
Stronger branding / Colors / Fonts - As we think about modernizing, we also want to start aligning the product’s look and feel to OpenSearch’s brand identity. To that end, we are proposing introducing a unique title font, and a refreshed body font. These changes accomplish three things: 1: They align around well-designed open source fonts that are broadly compatible across Mac, Windows and Linux systems (goal 4), 2: they help us stand out from the pack when it comes to bringing life to what otherwise are generic dashboarding and visualization applications (goal 6), and 3: they help guide our users to the information that’s relevant. We want to use type, contrast and hierarchy in order to surface the most important information, and help visually organize and guide our users through their pages and workflows (goal 3)
Additionally, we have listened to our users, and are changing our default theme to dark mode by default, while also introducing system-settings based controls as an additional option (so if your system automatically changes from dark to night in the evening, Dashboards will honor the system settings as well.
Finally, we want to make sure we continue to invest in mobile friendly, responsive layouts which work well enough while on the go. While we optimize for large displays, we know we have a growing user base who exists in a multi-device world, and will need to use Dashboards while on the go. This means additional investments in our UI libraries to ensure builders have access to accessible, responsive and well-built components to build from. In the fullness of time, this will also enable us to add additional customization such as density settings (comfortable and compact mode), language selectors for i18n, custom branding, etc.
Focus & Organization - A new navigation paradigm keeps users focused on the page they are in, vs being inundated with seeing the entire application structure at all times. We’re also proposing removing the top navigation bar in favor of a persistent left navigation, with a sticky-page header where appropriate. This keeps the context of the page in focus vs the context of the application in focus, while not taking up additional critical vertical space. This also returns space back to the application pages & individual pages, while getting out of the way of the user. Placing the contextual controls in that page header allows users to keep context as they scroll through the page. Additionally it provides quick access to these controls to make further manipulations (search/query/filter/other actions). This also reduces visual noise from controls that have low-frequency use & are more suited for menus. Over all, this allows our users to focus on tasks and workflows, rather than get distracted by way finding.
Contextual interactions - The current version of Dashboards uses a pattern to explore a deeper level of detail which appears in a Flyout. We think this pattern is underutilized today, so we want to use it more mindfully to both facilitate contextual exploration, as well as contextual help. There are opportunities to use flyouts to integrate controls on tables, visualizations, object lists, etc, and to drill down to get additional information about data and dashboard objects. This is less of a new proposal, and more around making sure we are investing in the patterns that have proven to work well today.
Persistent tools - Another insight that surfaced from user research sessions, is how often the dev tools console is used as part of our users’ workflows. Many times, we see mixed usage between UI actions and API interactions, often resulting in users switching windows and tabs in order to complete their flows. To that end, we are introducing both a help flyout for contextual help, as well as a dev-tools drawer that’s persistent across the application. Users can still open the full-screen tools if they would like to, but this allows for in-context interactions without switching to a new tab or a different window.
Organizing your work - To help you better organize your work, we are introducing Workspaces [Working name. I would love feedback from the community regarding what to call this]. A workspace is a container (and abstraction) for saved objects and tools. In that sense, you can think of the relationship between a dashboards saved object and a workspace, to be similar to a user vs a user group. It’s a way to organize your library objects, and help you collaborate with others in an easier way, control which tools are visible so you aren’t distracted by noise, and define which advanced apply to your workspace. We’re still defining a lot of our requirements for this work stream, so keep an eye on this space for more details.
Customization - Customization comes in many forms. From helping builders easily theme and customize their applications, to helping admins customize defaults and infrastructure settings, to helping workspace owners customize their workspaces, to helping end-users customize what’s relevant or important to the. Overall, our goal is to enable as much customization as possible, while investing in guard rails for builders & users.
System settings: We want to enable dashboards admins to configure system defaults, and dashboard level defaults. This means an audit of “Advanced settings” to determine which of those settings should be controlled at an application level, which of those controls could be moved to workspace settings, and which of those belong in user settings. For example, Theme and Dark-mode selection should allow for an admin to set an application default, and for a user to override it just for themselves. Today, if you change a theme, it changes the interface for all users.
Workspace settings: We want to give workspace owners flexibility in which tools show up on their workspaces, as well as which settings make sense for that workspace. For example, they may want all dates and timezones converted to a specific format while in that workspace. Or they may want a different visualization palette to be default.
User settings: we want to enable users to set favorites, be able to change their themes, and to override some display settings, if their admins have determined that they can do so (For example, an end user might want to change the default language, their density settings for tables or visualizations, or the theme for the application because they may have unique accessibility needs.). Additionally, we want users to be able to customize some quick actions (maybe they don’t find alerts or favorites useful, or maybe they’ve installed a new extension that provides a new widget)
Next steps - We are early in our thinking on many of these areas. From here, I and others will open additional discussion issues (@seanneumann just posted #4306 regarding technical modernization efforts) on these focus areas so we can have more detailed and focused conversations on these topics, so this issue will serve as a launch point for other UI/UX discussions and threads. We have a long way to go, still!
Finally, we would appreciate it if you could sign-up via this interest survey to participate in testing changes as we iterate through explorations of Dashboards!