#designToken operations are not hear yet, but feel like an integral part of design tokens, without which they will not be sustainable in the long run. @donnie has a neat writeup: https://buff.ly/3BsZ5nd

Personally, I gravitate to the simpler solution suggested in the w3c repo: https://buff.ly/4dmoOeg as it makes it easier for tools to adopt quickly and covers most cases.

#DesignSystem #tip: Split your system into sub-packages you expose. Legacy projects are more likely able to use #designTokens or #css #component classes, than react components.

Reaching more projects is more important than 100% perfection.

Totally agree with this idea from @Disco_lu post: https://read.cv/disco_lu/rethinking-atomic-design

> I think we can simplify [atomic design] by flattening atoms, molecules, organisms into a single “component”. 

Works well in practice: #components are built by #designSystem team and used by product teams.

Patterns are similar in size to organisms but are documented use case recommendations only, not reusable components.

Having a hard time deciding which #chart type to use?
This post helps you choosing the right one: https://www.atlassian.com/data/charts/how-to-choose-data-visualization

Find your use case and choose the type:
- change over time
- part to whole comparison
- data distribution
- comparing groups
- relationships
- geographical

A great thought piece on how #UI may look in the near #future:
https://www.browserlondon.com/blog/2024/05/22/future_of_user_interface_design/

Analyzing #AI, #generative UI, VR and other topics. I love posts like this to get my mind racing and envisioning possible futures.

Interesting post on #dataViz in the context of dashboards: https://medium.com/societe-generale-design/data-visualisation-the-value-of-design-4dc385d0d7ee

Learn which charts to use when, how to title your charts and how to bring the correct focus to your data.

Why do #designSystem teams take longer to build features than product teams?

If you ask Nathan Curtis, it is because of higher expectations and that is a good thing.

Higher quality expectations:
Design systems must be made to a level of quality to meet or exceed what every adopting team requires. Team(s) resist using features from somewhere else if they feel they do it better themselves.

Read more about it: https://medium.com/eightshapes-llc/design-system-ui-is-more-expensive-than-a-product-teams-ui-f3c3e48c555

The new #CSS anchor position specs are making a very complex problem extremely easy: positioning an element including a pin in relation to another element: https://css-irl.info/progressively-enhanced-popover-toggletips/

This problem normally requires #JS to be solved which is why we decided to remove it, to avoid the performance hit. Luckily, once support hits baseline it can be add again.

Love this quote by @linear on #figma's blog:

#ProductDebt (not #techDebt) is something to borrow against. Strategically narrowing a feature’s scope, “save” on quality, or optimize for the short-term, knowing you’ll have to pay “interest”—e.g. customer feedback or resourcing—later.

https://www.figma.com/blog/the-linear-method-opinionated-software/