Transcript

[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show. I'm Dave--in the shed--Rupert. With me is Chris--in the office--Coyier. Hey, Chris. You probably didn't recognize me because I rearranged the office. It's different now. There's a plant behind me.

Chris Coyier: I did. Did you go 180 degrees?

Dave: I 180'd the whole fricken' office. The mega bookshelf is even more mega now. I got all my Gundams up.

Chris: Okay.

Dave: It's great. We're doing good.

Chris: Yeah, it's a cooler background. It looks kind of futuristic. You know when you watch sci-fi movies where everything is just super bright for some reason?

Dave: Like white rim, yeah, yeah. That's... yeah. The sun goes past every single window in my office, like directly beams its bright radiation into my... [laughter] and it hurt my eyeballs, and so I just had the windows closed all the time. And so, I said, "I'm going to change that," and just put my back to the sun.

Chris: Yeah. Also, we're three for three today for having musical instruments behind us.

Dave: Yeah! Look... see...

Chris: Three being Brad Frost. He's on the show today. What's up, Brad?

00:01:22

Brad Frost: Hey! Thanks for having me.

Chris: Yeah!

Brad: Good to be here.

Chris: Good. Yeah. Thanks.

Brad: With our musical instruments behind us.

Chris: Yeah. [Laughter] Barely counts. I'm like, "What are you doing back there, you little piece of junk?" Little plastic thing for children, but it counts.

Dave: It counts.

Chris: It produces sound.

This is a big show because it's 601. We just finished. We just got past our milestone, and we did the future of the Web stuff. Now, all of a sudden, we're going to roll into talking about the future of the Web more.

This never happens on ShopTalk Show. First of all, we get some questions and comments from y'all. Keep them coming in. That's really extremely valuable for the show.

But a bunch of them came in that just had a link in it to a post by Brad Frost that's like, "Wow, guys. You need to talk about this." A straight-up request to talk about this, this being a global design system. That's what Brad's post is called, "A Global Design System," and it's quite a shout-out for the world coming together on a technology thing.

Hopefully, I've characterized that okay. That is our plan. We got Brad here. Brad liked the idea of talking about it on the show, too. Probably are going to be talking about this a lot in your life, Brad. And it sounds like you're pretty serious about it, so let's do this thing.

Dave: Yeah. Give us the elevator pitch, Brad.

Chris: Yeah.

Dave: What is a global design system and why do I need it?

[Laughter]

00:02:57

Brad: Oh, man.

Chris: Yeah.

Brad: Elevator pitch. Basically, I think what we are doing right now is spinning our wheels and rebuilding the same crap again and again and again and again and again for no real good reason. And so, what I would love to see is kind of a single sort of source of truth, as it were, in design system speak for things (common meat and potatoes stuff) like alerts and text fields and select fields and radio fields and accordions and tabs and all of just the common fair UI components we see the world over.

And in creating a global design system, we would basically dramatically improve the quality and accessibility of the world's websites and Web apps and stuff because we don't have to worry about the designers copying and pasting things wrong or omitting ARIA or whatever. They just kind of get the solutions for free, and it has all the good stuff baked right into it, right?

Chris: Which you kind of already get in a regular design system, right? I think you kind of start the post by kind of cheering on the idea that design systems themselves were a good idea and have now become kind of a standard practice.

Brad: Yeah, they are a good idea, and now it's time to take them further. Right?

Yeah, what we see at this micro level, at an organization-wide level, is, "Hey, let's create the single source of truth for tabs, for accordions, for form controls, for just basic common fare sort of stuff that we see across many different applications at an organization." Wouldn't you know, by creating that source of truth, it prevents--

Our work is with mega-corporations that have hundreds if not thousands of different digital products and teams governing and managing and creating stuff for those. You talk about the savings of having a bunch of developers no longer having to build a button from scratch every time they need a button. Instead, they could just reach for the design systems button. That saves up their human brains and potential to work on more important, more fulfilling projects than sort of reinventing the same damn thing for the 17th time. Right?

I talk about this in the post. There's this irony emerges, right? The need why we're all clamoring for design systems at an organization level is just like, "Hey, let's prevent this waste. Let's prevent this sort of just wasted energy -- time, effort, money -- that goes into designing, building, shipping, maintaining, et cetera all of these things again, again, and again. Let's just do that once and, hey, that actually works."

But whenever you zoom out, which is my lens as a design system consultant that works across many different design systems and have done that for the past decade, I see the same crap again and again and again and again. And all of the teams are all eventually coming to the same conclusions. We have an alert that (guess what) it's got an error variant. It's got a warning variant. It's got a success variant (probably like an info variant). And there's probably a slot for an icon if you need it - maybe.

You've got some body stuff. Maybe it has a headline in it. Maybe it doesn't. But in any case, here is this thing that has a certain shape to it. It has a limited kind of feature set.

When you cut across the world's design systems, you see the exact same thing again and again and again. Manifested differently. Maybe built-in different technologies. Maybe aesthetically it looks wildly different or can look wildly different, and that's something to sort of get into. But semantically, structurally, behaviorally, these things are identical. Right?

What if we collectively said, "Here's this thing called an alert. [Laughter] It's got a couple of variants to it. It might have an X button in it. It might not be dismissible - or whatever." We could, for a couple dozen components, basically say, "Here is the kind of 80/20 rule (the majority of the use cases for something. Let's get that out there," and most people can reach for that to sort of handle their stuff.

Forms is a huge one. If you talk about how many probably billions of accessibility errors there are on the Web that have to do with a label not being associated with an input, if we just removed that entirely and just said, "Here's the component. You pass in the label under the hood. It does the right thing. It always kind of creates the relationship between the label and the input." That would be a massive win [laughter] for the Web (right), for the quality of the Web.

What do we have instead? We have, well, let's yell at developers harder and louder to get them to care about this stuff.

Chris: You said in the post, "We have been doing that. It's not working."

00:08:49

Brad: Yeah, it's not working. And when you look at these, so many accessibility issues are just these total low-hanging fruit things. It's like rather than sort of chastising people and just slapping them on the wrist, coupled with, "Well, it depends. The context matters," no, no, no. For most use cases for form controls, there is a basic shape. There is an agreed-upon sort of thing, and it just gets executed differently, weirdly, and incorrectly across the world.

What if we were to sort of focus our attention on, like, let's just get this right for the majority of the use cases, put that up, have the whole world (including you guys) go, "Here's the world's text field component." You would be an idiot to not use it.

[[Laughter]

Brad: Done. Right?

Chris: Yeah, maybe that because there is... My mind goes a million directions. You do need some kind of marketing for it, right? You would need to convince people to use it and maybe negging is the way to do it to say [laughter], "You're going to do it wrong, so use this."

But circling back to the alert one because you spelled the alert one out pretty nicely, right? I think you're right. There tends to be four states to them. Sometimes they have headers. Sometimes they don't. Sometimes they have icons. Sometimes they don't. Sometimes they have X buttons. Sometimes they don't.

That's three things, and maybe, as we put stuff in the bucket of options for that particular component, now we're up to, say, 87% of needs, right? But not all of it. I wonder if you've thought about that type of thing. Are you cool with 87%? Are you trying to get to 100%?

Brad: Yeah. I think that that's not realistic to try to get to 100%. This, I think, brings up one of the things that I sort of spell out in the post is that I am seeing this as a layer on top of HTML because I think the efforts to date -- Dave, I know you have a lot of firsthand experience with this -- is like, "Let's get this into HTML, into the spec." With that, when you're working at that level, you have to get to 100%, right? You need to handle the 100% of use cases and, "What about this? What about this weird edge case?"

Chris: Hmm...

00:11:30

Brad: By creating a layer that sits on top of it, you sort of give yourself permission to be like, "Here is just the common fare stuff, the overwhelming majority of use cases, but doesn't necessarily need to be--" A button for a global design system doesn't need to support your custom SVG starburst animated wowie-zowie button. But it is going to support the types of buttons you see on most websites [laughter] that you interact with. Right?

Dave: The basic jobs, yeah.

Brad: Basic jobs, right, and I think that that's so much of this is this has to be pragmatic and practical. It's the thing that breaks my heart that I go into all of these organizations and everyone is just burning their energy rebuilding this stuff again and again.

It's hard as a consultant because your job is to sort of have them come to the conclusions, but I could just fast-forward to the end and you're going to end up with a component that looks like this, sounds like this, shaped like this. It's going to do these things. It's not going to do these other things.

It's just like, you do that for as many years [laughter] as I've done it and you're just like, "Okay. This is where my mind goes." Wouldn't it be nice...? [Laughter]

Dave: It's a little... It's a trick. You have to convince them that it was their idea, sort of. But almost like, "Oh, yeah. I'll come up with this great element that you click these buttons and then it'll show different things."

Brad: Right.

Dave: It's like, "That's tabs." [Laughter]

Brad: Yeah, exactly. It's so important to stress this and talk about it in the post. We've worked with Fortune 500 companies. We've worked with e-commerce companies. We've worked with enterprise Web apps. We've worked with nonprofits. We've worked with startups. We've worked with all this stuff.

The stuff is the same across the board. It doesn't... You are not creating the Fortune 500 company tabs. Tabs are tabs are tabs are tabs are tabs. it doesn't matter, this stuff.

If we had a global design system that kind of took care of the common fare stuff, it frees the teams up to focus on, "How do we wield these UI ingredients to create things that are special for our specific line of work?"

I think that that's the more interesting stuff, like, "How do we create and focus our efforts on creating the custom wowie-zowie components or the highly interactive things, or we use accordions in this way because this is our audience?" Just focusing more on here's what our organization does differently and to free teams up to focus on that rather than having to sort of rebuild badges. [Laughter]

Dave: Just kind of coming up from whole cloth, like from scratch, right?

00:14:55

Brad: Yeah. Yeah, and again, it's just like... We work with teams who have often been on that journey, so they've been at this for maybe a year, maybe three years - or whatever. You all are there, right? You all have products and things, and you've built these things.

It's like, okay, it takes a while to get to the critical mass, like, "Yeah, we've got our component library. Now we're ready to go. We don't have to do this." But there's a lot of effort to just get to that point.

Chris: Hmm...

Brad: Then the redesign happens and, "Oh, we're going to burn it down," or "We're going to redo...."

Chris: Right. Maybe you ended up in a good spot, but it took you years to get there.

Brad: Yeah. Yeah.

Chris: Then when we start over... Got it. I could see that being disheartening for somebody, too, or switches jobs or something, or is tasked with building a new one of these and almost have that heart sinking like, "Okay..."

Brad: Yeah.

Chris: "Let's just do literally exactly what we did at the last job."

Brad: Yeah. Yeah.

00:15:55

[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Jam. That's jam.dev. An awesome URL. Go to jam.dev/shop.

A really clever bug reporting tool, and it's for internally on teams. Imagine you're in Slack with a fellow developer and they send you a thing, like, "Oh, on the item page, that's broken," or something. I'm super guilty of sending this to people I work with, just thinking in my head, like, "Oh, well, just go to the item page and look. Then you'll see the error, too, if you're on my branch or you've pulled master or whatever."

But maybe they don't see it. That's not enough information. What if it was effortless to still be that lazy but also give that other developer all the information they could need to make sure that they can reproduce that bug because it's just as easy as taking a screenshot?

If you see the bug and it's visual in some way, which that's my job in the world, you drag a screenshot over it in the browser, and then you can optionally annotate it, like point at it or write something if you need to or whatever. But you don't even have to do that. By virtue of you having done it in the browser, you get all this additional information like all the console output is there. If there's an error in the console, which is highly likely in a JavaScript application, they'll see that (without you having to remember to screenshot that or copy and paste it or whatever), and the network requests, and all the information about the browser that you are in at the moment, and version, and on what operating system and device and all that stuff, reproduction steps. You can add comments to it, too.

But what you have to do is just take a screenshot quick and be like, "This is a bug." Effortlessly small. What a clever product. Then that becomes the bug report. So, check it all out at jam.dev/shop. I love it!

[Banjo music stops]

00:17:54

Dave: My experience with building Luro is, you know, I look at a lot of design systems, import them into Luro. It's test cases. I'm doing the Figmas and I'm doing the Storybooks and importing all this stuff.

What's uncanny is just no two design systems are the same, which is like, for a very systematized machine -- we're all thinking in systems, like, "What does this need to do? What does it need to be called?" -- none of them are the same. That was a very shocking revelation to me because we have all these people drinking from the same well, drinking the same Kool-Aid, but then we end up with totally different things at the end.

Even in the same organization, the Figma and the Storybook are 100,000% different. It's like, "Why?! What happened?" I mean I know what happened.

Chris: Are there any similarities? There must... like the actual componentry.

Dave: I mean like the button is always correct [laughter] but beyond that, it's very weird. Things are called different. Things are shaped different.

Brad: Yeah. They're called different, but again sort of conceptually they're identical. I think that's the thing that we've seen in our work is someone might call it alert variant=warning and then the next team calls it alert style=warning - or whatever it is. Or maybe error or danger instead of error or something.

These are arbitrary differences. That's part of the frustration is that it's not healthy drift. It's unintentional drift.

Chris: That's funny. Yeah, so you've got to get people to... Hopefully, people wouldn't care that much. If you were provided with a bunch of value, you're probably not going to be too picky about the name of the attributes.

Brad: Chris, you'd be surprised at how pedantic people can be. [Laughter]

Chris: Oh, I know they can. But things can change, too. I think the predominant opinion on tabs versus spaces now is, "I don't care. I just want the editor to be configured correctly."

Brad: Yeah.

Chris: "So that when I press the keys that I'm already used to pressing that it gets consistent output." That's the most normal.

Brad: Yep.

Chris: You might have a dumb little pedantic opinion. But you probably don't care that much because text editors are that good.

Brad: Yeah, it doesn't matter.

Chris: Yeah.

00:20:16

Brad: Ultimately, your opinions don't matter. People are weird and get hung up on certain things.

Chris: Yeah.

Brad: But for the majority of people... and things like Linters and stuff are a great example. We're increasingly getting to a point where we could conceptualize. And we're doing this with AI as well. We're able to conceptualize, "Here's a thing. It's called an alert. It's got this shape to it." Then the machines actually generate the stuff.

Chris: Hmm...

Brad: Increasingly, the TypeScript versus no TypeScript, yeah, any of that stuff, is falling by the wayside because who cares, really? At the end of the day, we want a thing called an alert that we could put on our webpage. What's going on under the hood (the HTML, the semantics of it, half of the styles, the majority of the styles, really), nobody cares, nor should they. Right?

I think that there's some interesting stuff tied up in here with HTML Web components and stuff like that. I love it. At the same time, I'm fully in favor of wholesale removing a lot of front-end development from the majority of application developers. I don't think that they should have to understand a whole lot of Markup. I think that they should be able to be like, "I need an alert. I need a grid of cards. I need these badges, this button group with these things in them, a pagination component, and there's my category detail page." They shouldn't have to know the semantic markup of that. They should just be able to pull from components and focus on their job.

Dave: Maybe another way to put it-

[Laughter]

Dave: I'm helping you out, Brad. You're just killing yourself with the ShopTalk guys. No--

[Laughter]

Brad: That's great. That's great. Yeah. This is me pouring gasoline over myself.

Dave: Just... Oh, God. You did it, man.

[Laughter]

Dave: No, we talk about pits of success, right? Like, how do you make it to where if somebody who doesn't know what their doing ends up kind of in the right place?

I think label for some ID input ID is just a classic blunder. And so, how do you create a pit where even if it's not all HTML, they didn't (for lack of a better term) fuck it up?

Chris: Right.

00:22:58

Brad: Yeah. Yeah. How? We talk about those all the time in design systems. How do you make the easy thing the right thing? That's what we're after, right? How do we do that?

Now, I think, technologically, it's possible to actually sort of deliver a solution that is theme-able, customizable, extensible, whatever. It's not so rigid where it's going to look exactly like this and you have to hack a bunch of CSS in order to get it on brand. No, it's absolutely possible to serve these things as aesthetically blank slates but all the behavior, the right semantics, all of that stuff is in place.

Chris: That's a good place to go with this, and I think that seemed to be where your vision was is that it's largely un-styled. You'd think that the success of this thing would be that.

Brad: It has to be. It has to be. That's why some of the reactions to it and stuff was really interesting. "Oh, well, we have material designer. We have bootstrap. This is just another of that." It's like, no, these things are great. People reach for them. They come with a default aesthetic that takes labor, takes work to undo and then redo and customize and make these and bend these things to your will. That's what we see time and again in our work is the teams that have adopted these things and making a big old mess because they have to sort of hack it and whatever.

The idea of having it as, like, here's this vanilla base, fully un-styled, BYOB (brand), bring your own brand, to here's your theme CSS custom properties. You flow your tokens through these things.

Chris: Hmm...

Brad: Do whatever you need to do.

Chris: Okay, so it's un-styled but not particularly challenging to style. I'm homing in on this because I think there's a whole bunch of people out there -- not that I have any data to back this up -- reach for a design system, one that's publicly available (of which there are many, many, many - several of which you already named)--

Brad: Mm-hmm.

Chris: --because it provides design.

Brad: Yeah.

Chris: That's what they're trying to get out of it. They might care a little bit about accessibility or something. But probably not as much as "I'm getting free design out of this. That's why I picked it."

Brad: Mm-hmm. Yep.

Chris: And so, I'm not going to pick this weird one that Brad made.

Brad: Yeah. I'm not making this, by the way.

[Laughter]

Chris: No, you're not.

Brad: Just making that perfectly clear.

Chris: No, the world is going to make this. We're going to come together like a Michael Jackson thing and hold hands.

00:25:52

Brad: I think that that's just it. Yeah, we are the world, and here's the tailwind UI theme for the global design system. Here's the bootstrap theme. Here's the material design theme. Here's whatever.

Chris: Yeah. I think that's a strong choice. There are themes available.

Brad: Yeah, absolutely.

Chris: So, I still can get the free design if I want. But I also cannot get the free design, which that's whatever Wells Fargo is going to do.

Brad: Undergirding it all is this vanilla base that is agnostic to pretty much anything, right?

Chris: Yeah. That seems kind of best of both worlds, which is cool.

Brad: But has ... smart as it needs to. This is stuff that I'm... It's a bit out of my depth. I have some experience with it, but it's things like logical properties and things like writing modes and things like that. That's the stuff that's really hard that would be great if this foundationally can take care of it. Then people are able to sprinkle their own... Do what they need to do aesthetically with it. But at the root level, it's kind of taking care of the hard and/or easily mess-up-able stuff, so then people are able to sort of, yeah, focus on the brand, focus on the UX of this stuff.

Chris: Yeah.

Brad: The stuff that really differentiates your site versus the next. But then I totally could envision an ecosystem around it where there's just the gold theme libraries for accomplishing what you need to accomplish.

Chris: So, how does--? You're the atomic design guy, too. It was one of the notes I jotted down, too, is that you imagine this as at any particular level of that base thinking. Didn't you always say the atom level? What's the smallest one in atomic design?

Brad: Atoms, yeah.

Chris: Is it atoms? Yeah, the really individual stuff. Those are hard to screw up, right? There's not a wrong button. A button can only be wrong in context. But just a button element sitting there can't be inherently incorrect. But it's the combination of things that make them incorrect, like the form label one that you brought up, which is a great one.

Brad: Yeah.

Chris: Unbelievable how much people screw that up. But once those two things are combined, that's what you called a molecule, right? That's two things combined. Do you think that this design system is more molecule-y than atom-y?

Brad: No. I'd say that it's more like atom-y--

Chris: All of it?

Brad: --molecule or maybe some organism level, like more complex things. But in general.

Chris: It's at the bottom, not the top.

00:28:33

Brad: In general, they're more like, yeah, simple combinations of a couple of elements that are working together as a group. That's, I think, the value of it.

Then I also think that it's important for certain things to be wildly composable. Something like a card, it's like, what would a global design system card component look like?

Chris: A div.

Brad: I'll tell you, because we've done this with a bunch of our clients, it looks like a box that has a border, maybe a border-radius, maybe a box shadow. Maybe there's a variant where it strips all that stuff away and it's just kind of invisible container for it. That's literally it, right? It's got a couple of slots where you could put the content. That's not the job of the global design system or even an organization-wide design system is not to figure out what goes in the box. It's just providing the box as a concept.

Here's a box. You put stuff in. Then elsewhere, at a different layer of this ecosystem, the teams, the e-commerce team is saying, "Okay, I'm going to take the card. I'm going to put this stuff in it in order to create the product card."

Chris: Yeah.

Brad: The analytics team is going to put this stuff in it to make the customer data card - or whatever.

Chris: Sure. It might be the difference between a really public design system and an internal one whereas if I'm building this and it's only for me that my tendency to turn up the dial on how opinionated I want that component, like I almost want it kind of high.

Brad: Yeah.

Chris: I want this to be so specific to us whereas this, that card component is a perfect example. Dial it down to almost zero; no opinion at all. Would you maybe try to keep that as close to zero across the board, like the alert component? Don't enforce that the header is at the top of an alert. For some reason, maybe it's in the middle - or something. That's an intentional dialing down of the opinionatedness of that alert.

I think that would be an advantage of a design system. This has kept that opinionatedness level -- whatever place you dial it -- consistent.

Brad: Yeah. Yeah, that's exactly right. It's like these things would need to just be incredible flexible to be able... Some people want to stuff whatever - Charles Dickens - into their alert component, and that should be possible even though it's probably not advisable.

Chris: [Laughter]

Brad: There are people... Yeah. Again, we've seen it again and again. [Laughter]

Chris: Yeah.

Brad: It probably has an icon. Maybe sometimes it doesn't. It might have a heading and some body text to the alert. Sometimes it doesn't. Maybe there's even a subhead to this, or maybe you're putting a button group inside of it.

00:31:25

Chris: Right. But if it's all the way down to zero, it's almost the value gets lower.

Brad: But it isn't, though.

Chris: It's not?

Brad: Because there's ARIA stuff attached to it. I think that there's really something to even something like a card where it's like, "What's the value of just shipping this box?" It's like, well, maybe especially because this thing would be connected and updatable, right? You update things under the hood to improve accessibility, to improve - whatever - internationalization, to improve - whatever. Sprinkle some metadata in there that makes--

The concept of a card deserves to exist and for people to use it and interact with it in this way. Under the hood, standards people, people who really know what's what can continue to improve upon the accessibility, the semantics, the structure, all of that stuff. Then everyone downstream from that that's ingesting these things get to be the beneficiaries.

Chris: Yeah, I wonder if just the consistent usage of it gives you opportunity going forward--

Brad: Yeah.

Chris: --to be like, well, all this stuff uses the card, so we have this level of control.

Brad: Yeah. I think that even for something that's, quite frankly, just kind of a div or whatever--

Chris: Right.

Brad: --to carve it out as, "Here's this concept, the UI concept, called a card." That is connected. Then all of a sudden, there's this road towards improvement over time.

That's what we see with design systems is whenever you ship V 0.1 of an accordion component, and then you come find some errors or bugs with it, you ship the next version of it.

Chris: Hmm...

Brad: Teams pull down that new accordion component and, bada bing bada boom, those issues are fixed. Imagine doing that at a global scale. [Laughter] It's amazing. That would be incredible.

Dave: What's the response been like? I feel like I saw... Well, congrats to you for hot-dropping this and then going to the Philippines for like two weeks. That's pretty... [Laughter]

Brad: [Laughter]

Dave: That was really a pro move there. But then--

Brad: Ain't nothing like a deadline, Dave.

Dave: Yeah. I mean, hey, that's good. You just hit it and then just had a vacation of a lifetime in the Philippines.

But I feel like if I were to stereotype, Twitter was like, "Ah, hell yeah, dude!" And then Mastodon is like, "I'm not so sure about this." Maybe those are characters of those two platforms.

Brad: [Laughter]

Dave: I guess, what was--

Brad: Yeah.

00:34:13

Dave: What's the feedback like and what's kind of circling around in your head now that it's been a couple of weeks out?

Brad: Yeah. Yeah, it's a good question. I think there's a lot of enthusiasm and excitement about it. I think a lot of people... I've heard a lot of, "I've been saying this for years."

Chris, you even mentioned earlier, it's like the disheartening, like, I go to my third job, and it's like, "Oh, we're doing this again. Okay. Here we go. Wouldn't it be nice--"

It's like this isn't exactly a revolutionary idea, I feel like a lot of things that I apparently seem to be a part of. It's just like taking common knowledge and shouting it loud enough where people... [Laughter] I don't know.

Dave: [Laughter] You're the guy at the part who tells other people's jokes but louder.

[Laughter]

Dave: And so, you're like... And everyone laughs because Brad said it louder.

Brad: Yeah, yeah.

Dave: Yeah. That was good.

Brad: Yeah, that's weird. But anyway--

Dave: [Laughter]

Brad: But yeah, a lot of people... I think a lot of people were like, "Where do I sign up? How do I get involved in this?"

Chris: Oh, just immediately. That's cool.

Brad: No, it's amazing.

Chris: They just... They're like, "This is an amazing idea. I'm in." Yeah.

Brad: It was so funny. The first time... I actually had sort of spoken at a couple of conferences about it. After the first time I ever talked about it, [laughter] somebody came up to me, and they're like, "So, where is this? Where's the sign-up form?" I'm like, "I literally just said this for the first time. [Laughter] So, that's been great because I think--

Chris: Yeah.

Brad: Overwhelmingly, that is the thing. I think that the skepticism has been, "Good idea, but that would be hard." Yeah. [Laughter] Yes. Uh-huh.

Right there with you on that one, so I think that that's a valid thing is taking this from a hairbrained idea to something that actually exists - and whatever. obviously, being totally eyes wide open with it, probably a big, multifaceted effort. Probably a multiyear effort. But whatever. We're used to that stuff on the Web.

Chris: It kind of is. It reminds me of a startup or a big open-source project. It needs funding. It needs people.

Brad: Yeah.

Chris: It needs marketing.

Brad: Yeah.

Chris: It needs all the stuff.

Brad: But also, it's kind of where it lives, too, really matters because it isn't a startup or it isn't a company. I see this as a W3C-ish arena, which is to say we need a central Switzerland, Sweden, neutral kind of party that is just like, "Here is this. It is more infrastructure than it is a new company," or something like that.

Chris: Yeah, that's interesting. Yeah, you're not thinking, "Oh, we're going to roll with a benevolent dictator style."

Brad: No.

Chris: Which is a way that things can get done.

Brad: No.

Chris: It would be all committee or whatever.

Brad: And there's great work, like OpenUI is a great project.

Chris: Right.

Brad: They've already been trailblazing, I think, a lot of stuff on this. I think that this is a little bit more of a tangible outcome of what OpenUI is already doing. It's like OpenUI is kind of getting a lot of stuff to gel in order to standardize things. It's like maybe instead of again kind of going the standards route where we're going to be creating a bunch of new HTML tags, for instance, it's maybe some output on--

Chris: Yeah, they almost had a different... Wasn't that the goal (or still is) that they ultimately want the thing to be in HTML, right?

Brad: Yeah.

00:37:59

Chris: That's almost a different end goal. I wrote down one of their things because tabs is one that's easy to throw around as an obvious one that people are sick of doing. For some reason, it's the number one that I've done the most in my career that makes me the most annoyed that I'm doing it again.

But I remember... and Brian Cardell wrote about this - and everything. He has some post about tabs specifically. Remember the whole discussion about spicy sections? Dave was involved in that.

Brad: Sure do.

Chris: I think you made one, too. When you try to define what a tab is, it is nontrivial. There are a lot of things that a tab can mean. And so, they struggled with that, I think.

If we're going to pick one for actual HTML, which is a huge bar, a very high bar -- don't put sloppy crap into HTML, please -- that I think, in the end, was too hard. There was no one definition that worked.

Brad: That's, I think, a great cautionary tale or a great tale that it really exemplifies this idea of, like, when you're having to deal with 100% of use cases, it's going to go sideways because it's going to get pulled apart by all the details. But when you go out of that standards layer -- again, don't get crap in HTML -- you have this idea of it. It's like, well, we have this place where we could at least handle the majority, the vast majority of use cases for these things and handle that and ship that and have success with this stuff.

Chris: I'm fascinated by that.

Brad: And maybe, over time, that could graduate to a standard. Maybe some of them don't ever.

I kind of see these things, and I talk about it in the post. I see HTML as the real low-level IKEA parts, the dowel rods and the screws and whatever.

Chris: Right. HTML is not going to ship a combined label and input, probably. It's too weird.

Brad: But all of those things exist but people don't use them on their own at that kind of atomic level. They use them together, and that's where everybody screws it up. So, wouldn't it be great to provide the combination of those things? [Laughter]

Just forms. You want to talk about MVP. We ship a global design system that just has form controls in it for basic rudimentary stuff like a text field and radio group, checkbox field, select field, text area field. Right?

Chris: Yeah.

Brad: Just that only does the label input matching and has some sensible stuff for validation states.

00:40:46

Chris: Great conversations, though, because if you're trying to... The alert one. I always like to be so practical about this. Maybe I should dial it back. Now there's a dialog element in HTML.

Brad: Yeah.

Chris: It's so good. I just used it yesterday. I found one little thing I didn't like, but I was like, "Holy crap! You open it and it's a fricken' thing with focus trap in the middle of the screen."

Brad: Beautiful.

Chris: It's supported across the board now, baseline support. Wow, right? If your opinion on what goes inside of that dialog is zero, you don't need a component because you already got one. HTML already gave it to you.

Brad: Mm-hmm.

Chris: It's starting to happen more and more. Maybe you saw it. I think this might have happened while you were in the Philippines, so please... It's cool.

iOS shipped input type=checkbox switch. You put this little attribute on it, and it looks exactly like a toggle.

Brad: Beautiful.

Chris: I'm like, "Man, that's in a lot of design systems, the little back-and-forth toggle." Great.

Then they shipped... put the name attribute on (What are those things called?) detail summary. Now you've got a native accordion or the mutually exclusive type of accordion, anyway. Really neat.

This conversation is old, too. Remember? Input type=date came out ten years ago, and we're all like, "Oh, thank god we don't need date pickers anymore."

Brad: [Laughter]

Chris: Which didn't quite pan out the way we all wanted it to.

Brad: Yeah. Right.

Chris: But HTML is kind of trying to be this.

Brad: No, it's great. But it moves at its own pace layer.

Chris: Right.

Brad: A necessarily slow, comprehensive layer, and we want to protect that, right? We want HTML to move at the pace that it needs to work at. We want browsers to move at the pace that they work at to get things right.

But there's this need. Right now, the chasm is so big. It's been like, "Here are all the raw ingredients." Then, "Do your thing on top of them." That's all we've had to work with, and there's just so much room for error in that gap.

That's why I'm putting this idea of a global design system in between there where it's like, "Yeah, you can have a date picker component that's using input type date - whatever - under the hood." That one is maybe too complicated of a thing.

Chris: Yeah. I get you.

Brad: Set that aside, but it's like the toggle is a great example of one where maybe there is a toggle or maybe there is a modal in the global design system that's using the dialog tag under the hood. It's using HTML's raw ingredients, but it's maybe adding a little bit more.

Chris: Yeah, it kind of has to, right? You have to call JavaScript APIs to open it and stuff.

Brad: Because the dialog tag... my understanding of it is it doesn't have an X button, for instance. Right?

Chris: It does not.

Brad: You've got to bring that to the party.

Chris: BYO.

Brad: That's a good example where maybe the global design system's modal component would be composed, so using the dialog tag.

Chris: I would use it. [Laughter]

Brad: But then it also has a button that's tab-able.

Chris: Yeah.

Brad: Keyboard accessible. It's like, boy, howdy. How many times have we seen that screwed up?

00:43:56

Chris: Well, think of it, too. I just did this the other day. I was like, "Ah, crap. It doesn't have an X button," so I did it. I was like, "Oh, now I need an X button." I'm sure everybody has their own little muscle memory for this.

If you're like most companies in the world, you use the literal letter X. That's nice. I love it when they do that. [Laughter]

Dave: [Laughter] Good. Yeah.

Chris: Or if you're really cool, you use the Unicode multiplication symbol, which looks a lot sexier.

Dave: You could use Elon X.

Brad: [Laughter]

Chris: I don't mind it. But of course, that's going to read as a multiplication symbol, so your opportunity to screw that up has already surfaced.

Dave: Times. Times. [Laughter] Button. Times.

[Laughter]

Chris: Yeah.

Dave: Oh...

Chris: Uh-huh. But of course, that's not going to happen in this global design system. We are going to have that solved for you. It's going to have a correct label on it already. It's going to be wired up to the right API for correctly closing the modal and returning focus to where it came from.

00:44:47

Dave: I will say I was involved in OpenUI. When I read your post, I was like, "Good luck, brother." [Laughter] That was my feeling because I spent two years trying to get a tabs thing to work, and it kind of got swooped and pooped by ARIA, and that's fine.

Brad: Mm-hmm.

Dave: Closing doors is good for me. I like closed doors because that just means I don't go that way anymore. Tabs is a hard problem.

Oh, the success story of spicy sections was we showed a Web component to browser makers, and I had multiple people from Chrome say, "Yeah, we could do that." That is amazing. That's something--

Brad: Mm-hmm.

Dave: If I'm giving you jQuery UI, they'd be like, "I don't know. What am I looking at?" If I give you React crud, it's like, "Ah... I'm not sure how much of that is React and how much is Web platform." But you show a Web component, and it's like, "Yeah. We could probably do that. That seems doable."

Now you're talking about an object that's real and close to the platform, not talking about something that's kind of buried into a 12-dependency hell.

Brad: That's precisely it. This stuff is wielding HTML. It's close to the metal. It is all Web standards stuff, just these nice, little, encapsulated Web standards bundles that we deliver.

Now there's a whole thing, and I have a forthcoming article on the state of Web components and stuff. It's like that ain't done. The dust hasn't quite settled there. I think that, from an implementation standpoint, we're close to being able to, I think, realize this, but I don't think that it would be without challenges at the Web component platform levels. But I think the scale and the scope of this and what this would be, I think would be a really good lens by which to shore up maybe some of those deficiencies with Web components right now where it's like, "Oh, it'd be great if this could work a little better SSR-wise or whatever." [Laughter]

Chris: Yeah. Yeah.

Brad: All of that.

Chris: Participate on forums. Yeah, you're going to run into about every edge case there is, probably, with doing it that way. It does seem to be kind of like, to me, the only answer. Let's say before Web components were in as decent a spot as they are in now, and your goal in the world was a global design system. Your choices were either to just ship it as HTML and CSS (kind of bootstrap style) -- they didn't go in on a framework -- or go in on a framework, which you know is super limited, so you'd have to make this really hard choice of, like, "Ooh, I guess we'll build it for the top three," or something.

Brad: Yeah.

Chris: We've seen that happen before. We'll build it for Svelte, React, and Vue - or something like that. That's probably not where this is headed, right? You have no interest in building a multi-JavaScript framework global design system.

Brad: No. No. That's just it. This is all very common fare, agnostic stuff.

Chris: Right.

00:48:22

Brad: I think, even stepping away from Web components as a technology -- although, I think that is a win there -- I think of these things more kind of conceptually. It's like what are the requirements for a sensible alert component. What are the names? What is the API design for an alert component, for instance?

Then that can be manifested in all sorts of different technologies, including things like Swift or Flutter or other things like that. So, it doesn't necessarily have to be even Web-specific. It's more about just identifying these things as concepts and bundling them up. But then, yeah, when it comes to the Web, shipping them in a way that can travel anywhere. I think that you've got to be talking about Web components, I think, imperfect as they are.

Chris: Right. Right. Although, it'd be interesting to come up with a list of possibilities. You could just have recommended HTML and CSS and deliver it in that way.

Brad: Yeah. I mean that was always the thing, right? Just coming back, and forgive me for harping on... I think that a lot of accessibility folks are really well-intentioned and want to do the right things. A lot of times I'm just like, "Give me the copy-paste tab HTML." Then it just ends up in this big sort of circular, "Well, it depends," and whatever.

I fundamentally don't buy that. Again, if you're talking about 100% use cases for every tabs on the Internet, sure it depends. But for the overwhelming majority of use cases of a thing, there is actually a correct answer for this stuff when it comes to basic HTML structure and whatever.

It's like, let's harness that, centralize that stuff. Sure, maybe... Here's the HTML, what's happening inside of the Shadow DOM for whatever. It's like if you can't use Web components for whatever reason, here's that copy-paste version. But for in so far as you're able, really have this as a truly consumable component library because that's directly connected. Again, you get those updates for free. You get the true value of it.

00:50:55

Chris: Yeah. Copy and paste kind of stops that. Dave and I were just talking about there's this popular one that specifically says, "This is not a component library." It's called Shadcn. I don't know if you've seen this one, Brad, but it's unique in the world of design systems a little bit in that it's kind of like a CLI.

You're like, "Oh, I need an alert." You type in npxshadcdnaddalert. I'm sure I have that all wrong, but it just then goes and gets the code and just plops it into your project. Then you just have it. It's not NPM installed. It's not versioned. It's not anything.

I mean they might internally have versions or something, but they've just barfed the code for that component now into your system and you're on your own. Whatever you want to do to it, you can do.

Brad: Yeah. That was a good little boilerplate. Yeah, it was cool. I like it.

Chris: I found it cool and interesting. Then to see it become as popular as it is, is interesting to me. People are, I think, attracted to the idea of how it's used as much as what it's giving you.

Brad: Yeah.

Chris: They like that idea. I don't know. I would have never thought of that. Without seeing them have broke that ground, I would have never thought that that could be a successful way to distribute a design system in a million years.

00:52:07

Brad: That's similar to what my team is working on at Big Medium with AI.

Chris: Is it?

Brad: It's like, "I need this thing," and it gives you the thing. You still have complete control over the generated source code, but what we're able to do is dial it into a specific set of code guidelines, like, "Here are our standards. Here are our code standards, and we want you to be trained on that. And we want you to give me the next component that looks exactly like the other ones in the same sort of shape and whatever."

It's cool because, again, we're getting away from developers needing to focus on all of the eye-watering details of every if-else statement or every, "Oh, did you get the TypeScript syntax right on this thing?" Increasingly, that's becoming a commodity, right?

There are, I think, some really interesting intersections between what's happening with AI and code, in general, and also this idea of global design systems. It really gets existential pretty quickly because it's like, "Well, what exactly are we doing here?" But I think if there's one overarching thing to say about this and why I care so deeply about this idea is I see incredibly smart, incredibly talented people totally wasting their finite time on Earth here rebuilding that alert. We're better than that.

Chris: Yeah.

Brad: We have more to do on this planet than debug does the accordion close when you click on it again? Let's collectively get out of that and actually be able to use our brains.

We see it all the time with our design system stuff. It's just like, "What do I do with my hands if I don't have to rebuild this rectangle again?" We're like, "Here are some thoughts." They're like, "Oh!"

Chris: Yeah.

Brad: [Laughter]

Chris: Gardening? It's great.

Brad: It's like I care about people being able to realize their potential as human beings.

00:54:27

Chris: You want to get as many people to use this, which I think that's the core tenant. You wouldn't have called it a global design system if you were shooting for 300 users. You want a lot of users. You want all the users, which I think is interesting.

You've got to make choices that maintain the maximum number of users and that's the challenge here. Every choice you make... You start with everybody in the world as your target audience that needs one of these things.

Brad: Mm-hmm.

Chris: Then every choice you make from that day forward, you're going to lose some.

Brad: Yeah, sure.

Chris: You're going to say, "Oh, we're going to use Web components." "Oh, I hate those." You've lost 10% right there - or something like that.

Brad: Mm-hmm. Yep.

Chris: Even if it's not even a rational choice, you lose some people.

Brad: Yeah.

Chris: "We're going to ship it un-styled," and you've got to BYO theme. Ah, you lost some people.

Brad: Yep.

Chris: "Oh, we don't have this component because we don't think it's an appropriate one to put in here." Oh, you lost somebody. But now it's your job to try not to lose people and not build the Homer Car. [Laughter]

Brad: Yeah. Yeah.

Chris: You have two frames.

Brad: Yeah, and I think that that's... and we see it all the time, right? We see designers do things that's kind of sort of the basic standard thing. But they want to do something fancy that's largely an arbitrary choice. I think the gist with this is here's really pragmatic, meat and potatoes kind of stuff that you build up enough of that that you'd be crazy not to use it. It's like, "Oh, if you do want to do weird, wonky, different things, things that are parallel but different, you still have all of the tools at your disposal to do it the old-fashioned way and build things the way that you want to do it."

But I think that what we see in our work is, as time goes on as a design system becomes more mature, there's more external pressure, I think, from stakeholders, like, "Wait. If we use this, we could build this thing in a day. But if we want to not use that, it's going to take us how long?" Again, it just becomes a no-brainer, right? I think that for this common fare stuff that we encounter again and again and again, that's I think the goal is that you would want it to be like, "Here it is. It's done. It's solved," and you work with the grain of this, you get all this great stuff for free, and you can move on to bigger, better things. I think that that'd be extremely attractive.

But yeah, people are going to continue to be weird and have opinions on, "Oh, I want to do it like this. I call it this other name." Great. Go do that. Let's see how your boss [laughter] likes you saying that that's going to take you three weeks to do instead of three minutes. [Laughter]

00:57:17

Dave: Well, here's the secret with Web components. You can just say, "Class my button extends Brad's button," and no one fucking knows the difference.

[Laughter]

Dave: It's a trick.

Brad: It's beautiful. It's beautiful.

Chris: Yeah. Extends keyword, a beautiful thing.

Dave: Hey, [laughter] I think we do have to wrap this up here, Brad. Thank you so much for coming on and talking about this. For people who aren't following you and giving you money, how can they do that?

Brad: [Laughter] My personal website is bradfrost.com. My business website--me and my team have been working on great stuff along these lines--is bigmedium.com. You can also check out... I did want to plug it. Can we plug it?

Dave: Yeah. Yeah. Let's go! Let's go!

Chris: Yeah, we've got to do this.

Brad: Frostapalooza.bradfrost.com.

Chris: Frostapalooza is the best, perfect name for this.

Brad: Do you want to do it? I kind of want to hear you guys pitch it.

Chris: "Forty musicians, two great causes, one epic night." I'm just reading from the website. Brad, if you didn't know this, is a very excellent musician, talented drummer, even better bass player. I don't know if that's fair. Are you equally great at both of those things, and probably lots of others? I don't even know what your full suite of instruments is. But extremely good musician and passionate about it. You're turning 40, right?

Brad: Right.

Chris: Sorry if that's not supposed to be part of it, but Brad is turning 40.

Brad: No, that's part of it.

Chris: So, this is your Porche, man. This is your midlife crisis.

[Laughter]

Brad: I love it.

Chris: No, but Brad scouted out this beautiful church venue. Of course, I've never been. I haven't spent that much time in Pittsburgh, but I think it's called the Mr. Smalls Theater. The pictures I've seen of it are amazing.

You found the perfect date. It's August 17th, 2024, and you've invited all these people you know, including us.

Dave: Yeah!

Chris: Which is amazing. I'm bringing my banjo, and I get to play on a couple of different songs on this night. And this is an open-to-the-public event. It's literally on Ticketmaster. I don't know how you pulled that off. But people can go to frostapalooza.bradfrost.com, click that "GET YOUR TICKETS" button, and you can literally come and see this show.

I think you're probably on every song, right? You're just up there the whole time because it's celebrating you and your 40th birthday and all that. And so, your family members, friends.

And the songs are all over the map. I'm on the country ones, but there's rock-n-roll and funk and all kinds of stuff, right?

All the people playing, there's a big list on this. It's going to benefit people. I don't know. I'm just very much looking forward to it. What an incredible idea for your 40th, man.

Brad: It is going to be amazing. The idea of having 40+ musicians for a night of music unlocks so many possibilities. [Laughter] And the fact that we have... it's cutting across a lot of different genres, cutting across a bunch of different styles, and you have all of these people, especially vocalists and stuff. It's really like certain vibes or sort of wheelhouses and stuff.

Chris: Yeah.

Brad: To be able to lean into all of this stuff and be like, "Oh, yeah."

Chris: You're so versatile, it'll be fine, right?

Brad: Yeah, and my brother, too, will be holding it down on drums, so there's a core band that is incredibly versatile.

Chris: Yeah.

Brad: Basically, my college band, plus my wife, plus my brother. Then there's going to be this sort of swirl, like ever-changing sort of amorphous, supergroup kind of oozing all over the stage from song to song.

Chris: The Frost Waltz. That's what I'm going to call it.

Brad: It's going to be so cool. It's going to be so fun. We have all sorts of ideas and fun stuff. It's an unapologetically just positive, we're all going to get together, just total love fest, party, amazing time. And I love it.

Dave: I'm excited.

Brad: I'm so excited about it! [Laughter] We've been doing a lot of work, so we have a year. That's the other sort of thing. We have a year. We've been scheming this thing for actually over a year, so it's like a year to plan 40 people playing music on a single night, and all of these people that I know are incredibly creative, wonderful people. And so, all of these ideas are kind of coming out of the woodwork, like, "Oh, it'd be cool if we did this." I'm like, "Yeah, that'd be great! Let's do it." [Laughter] It snowballed.

Dave: That's part of the reason I'm going. I'm playing, but I really just love trainwrecks, and I can't wait to see 40 people who haven't played together get into a room and play for 3 hours.

[Laughter]

Brad: But this is the thing--

Dave: It's going to be great. What could go wrong? It's going to be great.

Brad: [Laughter]

Chris: I heard there's free LSD, so that's why I'm going.

Brad: [Laughter]

Chris: [Laughter]

Brad: But that's the thing, the whole audience is going to be in on the joke, right? They're not expecting to see the Talking Heads perform, right? They're expecting to see this big, beautiful, snowball, trainwreck thing. That's the fun of it is we're all just in on it together, and it's just going to be a blast.

Dave: Well, cool. All right, well, that should be fun. Shop-o-maniacs, if you want to hang out in Pittsburgh, head over to frostapalooza.bradfrost.com.

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 Mastodon this time, [email protected]. If you want to join the real party, join us in the D-d-d-d-discord, patreon.com/shoptalkshow.

Chris, do you got anything else you'd like to say?

Chris: Um... ShopTalkShow.com - dum-ba-da-dum-bum bum-bum.