Sarai-WMDE added a comment.
Thank you so much for collecting all those valid thoughts here, @AnneT Adding my two cents to each one of your points, based on our experience with WiKit, and trying to keep in mind the new context: **Designer-developer hand off** Although I'd say this is still up for validation with the UX teams, designers should ideally be able to use tokens as values for specification. This means that they should select (e.g., from a visualization in Storybook) and document (in Figma) the tokens that apply to each individual property of the component that they are designing, in preparation for handover. Designers and developers should meet to validate and, if needed, complete said specifications together. For this to be possible, an exhaustive set of predefined design decisions should be made available early on. That first batch of tokens should document all known stylistic values (e.g. available border colors, background colors, heights, border-radius, etc.), and it might be subject to change (additions, modification, deletions) as the system evolves. **Where do component-specific tokens live? + Token visualization** I'm glad you're considering a monorepo setup. I know this would be encouraged by the developers involved in the creation of our design system. As you mention, this would reduce inefficiencies and provide better access to the design tokens (whichever their format) during implemention, also allow their visualization in Storybook, which is convenient. Also adding some inline responses to your last comment: In T266688#7267420 <https://phabricator.wikimedia.org/T266688#7267420>, @AnneT wrote: > Another practical question: when does a value become a design token? This should primarily be a design decision. Tokens are used to document and propagate predefined system styles. Detecting which those styles are, naming and organizing/grouping them, should be the responsibility of the system designer(s). > This is the process I've been following: > > 1. Is it a simple keyword, like `display: flex`? If so, probably don't use a token, unless it's something that gets repeated a lot like the value of `cursor: disabled` 1. This matches our approach. We originally "over documented" styles, and ended up having to remove tokens that did not represent a design decision, but only translated a choice among default CSS values. Curiously enough, we actually got rid of cursor tokens! > 2. Is it a simple value, like `width: 100%` or `margin: 0`? If so, probably don't use a token 2. Agreed, although we did document `width: 100%` as "full-width", a token that applies to all our block-elements by default. We also work with 50% and 200% (width-double), but I can see why this might not be necessary. Maybe it might be worth agreeing on the definition of "simple value". One of its characteristics might be the fact that it doesn't belong to a scale. > 3. Is there an existing token in Wikimedia UI base whose name makes semantic sense for this component-specific use? e.g. `border-color: @border-color-base`? If so, just use the Wikimedia UI base token > 4. Is there an existing token in Wikimedia UI base but the name doesn't make semantic sense for this component-specific use, like `background-color: @color-primary--active` or `border-color: @wmui-color-base20`? If so, create a new component-specific token > 5. If none of these things are true, create a new component-specific token This all sounds about right, but I would encourage the DST to prevent the creation of said single "component tokens" as much as possible. Meaning: Wikimedia UI base (or whichever token solution is built from it, T288383 <https://phabricator.wikimedia.org/T288383>) should ideally anticipate and provide an exhaustive and organized list of the available, premade design decisions that communicate intent and can be used with as many components as possible, all in order to centralize and propagate the system's source of truth. For example, looking at`margin-right: @margin-end-typeahead-suggestion-thumb;`, I assume that this component level token had to be created because there's no record of all the predefined system spacing values. In the context of WiKit, we'd select one of the reusable alias tokens from the spacing scale (e.g. `$dimension-spacing-medium`) to define the value of our component-level token (which we'd later use as the final styling value). > There's a lot of gray area in here, though, especially step 2. I looked through some WVUI components I've built and found some examples of values for which I did not create a token: > > - `outline: 1px solid transparent` > - `content: ' '` > - `top: 50%` > - `border: @border-width-base @border-style-base transparent` > - `transition: background-color @transition-base, border-color @transition-base, border-width @transition-base;` > > Those could all be debatable. The goal would be to take the debate out of it as much as possible with clear instructions on when one should create a token. I'd say that, except for `content:' '`, all the listed properties could be defined using tokens or a combination of those, in case the creation of an alias is not justified. TASK DETAIL https://phabricator.wikimedia.org/T266688 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Sarai-WMDE Cc: egardner, Catrope, Tonina_Zhelyazkova_WMDE, Jakob_WMDE, Michael, AnneT, Pginer-WMF, raja_wmde, ItamarWMDE, Sarai-WMDE, Aklapper, Volker_E, Invadibot, caldera, maantietaja, Akuckartz, DannyS712, Nandana, Lahi, Gq86, GoranSMilovanovic, QZanden, LawExplorer, Iniquity, _jensen, rosalieper, JGirault, Scott_WUaS, Niedzielski, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list -- [email protected] To unsubscribe send an email to [email protected]
