Andrew: Hello! Welcome to the dev tools, FM podcast. This is a podcast about developer tools and the people who make them I'm Andrew and this is my co-host Justin.
Justin: Hey, everyone.
Introductions [00:00:34]
Andrew: We're going to be talking to people who work in a part of the stack, you might not have that much experience in. When building a design system for multiple platforms. It becomes super apparent that a solution to store the base values is needed. And it's a harder problem than you might think. What'd you guys like to introduce yourselves?
Kelly: I'm Kelly Harrop and I am a senior UX engineer at Intuit and I work on our core design system team. Managing our design data as for my day to day. And I also help designers and developers generate artifacts and help teams collaborate together.
Danny: cool. And I'm Danny banks, I'm a design technologist at Amazon. Currently I am in the third party seller organization at Amazon I'm working on the mobile app that third-party sellers use to sell stuff on Amazon. As part of that, I also created, two open source libraries, style dictionary, and sketch constructor. So also maintaining those, I'm about to change jobs, but it's not official yet, so that will be coming out soon in the next couple of weeks. So I'll let you know.
Andrew: Yeah, it seems to be a symptom of quarantine that people like to leave their jobs.
Danny: So I won't be leaving Amazon though. So I'll be staying at Amazon, just changing teams within there.
Design Tecnologists [00:01:50]
Andrew: And so I think something that's interesting about both of the two of you that our other guests haven't shared so far is that you're both design technologist by trade and not computer scientists. How do you end up in a role like that? I've always been interested.
Danny: I've always I like, technically I was hired as a UX designer at amazon, and then I transferred over to being a design technologist just because I was doing a lot of like front end code. um, and actually coding a lot of the stuff that I was designing. So it just always fit. I've always really wanted to be building the things that I was designing and really wanted to like craft the actual things that users were seeing, you know, because users don't see a sketch file or a Figma file. They see HTML and CSS or objective C and Java. So that's really why, like I gravitated toward the design technologist design engineer position.
Kelly: So my background is a little similar to Danny's. I started out in design. And my first full-time job, I I was a designer. And then after I completed my first design task, they were like, so you're going to code this. Right. And I went, Ummm sure. So a lot of late nights Googling things. I did not have a formal background learning any of this.
So lots of YouTube and stack overflow. And seeing a lot of "well actually"s helped me form, I guess, my basis of best practices and learning. I like shame driven development. It's how I learn lots of comments in PRS. And I just I ended up falling in love with front end and building cool stuff and just finding out lots of different ways to do things and figuring, or trying to figure out what, which one is the most acceptable, which changes year to year.
Justin: I have a question about this role. I've worked with some designers in the past who I think would probably be better described as this role of design technologists who were pretty multi-faceted and can do a lot of things. Right. I'm just curious from your sort of day to day work.
And especially as you're getting into broadening from just doing designs to actually building things, have the tools that you've run across, been helpful? Or has it just made it harder because, um, I'll frame this will look a little context, sometimes in one of my previous jobs, I would show really technical people on my design team.
Hey, here's these react components. And you're like, wow, what is even going on here? But they could sit down with the code pin and build out like a, like pixel perfect, fully responsive, like HTML, CSS and even like with some behavioral stuff. But just handcrafted. And so I'm just curious about the state of tooling and how that makes design easier or harder as y'all approach it.
Kelly: So I love Figma and how it is super collaborative. There's less of that handoff period and you don't have to red line anything. There are more plugins and tooling that gets added almost, I feel every week, that lets you actually use coded components inside of these design tools.
And over time I've seen just a lot of different tools that are doing this these days, you know, there's Like Framer X. I think that was like a really good job of this because you're actually pulling in your components. Lots of different tools, especially integrations with storybook have also been really helpful.
And I love the transparency around just making sure everyone can use the same terminology and understand if a design changes. How does that impact development and having that kind of flow, I think has been great. And I think that's the direction that it's less, of a here's everything perfect. And then here go coded and it's more of a joint effort so that it's not as, you know, hopefully it's not as destructive to change things as you iterate and try things out.
Danny: Yeah, I think like we're going in a really good direction as an industry. I think for me, what's really interesting to see and what's really promising to see is getting. developer tools, more designer friendly versus the other way around. So like more kind of like storybook things. was it the like playroom where you can like graphically build with react components, like those type of, like tools so that it's rather than, Figma trying to like export something that, the designer and the developer working in the same space, but just different views of it. and it's one of the things that I've been trying to push like in my organization is, getting out of a design tool as quickly as possible. There are Some cases where. A designer can just tell me, Hey, I want a page and it's going to have a Banner and then a text input and a button. And, we don't need a design review. We don't need to create anything in Figma or sketch. We can just start building that and then iterating on the actual like production code components. and so getting to like getting to code as fast as possible, and rather than, I think Gina said it, like instead of bridging the gap, just removing the gap, between design and development. So like those types of, like integrations and tools I think are really exciting. I think that's the, a good future for, designer, developer interfacing and stuff like that.
Andrew: Yeah I view like your jobs as design technologists.
Like you saw that, Hey, I could be a better designer by designing closer to the platform I'm actually delivering. And a lot of these developer tools are making that same logical jump that like with Figma, what you're designing, you're designing for a web target basically.
So it makes it very easy to translate it from one to two. Whereas if you're like in sketch land things, it's kind of like a crazy Photoshop and it's like, sure, you are kind of designing for web, but it doesn't hold your hand in that way. And it's really exciting to see tool and go that way.
Danny: Yep. Definitely.
style-dictionary: Origins [00:07:59]
Andrew: So that translates pretty well into the next topic. Since you guys were more about designing for your platform, it's almost natural that making your own tools is the next step. After that you, you, already wanted to own more of the stack. What's a tool or two more. What drove you to create style dictionary, or even approach the concept of design tokens.
Danny: Yeah. it's funny back when the mobile application that I was working on at Amazon was first started. it was a very small team, like five or six people, very scrappy even for amazon standards. Yeah. And I just remember, I was designing a lot of stuff. It was before we like componentized our whole like application. And there were just times when, I was designing things, but also playing around in a little bit of the android and iOS code bases. and there were times when I would see like, okay, I just want to change like the font color and. I'd figure out to okay, to do that. I need to change, this objective C file. this other objective C file that's like file this Java file, this Android resource file. I need to do all these changes and lump them into one big pull request
And I was like, this is ridiculous. Why can't we just have something, where we store this information in a single place and have the platforms just consume and use that. And so it's the, the, I guess genesis of style dictionary was really solving that problem. And it was yeah. I started it from solving it for our team, but in a somewhat generic way. So like, I, we had first inner sourced. it, basically we built it, it was available any team at Amazon to use if they wanted to and then as I was evangelizing it within amazon and doing internal. like conferences and stuff like that. my. now co maintainer, basically approached me and said, this would make an awesome open source project. So, let's try to open source it. And, we spent a couple of months and got it out in the public and the rest is history.
Andrew: While you were making it Were they're like any other alternatives that were available at the time. Like why did you choose to make your own in this case?
Danny: Hm. not to my knowledge. it's actually kind of interesting, like theo and style dictionary were both probably being written around the same time. Theo came out like open source before style dictionary did. But like they were both, I would assume being worked on around the same time, like around 2015, 2016. I think we open source style dictionary, like end of 2017. And Theo came out like beginning of 2017 as open source or something, but it was like, roughly around the same time. So there wasn't like, at least to my knowledge, any thing that solved that and it's actually interesting. Like We'd both come up with similar, like paradigms, like transforms and formats, and we even called them both transforms and formats. which is kind of weird and creepy. I don't know how that happened, but it did. so yeah so there wasn't any, really anything that. I think did exactly what I wanted it to do. There were probably S like very specific things of going from one language to another, or doing like a very kind of narrow integration, but I saw it, and the creators of Theo also saw it as more of a generic problem that, wouldn't be solved by just doing one specific integration and it needed to be more flexible to account for swift and objective C and Java and Kotlin and everything else that you know could be imaginable.
Andrew: So that's the main thing style dictionary solves, right? Is producing all of these tokens in a very consumable format. how did you arrive at those implementations? Because as you said yourself, you're a design technologist, not a, computer scientist by trade. So knowing the right way to format your tokens for iOS versus Android, that's a lot of like platform specific knowledge. How did you arrive at that knowledge?
Danny: I would say I skirted that issue because I built it in a way, knowing that I wouldn't be an iOS expert or an android expert, or even a web expert. and building style dictionary in a way where a consumer user of it can define how they want to transform inform at the tokens for their application, they will know, My android application looks like this. And so I need my tokens to be consumed in this way. And my iOS application looks like this. it needs to be consumed in this way." so while style dictionary has built in, we have a couple here, here's an objective c. static singleton class format and here's, a swift. but the intention was always that, the teams using it would define their own formats for how they want it to consume it because, a again, I'm not an iOS expert or an Android expert and B, even if I was like my version of, the best way to consume design tokens in an iOS environment is not necessarily the only way. And we didn't want to like prescribe, this is how tokens should work on iOS. so we really wanted to build it as like more of a platform. That was meant to be extended, and customized versus a highly opinionated, this is how the integration works type deal, which I think is it's a double double-edged sword in that it. opens up a lot of applications to use it, but it is more difficult to get onboarded than something that's like, this is exactly how you define your colors. And this is how you can them on iOS, because there's no like canonical way necessarily to do that with style dictionary.
Andrew: What is your experience with that been? Has style dictionary been flexible enough to meet design system needs?
Danny: one of the things that, we really tried build into it and when of people ask me like, oh, how would I, how would you do this thing? and I always of stay, let's work backwards from what you want to be at, like what you want, the code to look like. Do you want, some CSS, custom properties? Do you want some, CSS helper classes? Do you want a JavaScript object? let's work backwards from there and then we can create from that, a lot of people will of ask me, am I doing something like, am I doing this right? Is my setup right? And generally they'll say there's no right or wrong way. if it works for you, then it's the right way. And I've learned a lot of things from just talking to kelly's team. there's a lot of stuff that I didn't know you could do with style dictionary that actually Kelly's team taught me. and other teams that I've met as well. And so it's been really interesting to see all of the different ways that you can integrate and build cool stuff on top of it. because there's a lot of stuff that like, I'm learning from other people about how to do. Yeah, cool stuff with style dictionary. And actually my team's kind of implementation of it for our application is very simplistic in comparison to like, Intuit and other companies that used style dictionary that have these, crazy setups that do all this cool stuff. Our setup is very simple and sad in comparison.
Andrew: Yeah, I helped contribute to Intuit's usage of style dictionary, and we definitely have some code going on there, like, or we're generating CJs ESM types. Like we're doing it all. That was quite a fun task to get working right.
Justin: A, somewhat of a related question on that notion of Bringing it closer to where developers are. One of the challenges that a lot of organizations have when building design systems and speccing out things like design tokens is that you ultimately need product engineers on product teams to be implementing these new product interfaces. Because if they're not, it doesn't really help you a whole lot.
So maybe it's a two-part one has this tooling helped with adoption? Do you have any clear signs of that And two have either of y'all had to explore actually getting some sort of like measurement or metric about adoption of this tooling. Does it like make that any easier?
Danny: I think it has made kind of adoption of using design tokens. I think easier. It was a journey to get there and, know, like what I did with my. internal team is I like kickstart that process. And like when of first built stuff like sharing first built our tokens, I did of the initial, okay, I'm just going to do a find and replace this hex value to this token and this other hax value to this token in this size, to this token. and then getting that initial piece in the whole application wasn't on design tokens, in one big commit, but getting it in there allowed of developers to of start seeing, " oh, like we're using, this, it's my objective C we're actually using macros, which is probably like really gross and weird, but it works." and so once like developers start seeing like, "oh, for, know, this color, I just have this, know, objective C macro. And for this size, I have this other macro." And now when I'm looking at pull requests, I'm seeing a developer using those things. And being able of see that adoption, just of through, I guess, osmosis of learning, know, I don't need to define like this hex value or this size when I'm designing my component or my interface. For it. The second part of the question, like in terms of having metrics for, the adoption or kind of when tokens are being used. that's not something we've explored yet. we are like, our team is actually going to be going through a rebrand this year. So we'll actually have a good kind of metric slash stress test of: are we using tokens to know, the to the best extent because when we do this, refresh if there are certain things that aren't using the tokens, then we'll need to make them use the tokens, or else they'll fall out of sync.
Justin: All right. So before we get too much further into it, why don't we take a step back a little bit and just talk about what a design token is and why someone who's interested in dev tools might care.
Danny: I like to think of a design token and kind of two ways. There's design tokens as like a methodology and design tokens as an implementation. So you could be using design tokens without using. signed token framework, like style dictionary or Theo. You could just be using CSS, custom properties or SAS variables, or Android resources. And, as a methodology, it's about systematizing your design decisions. So that rather than thinking about each, styling each component. in isolation, you're thinking about the whole system and creating relationships between colors and sizes and icons and fonts, so that, when you want to, support dark mode, or when you want to change your branding or enable multiple themes, you can make these changes in a way that makes sense. And it's reflective in the system.
And so you can do that without using a framework or. doing anything kind of cross-platform or multi-platform, and then signed tokens as an implementation is really that like multi-platform piece, it's getting those design decisions in a platform agnostic format so that you can then kind of output them to each platform in language and use them in your applications. Across different platforms and languages. However you want to consume them. and design tokens generally are thought of as colors, font, sizes, paddings borders. but really they could be a lot more than that. They could be SVGs that use that reference design tokens within them. They could be UI strengths with localization that could be binary files, like font files, shadows, animation, basically anything that you could think of to, use or style in your design system could probably be a design token.
Kelly: yeah. to add onto that. I love that design tokens offer a way to provide constraints. so you don't have to guess what's available. They just come naturally out of the box. and. One of my favorite applications is using utility CSS. And I just, I, I love tailwind I love having a preset defined lists of things that I can reference.
I don't have to think about it. It's already established. And I can use either, semantic tokens that described the relationship. And that's something vague that I think a lot of companies and teams really need to put more focus and establish what those are, because, anyone can just say, "all right, I want this thing to be blue." But what does blue mean in your system?
When should we use out versus when shouldn't we use that and you see a lot of products these days and you see UI elements and you're going, "why is that one? Purple. And why is that green and why is that blue?" And if you don't have that structure in place, if you're not taking the time to assign the meaning behind your design tokens, you just run into the wild wests of these applications. And that's actually something that our team currently is looking at is how do we map those things more strategically so that an end user, they don't even have to think about it. They know the usage, they assign the usage and then all of the colors and the topography and the spacing that comes for free.
And then that lets teams accelerate their work a lot more and work more efficiently.
Andrew: Yeah. You might not know it when you start out, but having a set of sizes really helps accelerate you. Like just coming up with, oh, what's a four spacing for us? That takes time. And then the amount of times that you repeat that little bit of code throughout your code base is going to make design refreshes, a nightmare.
What's using it been like? [00:21:39]
Kelly in your mind has having design tokens as a first-class citizen in the design system helped with updating designs with keeping Intuit's products, looking fresh?
Kelly: Yeah it's nice to have it all centralized in one place. One thing that is not fixed by design tokens, because a lot of people just assume, "oh, you're using design tokens. Everything's easy." The implementation part gets really tricky because let's say I have a token. Out of the box there's no way to know how that's being leveraged. Like, I don't know if someone's using that spacing token to do something wild and they could be , and you laugh, but I've seen some really creative usage. You're like, "who cares about the name? I just want the value." So they just plug in any token that matches that value.
And then we go to update the value later on and they're like, "whoa, whoa, whoa, why did it change?" I'm like, "well, Well, you're using the token. Like you use the token for the purpose, not the end value. "And what I think. Our next big assignment for tokens is figuring out that mapping and seeing how they're being applied.
Because if we're going to be updating these designed tokens to impact lots of folks, we need to have a visual way to ensure that we're not just blowing people's components up. Because, one person's bottom padding is another person's bottom margin and things, or a top margin even, and that's even worse.
That's something that we're hoping to accomplish through tooling and it's pretty exciting. Like I'd love to get to a place where. When, if we were going to update something, there's a quick visual way to just double-check and make sure everything works across multiple repos, products, platforms.
And I think that'll be fantastic.
Andrew: yeah. All my own personal design tokens journey. I first thought that that layer of indirection wasn't all that necessary, but as time goes on and you look towards the future, you really do realize that you need that like second layer that lives on top of your base token values. Otherwise your reds aren't going to be red someday.
Justin: There's always an intersection here that I like to think about. It's just basically this conceptual notion of codifying the language that we use to talk about something. So as you're describing that, like you want to use the thing for its context, not for its value. So maybe your design tokens has, I'll go to a classic example, like this notion of a primary color, which has be used on a primary button or interaction.
And it's, it's easy to know when to. Pull that in, but it's one of those reinforcing things when you're talking about like, not just what is the color, but what is the function of a thing that is often a conversation that can get lost between design and engineering, especially if there's a big gap.
Cause if you have like this ivory tower design, the same thing that happens with every ivory tower like. Architecture is like you get a design and you just implement it to what it looks like, but like semantically, the context is all gone and it's not really right.
Danny: Yeah. And even if you do have that kind of like nice semantic layer, like clear background, primary color font, primary. Yeah. I mean, th this is actually just bringing up. I was looking at a poll request, like even last week where, there's some iOS change that was like setting the label color of a UI label and it was setting it to color border primary. I was just like that's the text color. And you're saying
it's colored border primary.
It's like, yeah, but it's the same color. It's like, but if we were to change that, like, why don't you use color font primary? And it's like, oh, I guess I could use that and change it, but it is still, even if you do have that layer, it's still, I think a mindset change from, know, implementing interfaces in a way of like okay, I need to make this, this color and this, this size and that, abstracting those decisions a way. I think it's still kind of a mind shift change that a lot of people still need to make. And it will take some time to get there for sure.
Andrew: Yeah, it's another place where our tools are definitely helping us like the big selling point for me on Figma is the ability to create a design system in Figma and have all of your tokens easily consumable while you're designing. Because if a designer can still just go off and pick whatever blue they want for their button, like there's still gonna be a lot of friction between design and developer.
Kelly: my favorite things, like in slack when people ask, Hey, I noticed, this, thing is green. How do I make it pink? and a lot of it is like, it's framed as how do I just get this to match instead of the question of, Hey, maybe this isn't follow our system and maybe this shouldn't be this different color.
And I think just an understanding of what, what should be configurable versus what you know is set by the system, I think is. Not really explicit sometimes. And with using tokens, I think that could help because you are defining what's available in those choices versus just an open-ended style object over writing the styles.
Danny: Yeah, it's systematizing all of the decisions, like, do you want to change the button color for all of the buttons across all of the platforms? Do you want it, Do you want the button to be configurable so that you can override the button color in your page? like, what's the context that, or maybe do you want to change the brand color from blue to pink and that has, other changes as well. They'll change the link color. They'll change other colors as well. Like what is it that you're trying to accomplish and what part of the system do you want to. change or have an effect on. cause I'm tokens doesn't necessarily just solve that, but I think it brings the conversation up a little bit so that it's easier to have those conversations. At that level
Justin: I wonder if the like conceptual notion of a design system, as a thing is still trying to ultimately ramp up to this, like where it's just easier to do the right thing to pick the right constraint. Cause like we tokens by themselves or. Relatively simple to implement, but hard to, use in all your products. and then y'all are both saying you can easily pick the wrong thing. Like there's nothing stopping you, but if you go up a level of abstraction, you say, now we're just going to give you a primary button instead of the primary color and it's token. And there's less control that you have over that, but it's like more together. And just curious from the design perspective, and you're thinking about systems and like the tools that you provide. I don't know, how do you make the right call on what constraints, should be there or what shouldn't be there. That seems like a hard problem.
Danny: Yeah, that's a very hard problem. There's no like right answer, objectively across the board for every company. I think, one of the things that I have tried to do, like within like my team and organization is I'll never say no to anything, but I will frame it as, you could go off and build this new banner component. It'll probably take you. Yeah, eight dev weeks to build and consume and use, or you could use our current bear component, which looks like this. And I was like slightly different, which would take, a week to build, or we can have the discussion to change the banner components so that it would like all banners that would, Take two or three weeks.
And so it's not framing it as like, like, I don't want to say anything is right or wrong, but I want to give the, all the, options that are available And then hopefully if we've built the system in a good way. the right way will come about, maybe it is the right decision for them to build their own banner and spend eight weeks because they have a very specific marketing need or something, maybe the right decision isn't to do that, but it's not, I don't want to make that decision for any team. so I'm only there to help and to help understand the, the options and constraints.
Kelly: I really liked that banner example because it reminds me of something that we worked on at Intuit And it goes back to how composable are your components and how customizable what level of chaos and destruction is your, like your tolerance level, honestly, when you're making these decisions, because you can definitely put in a lot of constraints and, and some of it has to do with how strict is the design to dev connection. some of that I've seen before where a design has two sizes for a component. So does that mean a dev can put any size? Is it constrained to those two sizes? And I see a lot of that. It's funny, different teams have different philosophies on how strict to make it.
And then you have some folks like like me, I'm like, let's just flip them, have whatever. It's fine! Make everything a child. It's okay. That's what context is for now. And understanding everyone's philosophy on that really helps take the edge off of making these decisions, because if you understand, okay, this person really wants to make sure that nothing breaks.
Okay. This person wants to make sure that developers have flexibility. And it's interesting to see all those opinions come together to form essentially your component API. And I have found we're actually in the process now of really documenting those decisions and showing why we came to the decisions we make so that, as a product developer, they may not realize all the implications.
And if they see that context, it's suddenly not " oh, why did they do it this way? Don't they know that they could have made this a prop instead of a named export?" Or things like that. And what's interesting is when you document it, there's that empathy. It's oh, they did think of that. Oh, I see why they went in this direction.
So you can actually have a constructive conversation instead of coming in with your own kind of. "No, I, at my old company, we did this way, so we should do it this other way." And so I love just document. I love documentation. I love I'm a sucker for it. I love MDX. Just being able to write out my thoughts is, as crazy as they can be, and just get just get those thoughts out there.
Cause even if they're wrong, I want to be able to at least talk about it because. I just, I love being able to explore all these different solutions together and coming up with something where everyone feels like their voices heard. I've learned a lot. I know Andrew like taught me a lot about the values of tree shaking. I think every conversation I have at least one tree is shaken and yeah. I love the ability to think through customization and constraints, I think is really a cool topic.
Andrew: I think that really ties back to your idea of shame driven development. It's like put the PR up, let me get the comments, tell me what I'm doing wrong. Like that helps you grow as a developer immensely.
Kelly: Or you just cry.
Justin: I hope it's not shame!
Andrew: Yeah. Yeah. Not real shame. Just like helpful encouragement.
Design Token Developer Tooling [00:33:03]
Okay, Kelly so as a person central to the design systems effort at Intuit, what are some of the tools that you and your team have helped build out and deliver to help consuming design tokens as cool as the problem they solve.
Kelly: Yeah. So when we were first creating design tokens and this whole design data system, It was all JSON. And we tried having designers get all set up and clone the repo and pull it down and run yarn and yarn build.
Andrew: Didn't work.
Kelly: I think I scared some of them off. And then some of them were just, they were like, "I'm interested, but you know, maybe later."
And so that didn't work. So I'm like, okay, well we tried that. What else we got? So we already used storybook for our component demos. And so our designers, they love story book. And I saw, okay, well, if they like story book, then we could maybe leverage that to display or design tokens. And so we created our own token storybook, and a lot of thought went into, what's the best way to display it?
What do people need to know and see? And what can we leverage from our existing plugins that we've already built? That displays our customizations. So we built out a custom storybook! Users can swap the product , they can swap dark mode, light mode, they can see those values, they can copy and paste.
One of our limitations currently is that it only the formats only show up in. JavaScript. And we want to be able to show the variable names and the other platforms, because an Android, you have XML and it's like, with underscores and then you have other formats. So that's where we want to get to, but I'm storybook fan girl.
I, I really like the way that you can use the addons to just make it work for your use case. And in addition to storybook we also have this awesome vs code extension that Andrew wrote. And it's amazing because in vs code, you can see a preview, a visual preview of the token data. So as you're filling out, you're doing, you're like, you're on your own, you're doing your CSS.
And you're like, Hey, I want to use a spacial value. So you just started typing in and then you see all the space, like the spacings, it's amazing. There's light mode, dark mode values for hex values. It's really cool. And when I showed people this, or just like, I'm excited about design tokens. And so it's been a great learning tool to show people that, it's not just that we have these design tokens.
It's like, we're getting people excited about using them in their day to day. So thank you, Andrew.
Andrew: Wasn't a leading question at all.
Danny: it's funny. You mentioned designers, like no. Wanting to learn JSON stuff like that. I remember when I was first showing, designers in my organization, I was like, "oh, here's the JSON file with some colors. And here's what happens if you add something." and then designers was just I don't want to learn Jason. I don't know what that means. I don't want it do that. And I was like, " oh, okay. that's cool. And then, so yeah, so I think, designing tokens, like it's really the integrations that I think make it click for people. So like on the dev side, like the integrations into. Android and iOS and web, but also like integrations into like vs code or storybook where you can see, like where that data and where those decisions come out, I think is where it starts to really, click for people and get people really excited about design tokens.
Andrew: Yeah, we got surprisingly far on our teaching designers git journey. Like people were actually making pull requests, but then there was a merge conflict and it all came crumbling.
Danny: Merge conflicts are hard, man Like,
Andrew: are And I didn't want to teach a designer how to resolve one, but
Danny: yeah.
Kelly: Yeah, but now there's like a button that get GitHub added that lets you rebase, which is
Andrew: yeah, mess it up right on the web,
Danny: Yup.
Justin: Make it easy for everybody
Danny: Yup.
Justin: Back earlier in my career. I helped, a team design, a theme system at the time. This was like before I had the conceptual understanding of like design system, maybe 2015, 2016. Yeah. And we build out this really complex workflow in SASS where it was like a bunch of Nested SASS objects with like theme values and everything.
So the conceptual model works the same, but I have so much regret for what I did to those poor four designers. Cause they ended up working right. These like theme files and it was, it was not, not great. And I am so sorry anybody's out there listening to this. I'm so sorry.
Andrew: Kelly when I was leaving Intuit, I heard whispers of a Figma plugin for the design tokens. Has that gone anywhere?
Kelly: Yes, we hired a, so I'm a senior UX engineer and we have a team of UX engineers. We have two folks that joined us. And so one of them is focusing on Figma plugins. And part of that is a plugin related to design data. So that's that's, it's been really interesting to see how the different ways that we format our tokens can manifest its way into Figma.
And a lot of that, it's not just, apply the token as a style. That's just the first hurdle. The bigger hurdle is, understanding how designers are working. Whether it's a system designer or product designer, are they breaking apart the components? How does it, how do they work with variants?
Are they using the primitive token or using the semantic token? Are they using the component token? So there are lots of, there's a lot of tiers of knowledge to obtain when you're working with tokens. Right now we're just trying to get like a baseline understanding of how people want to use them.
So we're doing interviews and figuring out what's what the best workflow is for them. So that, that will drive how the plugin UI works together because even though you can do something knowing how it's actually going to be used can maybe reduce some of the scope, even for some of the things we have planned, at least for an MVP.
Andrew: Nice excited to see where that goes.
Kelly: Hmm.
Tooltips [00:39:36]
Andrew: Okay. So I think that about wraps it up for the questions and it's time to move on to tool tips!
Cleanshot X [00:39:43]
So one big problem that I encountered with my mac's native screenshot abilities is that it shows it on screen for like, 10 seconds. And usually I can be quick enough to grab that screenshot and then post it to wherever I'm going to post it in that 10 seconds. But a lot of the time it'll just go away.
And it's not the best user experience. I'm really lazy. I'll just go back and re screenshot the thing. Cause I don't want to go find wherever it put it on my system. What clean shot is is. A whole bunch of different tools that make your screenshots feel a lot nicer. So, like for instance, when you take a screenshot, it'll pin that screenshot to the edge of your screen. And it'll just stay there forever until you dismiss it or choose to do something with it.
So now I can take a screenshot, go type out my pull request description, and then add the image without any fumbling around or trying to get the timing right. Also has a bunch of other really cool little tiny features.
Like you can paint a screenshot on the screen and it'll be above all your windows, but it has definitely improved my life. It's a paid app, but I've gained a lot of value out of it. So I do highly recommend it.
Listen Notes [00:40:55]
Justin: Nice. Nice. Yeah, I'll go next. so my tool tip for this week, or the first one is this site called listen notes. It's a search engine for podcasts. So if you want to find anything, if it's mentioned in the podcast text, if it's in the title, if it's a person, whatever, this is a great way to find, to search across all of these index podcasts and find a particular episode. That's talking about a very particular thing. it's pretty amazing. I was looking for some like very niche elixir stuff, and I was able to find them like a bunch of different episodes across a bunch of different podcasts that had that like exact topic.
It was pretty cool.
Andrew: Oh, that seems like a super useful tool. Like I could see students really benefiting from this, like being able to search across all that data that probably previously wasn't searchable.
Justin: Yeah, it's really awesome. We're on there too.
Andrew: Oh, Um, shit!
So, Kelly, I think this is the one's yours react flow.
React Flow [00:42:00]
Kelly: I love react flow. I don't really understand how it works. It's just magical. I'm seeing all the sliders and like is updating things and you can put in all kinds of data, like the examples, the customizations are super cool and you can pretty much customize it the way, like for it to be however you want to use it.
And so I thought this was a really great way eventually to show how data flows through like a pipeline or a repo and just get a sense of the complexities around all these different data sources.
Andrew: That's funny that you brought this one up. Cause Adam was on last week and he he sh he showed it off his own react graphing library that had lots of the same features.
Kelly: That's
Andrew: think it was a different one though. That's funny.
Kelly: Well, we both work on very similar projects, so there's a lot of overlap with like, "Hey, did you check this tool out? And how can we use it for our projects?" We keep saying that we should just call it JSON R us, because that's what we, that's what we're doing.
Andrew: That's hilarious. Yeah, it'd be interesting to see how the design tokens look like visualized like this. It's a very pretty way to visualize it.
Danny: Yeah, I can see all the kind of dependencies and references and aliases and stuff like that. Showing an, craft like interface.
Andrew: So next up it looks like we have repl.it.
repl.it [00:43:32]
Danny: Yeah, So this one's mine. So I like it part of like my day, oh, go and answer people's questions about style dictionary. And a lot of times like, I'll want to like, make like a code example for them. Like how do I do this very specific thing? And there are multiple ways to do it, but here's a way I would do it. And. I never really found a great way to write that code and post it for the person. Like I've written just sometimes, but you can't really execute them. And it's very static. So I've done that and be like, "this code probably works. I didn't test it, but something around there, I can create a new GitHub repository. That seems a bit. like heavy handed for just building like a quick example. Also similarly, you'd still have to pull it down and run it and stuff like that. And one of the things with like static shirt, like it's generating files. And so for an example, people would want to see the files that it's generating.
So a lot of Like online code editors, code pen or code sandbox, you can't like some of them, you can generate files in like an NPM script. Some of them you can't, and even if you can generate it, they might not show in the file explorer. And so I like ask a question to where, like a design technologists, slack channel at Amazon. And I post a question like I need to be able to do this specific thing. And someone
showed me repl.it.
and it does exactly that, like, you can run NPM scripts or bash scripts, like CLI commands and they can generate files and they'll show up in the file Explorer, and then you can view them. So this is the only online IDE at least that I've found that I know about. that allows that to happen. And so, like I just went really deep into this. I was like, yes, this exactly what I need to be able to, write this 20 line demo for someone that I've been spending like six hours on, because I've been doing it in like six different online IDs. so I was just really excited to this.
Andrew: Yeah, it seems like it could be really useful for you since there's so many different ways to run Java script in a little like fiddle, like environment on the web, but other types of code, not so much.
Danny: Yeah. Yeah. Most of them are geared toward like front end developer. so you're building a webpage in some way. And you can do that super easily, but if you're building like a CLI or a build tool or, you something that generates stuff that isn't like a web application, out of luck. Except if you use replica, apparently. So that's awesome.
Andrew: Yeah, it's been really exciting to see them add features. And I see the founder posts about like kids in India who are not going to school cause they're having too much. Hold on repl.It. Like, it's just so easy to code that they're not even wanting to go to school anymore.
Danny: That's awesome. Yeah. And like, just that, like the tools they have for starting with a gitHub repository and like starting a project on it and like forking stuff. I still haven't gotten that deep into it, but Like, all of the tools I'm, I think it's a great kind of online ID platform for sure.
Justin: Really good for pairing to share into that thing.
Andrew: It's good for teaching. My girlfriend's sister was learning C plus plus and I helped her learn it with repl.it
Danny: Wow.
Andrew: Really cool. You can just be like, oh, you have a bug send me a link. I'll see what I can figure out for you.
CRDTs [00:46:47]
Justin: Yeah. there's, sort of like niche, subject that
I've been getting into a lot these days, and it starts with this notion of, building applications that are offline first. so local first, It's a really hard thing to do, because if it's local first and you make a change and stuff, one makes a change somewhere else.
You have to figure out how to resolve that. And that's why I git is great because it helps us do a lot of those things. But if you're building software, that you don't want people to have to manage a merge conflict and you need to figure out how to do that for them, it's hard.
It's super hard problem. One of the ways to solve this is there's a specific data structure called CRDTs. There, I don't remember what they stand for, conflict, something data types or whatever. Anyway yeah, conflict free replicated data type. There you go. Great. The, this there's this library that was developed by some folks at this research lab called ink and switch, which I think I've mentioned previously and another episode, but it helps you do CRDTs or, and helps you essentially gives you a framework for building applications that are local first.
That multiple people can make changes at one time or you can have delayed synchronized changes. Really, really interesting library. There's a lot of really good research behind it too. So if you're interested in that thing and trying to figure out how to build a real-time app, then I definitely recommend checking it out.
Andrew: Yeah. This is a problem engineers at these script are currently solving, trying to get it to be collaborative. And just the amount of thinking that has to go into that is crazy. Cause like, you don't want people resolving merge conflicts on their video files in our editor. Like you need to come up with something better than that.
Oh Kelly actually stole my last one.
Kelly: oh,
Andrew: this one.
Kelly: no, you can. You.
Andrew: Oh, no, you can do it. I didn't read up on it enough. So you're the reigning expert.
dom-events.dev [00:48:45]
Kelly: Yeah. So it's Dom events.dev, and I'm a sucker for educational tools. When I first saw this, I was like, wow, this is a really fun page. Like the colors are really vibrant and I just start clicking around. And as someone who doesn't have classical training for computer science I really loved that I could play around, check some boxes and have it play. And then it just shows you what is happening, what events are being triggered as in the Dom. And I was like, "wow, this is so cool." And. Maybe if I had had this in school, I would have been more interested in what all this was, but I guess better late than never.
And so I love all that, the information around what each thing is and what everything means. It also teaches you some terminology as well. And it's just, it was just something fun to tinker around with and learn a little bit more about what's happening behind the scenes. Cause dev tools can be a little scary sometimes and this kind of makes it more explicit and visual.
Danny: was a really cool car Reminds you of what's the like, like child programming, language scratch or something? like just like the visuals and it's doing, kind of reminds me of that, where you can graphically build, like what happens when this event does this play it, it looks really cool.
Andrew: They did a really good job of making this pretty and approachable cool. I think I saw some tweets from the developer that this is actually scripted after effects somehow.
Kelly: Oh,
Andrew: Yeah. We're seeing after effects on this page be scripted. Yeah. Which you can apparently do the JavaScript pretty easily. So take that into your design system.
natto.dev [00:50:34]
We got one last one and it's about some stinky Japanese food. No if anybody doesn't know, natto is fermented soybeans on top of rice, it looks snot!
Justin: Yeah, well, I don't know about the food but this is a really interesting library and it ties into, or it's similar to what Kelly was showing earlier, the react flow of thing. Natto.Dev is this Canvas that you can put these little elements in and they can have text or they can run code and you can link them together to do really interesting things.
So Andrew click on the render react example. I feel like that's a good, that's a good example. So yeah, you can just give it some text and feed it through and it'll render a react component. It's just a really interesting way to play with code and explore things and like pretty visually see what you're doing, but it is almost that react flow, like feel, yeah.
All these nodes are interconnected and have these rich relationships. I really liked. Visual programming environments just to break things down and make it more discoverable and explorable and watching the developer built this out. His name's Paul Shen is just been a real joy. This is one of the things that I always look for on my Twitter feed is just like an update on this project. Cause it's so fun.
Conclusion [00:51:59]
Andrew: I think that about wraps it up for this week's episode of devtools.fm. Thanks, Danny and Kelly for coming on. It was a pleasure to talk with you.
Danny: Yeah, thanks for thanks for having me. It was a lot of fun.
Andrew:And that's it. Make sure to follow us on wherever you listen to podcasts and subscribe to us on YouTube. Andrew:** Thank you. And goodbye.