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.
Updates This Week
Thanks to all who joined the open MFE Squad Design Call on Monday, where we had a special presentation from UX Designer Ciarán Duffy. Highly recommend seeing the short presentation at the start of the video here, or simply check out the slides here.
Since Monday, I was able to get a hold of both @bistenes and Joel Denning to update them on the discussion and hear any concerns. We also saw a couple conversations in the public #microfrontends channel in slack, and we covered the topic again today in the public weekly Micro Frontends squad meeting.
Summary of Current Thinking
I’m summarizing on behalf of the Micro Frontend squad, but very much recognizing this is a wider conversation too.
- Our Goals: 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. 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.
-
Where there is debate: There is debate about the risk of future API-endpoint-breaking upgrades in third party systems.
- On the one hand: Keeping the styling working after an upgrade could require a ton of variable replacement. Upgrading a styleguide generally has to be done all at once, which is a huge pain point for a distributed project like OpenMRS. One possible approach to address the API concern is use the existing storybook styleguide like a facade: Pull in/copy-paste the components we want from the Design System we choose (e.g. Bootstrap) into our own styleguide, so we can protect the API endpoints. (With a secondary benefit being reduced bloat.) So for new (especially transient) UX designers that join us, we can still very much say “we use [3rd party design system]”, but we maintain our own light-weight guide.
- However, as @florianrappl pointed out, 3rd party systems (like Bootstrap) generally keep their recent old versions pretty well-patched, so we are unlikely to be forced onto a new version. Wrapping would also mean the effort of maintaining a fork of the 3rd party library. @florian had some ideas on how we could use the Component Library to achieve similar goals. The good news is this is not “this or that ASAP” - we could chose the wrapping/forking path later.
We don’t need to solve the “To Copy-Paste, or To Pull Directly” debate right now.
What We Need to Do Next
Pick a couple Design Systems to compare against each other. This will include how well the Design System meets a number of criteria, pros/cons, and visual examples like this one Ciaran put together:
Here’s the evaluation list we’re thinking of:
- All necessary components are already there (compare what’s available with a Base Set of Components we rely on, e.g. date pickers, form field behavior, etc)
- Default style is acceptable (Can be adjusted with minimum effort)
- Framework agnostic - usable without framework lock-in (e.g. Bootstrap is not coupled to any frameworks)
- Configurable (can style easily for RefApp or whatever org/branding you want to have)
- Implementation considerations
I’ll be asking for feedback on the component list over the next week, and we’ll be sharing our findings for further input as we go. Happy to discuss further! (@bistenes @burke @dkayiwa @florianrappl and others - I welcome your additions/corrections here as well.)
Now this makes sense.