Data is for everyone
Accessibility
Long-term, we will endeavor to support WCAG 2.1 AA, however in the interim we will focus on following the guidance published with Material. Specifically:
For screen readers, we will endeavor to organize page contents logically, avoid encoding information in images and infographics, and use appropriate markup to avoid leaking hidden text. If we must encode information visually, we will summarize the content for screen readers.
We will meet text legibility guidance for contrast and size. We will use impaired-color-vision simulators to test screens to ensure they remain usable. Despite the term “colorblind,” ICV users do not see the world in monochrome. Careful color selection can preserve the communicative power of color without excluding these users.
We will ensure our screens are usable without a pointing device. Many users simply prefer to keep both hands on the keyboard, so this effort is broadly useful. We will ensure we have a logical tab order and avoid ghost tab stops.
User Expertise
While there is a certain minimum expertise we must assume from our audience, we should not assume all our users are experts in ever facet of the system. Some users will be Kafka wizards but may not know much SQL. Others will be data experts with a hazy memory of the specifics of JSON schema definitions.
We will use plain language whenever possible. When we use jargon for precision, we will include a plain language explanation.
We will link to documentation liberally.
Internationalization & localization
While full i18m support can be very expensive, there are easy wins which can ensure our product is useful for global users. We break i18n into three goals:
Data Preservation
If a user enters data in their local language, we should capture and store it accurately. When presenting that data back to the user we should use the same glyphs. If we collect data that is stored in another language, users should be able to query it accurately.
Data Formatting
We should detect the user’s locale via their browser and present dates, times, and numbers using the default format for their region.
Translation
There is no immediate requirement to support translation.
Responsivity & mobile
As a complex, enterprise product, it’s not appropriate to constrain every screen to the capabilities of a mobile device. We classify screens into three categories:
Essential
Screens like login, profile editing, and any default landing page should be mobile-first experiences. We can add additional affordances for desktop users, but our goal should be making these screens equally delightful on mobile devices.
Content Consumption
If the user is primarily viewing content, the screen should be usable on modern mobile devices at typical 4G wireless speeds {~15Mbps). Examples include dashboards, lists of items, and fault logs.
Content Creation
If the user is expected to perform complex analytical or configuration tasks, it’s acceptable to compromise on mobile usability. Examples include database queries, schema browsers, and dashboard builders. These screens should be optimized for 1920x1080 screens, but should also render at 1366x768 and 3440x1440 without errors or interior scroll bars.