Design Forum 2019-06-24: Micro Frontends Squad : RFC Discussions

Hey Everyone

Our next scheduled Design forum call will be led by the Micro Frontends team who will be discussing key issues around their RFC (Request for Comments) process relating to the following topics:

This discussion will take place on

Audio, Chat, & Screen Sharing (latest Chrome, Firefox, Safari, or other WebRTC-compatible browser)

Audio Only (Telephone or your favorite VoIP client)

Hey Everyone !

A gentle reminder of Todays Design Call.

Thank you to all who participated on the call!

@dkayiwa May you please share the recording of the call so that I could summarize? I had some connection trouble during the call.



Hey Everyone

Please find the summary of notes below: Summary points

RFC links:

Etherpad Notes for the call:

The purpose of the call was to discuss the RFC proposals put forward as indicated above.

Main Discussion Points:

  • Introductions to Styleguides and CSS were presented. A styleguide is CSS and/or Javascript code. It is reusable and helps organisations maintain a consistent look and feel throughout their application. CSS has improved significantly, with tools like Flexbox making it easier for dev’s to structure layouts faster and more effectively.
  • The envisaged styleguide must be lightweight (i.e., must be easy to adopt and not get in the way), leveraging on libraries like Bootstrap etc.
  • We need to define/understand what elements we need to standardize – they will be at a couple of levels of granularity. But once defined, a service (like Clem’s FHIR forms – ( ) to convert desired style to working code is ideal.
  • minimal core style guide, it should be paired with an extended style guide that the “central” micro frontend effort uses; in addition allow others to white label, styles/branding, bring their own to override or extend existing.
  • The above points do raise some inconsistency however: if you want a minimal style guide and don’t want devs to do css, what will they use?

4 questions were put forward :

1. How much CSS should OpenMRS developers write when building a feature?

None, very little, some, a lot, all


Just enough/Very little : Should work with default without doing a lot of work. but extensible/override

Devs should only be writing the CSS they need to write – i.e., just what’s needed to add their new widget or refine the UI to meet their implementation needs. And, generally, devs should not be writing CSS that impacts other modules/apps.

OpenMRS community may not also have enough dev’s who are conversant with writing css.

We could try and attempt to build new style guide and explore the level of effort. We don’t loose anything by making an attempt.

2. How much design consistency should we strive for in our UIs?

Same “atomic elements,” same “molecules,” same “organisms”?

Ans: Significant effort should be put effort into having a baseline of common atoms and a small handful of molecules.

We’ve made a preliminary set of functional components in an EHR’s / OpenMRS’s future, and from a UI perspective they can almost all be brought together into about 7 or 8 “molecules” tops. At least at the human-readable visual-example level, it will be useful to lay out some principles for those – that’s less of a heavy lift – and ideally to have a good standard example. Then could do deeper CSS/code build on the few of those that are most important.

3. What is the role of UX Designers within OpenMRS? How many design resources do we have available to us?

Ans. Varied over time, but we haven’t had the luxury of having UX designers dedicated to community needs with any consistency. We could certainly benefit from having a team of UX designers contributing to the community.This underscore the importance of having good UX design thought put into the style guide, since having well thought-out examples can be priceless (i.e., best practices get copied by many devs-in-a-hurry).

4. How hard is it to maintain an OpenMRS-specific style guide. What is cost/benefit?

Ans.: It depends on the scope of the style guide. We will not be able to design everything that everybody needs through a single process.

However if we design the fundamental pieces in a manner that is both extensible and re-createable – e.g., it’s clear to an implementation how they add their custom extension(s) locally AND it’s clear to an implementation how they can contribute an extension to the community style guide – then we have a greater chance for success.

Action Items:

  1. Continue the discussion on talk
  2. Convene a meeting with the full MFC squad including product owners to get more perspective and feedback . The discussions would be dialugue on progress so far, what new questions need to be answered, where can we start having decision points etc.