bearcanrun
commented
4 years ago Specifications or "themes" as used in other systems such as System UI or Tailwind specify styles on both a global level and the more atomic "sub-component" level usually called variants. Thus, it would seem logical to have in-between level of "component" declarations. As is common with component-based architecture, the practice of keeping component styles near or within the components should be maintained. The styles that may be extracted are the common patterns discovered in use throughout the components.
This line of thought came to light in discussion of Tailwind utility classes #27. In my mind's eye, it became clear that Designspek is not a "utility-first" solution, but more interested in capturing and sharing common patterns used throughout component sets used within a given domain. At the same time, there is wisdom is starting from a generic standpoint first, avoiding premature abstraction, and coaxing/discovering those patterns.
From this point, is there a Designspek alternative to generic but rapid development that transitions through pattern discovery to a more customized state? My gut is pointing towards a specification generator that caters not just to a developer-centric experience, but inclusive of the designer/UX workflow as well.
What is the scope of the role and responsibility given to a design specification? At this stage, the specification provides visual constraints at the global level and the atomic component level. Are there use cases for specifying constraints in the middle layers from layouts to higher-order components, etc? Beyond visual constraints such as haptic or audible responses?