Users of the web live with a spectrum of abilities. We need to be abundantly cautious to not create barriers to information access such as in these cases:
- Truncating essential information that either requires more interactions to view, or leaves the user stranded.
- Using colour alone to convey information that is not interpretable by colour blind individuals.
- Providing feedback after an interaction is made, but not focusing on that feedback; which is invisible to users with a screen reader or screen magnifier.
- Providing keyboard shortcuts for elements that have built-in standard shortcuts without informing the user, potentially breaking their workflow or breaking their assistive technology.
More information, data, guides, and resources: Accessibility.
We cannot predict our customers' network reliability, and there are many provable cases when a hospital network regularly or occasionally degrades. This can cause certain pages to take much longer to load, making some rare yet possible workflows to be frustratingly slow or impossible to fulfill within a reasonable time.
Components, especially interactive ones, should be minimally functional and rely on the server for state and information. In this way, users can navigate with confidence knowing their interactions will be received even when their connection degrades.
To best achieve this, focus on building solutions that allow essential information or interaction to be reachable without requiring browser-side JS. Some suggestions include:
- Standard HTML elements.
- CSS features to show or hide contents conditionally, such as with :has().
- Container queries to best arrange contents that adjust automatically to container size, viewport size, or content size.
- Use with buttons and fields, and for all interactions and navigation since they can be handled by both the server and browser for progressively enhanced experiences.
- Provide feedback for all interactions when JavaScript is available on the page.
Inspired by https://gridless.design/, avoid designing layouts based on a fixed number of columns. Instead, focus on:
- Container queries and responsive design.
- Let content dictate layout.
- Continue to use flexbox, grid, or related styles when composing pages or views.
Inspired by https://bradfrost.com/blog/post/atomic-web-design/, make some effort to ensure components are reusable without increasing complexity. Be inquisitive when a component features many configurable parts and find ways to break them apart into more components.
Some decisions may lead to one of 4 outcomes:
- Composables, which are components that are incomplete on their own, yet accept a variety of insertable components or elements. Example: Disclosure Widget.
- Components, reusable parts of a user experience that manage complex internal state for user interactions, and provide a declarative API.
- Elements, CSS classes or styles for built-in elements such as
<h1>that do not require JavaScript or enhanced capabilities. - Utilities, CSS classes or JS functions that help with reusable features related to layout, disclosure, size, interaction, and other primitive elements of design.
Note
Be careful with DRY (Don’t Repeat Yourself) as it can greatly increase the cost to build and maintain parts of a design system. The more abstracted parts become, the more impact they have on end to end tests and reusability, which may increase the maintenance costs.
Try to find a reasonable middle ground when applying concepts such as the UNIX Philosophy within strict layers of which there are a few: controller, view, interaction, user agent, server-rendering, pre-hydration, post-hydration. Sometimes a component with proprietary logic is more maintainable than 2 components with shared utilities.
When planning, consider which of the above 4 outcomes may most appropriately suit your needs.