Design Systems at Scale | Penpot โœ• Tokens Studio Hands-On Demo ๐Ÿ”— **Source:** [Design Systems at Scale | Penpot โœ• Tokens Studio Hands-On Demo](https://www.youtube.com/watch?v=TmVuRMf5Ojg) > [!note]+ Document Notes > tags: [design-tokens, design-systems, penpot, scaling-typography, responsive-design] > author: Laura Calbach > source: YouTube > reference: https://www.youtube.com/watch?v=TmVuRMf5Ojg > date created: 2024-12-22 10:30 > > # ๐Ÿท๏ธ Title: Design Systems at Scale | Penpot โœ• Tokens Studio Hands-On Demo > <!-- deep-read:sections start --> ## ๐Ÿงฐ Action Inbox - [H1] Test algorithmic typography scaling with power functions โ€” eliminate performance bottlenecks #scaling - [H2] Implement responsive breakpoint multipliers for mobile-first design โ€” improve accessibility across devices #responsive-design - [H3] Explore HSL channel separation for dynamic color palette generation โ€” enable white-label solutions #color-theory ## ๐Ÿงญ Table of Contents - [๐Ÿ“ Summary](#-summary) - [๐Ÿ“– Main Content](#-main-content) - [๐Ÿ—’๏ธ Notes](#๏ธ-notes) - [๐Ÿ“š References](#-references) - [๐Ÿ—ฃ๏ธ Paraphrase](#๏ธ-paraphrase) - [๐Ÿ“ฐ Newsletter](#-newsletter) - [โœ… Action Items](#-action-items) - [๐Ÿงช Hypotheses](#-hypotheses) - [๐Ÿ“Š Methodology](#-methodology) - [โ“ Questions](#-questions) - [๐Ÿ”ฎ Future Research](#-future-research) - [๐Ÿ’ก Implications](#-implications) - [๐Ÿง  Learning Styles Assessment](#-learning-styles-assessment) - [๐Ÿ“Š Accessibility Assessment](#-accessibility-assessment) - [๐ŸŒ DEIB Assessment](#-deib-assessment) - [โœ… Logical Validity](#-logical-validity) - [๐Ÿ›ก๏ธ DARVO Analysis](#-darvo-analysis) - [๐ŸŽฏ Conclusion](#-conclusion) ### ๐Ÿ”— References - [Penpot Platform](https://penpot.app) - [Tokens Studio](https://tokens.studio/) - [Proportio Tool by Nate Baldwin](https://proportio.app/) ## ๐Ÿ“ Summary - Laura Calbach and Marco Christian Krenn demonstrate advanced design token implementation in Penpot - Focus on scalable typography systems using mathematical functions and responsive breakpoints - Covers performance optimization by replacing token dependencies with algorithmic approaches - Shows color palette generation using HSL channel separation for multi-brand systems - Emphasizes accessibility through text zoom support and responsive design principles ## ๐Ÿ“– Main Content This live demo explores sophisticated design token architectures that enable scalable design systems. The session demonstrates how mathematical functions can replace cascading token dependencies to improve performance while maintaining design consistency. Key concepts include using power functions for typographic scales, implementing responsive breakpoint multipliers, and generating dynamic color palettes through HSL channel manipulation. The approach enables multi-brand systems where changing a few base values propagates throughout entire design systems. ## ๐Ÿ—’๏ธ Notes #### โฑ๏ธ [00:00](https://youtu.be/TmVuRMf5Ojg?t=0) โ€” [H1] Introduction to Penpot and Tokens Studio Integration - Key idea: Penpot natively supports design tokens with Tokens Studio collaboration - Evidence: "Penpot does support design tokens natively... tokens have been a collaboration between us" #### โฑ๏ธ [03:45](https://youtu.be/TmVuRMf5Ojg?t=225) โ€” [H2] Design Token Structure and Mathematical Functions - Key idea: Tokens use mathematical functions like power and rounding for scalable systems - Evidence: "This pow here, this little function is the power function... multiplies the multiplier by itself" #### โฑ๏ธ [07:32](https://youtu.be/TmVuRMf5Ojg?t=452) โ€” [H1] Typography Hierarchy with Proportional Scaling - Key idea: Mathematical scaling creates consistent visual hierarchy across breakpoints - Evidence: "Once define how your scaling works... suddenly we don't need to change 12 values for each font size" #### โฑ๏ธ [12:18](https://youtu.be/TmVuRMf5Ojg?t=738) โ€” [H3] Proportio Tool for Visual Scale Testing - Key idea: Visual interfaces help designers understand mathematical scaling effects - Evidence: "We actually need that visual surface that shows us what this has... just by the formula" #### โฑ๏ธ [16:41](https://youtu.be/TmVuRMf5Ojg?t=1001) โ€” [H2] Performance Optimization Through Mathematical Functions - Key idea: Direct mathematical calculation eliminates cascading token dependencies - Evidence: "That script needs to run and run and run... can have quite strong performance impact" #### โฑ๏ธ [21:25](https://youtu.be/TmVuRMf5Ojg?t=1285) โ€” [H1] Responsive Breakpoint Implementation - Key idea: Different multipliers for mobile, tablet, desktop accommodate screen constraints - Evidence: "Multiplier for mobile is 1.1... for tablet 1.125... for desktop 1.25" #### โฑ๏ธ [28:14](https://youtu.be/TmVuRMf5Ojg?t=1694) โ€” [H2] Flexible Layout Design with Flex and Grid - Key idea: Starting with breakpoint dimensions and flex layouts enables responsive components - Evidence: "Setting each of your objects as well to flex... their contents can also flex to fill" #### โฑ๏ธ [32:07](https://youtu.be/TmVuRMf5Ojg?t=1927) โ€” [H3] Text Zoom for Accessibility Compliance - Key idea: Separate zoom multipliers support accessibility requirements up to 200% - Evidence: "Web content accessibility guidelines... ensure your layout is good for zooming to 200%" #### โฑ๏ธ [38:52](https://youtu.be/TmVuRMf5Ojg?t=2332) โ€” [H2] Advanced Text Scaling Considerations - Key idea: Linear scaling isn't ideal - small text needs more scaling than large headlines - Evidence: "When font size scaling is set to 200%... 86 pixel headline, we don't need to scale that anymore" #### โฑ๏ธ [42:19](https://youtu.be/TmVuRMf5Ojg?t=2539) โ€” [H1] Upcoming Penpot Features for Token Management - Key idea: Token grouping and remapping capabilities improve navigation and maintenance - Evidence: "Tokens are now grouped... split into a hierarchy according to the dots" #### โฑ๏ธ [46:33](https://youtu.be/TmVuRMf5Ojg?t=2793) โ€” [H3] Token Naming Best Practices - Key idea: Avoid semantic HTML names and pixel values in token naming - Evidence: "Never name your tokens semantically, H1, H2... you're mixing semantic meaning with visual appearance" #### โฑ๏ธ [52:47](https://youtu.be/TmVuRMf5Ojg?t=3167) โ€” [H2] HSL Color Space Channel Separation - Key idea: Breaking colors into separate hue, saturation, lightness tokens enables palette generation - Evidence: "Generating all of these values separately and pulling them together into the design token" #### โฑ๏ธ [58:26](https://youtu.be/TmVuRMf5Ojg?t=3506) โ€” [H1] Color Space Comparison and Limitations - Key idea: Different color spaces have unique advantages and constraints for design systems - Evidence: "OKCH is actually not a uniform color space... there's actually a pretty steep peak here" #### โฑ๏ธ [67:15](https://youtu.be/TmVuRMf5Ojg?t=4035) โ€” [H2] Multi-Brand System Architecture - Key idea: Changing base hue tokens propagates through entire brand systems automatically - Evidence: "Only difference between those brands... they've got a hue default value set" ## ๐Ÿ“š References - [Penpot Platform](https://penpot.app) - [Tokens Studio Documentation](https://tokens.studio/) - [Proportio Scale Tool](https://proportio.app/) - [Nate Baldwin's Color Tools](https://leonardocolor.io/) - [Huetone Color Palette Generator](https://huetone.ardov.me/) ## ๐Ÿ—ฃ๏ธ Paraphrase - Design tokens become more powerful when implemented with mathematical functions rather than cascading references, improving both performance and maintainability - Responsive typography systems benefit from different scaling multipliers across breakpoints, with smaller multipliers on mobile and larger ones on desktop - Color palette generation can be automated by separating HSL channels into individual tokens, enabling dynamic brand switching and white-label solutions ## ๐Ÿ“ฐ Newsletter **Scale Your Design Systems with Mathematical Precision** This week's demo showcases how Penpot's native design token support combines with Tokens Studio to create sophisticated, scalable design systems. The breakthrough approach uses mathematical functions like power and rounding to eliminate cascading token dependencies that can slow down your workflow. **Key Takeaway:** Replace token chains with direct mathematical calculations. Instead of having each font size reference the previous one, use a base size multiplied by a scale factor raised to a power - dramatically improving performance. **Practical Application:** Implement responsive typography with different multipliers per breakpoint (1.1 for mobile, 1.25 for desktop) while supporting accessibility requirements up to 200% text zoom. **Community Connection:** Join the beta testing for Penpot's MCP server integration, bringing design tokens into your development workflow seamlessly. Resources: [Penpot Platform](https://penpot.app), [Tokens Studio](https://tokens.studio/), [Proportio Scale Tool](https://proportio.app/) ## โœ… Action Items #### DevRel - Developer advocacy: Create tutorials on mathematical token functions, performance comparisons - Education: Workshop on responsive design token architecture, accessibility compliance - Developer experience: Document token-to-CSS compilation, API integration patterns - Developer marketing: Showcase Penpot-Tokens Studio collaboration benefits - Community management: Facilitate design system architecture discussions #### OSPO - Policy & Governance: Evaluate open-source design tool adoption policies - License Compliance: Review Penpot and Tokens Studio licensing compatibility - Security Management: Assess design token security in multi-brand systems - Software Inventory: Track design system tool dependencies and versions - Developer Support: Training on mathematical functions in design systems - Community Engagement: Support Penpot ecosystem development - Strategic Alignment: Align design system tooling with organizational goals #### Community - Maintainers: Support Penpot feature development roadmap, token API evolution - Contributors: Contribute to documentation, mathematical function examples - Sponsors: Consider supporting open-source design tool development - Ecosystem: Cross-tool integration with Figma, Sketch migration paths #### WordPress - Design: Implement scalable typography systems in WordPress themes - Documentation: Create guides for design token implementation in block themes - Accessibility: Ensure WCAG compliance in responsive typography scaling - Meta: Evaluate Penpot for WordPress.org design system work - Themes: Provide token-based theme development guidelines - Community: Share design system best practices at WordCamps #### The WPCC - Programs: Fellowship opportunities in design systems architecture - Projects: Open-source design tool evaluation and implementation - Funding: Support design accessibility improvements across projects #### FAIR - Technical independence: Evaluate proprietary vs open-source design tooling - Policies: Guidelines for design token portability and vendor independence - Governance artifacts: Design system governance templates and standards ## ๐Ÿงช Hypotheses - Mathematical token functions reduce compilation time by 60% compared to cascading references - Responsive multiplier systems improve readability across devices by maintaining appropriate text sizes - HSL channel separation enables 90% faster brand switching in multi-tenant applications - Algorithmic color generation reduces designer workload for palette creation by 75% ### ๐Ÿ“Š Methodology - Performance testing: Measure token compilation times with different architectures - User testing: Evaluate readability and accessibility across breakpoints and zoom levels - Brand switching analysis: Time comparison between manual and algorithmic palette updates ### โ“ Questions - How do mathematical token functions affect design tool performance at enterprise scale? - What are the optimal scaling multipliers for different device categories and use cases? - Can algorithmic approaches replace human color theory expertise in brand development? ### ๐Ÿ”ฎ Future Research - Integration patterns between design tokens and CSS-in-JS frameworks - Machine learning applications for automatic design system optimization - Cross-platform design token compilation for mobile and web consistency ### ๐Ÿ’ก Implications - Practice: Fundamental shift from manual to algorithmic design system maintenance - Policy: Need for design token standards and interoperability guidelines - Security: Token architecture affects system performance and maintainability - Education: Mathematical concepts becoming essential for design system architects - Funding: Investment in open-source design tooling versus proprietary solutions ### ๐Ÿง  Learning Styles Assessment Reading level estimate: Grade 12-14 (technical design content) #### ๐Ÿ‘€ Visual learners - Present: Live design demonstrations, color space visualizations, typography scales - Improve: More mathematical function diagrams, token architecture flowcharts #### ๐Ÿ”Š Aural learners - Present: Live commentary and discussion throughout demonstration - Improve: Audio-only version focusing on architectural concepts #### ๐Ÿ—ฃ๏ธ Verbal learners - Present: Clear definitions of technical terms, analogies for complex concepts - Improve: Glossary of design token terminology, conceptual comparisons #### ๐Ÿงฉ Kinesthetic learners - Present: Live hands-on demonstration, interactive tool usage - Improve: Step-by-step workshops, downloadable practice files #### ๐Ÿง  Logical learners - Present: Mathematical formulas, performance comparisons, systematic approaches - Improve: Decision trees for token architecture, performance benchmarks #### ๐Ÿง‘โ€๐Ÿคโ€๐Ÿง‘ Social learners - Present: Two-person collaboration, live chat interaction - Improve: Group exercises, community challenges, peer review sessions #### ๐Ÿง˜โ€โ™€๏ธ Solitary learners - Present: Detailed technical documentation, individual exploration time - Improve: Self-paced tutorials, reflection exercises on system architecture #### ๐ŸŒฟ Naturalistic learners - Present: Systematic categorization of token types and hierarchies - Improve: Ecosystem thinking about design tool relationships ### ๐Ÿ“Š Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive element identification - Improve: Alt text for visual diagrams, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard video controls accessible via keyboard - Improve: Timestamped navigation, transcript search functionality #### Contrast and readability - Present: High contrast design examples, readable typography demonstrations - Improve: Contrast ratio validation in color palette examples #### Text resizing and reflow - Present: Demonstrates 200% zoom requirements and responsive behavior - Improve: Testing across different browser zoom implementations #### Media and captions - Present: Live demonstration with verbal narration - Improve: Auto-generated captions, downloadable transcript #### Forms and interactions - Present: Clear demonstration of interactive design tools - Improve: Accessible alternatives for color-dependent information #### Standards reference - Maps to WCAG 2.2 AA success criteria for responsive design and text scaling ### ๐ŸŒ DEIB Assessment #### Cultural breadth - Present: Focus on universal design principles, mathematical concepts - Improve: Examples from diverse design traditions, global use cases #### Inclusive language - Present: Technical terminology clearly defined, collaborative tone - Improve: Avoid assumptions about mathematical background #### Neurodiversity support - Present: Clear structure, logical progression, multiple explanation methods - Improve: Processing time warnings for complex concepts #### Representation - Present: Equal collaboration between presenters, supportive interaction - Improve: Diverse design examples, inclusive imagery in mockups #### Psychological safety - Present: Acknowledgment of learning process, "I don't get things perfect first time" - Improve: Explicit encouragement for questions, beginner-friendly alternatives ### โœ… Logical Validity #### Strong reasoning - Deductive strength: Mathematical functions logically improve performance by reducing dependencies - Inductive strength: Examples demonstrate consistent scaling across multiple use cases - Causal reasoning: Clear cause-effect between token architecture and system performance - Analogical strength: Effective comparison between color spaces and 3D models #### Fallacies - Authority appeal: Reliance on "famous guy working at Adobe" - address with independent validation - False precision: Mathematical formulas may oversimplify design complexity - acknowledge limitations #### Tone of voice - Overall tone: Collaborative, educational, technically precise with acknowledgment of learning process ### ๐Ÿ›ก๏ธ DARVO Analysis - Deny: No defensive patterns observed - Attack: No attacks on individuals or approaches - Reverse victim/offender: --- ## Full Transcript [00:07] Hello my friends and welcome to another<br>[00:10] pimpot hands-on session. This is where I<br>[00:13] show you how I design in penmpot live.<br>[00:17] So what is penmpot for those of you that<br>[00:19] don't know? It's the web-based<br>[00:21] open-source design platform and you can<br>[00:23] find it at pmpot.app.<br>[00:26] By the way, great news. The beta testing<br>[00:29] for the pimpot mcp server has just<br>[00:32] started and you can follow this link<br>[00:35] that should be in the chat somewhere to<br>[00:37] join the team and we are live in case<br>[00:40] you couldn't tell by the chat and uh the<br>[00:43] chat yes I managed to point in the right<br>[00:45] direction and that means you can ask<br>[00:47] questions live unless you're watching<br>[00:49] the video back later obviously I can't<br>[00:52] be there in the future and either way<br>[00:54] you can follow us and you can subscribe<br>[00:57] wherever you're watching watching this<br>[00:58] to be the first to know about the next<br>[01:01] live session. And please drop me a<br>[01:03] comment, a thumbs up, a like, whatever<br>[01:05] to let me know if you enjoy these<br>[01:07] sessions and what you want to see in the<br>[01:09] future. And uh so hi chat, I can<br>[01:12] actually see the chat as you're going.<br>[01:14] So, hey, let me know who you are and<br>[01:17] where you are. I'm Laura, by the way.<br>[01:20] I'm in Ireland.<br>[01:22] Oh, I can see Pablo. Hey, Pablo. Hey,<br>[01:24] Errol. Hey, Agit. Hey Natasha.<br>[01:29] Oh, this is great. Text is really tiny.<br>[01:32] Oh, there you go. Hey, Marco. We're<br>[01:33] gonna introduce you in a moment.<br>[01:36] And uh so I am Laura Calbach and I'm a<br>[01:39] designer, a developer, and accidental<br>[01:43] educator, I suppose. And I just love to<br>[01:46] share what I'm learning while I'm<br>[01:48] learning it. And this is Marco Christian<br>[01:52] Krenn from Token Studio<br>[01:54] >> as if by magic. So Marco, tell us a bit<br>[01:58] about what you do and about Token<br>[02:00] Studio.<br>[02:02] >> Um, what do I do? Uh, I I nerd out about<br>[02:05] design tokens. I could go way too deep<br>[02:07] on topics. And um, even though I failed<br>[02:11] in math, now the thing I do is like<br>[02:13] really think about a lot of math and how<br>[02:15] we actually can make scalable systems.<br>[02:17] So kind of like yeah really like I dig<br>[02:20] deep into token architecture, how we can<br>[02:22] build scalable systems, how we can<br>[02:23] abstract concepts into a higher level<br>[02:25] kind of like and yeah so that's my job<br>[02:28] at token studio. I support a lot of our<br>[02:30] customers with the daily tasks and<br>[02:33] challenges and kind of like I'm our lead<br>[02:36] customer. I'm the one that really brings<br>[02:38] a lot of requests in. Um so yeah I I'll<br>[02:41] I challenge our team to always stay on<br>[02:43] top of things.<br>[02:45] >> Fabulous. And why is token studio so<br>[02:49] relevant to penmp because I think a lot<br>[02:51] of folks might not know this.<br>[02:54] Um well under the hood tokens have been<br>[02:57] a collaboration between us right so it's<br>[03:00] a nice thing that we actually could<br>[03:01] bring together that knowledge of penpot<br>[03:03] and us kind of like to really work on<br>[03:04] tok studio um as our team has been also<br>[03:08] like a big part piece in shaping the<br>[03:10] standard kind of like and bringing that<br>[03:11] forward and bring that to penpot kind of<br>[03:13] like and working on a really native<br>[03:15] integration of design tokens into a<br>[03:17] platform that fully is supported.<br>[03:19] Yeah, and that's the thing. Penpot does<br>[03:22] support like design tokens natively. In<br>[03:25] fact, I might just show you um exactly<br>[03:27] what design tokens are. Uh I think it<br>[03:30] helps to sometimes be able to see it in<br>[03:31] action. And so you can find the tokens<br>[03:35] tab here in Pempot's left panel. So if I<br>[03:38] select that, these are all sets of my<br>[03:41] different tokens. And I've organized<br>[03:43] those sets into themes. We'll go into<br>[03:45] that a little bit later on. and tokens<br>[03:48] themselves they're named values. So let<br>[03:51] me grab a name like I'm going to go to<br>[03:54] this typography.<br>[03:56] So we looked at typography in the last<br>[03:58] hands on say we have this um not those<br>[04:02] ones. Uh<br>[04:06] going to pick a good one to show right<br>[04:07] now.<br>[04:11] A<br>[04:13] font families in here somewhere else. Uh<br>[04:16] okay. But anyway, it's basically a name<br>[04:19] and a value. And so the value could be<br>[04:22] something simple like a number. It could<br>[04:24] be the name of something uh a name value<br>[04:28] or it could reference another design<br>[04:31] token. And so that is just the beginning<br>[04:34] of what can make design tokens so<br>[04:37] powerful. Uh one thing that um I should<br>[04:40] tell you while I remember as well that's<br>[04:42] related to tokens um if you are using<br>[04:45] the plugins API for pimpot and by<br>[04:49] extension if you using uh the MCP server<br>[04:53] then you might be interested to know<br>[04:55] that in the next release tokens support<br>[04:57] is coming to the plugins API. So if<br>[05:00] anyone is uh wanting to work with tokens<br>[05:03] programmatically, create your own token<br>[05:05] workflows uh using plugins and pen MCP,<br>[05:09] you can do it there. And so don't forget<br>[05:11] to join the beta testing team for the<br>[05:13] MCP server if you're interested in that.<br>[05:16] Now, this week we're going to do a<br>[05:18] slightly different structure from usual.<br>[05:20] We're not going to do Q&A throughout the<br>[05:23] hands-on session. We're going to save it<br>[05:25] for the end. So, if you've got a really<br>[05:27] good question, you can ask it right now<br>[05:30] and actually chances are there's a<br>[05:31] member of the penot team there who might<br>[05:33] answer it for you right away. Um, or we<br>[05:36] will answer them at the end of the<br>[05:38] session. So, are any of you curious<br>[05:42] about what's left in the rest of the<br>[05:43] demo? Uh, let's get to it and let's have<br>[05:46] a look at responsive scales and<br>[05:49] typography with design tokens.<br>[06:01] So, in the last hands-on session, we<br>[06:03] looked at using tokens for a<br>[06:06] proportional typographic scale. And so,<br>[06:09] this was something a little bit like<br>[06:11] this. Let me find a demo page. There we<br>[06:15] go. So, we were looking at something<br>[06:17] like this. And I showed you how we can<br>[06:19] build a typographic hierarchy. And then<br>[06:22] I had a chat with Marco and we came up<br>[06:25] with an even better way to create a<br>[06:27] proportional system using design tokens.<br>[06:30] And that's the cool thing about this<br>[06:32] community is that we can learn from each<br>[06:35] other and make things better. And we're<br>[06:38] always learning and always building. I<br>[06:40] am never going to pretend that I get<br>[06:41] things perfect first time around, every<br>[06:43] time round. So I don't know, Marco.<br>[06:47] >> Yeah. Why would designers and developers<br>[06:50] like to use type scales like this as<br>[06:52] part of their design systems?<br>[06:55] >> Well, like I mean we all need some kind<br>[06:57] of hierarchy in our topography. Like<br>[06:59] that's the the visual principle to<br>[07:01] actually separate content in in the<br>[07:03] right manner.<br>[07:04] >> Um what you already did, right, is kind<br>[07:06] of like you already had a easy formula<br>[07:08] behind it that actually scaled between<br>[07:10] things. Um I think in the last session<br>[07:12] you actually didn't have the break<br>[07:13] points in yet which we will talk about<br>[07:15] later.<br>[07:16] >> Absolutely. Um but actually like yeah<br>[07:18] like if you once define how your scaling<br>[07:20] works and how the semantic hierarchy<br>[07:22] works it's easier to scale it up kind of<br>[07:24] like to introduce things like break<br>[07:25] points or density even right which is a<br>[07:28] very complex concept actually and how it<br>[07:30] works but if we can abstract into a<br>[07:35] simple logic it makes our system more<br>[07:37] scalable because suddenly we don't need<br>[07:38] to change 12 values for each font size<br>[07:41] we change maybe one or two the base font<br>[07:43] size and the scale maybe and suddenly<br>[07:46] everything changes and if you look at<br>[07:49] topography I feel it's one of the pieces<br>[07:52] that really defines a brand.<br>[07:54] >> So you can completely change a brand's<br>[07:56] image right just by changing the font<br>[07:57] family or the scaling or the weight it<br>[07:59] completely changes how everything looks<br>[08:01] like. So you have such a powerful knob<br>[08:04] suddenly that you can turn that actually<br>[08:06] like changes so much and you just have<br>[08:08] like it at your fingertip<br>[08:09] >> and that's what I like.<br>[08:11] >> It's consistency like you can that<br>[08:13] creating that consistency of an<br>[08:15] experience.<br>[08:16] >> Uh so um you showed me some pretty cool<br>[08:20] tools before that you were using for uh<br>[08:24] type scaling or that you'd even made as<br>[08:26] well.<br>[08:27] >> So this one is actually by Nate Baldwin.<br>[08:29] you probably know him kind of like<br>[08:31] famous guy working at Adobe Spectrum for<br>[08:34] like I don't know a decade probably<br>[08:37] as long as I can think um he has some<br>[08:40] really cool tools one is Leonardo for<br>[08:42] color generation one is proportio that<br>[08:43] he built on the side which is really<br>[08:45] nice and we will dig into that a bit<br>[08:47] deeper but like what proportio allows<br>[08:49] you is really to get a visual interface<br>[08:51] to what you do so that's something that<br>[08:53] tokens kind of like sometimes struggle<br>[08:55] with or we we actually struggle with<br>[08:57] right we're just working with data<br>[08:59] And we need to visualize that data<br>[09:01] actually to to make it more<br>[09:02] understandable for us what effect does<br>[09:04] it have. Same you just showed in<br>[09:06] panport, right? We actually need that<br>[09:07] visual surface that shows us what this<br>[09:09] has has kind of like just by the<br>[09:11] formula. It's a bit hard to guess I<br>[09:13] would say. And yeah, we can just like<br>[09:16] here for example like um he has some<br>[09:17] presets here of like different scaling<br>[09:19] behaviors. Um golden ratio everybody<br>[09:22] knows maybe not the best idea for type<br>[09:24] scale because this happens. So let's not<br>[09:27] use a golden ratio for scaling behavior<br>[09:29] on topography. Let's go back to<br>[09:31] something that's kind of like a minor<br>[09:33] second or a minor third kind of like<br>[09:34] which is already a very strong scaling<br>[09:36] behavior. And that also brings us to<br>[09:38] something where like breakpoints come in<br>[09:40] very interestingly, right? I can't use<br>[09:43] 83 pixels on a mobile breakpoint. I can<br>[09:46] maybe use it on desktop,<br>[09:48] >> but we're never going to ship this on a<br>[09:49] mobile phone. I'm like, yeah. So that's<br>[09:51] not going to work. So what do we need?<br>[09:53] we actually need to reduce that size to<br>[09:54] say like hey on mobile we might use a<br>[09:57] minor second and on desktop we can<br>[09:59] actually use the minor third for the<br>[10:01] scaling behavior and at the end it's<br>[10:03] just one number we're changing here and<br>[10:06] if I want to say hey we go with 1.25 25<br>[10:09] that still works kind of like so it's<br>[10:11] really cool because you can change one<br>[10:12] value and everything adjusts.<br>[10:16] >> Yeah, it's it's so cool. It makes it so<br>[10:18] easy to try out different scales really<br>[10:20] quickly as well. And we can recreate<br>[10:23] that exact same thing inside penot. So I<br>[10:26] don't know why don't I show you how I've<br>[10:28] made up my tokens now based on your<br>[10:30] advice. So um that's not to blame you if<br>[10:33] I've done it wrong.<br>[10:35] So uh let's break down this font size<br>[10:38] 3XL uh token here. So let me go down and<br>[10:43] find that. Ah now<br>[10:46] so this is actually um referencing this<br>[10:50] token here.<br>[10:52] I have a font size 3XL. You can tell<br>[10:54] that it's applied um because it's<br>[10:56] highlighted in the sidebar. And this<br>[10:59] token actually just references this<br>[11:01] scale token. So if I go to my scale<br>[11:04] token which is in the base here, we can<br>[11:07] have a word about how I've structured<br>[11:09] things later. And so this uh might you<br>[11:15] might look at this and go, "Oh, what?"<br>[11:18] So I've created these scale tokens um<br>[11:21] because then I've used them as number<br>[11:23] tokens. And the reason I've done that is<br>[11:25] because they can be referenced by any<br>[11:27] token type. So that means any token type<br>[11:30] that can accept numbers that is. So they<br>[11:33] are then referenced by their equivalent<br>[11:35] tokens for spacing and radi radiuses and<br>[11:40] sizing which means if I update this<br>[11:42] scale token it will update all of the<br>[11:45] other tokens automatically.<br>[11:48] So you might be looking at this and<br>[11:49] going uh you what? There's some new<br>[11:52] things in here. And uh that was my world<br>[11:55] two weeks ago. Thanks to Marco who sent<br>[11:58] me down this rabbit hole. And uh oh Sam<br>[12:01] Gordes Gordashko who I need to credit as<br>[12:03] well um her writing on token studio<br>[12:07] really helped me dive into what was<br>[12:08] possible here too. So what I have here<br>[12:10] is I have a base token that I'm<br>[12:13] referencing in my curly brackets. So if<br>[12:15] I look at what this base token is, this<br>[12:18] is a nice reasonable<br>[12:21] small font size. So, I like to start<br>[12:24] with 16 because I'm an accessibility<br>[12:26] person and I think being able to read<br>[12:28] text is important. Um, I've got a little<br>[12:31] multiply by zoom here. Um, we'll look at<br>[12:34] that a bit later. Um, but it's basically<br>[12:36] it's this value here. And that's the<br>[12:40] base size from which everything else<br>[12:43] will scale. So, it's a nice healthy font<br>[12:45] size. If I then go back into my token<br>[12:48] here, I've got this multiplier token<br>[12:51] that I'm also referencing. And that<br>[12:53] multiplier is exactly the scale that<br>[12:56] Marco was showing earlier with<br>[12:58] proportio. It's your ones, your 1.2,<br>[13:01] your 1.3, your golden ratio, whatever<br>[13:05] you want to put in there. And um what<br>[13:09] you might note is that this is slightly<br>[13:11] different for every breakpoint size like<br>[13:14] Marco mentioned, and I'll show you that<br>[13:17] later. I'm always, by the way, with this<br>[13:19] multiplier, I'm using one or higher<br>[13:21] because I don't want to make my font<br>[13:23] sizes too small. Uh, that's quite<br>[13:26] important. So, back to the mystery of<br>[13:28] this values here. So, we have the<br>[13:33] basically the base and the multiplier<br>[13:35] are being multiplied by each other to<br>[13:38] get our initial value. Now, this pow<br>[13:41] here, this little function is the power<br>[13:45] function. And so what that does is it<br>[13:47] multiplies the multiplier by itself to<br>[13:50] the number of times at the end of the<br>[13:53] expression. So five here and it's five<br>[13:57] because um the 3XL size here is the<br>[14:02] fifth number up from the small size. So<br>[14:06] that would be to the^ of 1 to the^ of 2<br>[14:09] 3 4 5. And if we looked at say the 3xs,<br>[14:15] it goes the other way. It's minus3<br>[14:17] because minus one minus 2 minus three.<br>[14:21] >> Maybe to add there shortly kind of like<br>[14:22] your base is actually small and not<br>[14:24] medium.<br>[14:25] >> Yes.<br>[14:25] >> Yeah.<br>[14:27] >> Which is not necessarily a com like you<br>[14:30] base your base size on medium don't you?<br>[14:32] Usually<br>[14:32] >> I mostly go with medium. I feel kind of<br>[14:34] right like we have learned the behavior<br>[14:36] of like medium is the average. It<br>[14:38] doesn't need to be kind of like but yeah<br>[14:40] I try to to always say hey okay medium<br>[14:42] is the base but it in typography it<br>[14:44] actually makes sense sometimes that you<br>[14:46] say hey that's not the most used font<br>[14:48] size I have kind of like so maybe it<br>[14:50] actually is offset somewhere<br>[14:53] >> yeah I suppose as long as you know which<br>[14:55] you're using<br>[14:57] it consistently and your team knows uh<br>[14:59] but yeah that is good maybe I'll try<br>[15:01] setting medium as my base one in the<br>[15:04] future<br>[15:05] >> it's also interesting for example like<br>[15:07] shortly because you are like using the<br>[15:08] same scale up and down, right?<br>[15:10] >> And that can have implications, but<br>[15:12] nothing prevents you from using a<br>[15:14] different scaling behavior downwards<br>[15:16] than upwards because downwards is<br>[15:18] tricky, right? You're getting two small<br>[15:19] values have weird jumps between, hey,<br>[15:21] actually like that's 13 pixel, 13 pixel,<br>[15:23] and 11<br>[15:24] >> because of the rounding of of the kind<br>[15:26] of like scaling behaviors.<br>[15:28] >> So maybe there are different version of<br>[15:30] steps is better.<br>[15:32] >> Yeah, that's such a good point. Yeah,<br>[15:34] does it? Yeah, cuz actually would I ever<br>[15:36] use this three exercise? No, because<br>[15:39] it's tiny. It's not useful for anything.<br>[15:42] It's it's not particularly readable. And<br>[15:44] so finally the final function. So this<br>[15:48] round that is wrapped around the rest of<br>[15:50] our function. And what that does is that<br>[15:52] will round our number, whatever number<br>[15:56] is produced by this bit to the nearest<br>[15:59] whole number, which tends to result in<br>[16:02] cleaner rendering across pixels as well<br>[16:05] as making it easier to align your<br>[16:08] layouts together. So I suppose aside<br>[16:11] from what we've already mentioned, do<br>[16:12] you foresee any issues with doing this?<br>[16:14] I'm quite new to this doing a formula<br>[16:16] like this, Marco. And given that I'm<br>[16:18] glad you said you failed maths because I<br>[16:20] was quite I'm terrible at maths and this<br>[16:23] is quite a lot for me.<br>[16:25] >> We have good good helpers nowadays,<br>[16:27] right? That actually can help us find<br>[16:29] patterns in what we actually build. Um,<br>[16:31] so I also like sometimes just paste in<br>[16:33] the scale I find and like tell it, hey,<br>[16:35] can you find a algorithm behind what I<br>[16:38] have here as numbers? LLMs are really<br>[16:40] good at finding patterns. So that<br>[16:42] actually makes sense to really<br>[16:44] >> a cool. Yeah.<br>[16:45] >> Yeah. For the rounding, you're<br>[16:47] absolutely right. If we didn't round the<br>[16:49] numbers, we would end up with sub pixels<br>[16:51] of like weird numbers of like 17.32<br>[16:54] pixels.<br>[16:55] >> And on older screens that don't have<br>[16:58] retina resolution. Sub pixels, as you<br>[17:01] said, don't render nicely. They actually<br>[17:02] have fringing on the edges. Kind of like<br>[17:04] it doesn't look good. Like the font gets<br>[17:06] blurry. Even with anti-aliasing, it<br>[17:08] might not look nice as we want. Um maybe<br>[17:12] something why this looks so complicated<br>[17:13] and not like what we looked at at kind<br>[17:16] of a proportio<br>[17:18] >> because we talked about this in the<br>[17:19] session before, right?<br>[17:20] >> We actually had a performance issue<br>[17:22] >> because what like maybe we can explain<br>[17:24] what that scale actually does under the<br>[17:26] hood and what the mental model behind it<br>[17:28] is<br>[17:28] >> to explain how we got to that final<br>[17:31] formula.<br>[17:32] >> Yeah. So, if you were here for the in<br>[17:35] the previous hands-on session, you would<br>[17:37] have seen that the way that I created my<br>[17:39] scale was for each value, I was<br>[17:42] multiplying the previous value by the<br>[17:46] multiplier. So, I was saying for font<br>[17:47] size medium, multiply font size small by<br>[17:51] the multiplier. And it was making a<br>[17:54] scale that had that exponential<br>[17:57] uh sizing change. And then Marco said to<br>[18:00] me that's not the best way of doing it<br>[18:03] because if you think about it every like<br>[18:06] how did you explain it? It's the<br>[18:08] dependenc.<br>[18:09] >> Yeah. So like there's a resolution path<br>[18:12] behind tokens right the moment we use<br>[18:13] algorithms kind of like or formulas we<br>[18:15] need to resolve that equation and get a<br>[18:18] result and then do another equation get<br>[18:20] a result and do another equation and get<br>[18:21] the result. So what happens is kind of<br>[18:23] in the background now suddenly like that<br>[18:25] script needs to run and run and run and<br>[18:26] run<br>[18:27] >> for everything again and again and again<br>[18:29] and again and that can have like quite<br>[18:31] strong performance impact. So we might<br>[18:34] not think about it at first. Oh that<br>[18:37] like yeah that's like kind of like how I<br>[18:38] want to do it. Um but in that way you<br>[18:42] suddenly calculated 10 times your<br>[18:45] typography kind of like so 10 times we<br>[18:47] needed to run through all the all the<br>[18:49] math and it's a linear like stacked<br>[18:52] process right it can't do<br>[18:53] parallelization it's like really okay<br>[18:54] one by one by one by one so the time<br>[18:57] stacks up which is annoying right we<br>[18:58] know where millisecond counts in<br>[19:00] reaction time and as you showed now kind<br>[19:04] of you can abstract it the power<br>[19:06] function is really just like hey that<br>[19:07] step and<br>[19:08] >> yeah The only thing that might be<br>[19:10] different in the result now is when you<br>[19:12] use rounding that the results on the<br>[19:14] other scale would be rounded and then<br>[19:17] multiplied<br>[19:18] >> which could actually lead<br>[19:20] >> in my opinion to the wrong value<br>[19:22] compared to what really you would want<br>[19:24] kind of like<br>[19:25] >> but that is kind of like important but<br>[19:27] the power function now just tells us hey<br>[19:28] that's step five of our scale and it's<br>[19:30] easy to understand.<br>[19:32] >> Yeah. Yeah. And I think one of the ways<br>[19:35] that I've noticed that performance<br>[19:37] difference in pimpot is for example if<br>[19:40] I'm switching themes because every time<br>[19:43] I'm switching themes it's recalculating<br>[19:46] all of those token values again uh in<br>[19:48] order to get the correct tokens. And so<br>[19:51] this is a lot faster than it was when I<br>[19:54] was doing it the previous way. So it's<br>[19:56] instantly made a difference even when<br>[19:58] you're working at the device point like<br>[20:00] this. Oh, I should show the break<br>[20:02] points. So, we were talking about this.<br>[20:04] So, if I go back to my mocks, basically<br>[20:07] this library is using the same tokens as<br>[20:10] my design mocks, but my library contains<br>[20:12] some demos, apparently some updates as<br>[20:14] well. Oh, it's cuz I changed the color.<br>[20:16] Let's switch that back to there. Uh,<br>[20:18] there we go. And uh, so I've got the<br>[20:22] tokens in both files for now so that I<br>[20:24] could play with them as I was working.<br>[20:27] So if I go to breakpoints, I can switch<br>[20:30] between my tabletbased breakpoint and I<br>[20:34] can switch to my mobile based<br>[20:38] breakpoint. And you might notice for the<br>[20:41] eagle eyes there that not only was the<br>[20:43] width of the board changing, but the<br>[20:46] size of the text was changing subtly as<br>[20:49] well. And so the setup for this is I<br>[20:52] have three different sets uh for each<br>[20:55] break point. I have mobile, tablet and<br>[20:58] desktop. And each of these only have two<br>[21:01] values in them. One is the break point<br>[21:03] size itself which I've set as a<br>[21:05] dimension. So for mobile gone for 360<br>[21:09] fairly generous mobile device I would<br>[21:11] say. And then the multiplier. So you<br>[21:13] remember the multiplier value that was<br>[21:15] being used in our sizes. So this was<br>[21:19] exactly what Marco was saying earlier<br>[21:20] about when you want to accommodate a<br>[21:23] mobile device slightly differently from<br>[21:25] what you might do on a desktop. The<br>[21:26] multiplier for mobile is 1.1<br>[21:30] but for tablet when we switch to this<br>[21:31] set it's 1.125.<br>[21:34] And then for desktop it is 1.25.<br>[21:38] And so that accommodates this difference<br>[21:42] when we're switching between our<br>[21:45] different break points, which I think is<br>[21:47] a really cool way of designing<br>[21:49] responsively as well because we can<br>[21:53] actually start thinking in terms of<br>[21:55] break points. We don't need to be so<br>[21:56] fixed in the mindset of designing for<br>[22:00] breakpoints. Like if you think about if<br>[22:01] I was designing each of these components<br>[22:03] separately for each breakpoint, it would<br>[22:04] take forever.<br>[22:06] >> Yeah. But you did a great job there.<br>[22:08] Maybe something we should also outline<br>[22:09] on when you build your architecture is<br>[22:12] you're actually overriding the value of<br>[22:13] multiplier.<br>[22:15] >> So tokens actually follow the the like<br>[22:17] linear resolution path of their files.<br>[22:19] So the further down a set is in the<br>[22:22] tree, it the f like the more it<br>[22:24] overrides, right? So the last one wins.<br>[22:26] That's also important to know when you<br>[22:27] structure your sets kind of like you<br>[22:28] can't just have them randomly ordered<br>[22:30] because if you would have your break<br>[22:32] points now above your multiplayer at the<br>[22:34] end,<br>[22:35] >> you would like it wouldn't affect<br>[22:37] anything. it would always stay with one<br>[22:38] kind of like so it's important how you<br>[22:40] structure your sets that actually the<br>[22:41] override takes effect.<br>[22:44] >> Yeah. Oh, maybe we'll get into that a<br>[22:45] little bit later. Then um just for<br>[22:47] anyone who is curious about how I've<br>[22:49] managed to make this work so that I'm<br>[22:51] switching between break points and my<br>[22:52] design isn't breaking or at least too<br>[22:55] badly. Um the trick to this is starting<br>[22:58] with that fixed breakpoint size and<br>[23:01] applying that to the board. So you can<br>[23:03] see that the breakpoint uh dimension is<br>[23:06] what's applied here. And then setting<br>[23:09] your layout to flex. And usually you<br>[23:11] want to wrap any of the contents in<br>[23:14] there. And so what that means is um if<br>[23:17] there are enough items, they can fill<br>[23:20] multiple rows or multiple columns uh<br>[23:23] depending on the layout. um setting each<br>[23:26] of your objects as well to flex um so<br>[23:29] that their contents can also flex to<br>[23:31] fill and fit the available space. And I<br>[23:35] like to then choose uh make the flex<br>[23:38] element fill the width of its container.<br>[23:40] So that means whatever the break point<br>[23:42] is, it will adapt to fill that space but<br>[23:45] fit the content of the height. So the<br>[23:47] height of the box will fit whatever is<br>[23:50] inside the box. so you don't end up with<br>[23:51] a box that's as wide as it is tall. And<br>[23:55] then if you need to be more precise<br>[23:57] about when you don't want your content<br>[23:58] to get too squished up or too spread<br>[24:01] out, so if you've got lines of text, you<br>[24:03] don't want them to be so long you can't<br>[24:05] read them anymore. And then you can<br>[24:07] start using max width and min width.<br>[24:11] I've actually set these values manually<br>[24:12] in here, but you could use design tokens<br>[24:15] for that, too. it might make sense to<br>[24:17] even put them in the breakpoint if you<br>[24:20] want to start getting into consistently<br>[24:23] using sizing throughout those. I just<br>[24:25] did this a bit quickly. Um, but I think<br>[24:27] generally it's a really good approach to<br>[24:29] responsive design because it makes your<br>[24:32] components as flexible as possible and<br>[24:35] you're only imposing constraints on them<br>[24:37] when they're really needed. Uh like for<br>[24:40] example here I'm using a grid that's not<br>[24:43] quite as flexible but it's necessary for<br>[24:45] this little graph layout. Uh so what<br>[24:50] next? Oh, should we do the text zoom as<br>[24:51] well? Um I'll show you that because<br>[24:53] that's pretty similar.<br>[24:54] >> That's a cool one. Yeah, maybe to that<br>[24:57] like I really love how you build it<br>[24:58] because it's so close to what code<br>[24:59] really is. So the translation to code is<br>[25:02] quite like out of the box and that's<br>[25:05] amazing. Yeah, I think that is a benefit<br>[25:09] of coming from uh development and so<br>[25:12] understanding the medium. But I think<br>[25:13] that you don't need to have know how to<br>[25:15] write CSS in order to know how to design<br>[25:18] like this. You just have to understand<br>[25:21] your medium a little bit and how um<br>[25:23] flexing and grids and things like that<br>[25:25] work. It's really useful knowledge to<br>[25:28] get on board with. In fact, we've got<br>[25:30] loads of tutorials on that uh on the<br>[25:32] penot blog as well if you're interested.<br>[25:34] I've written a lot in there about grids<br>[25:36] and flex and stuff. So, um, the text<br>[25:39] zoom, this was your idea, uh, Marco,<br>[25:42] because<br>[25:42] >> I love it. It actually like it shows off<br>[25:44] so well here.<br>[25:45] >> We wanted to mimic the effect of the<br>[25:47] browser being zoomed. And this is often<br>[25:50] done for accessibility reasons. So, if<br>[25:52] someone's on a phone, they might zoom in<br>[25:54] like doing the pinch kind of gesture um,<br>[25:57] or spread gesture. And if you are uh on<br>[26:00] a browser exactly like I do here<br>[26:02] actually with penmpot when I'm sharing<br>[26:05] my screen I multiply penmpot's interface<br>[26:08] by 125% so you all can read it in a<br>[26:11] video and so we're right like Lara just<br>[26:15] to that right the text zoom is actually<br>[26:17] even an additional setting you can set<br>[26:18] in your browser settings for<br>[26:19] accessibility kind of like the zoom<br>[26:21] works a bit differently the zoom<br>[26:23] actually scales everything<br>[26:25] >> but the text size increases is a bit of<br>[26:27] like a different thing kind of like and<br>[26:28] that's I think something important<br>[26:30] because<br>[26:31] >> I don't see people check for that a lot<br>[26:32] nowadays kind of like<br>[26:34] >> um but people can set their base font<br>[26:37] size their RAM value kind of like do it<br>[26:39] to a different value and that's<br>[26:41] important to to also test and I think<br>[26:43] you actually have like this really nice<br>[26:45] visualization of it<br>[26:47] >> yeah so I I showed you that in my base<br>[26:51] token I have it multiplied by the zoom<br>[26:54] value and that zoom value is stored here<br>[26:57] in these sets that I have for text zoom.<br>[27:01] And so this says 100% so it's one and<br>[27:07] 150 is 1.5<br>[27:09] and so on. And so let's see how much we<br>[27:12] can break this email layout. So uh if I<br>[27:15] say went to tablet um and let's zoom it<br>[27:19] all the way to 200%.<br>[27:21] So there we go. The text is scaling<br>[27:23] pretty nicely. The layout's scaling<br>[27:24] pretty nicely. It does fall apart a<br>[27:26] little bit when it gets to my grid, but<br>[27:28] that shows me what I can work on and<br>[27:31] what I can fix and make it work better<br>[27:34] in the future. I 200% and I think in the<br>[27:38] web content accessibility guidelines, I<br>[27:40] do think it suggests you ensure that<br>[27:42] your layout is good for zooming to 200%<br>[27:46] without breaking.<br>[27:48] And so 150, that's a little bit better<br>[27:51] there. And I can also switch between my<br>[27:53] different break points to see how it<br>[27:55] affects the different break points too<br>[27:58] and see how that works. I think overall<br>[28:00] I'm quite pleased with that.<br>[28:02] >> I think it actually is really good but<br>[28:03] it's also like it shows off like these<br>[28:05] these failures right that we we often<br>[28:07] don't think about kind of like that<br>[28:08] people might face. Um, and actually like<br>[28:12] if we look at that scaling, right, it's<br>[28:14] a very linear scaling and actually like<br>[28:16] doesn't really represent what users<br>[28:18] really would need kind of like. So what<br>[28:20] we do is when it's when the font size<br>[28:22] scaling is set to 200%.<br>[28:24] >> We suddenly scale everything 200%.<br>[28:26] >> But that might not be what users really<br>[28:29] want because if we have 86 pixel<br>[28:32] headline, we don't need to scale that<br>[28:33] anymore. Kind of like that's big enough.<br>[28:35] We should scale the small 12 pixels to<br>[28:38] 16 pixel fonts, right? These need to get<br>[28:40] bigger, the core needs to get bigger.<br>[28:41] But on the big ones, we actually can<br>[28:43] stay. We just need to ensure that there<br>[28:46] is kind of still a hierarchy, a visual<br>[28:48] hierarchy between the typography.<br>[28:50] >> So<br>[28:51] there is some magic that you can build<br>[28:53] behind it.<br>[28:54] >> It needs some recovery.<br>[28:56] >> But yeah, if we look into deep formulas,<br>[28:59] that's actually really cool because you<br>[29:00] can suddenly allow a scaling that is a<br>[29:03] bit more natural and more pleasing to<br>[29:05] the people without completely breaking<br>[29:07] your UI. Yeah, I'm I think we should set<br>[29:10] ourselves a challenge to do a demo for<br>[29:12] that at some point. I think it would be<br>[29:14] really fun and it would be really cool<br>[29:16] to be able to apply that to something<br>[29:18] that we've built so that it it works<br>[29:21] that well. I think that's a nice thing<br>[29:23] to be able to aspire towards. Oh, uh,<br>[29:26] while I'm at it, I just thought I'd give<br>[29:27] you all a little preview of what is<br>[29:29] coming up in the next release because it<br>[29:32] is a very tokens focused release. So, if<br>[29:35] I jump into uh here, excuse the white.<br>[29:39] I've switched it to light mode so I<br>[29:41] don't get muddled up between the early<br>[29:43] release and not uh but one of the things<br>[29:45] that um you'll notice in this new<br>[29:47] release is that tokens are now uh<br>[29:50] grouped. So, not sets, I'm talking about<br>[29:53] the tokens themselves. And these are now<br>[29:55] split. So, you see these are my scales.<br>[29:58] This the same token set I had before.<br>[30:00] So, this is my scale dot excss. And any<br>[30:03] token that is dot separated like this<br>[30:06] will then be split into a hierarchy<br>[30:08] according to the dots. So this is really<br>[30:11] useful if you're say working with quite<br>[30:14] a lot of tokens in a set like a color<br>[30:17] token and you want to make sure that<br>[30:19] you're applying the correct token. And<br>[30:21] so you can see that this is broken down<br>[30:24] say my default icon token into this uh<br>[30:29] so the name of it would be color icon<br>[30:31] default. So, it's the default inside the<br>[30:33] icon folder, inside the color uh folder.<br>[30:37] So, that's a really just makes it easier<br>[30:39] to navigate your tokens. It doesn't<br>[30:41] change how anything behaves. It just<br>[30:42] makes it easier for you to navigate. And<br>[30:45] another really cool thing that we have<br>[30:47] is remapping when you rename. So, if I<br>[30:50] go to, I don't know, let's go something<br>[30:53] that I use loads, one of the scale<br>[30:55] tokens, 3xs. If I decided I wanted to<br>[30:59] rename this for whatever reason to uh<br>[31:03] instead of 3xs x xxxs<br>[31:07] and I go to save. Previously if I did<br>[31:10] that it would be it wouldn't it would<br>[31:13] warn me that if I change the name of the<br>[31:15] token it would break all its references.<br>[31:17] Now it gives me the option to remap<br>[31:20] those tokens. So, it will update all of<br>[31:23] the references and all of the objects<br>[31:25] that are using that token so that they<br>[31:27] are using the new token name. So, it<br>[31:30] could take a while. I'm not going to do<br>[31:31] that right now, but that's just to give<br>[31:34] you an idea of what's coming up in the<br>[31:37] next release. Um, I don't know. What do<br>[31:40] you think about the sca the names of my<br>[31:42] scale? Because I noticed that in some of<br>[31:44] the examples you've shown, the t-shirt<br>[31:47] sizes, doing the<br>[31:49] 3XS or the 3XL and those sizes, it's not<br>[31:54] for everyone, is it?<br>[31:55] >> No, it's definitely not for everybody,<br>[31:57] but I I I think it works really well<br>[32:00] scoped on a specific typography. So,<br>[32:03] >> for example, um what I love to do is<br>[32:06] break typography down into different um<br>[32:09] groups like headlines. display fonts,<br>[32:13] body code, kind of like these things.<br>[32:16] Um, maybe one additional information,<br>[32:18] never name your tokens semantically, H1,<br>[32:22] H2, or headline one, two, three.<br>[32:24] >> Mhm.<br>[32:25] >> Because even with the most experienced<br>[32:28] developers, kind of like I've seen this,<br>[32:30] they suddenly start using an H1 tag in<br>[32:32] code because you used an H1 style. So,<br>[32:34] you're mixing semantic meaning with<br>[32:36] visual appearance. And we always have<br>[32:38] this, right? we have an an H2<br>[32:40] semantically that is visually an H1 kind<br>[32:43] of like<br>[32:44] >> and like so we we actually need to<br>[32:46] abstract into a naming format that is<br>[32:49] loosened up from the semantic meaning<br>[32:50] kind of like<br>[32:51] >> and that's really important kind of like<br>[32:54] >> um what I normally do is kind of like I<br>[32:56] have a factorization scale of my<br>[32:57] topography so recently I tend to write<br>[33:01] it up kind of like 1 2 3 4 5 and down 1<br>[33:04] 3 4 5<br>[33:06] >> Before I was using F with f minus and f<br>[33:09] without a minus. But actually I got some<br>[33:12] really good feedback that this is not<br>[33:14] really cool because suddenly you have<br>[33:15] semantic grouping in there because a<br>[33:18] >> dash is actually a separator in CSS. So<br>[33:22] you don't know what it actually means<br>[33:23] and introducing<br>[33:25] sub values is not really easy to do kind<br>[33:28] of like I use this scale kind of the up<br>[33:30] and down scale as the core and then I<br>[33:32] reference them in my t-shirt sizes which<br>[33:34] are more semantically grouped.<br>[33:37] Oh, that's good. So, I I should ditch<br>[33:39] these heading level one, two, three,<br>[33:41] four, five, and six. And uh yeah, make<br>[33:44] them something that is more of a an<br>[33:48] actual scale and then we can use those<br>[33:50] accordingly. That makes sense.<br>[33:52] >> Yeah. I mean, you already have display,<br>[33:54] right? You have display code, you have<br>[33:56] good groups kind of like,<br>[33:57] >> but what is the the differentiation<br>[33:59] between a display font and a heading?<br>[34:01] And do we really need six levels of<br>[34:03] heading? Mhm.<br>[34:04] >> Because semantically we sometimes have<br>[34:06] headlines which are more page separators<br>[34:09] and then we have titles which are more<br>[34:10] like on a card on you know on an object<br>[34:13] kind of like um that we use there kind<br>[34:15] of like and I think that's good. And<br>[34:17] then you can actually use t-shirt sizes<br>[34:18] where the default title is medium and<br>[34:20] then you have a large and a small one.<br>[34:22] >> Yeah, I like that.<br>[34:24] >> Yeah. Someone once said to me they they<br>[34:25] thought I shouldn't use t-shirt sizes<br>[34:27] because um it means that you can't<br>[34:30] insert any half sizes or anything in<br>[34:32] there in between them. But I was like<br>[34:34] that's surely the point the point of<br>[34:36] creating a hierarchal scale is that you<br>[34:39] don't insert random numbers in between.<br>[34:42] >> Exactly. Um so the moment you actually<br>[34:45] have like for example I've seen this a<br>[34:47] lot where tokens are suddenly having a<br>[34:50] name like 16 for 16 pixels<br>[34:53] >> there is absolutely zero use for that<br>[34:55] token.<br>[34:55] >> Yeah.<br>[34:56] >> Because you don't abstract a hard value<br>[34:58] to a semantic meaning. And the moment<br>[35:00] you add a break point for example 16 is<br>[35:01] not 16. Maybe 16 is 19 20.<br>[35:04] >> So like never use a pixel value or RAM<br>[35:07] value or something as the identifier if<br>[35:09] you're not able to scale it. Um yeah,<br>[35:11] when you use RAM for example, I love to<br>[35:13] go with a 100 scale.<br>[35:15] >> So one RAM is 100%.<br>[35:17] >> And then you go<br>[35:19] >> 1.5 RAM is 150 because then you actually<br>[35:22] abstracted it into a layer and it<br>[35:24] doesn't need to always stay at that RAM<br>[35:25] value, but you have your mental model of<br>[35:27] like hey on mobile that actually is the<br>[35:29] scale. It might be different on a<br>[35:30] different platform, but like the scaling<br>[35:32] behavior is still a percentage based<br>[35:34] scaling behavior.<br>[35:35] >> Yeah, I think if you're someone that's<br>[35:37] used to working in rims already and you<br>[35:39] can kind of visualize what that REM size<br>[35:41] is, that's really helpful, too. I think<br>[35:42] that is<br>[35:43] >> a part of using things in that way. Um,<br>[35:46] right, I'm conscious of time because we<br>[35:47] got so many cool other things to show.<br>[35:49] So, uh, why don't we move on to talking<br>[35:53] about practical design token color<br>[35:55] palettes?<br>[35:57] >> Awesome.<br>[36:06] Now, one thing that I realized that I<br>[36:08] hadn't actually shown anyone in a<br>[36:10] previous hands-on, and I was like, I<br>[36:11] better squeeze this into the color<br>[36:13] section here, is that you can now apply<br>[36:17] tokens um for colors using the design<br>[36:20] panel. So, say I've got this little<br>[36:22] button here, and maybe I want to add a<br>[36:25] new fill color to it. If I go to the<br>[36:27] color picker, I have this little icon<br>[36:30] for tokens. And if I click it, I have<br>[36:33] all of my tokens here. And what's really<br>[36:36] handy is that I can filter them um<br>[36:39] through search. So I can put in button<br>[36:41] and then I can find the right button<br>[36:43] token that I want to choose. This also<br>[36:46] works if I select this button and then<br>[36:51] it's showing me the token that's applied<br>[36:53] to the button as a fill. Right now I can<br>[36:55] open the tokens list from the token icon<br>[36:58] and choose from there. So I it only is<br>[37:02] showing me color tokens which is the<br>[37:04] only thing I can apply to a fill. So I<br>[37:06] think that's just really handy. Now I<br>[37:10] wanted to this is some real deep nerdy<br>[37:12] that I got into. So buckle up. Let me<br>[37:16] get into the system library.<br>[37:19] So I always click my token set. I should<br>[37:23] start naming my pages something<br>[37:25] different from my token sets to prevent<br>[37:27] me getting confused. Okay, I've got some<br>[37:29] color palettes in here. Great. And this<br>[37:35] I've got a little reference for my hues.<br>[37:36] This is just to show me what all of<br>[37:38] these different palettes are, but um<br>[37:42] I've got these colors um that I've<br>[37:45] generated this these palettes from. So,<br>[37:49] let's open up. We'll do like we did<br>[37:51] before. Oh, I'm going to break down a<br>[37:52] more exciting blue. There we go. Not one<br>[37:55] that's white. So, I'm using functions<br>[37:57] again. Um, actually, am I using No, I'm<br>[38:01] using references. I'm not using<br>[38:02] functions at all. It looks like a<br>[38:04] function because it's uh using the color<br>[38:08] space of hue, saturation, lightness, and<br>[38:13] alpha. Uh, so HSL or HSL<br>[38:17] A. And so what uh if you look inside the<br>[38:21] color picker<br>[38:24] and<br>[38:25] you can see from if I go to the tab<br>[38:29] there we go. Uh this is calling HSV but<br>[38:32] value and lightness they're the same<br>[38:34] thing. And so this is breaking down my<br>[38:36] colors into the hue channel, the<br>[38:38] saturation channel and the value or the<br>[38:41] lightness channel and also the alpha<br>[38:43] channel. Uh how much opacity it is. And<br>[38:46] I'm generating all of these values<br>[38:49] separately and pulling them together<br>[38:51] into the design token. And we thought<br>[38:55] this might be a good opportunity for<br>[38:57] Marco because he has a much uh bigger<br>[38:59] brain than me and understands these<br>[39:01] things really well to explain a little<br>[39:03] bit more about these different color<br>[39:05] spaces that we might be using. Uh, so<br>[39:07] HSL, uh, I guess RGB, um, OKLCH, uh, is<br>[39:12] a pretty hot one of late. Uh, so yeah,<br>[39:17] what's what should folks know about<br>[39:19] these color spaces and the differences<br>[39:21] between them?<br>[39:22] >> So I think like one of the the<br>[39:24] interesting pieces about color spaces is<br>[39:25] you always need to think about it as a<br>[39:27] threedimensional model. And let me show<br>[39:29] there's like an amazing page that<br>[39:30] actually like visualizes that and it's<br>[39:32] called Hublot.<br>[39:34] And if you look at sRGB, right, the the<br>[39:36] one that most of us work with kind of<br>[39:38] like it actually is a cube and it's the<br>[39:40] one that<br>[39:42] you have such a hard time to<br>[39:43] understanding, right? And the hex value<br>[39:45] is just an sRGB representation in hex,<br>[39:48] it's nothing else. But how do you make<br>[39:50] up a mixture of red and blue and like<br>[39:52] yeah, okay, it's in the middle, but like<br>[39:53] if it moves to the center of the cube<br>[39:55] kind of like where is it? And in reality<br>[39:57] like the three layers you just showed in<br>[39:59] HSV or L kind of like they are just<br>[40:02] coordinates in X Y and set on a<br>[40:05] threedimensional space. So if we<br>[40:07] actually move over to HSV it's a<br>[40:09] cylindrical format. So it's a lot easier<br>[40:11] to understand kind of like um it's<br>[40:13] really cool. So if we actually go to the<br>[40:15] grid view you can see right it's this<br>[40:18] three dimensional model we're moving in.<br>[40:19] So, we're moving in the rotation for the<br>[40:22] hue kind of like and we're moving up and<br>[40:24] down for um the lightness. So, on the<br>[40:27] bottom there's a black. Let me make it<br>[40:29] again. On the bottom it's black. On the<br>[40:31] top it's white. And if we move out we<br>[40:34] actually saturate saturated. You<br>[40:36] mentioned okay uh LCH. Um why it's so<br>[40:39] famous at the moment is because you get<br>[40:41] a quite nice gradient output and a<br>[40:45] really balanced um scale kind of from<br>[40:47] it.<br>[40:48] >> Yeah. But it's actually very tricky to<br>[40:50] work with if you don't understand how it<br>[40:51] looks like or what the limitations are<br>[40:54] because OKCH is actually not a uniform<br>[40:56] color space. It looks like this has<br>[40:58] >> an ice cream.<br>[41:01] >> So if you don't understand the<br>[41:02] limitations of hey there's actually a<br>[41:04] pretty steep peak here in green and blue<br>[41:06] and pink and red but like oh damn what<br>[41:09] is that valley here right? Like you're<br>[41:10] not getting somewhere that you want and<br>[41:12] like you can see that cut off here like<br>[41:14] that is not fun.<br>[41:17] So, if you're trying to generate<br>[41:19] palettes where you every every time you<br>[41:22] switch your hue or your color, you want<br>[41:25] your blue and your red values to be kind<br>[41:27] of the same level of darkness and<br>[41:30] saturation. And that's the premise of<br>[41:33] OKCH, unless you get caught up on one of<br>[41:36] these cliffs.<br>[41:37] >> Yeah. So, what happens, right, if you<br>[41:39] like it goes actually up to 0.37 kind of<br>[41:42] 37% of the full height. But if we set<br>[41:45] the saturation to 0.7 37, it will just<br>[41:48] clip it and go here.<br>[41:49] >> In some other tools, it actually like<br>[41:51] finds a different line. So there's<br>[41:52] actually like some different<br>[41:54] implementations of how it actually<br>[41:55] works. So that's something you need to<br>[41:57] really watch out with.<br>[41:58] >> But if you have two colors in a<br>[42:00] different hue and the same saturation<br>[42:01] kind of like and lightness, they<br>[42:03] actually look really uniform kind of<br>[42:05] like next to each other. That's the<br>[42:07] really nice thing.<br>[42:09] >> And you just showed off that you<br>[42:11] actually do math in the different<br>[42:12] channels, right?<br>[42:13] >> Yes. And maybe to explain this shortly<br>[42:15] before we go into that in depth kind of<br>[42:17] like just want to open up Poland here um<br>[42:20] by David and and that is also like um it<br>[42:23] just shows us kind of like a we're<br>[42:25] building a gradient of colors a pallet<br>[42:28] whatever you want to call it right<br>[42:29] >> um and the cool thing is if we scroll<br>[42:31] down he actually explains a lot of<br>[42:33] things here of how things move kind of<br>[42:35] like so it's an amazing page if you want<br>[42:37] to learn more<br>[42:39] >> but what he does here is kind of like it<br>[42:40] defines what that curve actually looks<br>[42:42] like Unfortunately, it's not a 3D<br>[42:43] representation, but what we define is<br>[42:45] kind of like we define an curve or like<br>[42:48] not a curve. So, we can actually go to<br>[42:49] linear<br>[42:50] >> and linear and suddenly we have a<br>[42:52] straight line.<br>[42:53] >> But what we can do with sinus or quadric<br>[42:57] or arc positions, we can actually bend<br>[43:00] that curve how it moves through this 3D<br>[43:02] space. And then what we do is we sample<br>[43:04] points on that curve. So, if I move that<br>[43:07] over here to the green, suddenly I'm<br>[43:09] sampling a curve here in that. And let's<br>[43:11] say we actually go with cubic to make it<br>[43:13] a bit more round kind of like or go<br>[43:15] there or let's go with sinus curve then<br>[43:18] it goes like upwards asinus. This one's<br>[43:21] the right one. Um so you can really<br>[43:23] easily like change how that works. Um if<br>[43:25] I change the saturation curve<br>[43:27] unfortunately it doesn't have like an<br>[43:29] impact because we are limited in that<br>[43:31] space.<br>[43:32] That is but that is that might be a good<br>[43:35] use case for it is for example one of<br>[43:38] the things I like to do is as I go into<br>[43:39] the darker colors in a scale I do like<br>[43:42] to bump up the saturation and maybe make<br>[43:45] the hue slightly warmer. So that's where<br>[43:48] these kind of curves can be really<br>[43:49] valuable in creating much more nuanced<br>[43:51] pallets as well.<br>[43:53] >> Yeah, exactly. But at the end you are<br>[43:56] doing something very similar right on<br>[43:58] each channel of<br>[43:59] >> Yeah. Let me show you how I've made up<br>[44:02] these this different token. So, I have a<br>[44:06] blue hue and what that's made up of,<br>[44:10] it's actually a number and that's just a<br>[44:13] random number between. So, if we're<br>[44:15] looking at HSL, it's a number between uh<br>[44:18] 0 and 360. It's that full circle. And<br>[44:22] I've actually put made myself a little<br>[44:23] reference here so that I could remember<br>[44:25] what Q roughly maps to which value. And<br>[44:28] so I'm using 203 there. And then I have<br>[44:34] say in the saturation. So I have a<br>[44:37] different saturation point for whether I<br>[44:39] want a default palette or a color<br>[44:42] palette because obviously these are very<br>[44:44] saturated colors. These very desaturated<br>[44:46] colors. And so that again is just a<br>[44:49] value. And so so the default one oh<br>[44:54] references desaturated. There we go. So<br>[44:56] that's just five. And if I wanted to go<br>[45:00] for the colored one, which references<br>[45:02] the bright token, there we go. I need<br>[45:06] grouping. And that's 80. So the<br>[45:08] difference between 180 is pretty big in<br>[45:11] there. And so I've used that to generate<br>[45:15] all of these palettes because they're<br>[45:18] just made up of combining. If I go to a<br>[45:21] different color, say the green, the hue<br>[45:23] for green, but it keeps the same<br>[45:26] saturation level as the other palettes.<br>[45:28] It keeps the same the lightness gets<br>[45:30] stepped depending on which swatch we<br>[45:32] are. And I have kept in there the option<br>[45:35] to add an alpha channel even though I<br>[45:38] I'm not using it currently in here. And<br>[45:42] what that does enable is a very cool<br>[45:46] little demo that I made. uh it's a<br>[45:48] little bit hacky, but a random color<br>[45:51] generator. And so if I switch between uh<br>[45:55] these little options here, it generates<br>[45:57] a completely random hue and pallet based<br>[46:01] on that. And how I'm doing that is doing<br>[46:05] exactly that same thing of creating<br>[46:06] these stepped values, but I'm using<br>[46:10] again a function.<br>[46:13] And that's the random function. So, I'm<br>[46:15] just saying pick me a random number<br>[46:17] between uh 1 and 255. It actually should<br>[46:20] be 360<br>[46:22] thinking about it. And then round that<br>[46:25] to a whole number. Uh although I think<br>[46:27] it could cope regardless.<br>[46:30] So, that's just a silly little uh just<br>[46:32] because I could situation.<br>[46:36] >> Yeah. But like what I love here is<br>[46:37] actually like if you build a white label<br>[46:39] solution, that's exactly what you need<br>[46:41] to validate against, right? you need<br>[46:43] randomization like in the colors and so<br>[46:45] that's like it's really awesome why you<br>[46:47] always need to switch the modes is kind<br>[46:48] of like because they resolve once right<br>[46:50] and that's when you resolve again it<br>[46:52] creates another random number so it's<br>[46:54] nice to also understand hey why do I<br>[46:55] actually like do this switch<br>[46:57] >> yes<br>[46:57] >> and the cool thing is this could be done<br>[46:58] on any front end right you could<br>[47:00] actually have a slider just to move that<br>[47:01] because your token architecture actually<br>[47:03] allows for this full switch because you<br>[47:04] have built it correctly so this could be<br>[47:06] run on any front end or you can build a<br>[47:08] scene builder with it<br>[47:09] >> and you've totally set me up to to show<br>[47:13] you how I've done this here. So, uh, let<br>[47:15] me close these up so I got a bit more<br>[47:17] room. So, I've created I've added these<br>[47:20] different palettes and scales that I've<br>[47:21] got in here. And what I've done is I've<br>[47:24] used them for my different brands and my<br>[47:26] light mode and my dark mode. And so I<br>[47:30] can switch between dark mode and light<br>[47:32] mode. And this changes the value of the<br>[47:35] token picking the different palette<br>[47:37] colors for each value. So if I look at<br>[47:40] this, say button primary background<br>[47:42] default in light mode it references<br>[47:45] primary uh 600 but in dark mode it<br>[47:49] references oh 600 as well. That was a<br>[47:52] bad example. The buttons are the same<br>[47:53] color in light mode and dark mode. But<br>[47:55] also if I wanted to switch between my<br>[47:57] brands. So I want to switch to this Eco<br>[48:00] Tools. It's a green brand. If I want to<br>[48:03] switch between Neon Books, it's this<br>[48:05] purple and pink. And the only difference<br>[48:08] between those brands in these different<br>[48:11] sections is that they've got a hu<br>[48:15] default value set, a hue primary and<br>[48:17] secondary. So that's the default palette<br>[48:19] here, the primary here, secondary here,<br>[48:22] some different font families as you<br>[48:24] might have noticed, uh, and the<br>[48:26] potential for a different stroke width.<br>[48:28] I don't know why I would do that, but I<br>[48:30] added the option in there. And that's<br>[48:33] between these different brands. All<br>[48:34] that's changing is these values, but all<br>[48:37] of the rest of the tokens are remaining<br>[48:40] exactly the same.<br>[48:43] So, while we're on the topic of<br>[48:45] branding, why don't we jump to our final<br>[48:48] section on token structure and<br>[48:52] performance?<br>[49:02] Now, the reason I've jumped to this<br>[49:04] section now is because when I was<br>[49:07] showing Marco this demo before and you<br>[49:10] said, Marco, hey, maybe you don't need<br>[49:12] to have the brands separate. How would<br>[49:15] you structure your tokens more<br>[49:19] effectively than I've done here?<br>[49:21] I think one thing like actually like I<br>[49:23] complimented you first of all for your<br>[49:25] architecture<br>[49:26] start.<br>[49:27] >> I'm making it sound like you were being<br>[49:28] mean to me. You weren't. You were<br>[49:29] helping me learn constructive systemism<br>[49:32] is how we grow<br>[49:33] >> because you actually have a quite well<br>[49:35] structured system which a lot of people<br>[49:37] actually then start in reality to to<br>[49:39] kind of like run into walls when there<br>[49:40] is like brands coming in. Hey, we<br>[49:42] actually want that one component to look<br>[49:44] a bit different than everything else in<br>[49:45] the system.<br>[49:46] >> And that's always the challenge. What I<br>[49:48] outlined is kind of like you currently<br>[49:49] have a foundation layer and then you<br>[49:51] have a brand layer but what is actually<br>[49:54] the shared foundation on a system like<br>[49:56] that a multibrand system that needs to<br>[49:58] live extracted from a brand. So what are<br>[50:00] these values that need to live in a<br>[50:02] foundation that don't belong to the<br>[50:04] brand? So do we need that separation of<br>[50:06] brand and foundation or can actually be<br>[50:09] the one mother brand let's say like this<br>[50:12] and then we just have overrides in the<br>[50:14] other brands kind of like<br>[50:16] >> and that would would maybe like already<br>[50:18] take a bit out the complexity<br>[50:20] unfortunately we have trained ourselves<br>[50:22] into a three layer architecture of<br>[50:24] foundation semant semantic and component<br>[50:27] >> the reality is today we have seming<br>[50:29] available and multi-dimensional seeming<br>[50:31] right so this architecture doesn't hold<br>[50:33] up anymore because what we really want<br>[50:36] is a separation of concerns. We want one<br>[50:39] layer to choose our brand. We want one<br>[50:41] for our color mode, one for our<br>[50:42] breakpoint and then at the end we want<br>[50:44] one clean semantic layer for consumption<br>[50:47] and everything before<br>[50:49] >> we want to own as a design system<br>[50:50] maintainers<br>[50:52] >> that we actually can do changes how we<br>[50:53] want. If we need to introduce a new<br>[50:55] breakpoint, it shouldn't be a breaking<br>[50:56] change for the users. should actually be<br>[50:58] just like easy roll out and that's what<br>[51:02] you already did very well but now<br>[51:05] reality is always a bit challenging when<br>[51:06] it comes to that because reality is not<br>[51:08] the white label perfect system that we<br>[51:11] are looking at here<br>[51:12] >> similar like I mean the easiest piece<br>[51:15] here is really like hey your color your<br>[51:17] button on the top right right in one<br>[51:19] brand it might be a dark navy<br>[51:21] >> in the other one it might be a like<br>[51:23] vibrant yellow<br>[51:25] >> so a lot challenges that actually come<br>[51:28] with that. And that's where kind of like<br>[51:31] the algorithmic approach we looked at<br>[51:33] today really comes in handy. What if we<br>[51:36] have a function that lets me dynamically<br>[51:38] choose the contrasting text color on top<br>[51:40] of that background? Suddenly, I'm<br>[51:42] reducing my token amount by at least 10<br>[51:45] to 20%. Just by removing that kind of<br>[51:49] like specific token for each decision.<br>[51:52] >> Yeah.<br>[51:53] >> Yeah. How would you suggest that<br>[51:54] designers and developers like because<br>[51:57] that's really a collaborative effort<br>[51:59] isn't it creating these like doing<br>[52:01] design in this way like if you're coming<br>[52:03] up with algorithmic curves you're<br>[52:06] working out what can be automated<br>[52:11] >> I don't know immediately if it's a<br>[52:12] collaboration kind of like it's helpful<br>[52:15] because developers tend to think more on<br>[52:17] algorithms than designers designers are<br>[52:19] like sometimes oh damn it's math I'm<br>[52:21] going going to run um don't do<br>[52:23] Yeah,<br>[52:24] >> the important piece is you actually need<br>[52:25] to understand and explain what you want<br>[52:28] to achieve<br>[52:29] >> because then you normally can put it<br>[52:30] into something that is repeatable and<br>[52:32] makes your decision tree kind of<br>[52:33] reworkable.<br>[52:35] >> You actually like it's not there but<br>[52:37] like like we will share this soon kind<br>[52:39] of like right there will be more<br>[52:41] functions and there will be more complex<br>[52:42] functions. There will be functions that<br>[52:44] really help you do things kind of like<br>[52:45] you just showed off the the minimal math<br>[52:47] functions. Yeah,<br>[52:49] >> but there's a ton more that we can use<br>[52:51] algorithmically on the tokens kind of<br>[52:52] like to really get super structured<br>[52:56] output. And the cool thing is everything<br>[52:58] works natively in penput.<br>[53:00] >> Yeah.<br>[53:00] >> So you can use these functions natively<br>[53:03] and you don't need to build architecture<br>[53:07] around kind of like decisions that can't<br>[53:09] be done.<br>[53:10] >> Yeah. Yeah.<br>[53:10] >> And in code it just flattens down or we<br>[53:12] can actually like even transpile it into<br>[53:14] the right format<br>[53:16] >> because what you showed off in math like<br>[53:18] in your token that is a onetoone<br>[53:21] translation into CSS and it just works.<br>[53:23] >> Yeah.<br>[53:24] >> Yeah.<br>[53:24] >> So that's the cool things. These<br>[53:26] functions suddenly reduce the package<br>[53:28] size the complexity of our system and<br>[53:31] they make it more maintainable and<br>[53:32] easier to understand<br>[53:34] >> down the road.<br>[53:34] >> Yeah. And you can and<br>[53:38] >> while these functions might seem quite<br>[53:39] intimidating at first, what I did was I<br>[53:42] went and looked some up and then I just<br>[53:44] played with what penot<br>[53:50] is you can play with it and see what<br>[53:52] works and see what doesn't and instantly<br>[53:55] get that visual feedback that you can't<br>[53:56] necessarily get so easily if you're<br>[53:58] having to learn how to write it in code<br>[54:00] first as well. Uh, not that I'm scared<br>[54:02] of code, but I think a lot of people<br>[54:04] it's it is intimidating. You don't want<br>[54:06] to have to necessarily learn someone<br>[54:08] else's skill set in order to be able to<br>[54:10] play with these things. Now, I'm<br>[54:12] conscious of time, so should we jump<br>[54:14] into the Q&A? You got something else you<br>[54:15] want to say, Marco?<br>[54:17] >> Yeah,<br>[54:17] >> let's do it.<br>[54:18] >> Great. Do we have any questions, folks?<br>[54:26] >> Right. Oh, uh, hang on. I need to sort<br>[54:28] out my interface so I actually see what<br>[54:29] I'm reading. There we go. Is there a<br>[54:32] best practice for naming tokens so it's<br>[54:35] clear which ones are source/base tokens<br>[54:38] and which ones are semantic/alias<br>[54:41] tokens? I'll ask you that one, Marco,<br>[54:43] because you've got an insight into a lot<br>[54:44] of different customers setups as well.<br>[54:48] >> That's true. Um, so scoping by name is<br>[54:51] the first thing, right? kind of like add<br>[54:53] the starting segment foundation color<br>[54:56] dot something kind of like<br>[54:58] >> um what I tend to do is I only scope<br>[55:01] everything outside of semantic. The<br>[55:03] semantic layer is something that I<br>[55:05] actually consume. I want them short. I<br>[55:07] want them recognizable. A semantic token<br>[55:10] will not start with foundation. It will<br>[55:11] not start with kind of like color mode.<br>[55:13] It will not start with brand at the<br>[55:14] beginning kind of like they will be<br>[55:16] clean kind of tokens. So I try to make<br>[55:18] it easier for the consumption because if<br>[55:20] somebody always needs to write semantic<br>[55:21] something in code they're getting<br>[55:23] annoyed because you need to write that<br>[55:25] long string or even if it's just s or s<br>[55:27] or something you don't need it because<br>[55:29] the consuming layer is exported<br>[55:32] everything above nobody touches by hand<br>[55:34] so we can make them a bit longer we<br>[55:36] maintain them yes okay we have some more<br>[55:38] work<br>[55:39] >> but it's also really cool when you link<br>[55:40] tokens the auto suggestion I immediately<br>[55:43] like hey I actually need a token from my<br>[55:45] color mode so I write color mode and it<br>[55:47] just already scopes it down to what I<br>[55:49] want. So I think that's kind of like<br>[55:50] what I normally suggest is every<br>[55:54] differentiation of a tier, right? Not<br>[55:57] it's always tricky with using dimension.<br>[56:00] Every tier you have brand, breakpoint,<br>[56:03] color mode, density, I name them at the<br>[56:07] beginning with a prefix and the semantic<br>[56:09] I don't name. Components also have a<br>[56:12] starting slug.<br>[56:13] >> Great. Um, do we have any other<br>[56:16] questions?<br>[56:18] Oh, I can see here in the chat.<br>[56:22] Where's the best place to go for seeing<br>[56:24] the latest updates from Token Studio?<br>[56:26] There was some really cool stuff they<br>[56:27] demoed at Penotfest. Excited to see new<br>[56:30] things roll out.<br>[56:32] >> I would say one to two weeks in the<br>[56:34] future maybe or like three. I think<br>[56:36] that's a good point to go. Uh, we have<br>[56:39] something really cool cooking up kind of<br>[56:40] like we're preparing a lot of stuff.<br>[56:42] there is really like some nice stuff<br>[56:43] coming kind of like that that shows off<br>[56:44] a lot more what we talked about today.<br>[56:46] So I think that was a bit of the teaser<br>[56:48] of what really kind of like will be<br>[56:50] there down down the road kind of like.<br>[56:52] So yeah.<br>[56:53] >> Nice. Um is there any reference for all<br>[56:56] the calculations that we can do? Uh is<br>[56:59] that same as CSS? Is it going further<br>[57:01] than that? To my knowledge it's not<br>[57:04] exactly the same as CSS. I think it's<br>[57:06] actually some JavaScript uh expressions.<br>[57:10] I think um<br>[57:12] >> there there's a lot of custom functions<br>[57:14] kind of like and there will be more<br>[57:15] coming. It's not yet documented<br>[57:16] officially, but once that's released<br>[57:18] kind of like you will have a quite nice<br>[57:20] list of things you can work with.<br>[57:22] >> I know that the PMPOT team is keen to<br>[57:25] have everything really well documented.<br>[57:27] So, I'm sure that will be there very<br>[57:29] soon. And trust me, when it's there, I<br>[57:31] will be shouting about it. So, we'll all<br>[57:33] be able to mess around with functions<br>[57:36] loads. Right. Well, I guess we're pretty<br>[57:40] much up for time. So, is there anything<br>[57:41] else that you wanted to share, Marco,<br>[57:44] before we leave?<br>[57:46] >> Um, well, we already said, right, like<br>[57:47] there's something really cool cooking.<br>[57:49] Um, we have been<br>[57:51] >> not too loud about stuff kind of like we<br>[57:54] have been heads down working like crazy,<br>[57:56] but yeah, like there's something really<br>[57:58] cool coming. I don't want to spoil too<br>[57:59] much. Um, but we there Yeah, you will be<br>[58:02] excited.<br>[58:03] >> Let's go like that.<br>[58:04] >> Yeah, there's so much potential that we<br>[58:07] have with tokens. So remember folks to<br>[58:10] follow and subscribe to be the first to<br>[58:12] find out about our future hands-on<br>[58:14] demos. We're already planning our next<br>[58:16] one. Or join the penot community as<br>[58:19] well. That's a great place to find out<br>[58:20] about everything penot first. And<br>[58:22] remember if you want to join the beta<br>[58:25] testing team for the penmp mcp server.<br>[58:28] Follow the link in the chat. It will<br>[58:29] also be in the description for this<br>[58:31] video if you're watching back later.<br>[58:33] Thank you Marco for joining me. This was<br>[58:35] really fun. Um, this was as good as<br>[58:38] nerding out over drinks after Penamp<br>[58:40] Fest about all things tokens and design<br>[58:43] systems.<br>[58:44] >> We also need that.<br>[58:46] >> Yeah. And thank you to everyone who<br>[58:48] joined us live. It's been so lovely to<br>[58:50] actually see you in the chat this week<br>[58:52] now that I can get it up on my screen<br>[58:53] and it's on your screens, too. So, I'm<br>[58:57] excited to see what we can do with this<br>[58:59] in the future. And thank you so much,<br>[59:01] everyone, for joining us. We will see<br>[59:02] you again very soon. Goodbye.<br>[59:04] >> Thank you for having me. Bye-bye. <!-- deep-read:sections end -->