# TRUS: Design Systems & Carbon --- [Link to Slide Version](https://hackmd.io/@5-8HeiIYRb-qH3JmIYsTtA/Skqy9EDtU#/) [toc] --- # Defining the problem - We have *visual* and *functional* inconsistencies in TRUS. - Different ways of navigating, conveying information and state, and manipulating data --- ## These inconsistencies lead to pain points: - :fire: increase friction in onboarding - :fire: complicate code/design reuse - :fire: confuse/misinform users about how to do certain actions - :fire: decrease users' certainty about the state of things _In a word_, it increases day-to-day mental overhead for Ops, and contributes to tech debt. --- ## Some visual inconsistencies - Several different tables with their own styling: - Queues - DocumentsHurdle - Worksheets - Simple styled `<table>` (`/pipeline`) - Icons changing meaning over the years - :gear: = Setting, but we use it to mean "Add Override" - "External Link" icon being used as dropdown caret - "Add Label", used to mean "Add Condition" --- ## Functional inconsistencies - Going "back" can be done by: - `<- back` - `(X)` button - `OK` button - EDITING data: - Double click to edit inline (worksheets) - Double click to edit via popup modal - Click a button to enable "Editing Mode" --- ## Functional inconsistencies (cont'd) - SAVING data: - De-select field (worksheets) - Hit `Save` - Hit `OK` - Indicating loan app state with: - status bubbles - location in tables --- # What is our ideal? Ideally, we want TRUS to adopt a singular set of UI and UX patterns that is intuitive: - to use - to develop with - to design with --- ## Enter the "design system": > A design system should be a coherent, cohesive embodiment of opinionated UI and UX. It offers a set of premade code components that share a visual design language. It also offers prescriptions on how to stitch those things together to achieve goals. --- # What is Carbon? - :heavy_check_mark: React components to aid code-reuse - :heavy_check_mark: Sketch components to aid design-reuse - :heavy_check_mark: UX Recommendations for data entry oriented tasks - :heavy_check_mark: Thorough documentation to ease onboarding and adoption - :heavy_check_mark: Just another NPM package to adopt, "plug and play" --- ## Why Carbon, specifically? - Optimized for data entry & manipulation, with really great examples and components for it - batch select tables, file uploaders, [multi-select tiles](https://www.carbondesignsystem.com/components/tile/code#top) - Backed by IBM, high confidence in LTS --- If we are looking for something with all those qualities, we can eliminate Bootstrap, Foundation, Bulma, Ant, and [a bunch more on this list](https://github.com/alexpate/awesome-design-systems). IMHO, the other strongest contender was: [Material UI](https://material-ui.com/components/cards/). Within `n` days, if we discover any hidden dealbreakers with Carbon, we can try that before gaining too much inertia. (Carbon is just the front-runner.) --- ## What can Carbon replace for us? If we fully adopt Carbon, it could theoretically replace: - Bootstrap (Carbon has general components) - Foundation (Carbon has its own grid) - FontAwesome (Carbon has its own icons) - Typography-related design concerns (Carbon endorses IBM Plex as the font) --- ## What _can't_ Carbon do for us? - It's usefulness correlates to our adherence to its recommendations - We'll need to get a good sense of Carbon's [Patterns](https://www.carbondesignsystem.com/patterns/overview). - Hopefully, over time, we'll be able to phase out the old flows and move to the new flow --- ## Risks, cons & how to mitigate them when possible - The risk of "yet another competing standard" - Increased bundle size (until we can phase others out) - Ramp-up time for devs/designers - Story point "inflation" of `1-2` points for any stories involving porting --- ## How can we mitigate those cons? - Carbon's features can be seen as a super-set of other systems/frameworks. - Many frameworks have their own grid system, common conventional components (e.g. "Card") - Carbon has all of that + dataviz, animation support, theming support, - It seems unlikely we'll need to reach for yet another framework after this for more functionality --- ## cont'd - Webpack has lots of optimization features that we already use, we can explore more optimizations like adding more entry-points, etc - As part of Webpack update epic, we'll be deleting unused code, which should (?) help offset slow recompile times and bloated bundles --- # How should we roll this out? Rules of thumb: - Brand new components should be based off Carbon 100% if possible. (DESIGNS TOO) - For global components like Navbar: port to Carbon piece-meal as part of `tech sustainability` efforts --- ## Worksheets - For worksheets-related components: I think we should ignore these for now, but later we can do some light cosmetic reskins as part of `tech sustainability efforts`. --- ## General components Let's be pragmatic to minimize upfront cost: - For very small components: port to Carbon on next update of any kind - For medium components: port to Carbon on next significant functional update - For large components: only port if/when necessary or if we decide to rewrite --- ## Socializing the changes - Make a point to let ops know about UI/UX changes in advance - A frank & honest ask for ops' patience during any initial turbulence, we will probably miss some things --- ## How can we ease developer adoption friction? Some ideas: - Give everyone at least a dedicated hour to read/vet Carbon for themselves - I'll create a long-running Google Form for anonymous questions & feedback regarding Carbon (to be answered on Slack or All-Hands) - I'll talk about the most useful concepts/patterns at All-Hands to help ease everyone into it - `_compatibility.scss` to alias new mixins to the old names --- ## What are some next steps? - I've created a `install-carbon` branch and PR [here](https://github.com/homelight/eave-web/pull/850/files) in `eave-web` for any interested parties to try out and review - I'd like to start with a ~3 point story for some global config and clean-up - [Click here for the Carbon React Storybook](https://react.carbondesignsystem.com/?path=/story/accordion--default)