Wiki Spaces


Get Help from Others

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


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


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.

Existing OMRS style guide  |  MFE squad style guide 

  • 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 - (Priority due to ease of use and community history)
  2. IBM's Carbon - (Priority due to documentation & UX consultant recommendation)
  3. Google's Material - (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 - (If time)
  5. Atlassian's ADG - (If time)

Next Steps

  • Visual comparison of data-heavy EMR screen (Patient Chart View) example from both Carbon and Lightning - Ciaran
  • Compare key points of using Carbon vs Lightnight with style guide vs design system approach - Brandon, Romain, Ciaran, (reach out to Brandon if interested in comparing technical pros/cons)
    • What people can do right away:
      • See and share the video tutorial Using CSS from Third Party Style Guides. This is an example of how we might easily pull from style guide into our own system via dev tools & copying CSS.  
      • Look at Lightning & Carbon component blueprints - this is where newer devs would pull from to contribute more, faster. Please have a look—these are a way of making it easy to build styled components without introducing hard-to-manage dependencies into the application.

Summary of Analysis

Overall Grade


Good responsiveness support if config guidance followed. Templates and grid system help with rapid set up.

More of a framework (e.g. with grid system); visual components need some refining for EMR context - more useful for SaaS website or online store offering. Not so much styles or components that speed things up.

Heavy - may perceptively impact loading time.

Uses global CSS.

The big difference between Bootstrap and the other three systems is that the other three are design systems with component libraries (and grid systems) while Bootstrap is just a component library (and grid system).

Clear documentation, including data visualization.

More white space - would be helpful to compare spacing on dense page btwn Carbon/Lightning.

Uses global CSS.

Bigger learning curve for devs. Google-maintained. Extensive documentation. Tries to bring designs to life with more dynamic options like animation. 

Component library has self-contained CSS.

Professional, enterprise tool oriented to professionals, by nature of being driven by Salesforce. Already has look and feel of an EMR. More data-heavy/less white space.

Proprietary font and icons - switching that out could have implications for weight of loading for users with low bandwidth

Component library has self-contained CSS.

Has the CSS-only Lightning Component Blueprints if we don't want to use the component libraries.

Noteable Strengths
  • Familiar to many devs
  • Mobile First / Responsive
  • Strong Documentation and Community Support
  • Bootstrap 5 to drop JQuery for VanillaJS
  • Plenty of documentation on implementation / usage ( )
  • Plenty of free and professional templates, WordPress themes and plugins
  • Huge community

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

  • A lot of quick start elements with a search function for any of them 
  • Well defined Icons library with various alternatives
  • Provides strong guidance about design
  • Get started kits for prototyping with sketch ,Azure and Adobe XD
  • component Libraries for UI development with Sketch,react angular and Vue
  • Extensive component library

  • Maintained by Google and therefore has extensive Documentation
  • Subtle skeuomorphism against flat design makes it easy for many users
  • Mobile First / Responsive
  • Promotes animation in designs, both for user feedback and to hint at how different features function.
  • dark theme options have been made available (maybe good for analytics)
  • Familiar UI for many users
  • Huge community
  • Component library has self-contained CSS.
  • Comprehensive UI
  • SalesForce constraints are similar to OpenMRS's:
    • Users are professionals
    • Extensive use of tables and lists (small or big)
    • Need for trends
    • Input forms
  • Simple design that looks professional.
  • No animations that could divert user's attention
  • Subtle skeuomorphism
  • Responsive
  • Component library has self-contained CSS and tree-shakes well
