We're comparing our outfits, deleting Twitter, and lurking in Discords. And wondering about how much customization you should have over an app's UI? Do you expect it? Should it be driven by data instead of hand-coded markup? Is taking ownership of Babel transform a smart thing to do? What are design tokens, really? And how do we get to cyber pink?
Time Jump Links
- 00:42 Check out our 'fits
- 03:07 Dave deletes Twitter
- 04:42 Lurking in Discords
- 08:36 Configuration based UI
- 17:24 Rolling this into testing
- 26:48 Sponsor: Netlify
- 28:31 Do you expect customizable controls in your apps?
- 32:28 What if a team account on MDN could be customized?
- 36:34 Is taking ownership of Babel transform a smart thing to do?
- 38:57 Talking about design tokens
MANTRA: Just Build Websites!
Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.
Chris Coyier: Hey. How ya' doin'?
Dave: Oh, good. You probably can't hear by the sound of my voice, but I am once again wearing ath-leisure.
Dave: You probably said, "Whoa, Dave! You got a shirt with buttons?" [Laughter] Yeah. I've got a shirt with buttons and ath-leisure on the bottom. I'm basically the mullet of business, but I could still go to the store or answer the door if a package comes or something like that.
Chris: Oh, I see. Yeah. Yeah, nobody does the opposite, right? Nobody wears an old, grungy T-shirt and slacks.
Dave: No, no. That could be a thing.
Chris: That could be. Yeah.
Dave: But no -- whatever.
Chris: Feeling good, though?
Dave: Embracing some ath-leisure as the pandemic stretches on. [Laughter]
Chris: I dressed up nice today. I've got a button shirt on, a cashmere sweater. Wore my lucky belt. Can't see that but feeling good.
Dave: Whoa! You've got business goin'? Are you interviewing somebody? [Laughter]
Chris: Yeah. I actually totally do have a business call today, which is partly for it. It's one of those cross-your-fingers kind of calls.
Dave: Big enough. Big enough to need to put buttons on.
Chris: Yeah, big enough.
Chris: I wanted the lucky spirit to it, and we're talking about fantasizing about a Mexican vacation, too, so I wore the Mexican belt to see if maybe both those things could come true on one day.
Dave: Oh, good. Good. Ooh, manifest it. Manifest it.
Dave: Yes. I love it.
Chris: That's right.
Dave: I had -- we had, over the Christmas holidays, an important business meeting. I was dressed.
Chris: Mm-hmm. mm-hmm.
Dave: I'm in my step-mom's office, which has got photos of me and all my step-brothers on the wall, our graduation photos. It's so full dork.
Dave: But I'm like, "I'm dressed up, ready for a business call with important business." Straight up, we got ghosted. It's fine. It all got resolved, but it was like a no-show meeting because it was over Christmas.
Dave: No one was expecting it, but that's when it got scheduled. You know there's a slight chump feeling when you get dressed up for a meeting and it just doesn't make - or whatever. Yeah. That was a good feeling.
Chris: Yeah, indeed. Sorry.
Dave: Manifest it. It's going to happen.
Chris: This is better.
Dave: Today is the day.
Chris: You in that office, I would say yes to anything you were trying to sell me. I'd be like, "Look at this guy. He's creative. He's full of life and energy. He knows what he's talking about. He's got those smart guy glasses on."
Dave: He makes his own robots out of plastic.
Dave: Yeah. Big into Gunpla now. That's a new hobby I got, so yeah.
Dave: Yeah. We can get into Web design questions or whatever, but I've been getting into--
I basically quit Twitter because Twitter is stupid to me now, but I don't use it as much as I used to. It's uninstalled from all of my devices, so I have to go to the website on my computer.
Chris: It just freed up some time, apparently. Yeah.
Dave: It has freed up some time, so I've been getting into almost like crafts, crafting or hobbies where you use your hands and stuff like that. I don't know. I'm just getting new obsessions. It's kind of fun. Fun and nice not just making websites.
Chris: I like that you found some time in that way. I feel like most of my fantasies in life revolve around what would I do if I had more time.
Dave: Mm-hmm. Right. Right? If you had more time--
Chris: And then you actually have--
Dave: Well, the only way to create -- I don't have a bunch of time, but the only way to create time is to just be like, "No!" [Laughter]
Chris: Yeah. Nuke something else.
Dave: I'm just not going -- I'm not looking at that.
Dave: TikTok, that was a big time void for me, so I quit. I used that for a bit, a hot minute, and then quit that. Yeah, I don't know. It's like the Internet is kind of boring now. It's like RSS feeds. [Laughter] It's great, but yeah. I'm not hanging out on Reddit. Not really.
I've got some Discords. Of course, the D-d-d-d-discord popping off, but that's more peppery when that shows up. I'm not fully, 100% typing in 17 Discords at once.
Chris: Yeah. Yeah. Yeah. Somebody was saying to me -- no, I was listening to Postlight, this podcast, about how they just threw out this offhand remark that the majority of Discord usage for people is passive. They're like, "99% of all usage is just people listening," kind of thing.
I was like, I wonder if that's true because it doesn't sync with my usage, and that's all I have. Right? I just think of myself, as I always do.
Dave: Well, that's a natural tendency. That's your center.
Chris: If I'm in a Discord and I'm not participating, I just leave it because it's just boring to me. I don't get anything out of listening to it. I need to participate. Otherwise, I don't know what's going on. I don't understand the vibe as well as I should. If I have nothing to say, why be there? Maybe it's just my personality or something but, yeah, definitely I'm not a Discord lurker.
Dave: Yeah. I have a lot of Discords now, just very recently. One is my eSports Team I follow. One is this Patreon I support for Game Maker's Toolkit, which is really awesome. But then there are some tech ones now.
All the support channels are starting to go to Discord, right? Which is good and bad. I like it, but I also -- it's like, "You need help with something? Cool. Here's just the firehose, dude." [Laughter] That's kind of not what I wanted.
The older I get, the more specific my problems are. I need this. I need terraform to work on Digital Ocean. I need database firewalls for terraform on Digital Ocean. My problems are really specific.
Dave: But I don't want to just hop in the Digital Ocean or terraform Discord. No offense, Melanie. But I don't want to hop in the Hashicorp Discord just to get one question answered.
Then I'm in a keyboard -- two keyboard ones now. But one is customer support because I paid a bunch of money. I want this keyboard. Where is it? There's no status on the website. Then they were like--
Chris: Did it work?
Dave: No. I go to the Discord, then they're like, "Hey, send an email if you have customer support." But I was kind of hoping for some chatter, like other people who were like, "Where's my keyboard, dude?"
Dave: But then maxvoltar, you know, Tim Van Damme--
Dave: He has one, a whole keyboard, because he does keycaps now. That's kind of like a little side hustle he has.
Dave: They're beautiful, but I'm in this big Discord now. I like it.
Chris: Is it totally run by just him? Is he super active in it?
Dave: Yeah, he's pretty active, and so I guess there's only 150 members, which I think that's the max Dunbar number I can really handle. 150+ people in a Discord or Slack, it starts to get wild.
Chris: Yeah, it's probably a good number, and it's a little too sad if it's too much less than that, too. [Laughter] You know?
Dave: Right. Right. The volume, the velocity is maybe not as interesting. I don't know.
Chris: Yeah, right. You were talking about podcast consistency the other day, and it was like if you have a podcast that hasn't been updated in even like three months or something, you're kind of like, "Well, that's dead." Unsubscribe. You know?
Dave: Oh, yeah.
Chris: Whereas the number for a Discord is like, "Oh, nobody has said anything in a week? Done. Bye." You know?
Dave: Right. Right. Yeah. Even channel-by-channel. It's like, "Do we need this channel? No one has talked in it for a long time." You know?
Chris: All right. I'm going to hit you with one that you're not prepared for.
Dave: Ooh. This is a classic, surprise old Dave. Here we go.
Chris: Yeah, kind of. Just like I want your honest take on this, if you even have one, because you don't have to force an opinion if you don't have one. I guess the first weigh-in is about configuration-based UI.
Chris: Let's say you're going to build out -- and I happen to have seen the inside of Luro, so I can see some of that. Let's say you have a sidebar of stuff. One way to build a sidebar of stuff is to write some HTML that's like, "Here's an unordered list with LIs and As." I handcraft what that is.
Then I pass that data to some kind of component and it loops or maps over it and produces the markup that it needs to do. It's kind of like saying, "I'm not going to handcraft the markup for this." The first class citizen is the data.
Dave: Mm-hmm. Mm-hmm.
Chris: The front-end builds itself from the data. That could be a form. It could be a big list of settings. It could be a modal where you say, "Nope. Don't give me HTML for this modal. Give me data for the modal, and I will build the modal from it."
Chris: That's what I mean by configuration-based UI. You could really go all in on this or you could reject it. I feel like I've heard very different opinions on this, and I'm curious which way you normally go or if you even care.
Dave: I think I tend to be more static, like this is the navigation or the UI. But with Luro, I have been kind of thinking what if there are pieces that don't apply, like pieces of the application, like, "We're never going to use that." I'd rather just hide it from the navigation. That's totally fair.
I can think of two situations where it gets tricky. The classic WordPress WP nav client handoff where you handed them five beautiful links. Oh, beautiful five links. Six weeks later, it's 22 links and exploding layout. Nothing. The tolerance wasn't there, but it was just not made for it. Or that's just way too many, but they wanted to add that.
That could go two ways. I could go two ways. I could say, "Man, they shouldn't be able to do that." Then I can also be like, "Well, if that's what they wanted. They're probably happy." [Laughter] And so maybe they're happy.
Chris: I could see that. In this scenario, the data based part of it comes from an admin tool or a CMS.
Chris: In that kind of way, you really had no choice, really. You had to template out the UI to loop over data that is being given.
Chris: Let's say, though, just for the sake, you controlled both. You're making this data abstraction choice for yourself and for your own team.
Chris: If somebody wants to add a form element or add a setting or add a navigation bar, they don't just go edit the template to do it. They have to add -- This could be--
Let's assume that it's JSON data. They have to go into this thing called sidebar.json and copy/paste a chunk, an object. Yeah.
Dave: Again, I think I like it. I think where it's -- Man, I'm getting a bunch of ideas here.
I think one place where it gets tricky is what if you add a new feature, like to the application, like CodePen NFTs? I'm doing it. Whatever. But I configured my navigation, so I don't actually see the CodePen NFTs because I configured that. I already preset it.
Do you just inject that for them? You know what I mean? Do you kind of heavy hand and just be like, "Everyone gets to see the new features in the navigation in the configurable UI," or something like even going more micro than a navigation, like a WYSIWYG?
It's like, "Oh, we added features to the WYSIWYG, but you can configure the WYSIWYG to show whatever you want." How do you let people know there's been new features added and they have to now click something - or whatever - to add it back or write the JSON to add it back in?
Chris: Yeah, right> I think that points at a limitation to it in that let's say you wanted to show it to 50% of people or even show it to 100% of people but call it out specially. Now, all of a sudden, this goes through the--
Let's say it starts in design. The designer has now a sixth navigation item (where there used to be five) with a big badge that says, "New!" with a yellow sparkle on it - or something. How do you pull that off when it's configuration-based?
Now you have to be like, "You know what? I think we should have, in the JSON data for the navigation items, we're going to have to have a new property, and it's called 'New'. We'll say, 'New True.' Then in the template, if new is true, we'll output this little new badge."
Dave: Always, yeah. Always show that. Yeah.
Chris: What a weird abstraction, right? Whereas if you didn't do the abstraction, you'd just put the new badge next to it because you're not limited in that way.
The same thing with the modal. If you made a modal that says, "This modal does not accept arbitrary HTML to show. It accepts a title. It accepts a description. It accepts any of these three buttons - or something," and that's it. Whereas another way to design a modal is to just say, "Here's the shell of the modal, and maybe we'll automatically add okay and cancel buttons - or something - if you want them."
Chris: But otherwise, just put whatever HTML you want in the middle. That opens up some design control. I can do whatever I want in that modal and feel like I have design control. Yet, it also opens the door for inconsistency.
Dave: Big time, yeah, because every little modal now is a webpage. It's not a uniform-- [laughter]
Dave: --information device - or whatever - a flow control. It's now a webpage inside a square.
Chris: Right. You might do the configuration-based to force some consistency. You also might argue that it could be a little easier. Let's say it's a form and you wanted to add a form element that just copy and pasting a little previous piece of JSON data and putting the stuff in there that says, "Oh, this is field eight now, and it's capturing a refer URL - or something," that you don't have to worry about getting the markup right and things like that.
Dave: See. I mean that's kind of cool.
Chris: Now, in the case of settings, let's say you had hundreds of settings. Yeah, they're not little bespoke components. There's less surface area to get it wrong.
Dave: Mm-hmm. Mm-hmm. I do like that. You've used Rails. [Laughter] The form helper on Rails was kind of cool because it knew about your data structure. It just was like, "I'm just going to spit out a form for you," like automatically.
Here's all the junk. All the error handling comes back from the server. It all hooks in. All you had to do was be like, "Rails generate scaffold - whatever - posts," and it just did it.
Chris: Right, and so it was trying to help you, but I remember -- I'm sure we still have some of them in our codebase in some places -- that it wasn't that. In some cases, almost more verbose. It's not like it saved you typing, but it gave you guardrails. It said, "If you call this wrong, then we're going to yell at you."
Chris: Meaning that it's almost like an implicit test for your front-end because it would bomb if you got it wrong.
Dave: Yeah. Yeah, yeah. Yeah.
Chris: To roll this forward into testing a little bit, let's say you went for it in some areas of the app. It's not like you have to go all in on a configuration-based UI, but some parts of your UI might be built from data rather than handcrafted HTML or JSX or Vue components - or whatever else.
Chris: Any language can do this. That's kind of the beauty of JSON is that it's so digestible by so many different languages. You just import it and loop over it and use it.
You can also validate it, so I was kind of going down that road this week a little bit in testing out some libraries that say, "Okay. Here's a chunk of JSON that, in this case, describes UI, but also, for the record, could also kind of describe the data that it represents, too."
Let's say it's a form. The data that builds the UI, you can have a schema for that that relates to the data that it outputs also.
Chris: I know that feels a little abstract. You could be like, "Well, I said that this input has this ID, so the name data that comes out the other side should have that ID, too." You can validate them against each other.
But anyway, let's say you're describing the Luro sidebar - or whatever. It says there's an object, and it has a name. Maybe it has a hover name - or something - if you wanted to be more verbose. It has an icon, which is a URL to an icon. It has all these. Maybe it has a color. Maybe it has a hover color.
You're crafting a little piece of JSON that describes all these things because that's how you're going to build the UI. You could also write a schema and sit it right next to that thing that says, "This is the shape of that object that I expect." If somebody comes in here and adds a sixth navigation item but forgets the hover color, that schema can say, "Hey!" It could yell at you just like Rails would have yelled at you - or something - and be like, "You forgot that. That's going to cause a problem." It's a way to add this unit testing to a UI.
Another way to do it would be to write a Cyprus test - or something. "Are there six navigation items? When I hover it, is it blue?" That's nice, too, but it's almost easier in a way to write a piece of schema.
Dave: No, I like it. There is a point, right? There's a point where you now have so many options in the thing -- dropdowns, exclusive dropdowns -- and you can have as many dropdowns open as you want, or hover colors, focus indicators, focus visible indicators. There's a point where you could possibly have so many options that it was just easier to write HTML. [Laughter] You know what I mean? Where raw HTML would actually be the more succinct choice than globs and globs of JSON properties.
Chris: Yeah, right.
Dave: I'm just seeing it where it's like a cart UI, and you're like, "Well, just offer 20 props to configure the cart UI."
Chris: Right. Twenty starts to be too many for whatever UI it is.
Chris: Twenty is nuts town, whereas one is too few. Then why did you even bother? There's probably this sweet spot of--
Dave: Like five to seven - or something.
Chris: That's why I brought up the new badge thing because then one little design decision, you've got to update the schema. Maybe your UI, really, you don't just add new equals true to the one. You've got to add new equals false to the five other ones, too, because you want the schema to really mean something. It's not really much of a schema if everything is optional.
Dave: Yeah. Well, then configuration starts to become the enemy. You know? [Laughter] It's like, okay, we have a new. Right? It's kind of gold, right? But this one is extra new, so we have a sparkle. We're adding a sparkle. During pride, it's kind of rainbow.
You get all these -- ugh -- you just get all these configurations that now you have to manage. It's technical debt, kind of, at that point. You know? Then every new person has to come up, and they have to read a book about the options for the [laughter] navigation.
Dave: Or for the card, and there are 10,000 things.
Chris: Let's say it's a Vue component or a React component anyway. That's what gets mapped over and called to produce the navigation anyway. There might be prop type validation there anyway. What you pass into this nav item thing is now validated twice. It's like, "Oh, my god."
Dave: Double validation.
Chris: Yeah. How fricken' -- you know? How many times do I need to get yelled at while I'm trying to make an anchor link? This could have been one little piece of HTML that will probably never cause us a problem and, in fact, maybe cause us less problems because it's such a simple piece of UI. Why does it need an army of crap behind it?
Dave: Yeah. Well, you know the WordPress footer links was always a thing, too. It was like, "You need five links. Great. Got it. Loop through four links. Do it." You know? Then it's like, "Oh, but we need columns of links." Okay, cool, so for calls and links and call... You know, like, "Dude, doing it."
Dave: "Oh, but you know the newsletter sign-up? That's a fricken' form." Okay, well, okay... And you just start tumbling down this pain train of configuration-based UI. It's interesting.
Chris: I've heard real -- like I hate it even stronger, because I think there can be a very different coding style where if you don't decide on a team, you might open up a component in a PR one day and at the top of the component is just a random array. They didn't even bother to make it JSON and validate it or anything, but they know they needed to loop over something three times. Rather than repeat themselves, they abstracted the three things into this array and then looped over it and then made one, just because that's how they think.
Chris: They're like, "Oh, there are three, and they're very identical," and I've seen that pushed back against really strongly, like, "Oh, gosh. Why?" It's hard to think about because now I have look at your array and get it in my head and then scroll down and look at the actual rendering of the component.
Chris: Kind of marry the two up in my mind. You're like, "For what?" You know?
Chris: Where is the real value?
Dave: For three links in a navigation. You know?
Dave: Unfortunately. But it's interesting. Yeah. I feel like my whole life, my whole career has been this oscillation between the client said they wanted it configurable, so we're going to offer configurations. So, we build out all this configuration, Web flow, super WordPress. We're doing all this configuration, and then, guess what. They don't want a configuration. They want me to do it.
Now I've just made my life harder. [Laughter] Then I go back to, "Guess what. You're getting a Jekyll site." Then I do the Jekyll site, and then they're like, "Hey, we're going to go back to Web flow," or whatever.
Dave: You're just like, "Ah!" Anyway. It's just been -- I feel like there's a yin-yang of desires.
Chris: I get you.
Dave: Even on a small team, people may not actually know what they want. It sounds great to configure a UI. I think it is great in most circumstances, but then it can just be harder.
Dave: I was thinking of one more example of a configurable UI that actually is kind of good and longstanding is the browser Chrome. You choose what buttons go in there and what plugins show up. Then you have your identity thing and then your hamburger shish kabob thing.
Chris: Hmm. Like your browser is a version of configurable UI?
Dave: Yeah, you can right click it, then it's like, "Hey. You want to add buttons to your UI? Customize toolbar," and there are all these buttons on there.
Chris: Yeah. You can literally just click and drag them around (in the case of browser extension icons and stuff). Yeah, I think about that, too.
How would you describe that? It's a slightly different concept because, behind the scenes, that's probably a configuration-based UI. But it would be really hard to do if it wasn't.
Chris: In this case, maybe these show up in the browser because they're an array.
Chris: That have an index of which one shows up first, and all they have to do is save that index order for you. Then it'll just build itself that way when it needs to be built. If you didn't choose some configuration-based thing to do this, that would be much harder to pull off.
[Banjo music starts]
Chris: This episode of ShopTalk Show is brought to you in part by Netlify. You know one of the things Netlify does is it can run cloud functions for you. Meaning that even though you have this static site as your base, you can still run Lambdas, essentially. You run them at local URLs to your site, so there's no cores issues. It's so cool.
Netlify makes that so much easier because they offer things like the Netlify functions product and like Netlify auth. Functions are just so awesome. It's just such a powerful way to handle doing back-end tasks even though your front-end side is essentially static. That's the new paradigm. That's what Jamstack is.
They have long-running functions as well, so it's not just necessarily a really quick running Lambda. If there are longer, beefier tasks you need to do, Netlify can handle that well.
Here's a brand new one. This is just hot off the presses. They have scheduled functions now as well. Meaning that if you want to say, "Hey, run this every day. Run this every hour. Run this on the 1st of February (kind of thing)," what you might think of as cron, Netlify can do that, too. This just dropped into Netlify Lab, so I think you've got to turn it on and all that, but you can do that as well.
I've used this kind of thing in the past. If you have a site with timely content in it like, oh, say a site with a list of conferences, you want to run that so that it could maybe fetch the conferences that are relevant to today's date. Build the site. Then have that site be updated in the new build. Kind of important to run that on a schedule. Netlify offers that, too.
Good job. Thanks, Netlify. Bye-bye.
[Banjo music stops]
Chris: Yeah. Do you expect that out of your UIs? That's an interesting thing, too. You open up VS Code. You have a lot of choice in how you want that app to behave. You can turn on and off sidebar icons. You can drag them around in different orders. You can take that console and drag it somewhere totally different if you want to, open it like a tab. There's just a lot of control you have over it, whereas perhaps in sublime text or something, they were more opinionated. You had some control, but not nearly that level of control. Which is better?
Dave: Yeah. No, I mean that's a good thing. Like Slack. You don't really control -- you can change the theme color, but you don't really control the UI, right?
Chris: Not really.
Dave: You can drag channels into the starred channel. You can kind of rearrange channels. I was thinking of Notion, another app I use all the time. Would Notion even work if you couldn't customize the sidebar? [Laughter] Probably not, right? It would just be an utter failure, right?
Chris: Right, but they draw the line with customizability on Notion. There's no color picker in Notion.
Dave: Oh, yeah.
Chris: Not even a color picker. You can't even -- you know -- and I kind of like that. It means that unlike a Word document, which the chances are if you let the intern go hog wild with the design choices in a Word document, it's going to be nigh unreadable.
Dave: Yeah, you've got purple H1s real quick.
Chris: But you can't. You almost can't make an ugly Notion document. I've always appreciated that.
Dave: There's some uniformity to it that's really nice. Yeah. No... Yeah. This is all interesting. Yeah, you can't change the hyperlink colors. They limit how much you can do.
Chris: Yeah, I'm sure that's very much an on purpose thing.
Dave: But maybe that's more file system, like when you have trees of content. You want to be able to drag them around, or whatever. I wonder if there are subtle rules here.
Chris: Yeah. Is it just an outcome of configuration UI? As soon as you've built your UI from configuration, it just becomes a lot easier to make it customizable. So, why not? You know? You're a hop, skip, and a jump from making it customizable. Maybe just allow it.
Dave: Yeah, maybe that's the difference. Configuration is a data-driven generation of the UI, and customizable means the user can manipulate that configuration file or that configuration store.
Chris: Yeah, possibly. There's probably a master one that it defaults to.
Chris: But then you can marry that up with a customized one or just slap it in local storage - or whatever.
Dave: Yeah, how deep do you go on this? CodePen, I could see as right on the fence of something you'd want to offer a big, customizable UI with. I think Luro, too. Just purely for Luro, it's like on and off would be my first thing. Just a little "hide this."
Chris: Yeah. Exactly. Yeah, dip your toes first and see how painful it is.
Dave: I may actually--for Luro, because I've been thinking about that--start ENV VAR, like a process.env, like turn this off, turn that off.
Dave: I can disable whole routes in chunks of the app if I need to.
Dave: That would be kind of something to think about.
Chris: What if you have a business account - or whatever? You've purchased accounts for everybody that works for you. At the business level, you can set your browsers list and say, "We don't really care about IE 11 anymore because we've set our browser support higher than that." When I'm looking around MDN, I don't need to see IE 11 support charts.
Chris: You can just hide them. Those support charts are really thick [laughter] on MDN.
Chris: They can be hard to look at when they show every browser in the universe.
Chris: If you said, "These are the five browsers I care about," you could customize MDN to what your company cares about because your whole dev team is on MDN - I promise.
Dave: Yeah. Yeah. Then you just kind of--
Chris: Pretty cool.
Dave: It's all green lights from here.
Chris: Yeah, well, you just want -- if there's a red light, you want it to be more visible.
Dave: Mm-hmm. Mm-hmm.
Chris: You want it to say, "No, no, no, no." Even in our browser support thing, that's off.
Dave: Because, yeah, you'd even want -- almost like when you do "Can I use?" Not that they should steal stuff, but with "Can I use?" you can be like, "I want Safari 12. You know? That's a few versions back now.
Dave: We're on Safari 15, but we just know we have customers on Safari 12. I need to know Safari 12. That classic Jim Neilson post. You saw that, probably, about his mom's iPad didn't work, or the website for her church or something, or community group she was volunteering at didn't work.
Dave: He was like, "What's going on?" He looks at the iPad, and it's like, oh, it's like a first gen iPad Air, and it's locked to Safari 12, and it doesn't support optional chaining. That's what was causing the church website to break down. I just was like -- it's just something you don't think about. You know?
Chris: No, I mean I think about it more on Safari because I knew that particular version of locking, but it was interesting in that she also couldn't look at it also on her Chromebook, which also was hardware locked.
Dave: It's Chrome.
Chris: Chrome locked too.
Dave: It's Chrome. You know?
Chris: Definitely, in my brain, it's like, "If Chrome, then evergreen." You know? I need to shake that from my brain because it's fricken' not true.
Dave: Yeah. Eric Bailey had a good post, I guess, on CSS-Tricks about evergreen is not always updated - or something.
Chris: Right. Yeah, exactly.
Dave: Ah, man. There's a lot to think about. You know what I mean?
Chris: Yeah, there really is. In this case, the solution isn't even that bad. It just means we should do the Babel thing and send down a bundle for it. It doesn't mean that we have to Babelize.
Dave: But do you think that's manifested in the tooling? Let's manifest it. Come on. [Laughter] Split differential serving.
I don't know that it's manifested in the tooling. I don't think my Nuxt app builds an IE bundle. You know what I mean?
Chris: Yes, I do. I think you're 100% right. I think if we were all still managing our Gulp files that there would be some Gulp pattern to do this that would have gotten popular. That would have solved it, but that's not true anymore. The default settings of bundlers aren't "give me two bundles." That would be kind of cool if that was a default.
What if Vite did that, like out of the box Vite said, "Every time we build your site, we're going to build it twice, an old and a new"? It's not. It's not a default.
Dave: It's not a default, so maybe you have to ask for it. I don't know.
Dave: I had an interesting situation -- speaking of optional chaining -- in my Nuxt app, or Vue. I guess this is a Vue thing. In Vue 2, you can't V if post question mark author or hmm dot, question dot. You can't use the optional chaining in a Vue 2 template. You can in Vue 3, but then I could install this whole other Babel transform in my Nuxt conf and do all this stuff.
Dave: I punted on it. I think it would actually lead to really nice, cleaner code, but I just was like, I don't know. With a big framework--
I guess it's not big. But with a framework like Nuxt, is yonking out the Babel, is taking ownership of the Babel transform really a smart thing to do? I think that's where I was kind of like--
Chris: Ahh, there it is.
Dave: I think that was sort of like, is that a smart move or am I just entering a world of hurt?
Dave: I know Babel is very tested. Lots of people use it. I'm sure lots of people use this plugin, but I just was like, I don't know if old Dave Rupert has the energy to fight Webpack for the next six weeks - or whatever. [Laughter]
Dave: Oh... Oh, okay. Yeah.
Chris: To something that's way, way faster. Some Rust-based thing - or whatever. But not if you've done any customization at all because then you run Next at the command line and it says, "Oops. Aborting on the new compiler because you're doing custom stuff."
I understand why they did it. They can't port your custom config to a new tool where that confi isn't the same.
Chris: I get it.
Chris: But the second you take control of config stuff, you better as hell know what you're doing. You know?
Chris: And realize that you're now against the grain and that there's real downside to doing it.
Dave: Yeah. No, you've got to think about it.
Chris: Well, talking about configuration-based UI, there was a request in here. It came in from a listener (who requested to be anonymous, which is perfectly fine, of course) that wanted to talk about design tokens and specifically their history, which I'm not super qualified to talk about, I would say. Although, I know that Jina Bolt -- or just Jina, right?
Dave: Jina Anne, yeah.
Chris: Jina Anne perhaps coined it.
Chris: In the early days of Salesforce stuff. Maybe that was the origin of it. Just did tremendous work there and is occasionally not credited for it properly, so I guess we can attempt to at least get that right.
But I always think of design tokens as the classic is colors. Right?
Chris: You say brand colors red, and that can manifest itself in CSS. I can brand color red. But I don't know that that's a design token at that point. That's just a CSS custom property or a variable (if you're using a preprocessor).
I think the point of design tokens is that you pull it back a level, and you say, "I'm going to put these tokens in some other language."
Chris: I'm going to put them in JSON, or I'm going to put them in a YAML file or invent a syntax or put them in an Excel file. I don't know, but something that is a little bit more language agnostic than just CSS is, or even if you're going to put them in CSS, then you have built tooling to yank them out of CSS if you need them.
The point is that these things should be usable by all sorts of stuff. You should be able to pull them into your Figma. You should be able to pull them into your iOS app or your Android app.
Chris: It's the size of things: small, medium, large. Maybe you have column widths or something. Maybe you have special filters that just your app uses and the expression of that filter is a design token.
Chris: Or your timings. How do things feel when they open and close? That could be a token. Like the animation. Do you have a special shake animation or something? That could be a design token - all those things.
They just wanted to hear us talk about it to some degree. I don't know the deep history, but I do love the idea of it, especially the second you have two things that you're building instead of one.
A lot of times, I just work on websites, so I kind of don't go down the road. I just put them all in CSS. But if I had two things, if I was building an iOS app, believe me, I'd be looking into this.
Dave: You nailed the history there. I think what it's really about is having a shared terminology for things because I can name a variable brand color grayish 500. You know?
Dave: But the iOS app doesn't know that. They don't call it brand color grayish 500. They call it Inspired Desert. [Laughter]
Dave: You know? And so Desert Calm and grayish 500 are the same color but just named differently because it takes the human naming system a step back. That happens at a higher level, so everyone is operating from the same variable names, viable meaning. I think that's pretty powerful in and of itself.
But like you, Chris, Paravel hasn't really jumped on the tokens thing until maybe kind of recently. Now that we've been using Figma more, Figma kind of has this concept of styles inside your Figma, and you can use a plugin to export the styles. Now you have tokens.
We're actually kind of bullish on that just because it's kind of cool to just have, like, "Here are the colors, and here are the styles. Here's how they're organized. If you don't like it, you have to invent new ones, but this is just what we use." Then everybody -- your Figma app and your Web app and your iOS app and your Android app and your Sass variables and your CSS variables, they're all using the same thing. That's pretty powerful from a distribution perspective.
Dave: There was recently the W3C. There's a community group or maybe a standards group for tokens. Design tokens are kind of like there's an official format and that's supported by Amazon's style dictionary.
Chris: Oh... really? Nice. Yeah. I should have known that.
Dave: Amazon style dictionary, and then there's another one.
Chris: Is it totally unique? Did they invent a syntax or is it like JSON?
Dave: You know it's weird. I think they all had their own. Theo had one and design style dictionary had one. But it's basically just a very loose, like, name value, like a P-value structure.
Dave: P-value description, I think, is what it is. But I think there's keywords like font, color, gradient. There are some keywords that they have kind of all agreed on as sort of some common tokens in there.
Dave: Color, font. I think you just said them, but color, font, gradient, spacing, border, timing - stuff like that. I'd have to get into what those officially are, but the good news is there's some standardization here happening. Hopefully, it just gets better as things go forward. It's not just like, "I invented it, and so now it's this weird thing we have to live with for the rest of our lives." [Laughter]
Dave: It's a bit more standardized on what you call things.
Chris: I like the idea of getting the format right because then tooling can build itself around the standard. I like that more and more. I feel like when a processor errors, every processor in the world just invented a format. They're like, "Oh, well, we'll just throw it this object." But there was no effort made of, like, maybe we should make a standard error format for a processor, and all processors will use that error format. Wouldn't that be nice? Not a thing, you know.
But then there are good examples, too. That browsers list one we mentioned is good. Somebody had a desire. It probably came from the auto-prefixer people that there should be a way to describe what browsers you're trying to support.
They said, "Rather than us just inventing it, we are going to invent it, but we're going to call it this. It's going to be a separate repo. We're going to try to get Babel to support it. We're going to try to get other things that care about what browsers you support - all using the standard format." That one was kind of a success story.
Chris: I think now when tools come out that need to support a list of browsers, it's in people's brains. They're like, "Oh, I'll just use that format."
Dave: For me, I'm getting more bullish on them. We weren't there, but I think Figma actually is maybe the gateway drug just because it's a website.
Dave: It's in Web.
Dave: Let's make our website and the design website use the same variables.
Dave: Kind of interesting.
Chris: That would be nice.
Chris: Ours was good for years, and then we had this -- so here's just a situation, right?
There's all our colors. We have ten of them or something: yellow, blue, red - blah-blah-blah. But then it comes to grays. Five grays isn't enough for a website. We have 20 grays. We just decided we're going to have a level of 20, and I think that's about the right number. Maybe a little high. Maybe you could get away with 12, 15, 16, or something like that, but we have 20 and I don't regret it.
Chris: Five ain't gonna cut it. It's not happening. Not enough grays.
Chris: We have this thing, and they're kind of tinted, and they have some spirit to them beyond just gradient between gray on black.
Dave: Yeah. Yeah. Usually, it's just like a fade the luminosity, right? The HSL, you fade L from zero. You do 0, 10, 20, 30, 40, 50. Right?
Chris: Right. Right.
Chris: I was just learning yesterday from the Discord. We were playing around with this grayscale idea in that if all three numbers of RGB are the same, then that's gray, and that if you're trying to make a scale of grays, that you can just kind of like choose a scale from zero to 256.
Chris: You just use the same number for all three, and it's a pretty easy, programmatic way to do it. Even though my brain is like, "If programmatic color then HSL." [Laughter]
Dave: Yeah. Yeah. Yeah.
Chris: That's changing a little bit. We'll see when LCH drops and stuff. LCH is the HSL of the future.
Dave: Whoa! Whoa!
Chris: It could be interesting.
Dave: LCH is HSL of future. All right.
Chris: Yeah. Write that down.
Dave: That's a good episode title, Chris Enns. Lock it in.
Chris: [Laughter] Umm... Where was I going with this? Okay, so we have 20 grays. At the time, this was pre- before anybody thinking about us maybe someday having a light mode.
Chris: CodePen is naturally dark, right? We have just gray in the middle, and then we named our colors gray light (moving away, lighter, from the middle) and gray dark (moving away, darker, from the middle).
Chris: Named them such, and they were correct in Figma and they perfectly matched our Sass variables at the time - for years.
Dave: Did you work with my coworkers on this naming scheme? [Laughter]
Chris: No. Do you like it?
Chris: It works fine, except for that if you call it gray light and gray dark, and then you try to make an inversed colored theme, you're screwed because now the names are wrong now.
Chris: Gray light means gray dark, and you're screwed. So, we decided to throw that all away, and we were variabilizing CodePen anyway doing some work in that regard. Just changed the system to just basically just 1 through 20, gray 1 through gray 20. They don't mean anything. They're just a scale of grays. If you were to reverse that scale, fine. It's still gray 1 through 20. It doesn't mean anything.
Dave: Do you invert the colors? Do you--?
Chris: Yeah, you change the scale. Now one used to be really dark and now one is really light.
Dave: Okay. Okay. Now your gray 1 is gray 20 - or whatever? I guess the source of truth version, yeah.
Chris: Yeah, exactly. It's what it used to be. You can get pretty far. We haven't quite figured it out, but maybe all the way. Maybe to the point where all we do is redefine these grays in a light mode and we're done.
Dave: Mm-hmm. Mm-hmm.
Chris: That would be awesome.
Dave: I like that. That's actually pretty good.
Chris: Yeah, but now our Figma names are wrong because we didn't update that. We kind of left them, and I don't have a good mental mapping of gray light five, what does that mean now? [Laughter]
Dave: Right. Right.
Chris: We've just got to kind of update them.
Dave: You can't do those switch-a-roos like if you were designing the dark and light mode in Figma. You can't really do the switch-a-roos there, right?
Chris: I don't think so, actually. I think we'll have to have two scales over there - or something. Yeah, that's a little unfortunate.
Dave: Yeah, you need the light scale.
Chris: You can't say, "In this document," or temporarily redefine all these color variables. Yeah, I don't think that's possible.
Dave: Light and dark, those words are problematic not in the social justice sense, although they may be, but when you're talking light, are you talking about the theme is light colored or the browser is light? Is it light mode?
Chris: Or is it relatively light to the next color by it.
Dave: Yes! Yeah.
Dave: Those words are just hard.
Chris: Yeah, they're bad words. "Don't use them," is my advice.
Dave: Yeah. I tried to find Japanese Kanji that would actually fit this better, [laughter] but that was not a rabbit hole that was successful. But I just was like, is it a limit of English? Is English the problem? English might be the problem, so is there a country that has--? Germany has the perfect way to describe hue scales.
Chris: Maybe, because you can have your red, green, blue - whatever - and those are fine because you can redefine them a little bit when you change modes. But what if you had a blue, a light blue, and a dark blue, and a pink, and a light pink, and a dark pink?
Chris: Are they still--? Does that map well, or does dark pink turn light pink in light mode - or whatever? Eck...
Dave: I'm taking it so far here, but P3, the display P3--
Dave: There are new pinks, Chris. Pinks you've never seen before.
Dave: They are beautiful, powerful, and vibrant, and they exist only on this one color spectrum, [laughter] not RGB.
Dave: That's the other trick is now, with multiple color scales, we're talking about colors. It's very difficult.
Chris: It really is! I've been really looking into this because I had this blog, this draft blog post idea where I just want to tell you about the new things coming to color with one paragraph of why you should care.
Dave: Mm-hmm. Mm-hmm.
Chris: It's so hard to write because it turned out I didn't really understand all this all that well. There are so many things at play that are different.
I called the draft blog post a Whistle-stop Tour of the New Color Function. It's really hard to do a whistle-stop tour because you can't. You have to say a lot to have any meaning in this world.
For example, all of the stuff we have now is SRGB as the color mode (I think is the right word to say).
Dave: Okay. Yeah.
Chris: Then there are functions that map what you give that function to that color mode. And so, there's some terminology in there. The way that RGB does it is it has this model that's like a cube. There are polar coordinates that handle that, which is fine, but you're still in the SRGB mode.
HSL maps it differently. There's a different model of describing those colors, but it still goes back to that same mode. So, if something changes like there's a new mode, like display P3, that's just totally different than RGB. Then there are two things that are changing. There's the function and how it's described and how you map a color over there and the mode itself is different. It has these more colors, but there are two things that are changing, not just one. Oh... tricky.
Then there can be more. Like in the case of P3, I think there's only one method - or whatever - at the moment to talk to it, which is the color function. You say it's color P3. Then you pass it these three values that map to that space. But that wider mode -- the word "gamut" gets involved, too.
Dave: Yeah. Yeah.
Chris: You have this lab color, an LCH color, and stuff. They're a little bit like RGB and HSL, but they use this wider gamut to get there.
This is really weird. You're like, "There's pinker pinks." Right?
Chris: You can describe a pink that's so pink that it's outside even the realm of monitors today. Eric Portis was describing this in the Discord thing.
Chris: That's even pinker than Panic's fancy pink on their fancy Panic website. It's so outside of it that it's the pinkest pink ever known to possible to describe by math. Then what happens is that gamut sucks it back in, and it maps it on this weird 3D map to the closest pink that it can get to that pink.
Chris: But then as monitors evolve, it will become pinker, as it's possible to display that pinkness.
Dave: Ooh! Yes.
Chris: Isn't that wild?
Dave: In the future, monitors will have more pink.
Chris: It's cool to have a color model, I guess, that's wider than the monitors rather than SRGB right now, which is not capable of expressing through math the colors that our monitors are capable of. We're catching up, but we're catching up past where we are instead of must mapping to what monitors have now. It's so crazy.
Chris: And they want it to be human usable, too. They want these functions to be -- and I don't know how successful all that is, necessarily, but they're at odds.
There's this idea. There's this great Adam Argyle tweet of HSL and how borked it is. You could have three colors in HSL that all have the same L that are definitely not the same lightness.
Chris: They want to say, "Well, that's unusable for designers." You can rotate the hue. What the heck is that?
Now, in LCH, the HSL of the future, if you have the same lightness there, it really is truly the same lightness. And the way they've modeled it is let's say it has the same level of richness as a color. Then you make a gradient to another color that's quite rich. It's never going to travel through territory in the model that's less rich. It's just going to go from rich to rich rather than in SRG model. Just because of the math and the way things are mapped that it could travel through some rich color territory or it could travel through bummer gray town.
Dave: Yeah, it's going to go through brown town.
Chris: Yeah. [Laughter]
Dave: And just take a trip there, yeah, every time.
Chris: How fascinating!
Dave: Yeah. No, it's fascinating. The way they show these, they're like, "Look at this 3D orb that's living." [Laughter] We're all going to need VR crud.
Chris: Yeah, right.
Dave: To pick colors. We're like, "Okay, I'm in the gamma quadrant, and I'm going to select this pink node." That's the future of color.
Chris: Yeah. Lots of stuff changing there. I can't say I totally explained it all. But woo! Fun.
Dave: Well, that makes me want to change my hyperlinks to pink on my website. Anyway, I'll figure that out.
Chris: I really like the idea of picking a pink that is not possible to display yet. Hyper pink.
Dave: Oh, just cyber pink.
Dave: That's what it's called. Yes!
Dave: Oh, cyber pink. Beautiful. Gonna get there. Gonna get there.
Chris: All right.
Dave: Let's wrap it up. Man, we only did one question, but we'll answer more questions next time.
Chris: That's okay.
Dave: Thank you, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for 16 tweets a month.
Join us over in the Discord, D-d-d-d-discord, patreon.com/shoptalkshow. We have YouTube now. Hopefully, some more coming out. Chris, do you got anything else you'd like to say?
Chris: [Deep inhale] ShopTalkShow.com.