Table of Contents
Summary
A shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. 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.
For future frontend design and development, we are trying to decide between third party Style Guides, and whether we want to implement those third party’s complete Design Systems. This is not about re-doing our current as-is RefApp; rather, as we move our Frontend vision forward, this decision is currently blocking frontend design and development efforts for the Micro Frontend squad. The MFE Squad has reached consensus that a 3rd party Design System is the way forward, and so far this is also the resounding feedback we’re hearing from others in the community.
What we need to decide now:
...
A 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 thus far is that a 3rd party Style Guide or full Design System makes the most sense in our case.
Why Now
Vision for 3.0 FrontendOur vision of an amazing future for OpenMRS led us into working on a Micro Frontend development approach, where many implementations and volunteers could contribute to a shared, congruent-feeling, modernized, stable front-end experience. We are now underway planning a 3.0 Frontend and we would like contributions to this frontend to be consistent and share-able across contributors. The Micro Frontend squad no longer has a dedicated UX lead, so the squad has increasingly felt the pain we've experienced across the community for a while: there are not enough UX resources to guide new design in a way that makes it easy for devs to contribute quickly.
See more in Recent History of Style Guides in OpenMRS below.
...
Why use a 3rd party Style Guide or Design System?
Summary | tl;dr: The MFE Squad has reached consensus that a 3rd party Design System is the way forward, and so far this is also the resounding feedback we’re hearing from others in the community. The MFE Squad commits to reviewing some Design Guides (definitely including Bootstrap) and coming back with pros, cons, and screenshots/visual examples, and then we’ll come back together to evaluate which one to use. Then we can discuss implementation considerations. Our Goals:Users want a consistent, professional front-end UI. | A shared, clear Design System will help us have consistency among contributors w.r.t. how things should look. This is especially important given we don’t have dedicated long-term UX resources. |
We want it to be fasteasy for devs to contribute meaningful work. And, it’s much better to figure out our design framework and styling sooner rather than later!We want a consistent, professional front-end UInew volunteers to contribute meaningfully. | We want it to be easy fast for new volunteers devs to contribute meaningfullymeaningful work. OpenMRS-specificAn OpenMRS-specific style guide increases the learning curve. Of course, there is a learning curve when using a 3rd party resource as well, but the flip side is that this gives the developer experience using a much more widely-used Style Guide. Knowledge of that particlar style guide, or how to navigate mature style guides in general, may help the contributor later in their career. | |
We have limited Design Resources - and the designers that become available, we want to use very efficiently. | We don’t have the resources to build/maintain our own design system. IMO there There are not enough skills, resources and knowledge within to build, maintain an internal style guide, and its better to leverage work and investments done by others in the industry. Requiring designers to start from scratch or maintain/change our own custom Style Guide(s) constrains the ability for implementors to leverage non-OpenMRS UI designers and contractors to extends extend and implement UIs, and places extra burden on implementors to learn the OpenMRS way, while . While having our own style guide is very attractive to move fast, it becomes a weight that slows down advancement in the future. | |
Cost of maintenancerecommend staying away from any design, implementation, and approaches which are OpenMRS-specific |
Engineering Concerns
As engineers, we’re centrally concerned about the API—how usable is it, how familiar is it. We’re secondarily concerned about other technical questions, like maintainability and weight. With an independent style guide, all the technical and API questions are mooted. The only meaningful difference between 3rd party libraries to imitate becomes “how should it look.” In that case, if the designer says they like a particular look (ie Carbon), I’m happy to follow that. But if we don’t keep an independent style guide, then all of the devs’ concerns about API etc become very important, and we should choose according to the prevailing preference on those grounds, which is Bootstrap.
...