Noteable Weaknesses or Differences
  • Monotony across all sites using bootstrap .(All sites using Bootstrap can easily be recognized  they all look the same ). This means a lot of customization is necessary.
  • Bootstrap sites can be heavy
  • JavaScript is tied to jQuery and is one of the commonest library which thus leaves most of the plugins unused (Thanks to Bootstrap 5 )
  • Grid system is basically redundant with CSS Grid
  • Very little design guidance—just some easily reproducible "styles" that can be applied to basic components.
  • Both react-bootstrap and reactstrap rely on global CSS to be imported
  • Relatively small community
  • Relies on global CSS to be imported
  • Component libraries don't tree-shake well
  • According to Adam Butterworth carbon had the following weaknesses in January 2019 (Carbon 9 era, before Carbon 10)
    • Compiling SCSS on save takes more time than expected

    • (Minor) Cannot pass className through DataTable to element nodes.
    • It seems that spacing and layout are mostly left to the app developer
    • most elements have zeroed-out margins.
    • Carbon leverages an import-once mixin to prevent multiple imports of the same scss file which may be responsible for slow compilation time .
    • Accessibility gap in React version of dropdown (V2 is on the way, not sure if it addresses it)
    • Documentation for React Components is not ideal.
    • More can be read Here
  • Material Design is immediately identifiable and is strongly associated with Google and, specifically, Android.
  • There is  a learning curve. Beginners may find that the Material Design specification is more complicated and harder to implement than other styles like flat design.(Material Design system is so comprehensive, there are a lot more things to consider and adhere to than many new devs / designers may be comfortable with).
  • There are also some usability issues in Material Design that can make websites and apps very user-unfriendly .One of them is “mystery meat” navigation encountered on many sites and mobile apps(it puts emphasis on aesthetics versus text which gives a bad user experience)
  • Mixed reviews about tree-shaking.
Documentation not as clear for getting started.

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

according to Ayeshmantha Perera

"So carbon. I used carbon angular for another project called zowe (LF). It seems it is not stabilized yet a lot of things including docs needs to be stable. So I looked into the style guide as well but there were times I couldn't figure out things and had to mix and match components with other component frameworks.So I can say bootstrap is in the front from these two "

Missing core data table supportYes. At first glance it seems that all components at there (see table below)

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. Default style is clear and uses fairly pale colors, which matches OpenMRS 3.0 design guidelines of a UI with less disturbance for the user.

Is it framework agnostic?

(Usable without framework lock-in)

Yes, probably has libraries for all the frameworks we'll ever use.Yes, has libraries for

and for other frameworks, components can be built following this guideline

No doubt

Component Blueprints: Yes. Pure HTML/CS.

Component libraries: Sort of; only officially for React and Angular.



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)

Yes, by overriding Bootstrap CSS classes.

Carbon has an SCSS-based theming system using "tokens." It looks like it allows easy customization of colors, spacing, fonts, and miscellaneous other style properties.

These style properties are do not provide full coverage of all the CSS on all the components. Customizing things that don't have tokens will require overriding the CSS mixins, which could be tedious.

Material UI has a JS-based theming system using "variables."

It would not be practicable to override aspects of the CSS which are not encapsulated in these variables.

If using global CSS / Lightning Component Blueprints: yes, we just override the CSS.

If using the Lightning React Components: no.

Implementation considerations

  • Stability of API
  • Documentation


Already used by ___

Documentation is available from IBM carbon team

Documentation harder to use (JJ to expand?)
The UI is Free and partly open Source 
Free and Open Source
User Interviews: Community Developers

 from Ayeshmantha Perera "

I worked with both carbon by ibm and bootstrap.

I would say bootstrap is very matured.So I mainly worked with bootstrap on migrating ref app to bootstrap with openmrs.Prior that as well on some other work.Normally its a pretty norm to use in any web app u develop in these days.And I like the backward compatibility it has with the previous versions. Now there will be a new release.

So carbon.I used carbon angular for another project call zowe (LF). It seems it is not stabilized yet lot of things including docs needs to be stable. So I looked in to the styleguide as well but there were times I couldnt figure out things and had to mix and match components with other component frameworks .So I can say bootstrap is in the front from these two"

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



Great Typography defined by type tokens for two situations.

productive for products and web designs 

Expressive for web graphic usage 




Buttons in general

Confirm/ Save buttons




I can't find any card components.

Collapse/ Accordions/ Expanders





Navigation: General

Navigation: Menus


Navigation: Rails

Navigation: Tabs

Navigation: Progress bars



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



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.