Wiki Spaces

Documentation
Projects
Resources

Get Help from Others

Q&A: Ask OpenMRS
Discussion: OpenMRS Talk
Real-Time: IRC Chat | Slack

Documentation

Page tree
Skip to end of metadata
Go to start of metadata

Purpose

Purpose of This Page: Compare a number of Design Systems and see how well they meet a number of criteria.

Why We're Doing ThisA shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. We don't want to spend precious technical time deciding details of how widgets should look and behave - we want to focus on the clinical use/workflows for those concepts, and allow another community to worry about the rest of the details. This is especially important given we don’t have dedicated long-term UX resources. We want it to be fast for devs to contribute meaningful work. And, it’s much better to figure out our design framework and styling sooner rather than later. We don’t have the resources to build/maintain our own design system. Group consensus is a 3rd party Design System makes the most sense in our case. More OMRS context here; and an Overview of Design Systems here.

  • Goal: High-level recommendation for UX contractor by when they start on August 18, to then hear their feedback.

Style Guides vs Design Systems

Style Guide: The visual guide to how things should look and behave. The world we ground our design decisions in.

Design System: The Style Guide linked to code you'll use in your actual code base - the how.

Design Systems for Analysis

  1. Twitter's Bootstrap - https://getbootstrap.com/ (Priority due to ease of use and community history)
  2. IBM's Carbon - https://www.carbondesignsystem.com/ (Priority due to documentation & UX consultant recommendation)
  3. Google's Material - https://material.io/design (Priority due to prevalence of Material UI in the daily lives of our users, and because already being used by OCL for OpenMRS)
  4. Salesforce's Lightning Design System - https://www.lightningdesignsystem.com/ (If time)
  5. Atlassian's ADG - https://atlassian.design/ (If time)

Summary of Analysis

CriteriaBootstrapCarbonMaterialLightningADG
Overall Grade




Noteable StrengthsFamiliar to many devs

Very strong/clear web documentation on how things should be done


Familiar UI for many users

Comprehensive UI.

SalesForce software is quite similar to an EMR. Target users are professionals, use data tables, need data input/forms and display trends etc... So we can feel safe  that all tools are there.


Noteable Weaknesses or Differences





Are all necessary components already there?

(relative to Base Set of Components)

Missing core data table support (may be options via plugins)

No header

No card view

Missing core data table supportYes.

Is the default style acceptable?

(Can be adjusted with minimum effort; friendly for end users/used to what end-users see in their daily lives; responsiveness)



Mobile-first. Doesn't perform well on desktops. 

Is it framework agnostic?

(Usable without framework lock-in)

A

Not coupled to any frameworks





Is it easily configurable?

(Can style easily for RefApp or whatever org/branding you want to have; how it can be customized; how it works (out of the box vs. possibilities, e.g., could we have CSS variables that would allow runtime configuration)






Implementation considerations

  • Stability of API
  • Documentation

A

Already used by ___



Documentation harder to use
Cost




User Interviews: Community Developers




User Interviews: Implementation Leads




User Interviews: End Users




Base Set of Components

Compare systems' available components with a list of components we rely on.

CriteriaOMRS Style GuideESM Style GuideBootstrapCarbonMaterialLightningADG

Headers/ Text





Search



Font



Icons



Badges

 



Buttons in general



Confirm/ Save buttons







Links




Breadcrumb



Cards

I can't find any card components.


Collapse/ Accordions/ Expanders



Modal



Toasts




Alerts



Popover/Help




Navigation: General




Navigation: Menus






Navigation:Drawers





Navigation: Rails





Navigation: Tabs






Navigation: Progress bars




Pagination





Loading/spinners




Form: String Field




Form: Field Units






Form: Text Field (Longer)




Form: Validation




Form: Helper Text




Form: Date Picker





Form: Radio Button




Form: Dropdown




Form: Checkbox




Form: Toggle Buttons




Form: Sliders




Graphs or Charts





Tables





Deeper Analysis Notes

Twitter's Bootstrap


Google's Material



IBM's Carbon


Salesforce's Lightning Design System


Atlassian's ADG















  • No labels

1 Comment

  1. I'm in favor of adopting a design system where developers can focus their efforts on weaving components together for needed application functionality instead of building or maintaining the widgets themselves. OpenMRS needs to run well on all major browsers & platforms and building/styling/maintaining UI elements that do this well is a lot of work, so the number of UI components we manage should be limited to a small set of special cases where it's absolutely necessary. To this end, I'd favor any approach that allows other communities (not OpenMRS) to worry about rendering details & supporting/maintaining robust browser/platform compatibility and let our devs focus on applying those elements to improving healthcare worldwide.