These are considerations that we want to keep in mind as we design systems for styling components and sites. Not all considerations must be met 100%, but the weighting of relative importance will determine what we want the system to focus on.
- maintainability
- ease of creating new components
- ease of creating new sites
- ease of updating components
- ease of updating sites
- developer / designer happiness
- understanding scope of changes
- in styles / css
- in templates / handlebars
- knowing where code lives
- dev / design systems and mental models matching
- dev / design having a shared vocabulary
- atomic changes (only having to change one thing in one place to make a single qualitative change)
- no fighting hierarchy
- no fighting cascade
- no specificity wars
- understanding scope of changes
- portability
- using components across sites
- using components across clay installs
- using components across organizations
- lower priority, but must be considered so we don't design systems that prevent this
- quality assurance
- ease of testing changes
- css files live in components, not sites (or themes, or etc)
- design variations rely mostly on component variations (i.e. different data/settings in components triggering different æsthetic rules)
- different sites have different default data for components, so new components created on those sites will have different variations
- when creating new components, they will be designed for all / arbitrary sites
- Sites have style guides which contain variables (colors, fonts, font sizes, etc) (or potentially groups of rules, e.g. typographic scales)
- component css files allow variables with fallbacks, e.g.
color: $my-component-title | $primary-color | red
- colors - primary, secondary, greyscale (blue-grey!)
- typography - 6x headers, 3x paragraphs, blockquote
- inputs - buttons (primary, secondary), radio, checkbox, text, dropdown, toggle
- shared atomic ui elements (tags, alerts, notifications)
- grid system
- how well does a component-centric approach emphasize the considerations we care about?
- how well does a variable-driven approach match design's language around style guides?
- how much variation will components have between sites? (vs variation that can be taken into account by component data)
- how must our workflow change to accommodate this system?
- how will our workflow change to accommodate a more systems-based approach?