Hey Everyone
Please find the summary of notes below: Summary points
RFC links:
https://storybook.jumpsoftware.com
Etherpad Notes for the call:
https://notes.openmrs.org/Design_Forum_Styleguide_June_24_2019
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 – ( https://lhcforms.nlm.nih.gov/ ) 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
Ans:
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:
- Continue the discussion on talk
- 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.