Search

374: VisBug with Adam Argyle

Download MP3

Adam Argyle stops by to talk with Dave and Chris about his web design tool, VisBug, and interesting ways designers and developers can use it to be involved in modern web design and development.

Tags:

Guests

Adam Argyle

Adam Argyle

Web · Social

Google Chrome CSS Developer Relations, VisBug maker.

Time Jump Links

  • 01:24 Guest introduction
  • 08:23 How do you decide what to include in VisBug?
  • 15:33 Sponsor: .Design from Porkbun.com
  • 16:43 What is the workflow?
  • 21:53 Systems and design process
  • 23:16 Lateral vs linearr thinking
  • 25:10 How do I capture changes or handoff?
  • 33:34 Sponsor: Datadog Synthetics
  • 34:18 Where do I use VisBug?
  • 36:41 Using local overrides to make changes available
  • 38:19 It's just a web component
  • 40:37 Breaking things is fun
  • 46:59 DOM breakpoints
  • 52:53 Accessibility tooling

Transcript

[Banjo music]

Chris Coyier: Just Build Websites! Nailed it.

Dave Rupert: [Laughter]

Adam Argyle: Dave, were you in on that?

Chris: In spirit he is, yeah.

Dave: Hey there, Shop-o-maniacs. You're listening to an analog edition of the ShopTalk Show. I'm Dave--Make the Logo Bigger--Rupert and with me is Chris--Two Pixels to the Left-- Coyier. Hey, Chris. How ya doin'?

Chris: Good. Good. Good. Yeah, we were just working on our first design system library.

Dave: Mm-hmm.

Chris: Just with our mouths, you know, like we're going to decide what words we could use, you know, under what parameters and such. No, actually, with us is a really special guest. He's a cool guy, cool job. He's actually Google's first acoustic guitar advocate.

[Laughter]

Chris: You'd think, "Why have one of those?" but they're just experimenting with new roles and new things. It's Mr. Adam Argyle. Hi.

Adam: Yo-yo-yo, hi. Thanks for having me on.

Chris: Yeah. I can't wait. This is really cool. That's a joke title, but you have a title that nobody has ever had before at Google, I believe, right?

Adam: I think so. There's been others that have done the role but didn't have the title, I suppose, or they shared it. I still share it with them. I'm happy to share it. It's not mine.

Chris: The title is CSS Advocate, or is that not it? Is that a side title or is that the real thing?

Adam: No, that's the real thing. That was the opening they had. That's what I interviewed and applied for. Yeah.

Chris: Yeah. Cool. Wow. What a cool role. Definitely, you still have a pinned tweet of getting that role because it's not that old. Has it been a year yet? Maybe not even.

Adam: It has not even been a year and, yet, I cherish this. Yeah.

Chris: Cool. Cool job. A lot of people congratulating you, but also with their lips curled of jealousy too, I feel like.

Adam: I think so too. I even felt bad taking it. I was like surely there are other folks that are better.

Chris: No. Come on. Don't sell yourself short.

Adam: Not as excited. Not as excited. I'm more excited.

[Laughter]

Chris: Fair enough. So, how cool is that? I feel like, of the people I've known at Google over the years, your job really is, probably is, open-ended and as cool as that. What are you excited about? Here's a bunch of stuff that I think we could push forward in the world. I'm just going to do that. Then also, prove that I'm doing a good job somehow with numbers. I find that Google likes the numbers.

Adam: Google likes the numbers. Yeah, Deveraux has this. Yeah, how do you prove your worth? Right? This is really difficult for anyone and Deveraux is like, "Well, look at my views." It's like, views, um, I mean sure that's a number and it's a high number, but is that really your value? You're like, "I guess not. YouTube is not my value. Yeah."

Chris: Yeah. Well, views is a thing. Yeah, who knows. Of the numbers I've been asked for over the years, they're always not random, but I made this template. How many people use the template under these circumstances? I'm like, well, let me call my data analyst for you.

I don't know, but I get it because that's the deal. You've got a cool job. You better cough up some numbers, yo.

Anyway, Addy is your boss? That's weird.

Adam: Addy is my boss. Seriously, that is--

Chris: Not weird, but it's weird.

Adam: It's … it's amazing. It's not weird. Oh, it's weird to me.

Chris: Yeah.

Adam: I read his books. I used Backbone. I've been a fanboy of pretty much Googlers, well, anyone that was willing to go share their information. I'm like, "Wow. Thank you so much."

Chris: Yeah.

Adam: I would admire them and put them on pedestals. Yeah, Addy is way there at the top and now he's kind of like a homie. I'm friends with him on Insta.

Chris: Yeah.

Adam: I send him direct messages. I'm like, "Yo, Addy."

Chris: I see he's just signed up for Instagram. I don't know if just signed up, but I saw him follow me and I followed him back. Now he's doing the Addy thing on Instagram. You know how he puts a little more effort into things--

Adam: Yeah.

Chris: --than the next guy, I feel like. One of his tweets will be like an eight-page thing explaining how mobile performance works with little graphics reminding you, you need to swipe through to get the whole story and stuff. I'm like, holy crap. [Laughter]

Adam: Yeah, he's going full in. It looks good too. Yeah, new venue.

Chris: Yeah, but this is about you. You have this job, there are other interesting things to talk about too. We've met in person. The heck if I remember where, when, or why.

Adam: It was At Event Apart Seattle, man.

Chris: Yeah.

Adam: It was because I hit you up. I was like [gasps]

Chris: [Laughter]

Adam: I'm a fanboy of Chris too! I must say hi.

Chris: Yeah. Those hotel lobbies, they melt together, don't they?

[Laughter]

Adam: Yeah.

Chris: There's always a fireplace and a cosmopolitan.

Adam: And some nuts, right? Nuts and beer.

Chris: Nuts, generally, yeah. We talked about all kinds of stuff, so I knew you'd be a great guest for the show because you have a rich history of building websites in kind of a real world way, right? Before this, you were just building websites for the common man. [Laughter]

Adam: Yep, sites and apps for over ten years. Yep, and I loved that. Oh, man, a huge fan. I mean I love JavaScript and all the technical ways we've gone. I love seeing how JAMstack has evolved and how that compares with all the server-side stuff.

Anyway, yes, I could riff on this for days. I'm a huge fan of pretty much anything that makes UI. But my favorite part is the part I can show my mom or my kids.

Chris: Ah.

Adam: Be like, "Yo, touch this button," and then it animates. I'm like, "Yeah, I did that."

Chris: Ah!

Adam: I like that part of it. It's really nice.

Chris: Yeah, the visual stuff. Yeah. Certain, certainly, yeah. It's funny how jealous back-end people of that can be. You know? I definitely work with back-end people who slave away for four months on some migration or something only to have all the fanfare happen in a 30-minute job because you made the user menu slide out from the left. Come on! Where' the love for the metrics. [Laughter]

Adam: Right.

Chris: Lowering those query times.

Adam: Just like a car.

Chris: Yeah.

Adam: Yeah. You get in a car and you're like, "Oh, this leather is really soft," and the guy who built the engine or whoever built the engine, they're like, "But the engine is so pristine and perfect."

Chris: Yeah. Yeah.

Adam: It's like, I'm not going to pop the hood. Sorry. I'm only interested in the leather.

Chris: Too bad. Where's the cupholders?

Adam: [Laughter] Yeah. You missed a spot. Yeah.

Chris: [Laughter] Then a big product that you work on, and I don't know how it's related to Google, how important it is to that job, or what is that thing called VisBug. It's a browser extension that you enable. It brings up a little toolbar and it gives you just a whole bunch of things that you can do on a website. Do you want to tell us about that, how it works, why it works, what the heck?

Adam: Yeah. Yeah, VisBug is like FireBug for designers. I wanted to sort of invigorate folks to almost break the glass on a webpage and be able to reach in there and touch those things. For so many years, the story has been, "Ah, yes. Together, we made this car," and, in this car, I'm talking about software.

We made this car and the designer is like, "Yes, but you painted it. the red is just candy apple red and I wanted--I don't know-sparkly red. They're like, "Okay, well, here. Just pop the hood. Remove the engine piece here and reach right back there. If you twist that little knob, you can change the car color."

Designers are like, "That's not really fair to ask of me to do." You call this something, Dave. You say it's scary. Oh, man. I had it pulled up. You lower the barrier of scary.

VisBug wants to lower the barrier of scary where popping the dev tools open is not an enticing thing to many, many people in the world. Now, if you spend the time to learn dev tools--

Dave: Okay.

Adam: --you are a god. You have every power that you could ever want on a webpage. But if you're not willing to learn that, you're kind of powerless. What I wanted to do was take everything that you know and love about an artboard and working on artboards and just bring that to the browser. That comes in the form of a whole bunch of tools these days. Yeah.

Chris: Well, that's cool. Was that, in retrospect, that's what this thing turned out to be or was that a guiding principle from the start?

Adam: Yeah, the start was guided by kind of two core principles. Oh, let's see. I lost the train of thought.

Chris: Well, let's say somebody comes in with a feature that would be really cool for somebody like me. Then you might even agree because you're like me. We're like, "This is a cool feature, period, because I could use this." But, it's actually a little complicated.

In VisBug, I might use it. You're kind of telling me right now, it's not super-duper for you because I've already invested in dev tools. I already know how to use dev tools and I think they're really powerful, cool, and in there.

Adam: Yep.

Chris: It almost invalidates my opinion for VisBug in a way because it's not for me. It's for the other people.

Adam: [Laughter] I think it can do so much DOM manipulation so fast, I think it's for you. I totally recovered my thought points. One of them was that most designers just want to change spacing, colors, and font size. That was the initial goal was, if I can just solve those basics, I can unblock them from tons of rework that they're doing in Sketch. They can just use the production, use our product as an artboard.

Then the other thing; I'm a huge consumer of design tools. I'm just obsessed with all of them. I've been using all these new tools that have tons of framework buy-in for the value of design system pupetting, this concept where developers can give you Legos and you can use those Legos to design with. It gets you closer to the metal in this higher fidelity design experience.

I believe in that. I think that that should continue to get hacked on. But, at the same time, I was very frustrated that everybody was investing in not the browser engine. I was like, the DOM. I was like, the Chrome renderer is amazing. Why isn't there a DOM tool that lets me actually use the layout of the browser instead of a synthetic layout?

With that kind of thought process in there, I was like, I just want to go make something that works with what everybody has today, has no framework buy-in, and just sort of -- yeah, it just works. I wanted something that just works without a framework. Anyway, those were the two tenants: give them the ability to change spacing and some basics and make sure that it's not a framework buy-in, that it just works with whatever HTML you have today.

Chris: Cool. Just to paint a picture in people's mind of what it is, there's a little bug in your toolbar. You click the bug and you get a little sidebar of tools. That's kind of the placement and structure of which was probably quite intentional because it's not trying to mimic Photoshop necessarily, but maybe, in design tools, you're used to having that bar of tools along the upper left of something.

I think, by default, it turns on kind of a measuring tool, which is kind of cool, like, where is this thing on the page? How big is it?

More importantly is maybe all the other tools, which is like, I can click onto something and then, for example, just hit the F key and now I'm controlling its font size. Then my arrow keys are enabled to pop that font size up and down.

I like what you said there, kind of the main thing designers want to do is just fiddle with some colors, sizes, and stuff. Those things are really what seem like first class citizens, to me, of this thing because of how quickly you can activate that tool and then be pressing arrow keys to be adjusting all of those values really, really kind of quickly.

Although, it does make you wish; you click something on a page, like a row of buttons. You click one of them and adjust the font size. You're just begging for the thing to increase all of the button sizes.

Adam: Oh, it can.

Chris: It can? Yeah?

Adam: It can. Yeah, so with VisBug, what kind of happened is it's almost like you're opening someone else's artboard for the first time. Like, "I just got this sketch file. Let me open it up." Then you open it up. You're like, "Who makes their groups in layers like this?" Like, "What kind of noob?"

Then you have to fiddle around and figure out it, double click, double click. Anyway, you're in explore mode so that you can start to get a tangible feel of that artboard. Then you can make some changes.

VisBug has similar things to kind of help you make selections. What you're talking about there is, "I want to select all the buttons."

Chris: Shift, click, right? I knew it.

Adam: Okay, so shift click is supported, in general. You can multi-select in VisBug. Yeah, just hold shift and click anything you want.

The cool thing about multiselect, just as a side note, is if you were to shift click an H1, H2, and H3 in a paragraph and use the font tool and hit up and down, it changes each of those fonts for each of the selected items contextually so that the flow of your typography, your relationship you have from H1 to paragraph, is maintained.

Chris: Oh, that's clever. If I select a header and a paragraph, those are widely different font size. If you were to have coded this sloppily, perhaps, when you press the up key it'd be like--I don't know--let's make them both 11, then 12, then 13 pixels, or whatever. Now you've ruined that hierarchy.

Adam: Yep, so that's just a really cool side note about multiselect. But a button, for example, has a few ways that you can go grab the rest. One is a typical hotkey in IDEs, which is Command-E. Command-E will expand your selection to the next sibling item that matches the query. It's like, "Whoever has my same class name and my same node type? Go find them." That'll expand based on what your current selected item is.

You can also hit Command-Shift-E, which will find all matches, so that could get you all buttons that have that same class name that you had selected, or there are two more ways. You could also use the search bar. The search bar, straight up, you could just type the word "button" in it and it'll go find all the buttons, or you can say "button." And specify your class names, so you can select on the DOM from that search bar, which is kind of neat.

Then the last way, which is kind of my favorite way, is when you select items with VisBug. You get this little label there that says the node name and the class names on it. Those are interactive labels. If you hover over a class name, it will draw an outline around all the matches that match that class name. If you click that class name, it selects all of those items that were matched and then you can go do a multi-selection performed operation on them.

The workflow would be, you launch VisBug. You click a button. You click the link that is in the label that says the button class name of, like, primary button or whatever it is that you're trying to target. You select all of them. You go over to your toolbar and you change the color all at once.

Instead of where you might traditionally need to go find the class name in the DOM with the dev tools and change it at the level of the class name, VisBug instead empowers you just to find all the things currently using that class name and then to perform a calculation on those. It doesn't know that you authored an underlying class. VisBug isn't that smart yet. But what it does let you do is it piggybacks on your good architecture and lets you use all those kind of fun things to make a good, healthy selection and then you could go about your task.

[Banjo music]

Chris Enns: This episode of ShopTalk Show is brought to you by something really cool. It's an alternative to .com. It's the .design domain name. In general, I'm a big fan of interesting, unique, good URL website names and especially alternatives to .com. If you're a designer and you've thought of a sweet name for your website and it isn't available under .com, check out .design. Chances are, the domain name you want is waiting for you.

You can head over to Porkbun.com and use the coupon code SHOPTALK on the checkout page to get your free .design domain name for your website. Yes, you heard that correctly. It's a free year if you go to Porkbun.com and use the coupon code SHOPTALK on the checkout page and get a free year of a .design domain name that's bundled with free email hosting, WHOIS privacy, and SSL certificates.

I don't really consider myself a designer, but I didn't want to miss out on the fun of registering a .design domain name, so I registered ipodcastbecuaseicant.design, which you can go check out and see how it worked. There are plenty of fancy companies using .design like Airbnb.design, Facebook.design, Uber.design, Adobe.design, and many more. It's exactly the same, just a domain name.

Google doesn't care and it functions the same way as a .com or .org. It just looks a little more interesting, so go check out Porkbun.com and use coupon code SHOPTALK at checkout to get a free year of a .design domain name. our thanks to Porkbun for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: It's interesting to talk about workflow a little. What is it? I guess you don't really care, right? It could be anything. You could fiddle around in here during a meeting and then have everybody just take notes. Then that's that, or you could just play around just for no reason at all just to experiment, just to try something aesthetically that you haven't tried before.

You wouldn’t want to spend an hour in here, would you? It's so precarious, right? You Command-R and it's gone.

Adam: It's ephemeral.

Chris: Yeah.

Adam: Yeah. Yeah, spending an hour in there would be interesting. I think you could spend ten minutes.

Here's a fun thing. If you wanted to spend ten minutes with VisBug, you could visit. Let's say you go to your dashboard of your application and then you get into a state where you're managing settings, for example. Then you could launch VisBug and delete everything in that settings page, rename the settings tab to profile, and then start using other elements on your page to rebuild a new one. You could leverage the majority of the page and then sort of clear out a section and redesign it a little bit.

Chris: Sure.

Adam: Yeah, you're right. Yeah.

Chris: Then when you're done, it's kind of like, yeah, okay, well, now I've thought it out loud. Now I need to build it elsewhere. I'm not telling you, like, "Hey, Adam. Get on this thing. All your changes need to intelligently map themselves to however I've coded my project."

Adam: [Laughter]

Chris: I just hit Command-S and they're live. [Laughter]

Adam: That's the dream, I think.

Chris: But it is funny because--

Adam: That's kind of the promise of FramerX and stuff. Yeah.

Chris: Yeah. Design tools, they've never hit that mark. They're begging to. The ones that are trying to get there, now they get there and then there's pushback from everybody else saying, like, "Well, it only works in React, and it only works with your weird library." The tradeoffs to get to a point where I can fiddle around with a design tool and have that be production quality code, it's still not -- like, literally nobody has done it.

Adam: Yeah.

Chris: Except for like Webflow.

Adam: Have you heard the phrase--?

Chris: [Laughter] But that doesn't count.

Adam: Well, Webflow is great. Yeah, at some point, we should talk about Webflow.

Chris: [Laughter]

Adam: Have you heard the phrase where you asked for a banana, but you've got a gorilla holding a banana?

Chris: [Laughter] No, I never have.

Adam: It's a super classic thing when you're talking about object oriented programming. You're like, I just wanted that one class, but then it was sub-classed and sub-classed. There's an inheritance chain that you didn't know was there.

Dave: Yeah.

Adam: This goes with component architecture too. You're like, I just wanted a React component, but then what you got was a gorilla holding the React component. That happens with these design tools.

These design tools, you're like, I want to go use my developer's Legos and build a new page with that. You're like, I want the banana. But then that banana comes with a whole gorilla, which is this tradeoff that you're talking about. Yeah, VisBug doesn't have that.

Chris: I've never met a designer who hasn't, at some point in their career, had the philosophical moment where they're just like, this is crazy that we do this work over here and we do this work over here. Why would we do that when one of them is production already? It's happening in the browser already. This is the design tool of the future and all these Silicon Valley nerds have not cracked this fundamental problem.

[Scoffs] I feel like now I'm about to do the same damn thing, but like, "Oh, there's some Chris philosophy for you about to drop." Maybe it's good that they're different. Maybe it's okay that there are separate places because there are separate ways of thinking and it separates this code architecture concept from an aesthetic concept and maybe that's okay.

Adam: I have a conversation piece just like this. VisBug is not like anything else because it's the only one that just edits what you currently have. You don't really create in it. It's not really a competitor to all these design tools. It's kind of a complement. It works on your page you have now. Anyway, yeah, it's right in line with what you're talking about.

Chris: Well, it is weird, right? VisBug is in a class of its own.

Adam: It is weird.

Chris: It's a design alteration tool. You literally can't create any -- although, you were kind of saying you kind of can, right? You can kind of copy and paste things that already exist.

Adam: Yeah, you can duplicate. Yeah, you can steal stuff from other webpages. Those have been some of the recent tweets. They're like, "Hey, you can just hit Command-C and copy the HTML for the item you have selected. Then go paste that HTML somewhere." Whee!

Chris: Which is weird, right? It's a workflow enablement thing that--

Adam: Yeah.

Chris: Not weird in a bad way, just like, hmm. Now what does this unlock? If that is the direction of this product, it could just take over. You haven't bet the farm on this as a product, right? It's free. It's just a browser extension.

Adam: It's free.

Chris: Yeah.

Adam: Yeah, and I hope it stays that way forever. I kind of want to go back real quick to the systems versus this design process because I think it's really awesome and I think designers are hungry to get into the details of a design system. I think that's why design systems are popular right now is, designers are like, "Yes! I want to be included in the Legos and how these rules are made." I think that we should continue attacking that and developing that. But, at the same time, we needed some tools that don't know or don't care about the system and whether or not that's to just let you get a little idea out or it's just to let someone who doesn't know anything because the dev tools are too scary, can go in there and make some changes too because it should be that easy, right? I should be able to go to a webpage and change some colors and not have it be so difficult.

If you get a design system tool, essentially, in order to change that color, I have to go learn about the system. Then I have to go figure out that this color is inheriting from this color, which is getting its hue from over here. In order for me to change that button to just a slightly darker blue, I have to go understand the universe. I know that's an exaggeration.

I think that that's good in some cases. Like you're saying, it's also not good in other ways. We might need these two worlds to coexist for almost ever. That's fine. I'm actually super happy living in these two worlds because they do, the complement each other well. They each have good tradeoffs.

Dave: I'm reading a book right now and it's talking about lateral versus linear thinking. Lateral thinking is solving problems in an indirect and creative way, kind of like, yeah, I'm not addressing the actual code. I'm just solving the problem. [Laughter] I'm trying to solve the problem in an indirect way.

Linear thinking is all about the process and the logic of the problem. I think that applies to this discussion, but just even people themselves. This gets into left brain, right brain stuff, which I don't exactly believe, but I think people go into modes of problem solving. It's like sometimes you are like, "I'm going to just solve this in a more exploratory fashion," or I'm going to solve this through a process or logic in figuring this out. I think code lends itself to the other side and things like VisBug kind of do the lateral thinking.

Chris: I like it.

Adam: Yep. I like it too. That's good. There's a book called -- oh, snap -- it's "Persistent Fools," and they have the concept of a joker. It's almost like a punk rock designer whose goal is just to go mess things up. It's almost like a troll.

They're saying, there's value in a troll because there is always a little bit of honesty in what a troll trolled, and so it's like commentary on the state of the system and the state of our tooling. VisBug is kind of a weird little skateboard statement in terms of all of our tooling right now that designers don't have debug tooling. The concept doesn't even exist anywhere, which is kind of funny.

We've had dev tools, and it's like our bread and butter. When you need dev tools, dev tools is mission critical, but designers don't have anything like that to requeue them in those moments of tweaking.

Chris: Right. Right.

Dave: I had a question. I'm playing around in VisBug. I fixed CNN. I fixed all of its problems. Okay?

[Laughter]

Dave: How do I capture my changes or how do I send those to CNN and say, "Hey, I fixed your website"? Is there a way? Do these changes get documented anywhere?

Chris: Yeah.

Dave: I know, inspector their local stylesheet, right?

Chris: …local overrides. That's what I think.

Dave: Yeah, there's like a local, independent stylesheet or whatever, but is there anything that this creates, like an artifact that can hand off to somebody?

Adam: Yeah, let's talk about handoff really quick. Real quick, for some reason, when you said, "How do--?" I started singing in my head, [singing the words] "How do I leave without you?"

Dave: [Laughter] [Singing the words] "How do I hand VisBug stuff off to development?"

[Laughter]

Adam: The whole rest of the time you're talking and I'm like, "Adam, dude, stop singing that stupid song to yourself. That's not going to help you at all."

[Laughter]

Dave: We have to pay royalties now, Adam. Thank you. Thank you.

Adam: Oh, dang-it. Wait. My rendition was terrible.

[Laughter]

Adam: The handoff is kind of funny these days. There are all sorts of cool plans and cool potentials. For example, the changes tab.

Here's something just right off the bat. VisBug changes the page with inline styles. It doesn't use the Chrome dev tools protocol. Therefore, it can't tie into the cool features that the Chrome dev tools has. It doesn't have the concept of changes or things like that, so VisBug has its own.

VisBug would like to do that, of course, in the future. Why wouldn't it? It should use the protocol if it can. Anyway, we'll get there. For now, it doesn't.

Let's say you went and you changed -- here's a really good example. You opened up a page. You look at a button and some text. You're like, this is too designer-y. There's not enough contrast. I can see it just with my eye right now.

You go to the accessibility tool in VisBug. You hover over some buttons and, sure enough, the colors aren't hitting the spec properly.

Chris: Yes. That's a super valuable thing that the whole world should use more of. Anyway, I have a question, but you tell me what you were going to say.

Adam: Yeah, so you hover. You see that it's bad. You click on the button. You expand your selection so you get all the titles. Maybe you just want to fix that one button.

You go change the colors. You use the color pickers. You increase the contrast and you recheck again with your accessibility inspector tool that's in VisBug. It says green checkboxes. Then what you can do is go to the style inspector tool, which is just above it, hover over the button, and it will tell you what colors you changed and what you changed them to.

The idea is, the style inspector tool is the one that knows the difference between what was there before and what was there since you did it. That style inspector tool, you can pin those so you can make them stick over the button that you changed with the option or alt key and clicking so that you can stick the style changes that you did right next to the element on the DOM in your page. You screenshot it and you make a really good JIRA ticket.

You're like, okay. So, I went to the site. Our accessibility contrasts is off. Here's a picture of what I changed the colors to and now we're passing. Would you, developer, please go to your system? I don't know if you're using Sass or CSS and JS. I don't really care. I'm a designer and the contrast is wrong.

Then they have the values that they want and they can go put those into the developer's system however it is that they have it. That's one way to workflow with VisBug.

Dave: Cool. That's cool. Yeah, so you can kind of just show the changes or, I guess, if you did a big layout thing, you could just screenshot the whole page, maybe.

Adam: Yeah. You could copy the DOM and paste it too, I suppose.

Dave: I liked it. I think what you said about what I said.

[Laughter]

Dave: Just like, you know, oftentimes working with a designer or something who won't open Web Inspector, I'm just like, don't tell me more padding. Tell me a number. Just give me a number. That would make my job a whole lot easier. I don't have to open a Figma file, get it to the right zoom. Hopefully, it's not 2x.

Adam: Yeah.

Dave: Then WebInspect it. It comes out to 57 pixels, which doesn't match anything. I'm totally not talking about anything I ran into today. [Laughter]

It would just be cool. Just tell me the number. [Laughter] Use this tool and tell me the number. If they can't open or operate Web Inspector, which I don't expect the whole world to, I would hope designers who work on the Web would, but not all designers only work on Web.

This tool seems to bridge that gap pretty well in terms of, like, yeah, just mess with it in here and then send me a screenshot. That's what I want.

Chris: You want the exact number. That's funny. I don't always want that, not that I would ever say no to it.

Are you worried that you're going to get it wrong and then you're going to get another ticket that says, "How about three more pixels?" and you're like, "Jesus!"?

Dave: Yep.

Chris: Yep.

Dave: You send me a redline, I'll just quit.

[Laughter]

Dave: Redline … is just -- later, everybody. Thank you. Good night. This was a great project. I hope you have the best of luck in your future.

Chris: Maybe that divide. The divide is that exact moment where a designer could be like, "Why can't I just make this change? I'm right here. I know exactly what I want. Why can't I just make it? Why do I have to make a ticket and then have somebody else make the same change? It's not an efficient use of human resources."

Or you could think of it as, one person's job is to get this just right because of aesthetics, accessibility, user experience, and stuff is the realm that they live and work in. Then that change should be passed off to somebody who has a different set of responsibilities, which is like managing the system in which this all lives in and making sure that that change doesn't just happen in this isolated, one-off kind of way. It makes that change in a place that makes sense for the larger system because that's their job and they are two different jobs. I don't know.

Adam: Amen.

Chris: Maybe. Sometimes. If you're working on a fricken' brochure site, fine.

Adam: Sometimes. Yeah, absolutely.

Chris: Then make the change real quick. You know?

Adam: No, that's a really good point, though. That is the sort of workflow. I think, while designers are hungry to get into the system and the details and we're providing more and more opportunities as time goes on to let designers in, at the same there, there are so many moments where I don't care about the system. I want this right now. I should be able to go do that right now, not care about the system, and tell the developer who does care about the system deeply that this is what I want. Can you just go make that happen in the system? I think that's a healthy relationship.

It's almost like it's service oriented architecture. This is the service that you're doing. This is the service I'm doing. We collaborate this way. I trust you to do it the best in the system. You trust me to pick something healthy visually and that's our relationship.

Anyway, yeah, this can empower the designer to feel like they can change the stuff that the developers are making because I feel like, traditionally, this relationship has almost been a little one way where a designer makes this bundle and they put a bow on it. They give you Zeplin and they give you all these comps. They redline, maybe, and maybe green line if they're doing a really good job. Then they'll hand over this bundle in this really innocent, nice way, like, "Please, engineering team. Would you implement this with Fidelity? It would make me so happy. I've given you everything you need." Like, "Look, here're ally nice SVG. It's ready to go."

Then it feels like developers always take it and they get really greedy. They're like, [scoffs] "I see a bug already. You're not consistent with your margins and there are too many font sizes." That relationship has always been kind of weird because the developer had so much power and so much control over the conversation, and so much -- eh.

Anyway, this kind of flips it a little bit, whereas, during the prototyping phase of whether you're in production and you have a bug that has to do with the German language, designers can now go use the things that the developers made without asking, just go make some changes, use that state, and use that chaos of production as an artboard, or the chaos of a prototype as an opportunity to design on. I think those are really awesome design surfaces. They're found in the browser when you're changing viewports and something shifts. Anyway, there is so much you can do now that that page is very tangible and manipulatable.

[Banjo music]

Chris Enns: This episode is sponsored by Datadog, a scalable, full stack monitoring platform. You can get user's eye view of your front-end services with Datadog Synthetics. Datadog automatically tests your application endpoints with simulated traffic from global locations, allowing your teams to proactively identify and improve issues before they affect your customers. Plus, you can build multistep browser tests simply by interacting with your application. Datadog will record your actions and automatically execute the tests and intelligently adapt to changes in your UI along the way.

You can build your first test today with a free trial of Datadog Synthetics and receive a complementary T-shirt by visiting dtdg.co/shoptalk. Our thanks to Datadog Synthetics for sponsoring this episode of ShopTalk Show.

[Banjo music]

Chris: VisBug is a Chrome extension. Does it work in Firefox, too, or is it Chrome only?

Adam: It's a custom element, so it has no affinity to Chrome or dev tools at all. That's why, if you go to visbug.web.app, the webpage, that you can try VisBug right there as not an extension because I've got it preloaded in there. You can go try before you buy. If you give it five or ten minutes on that site, you can just walk through each of the little artboards and they're all little lessons for you to teach you how VisBug works.

Chris: Oh, fun. That's nice.

Dave: Cool. Yeah. This makes it look a lot more like a sketch thing. This is fun.

Adam: That's what I wanted it to do.

Dave: Yeah.

Adam: It should look like sketch artboards that are messed up. My goal was to make artboards that provoked your design brain so that you're like, "Hey, that's not in the center," or, "There's something weird here," and then VisBug gives you the opportunity to correct it. That's how I thought it would be a good learning exercise is very tangible learning.

Anyway, yeah. It's just a custom element and I think it works in Safari Tech Preview and it works in Firefox, but it doesn't work right now as a Firefox add-on. There's a bug about instantiating a custom element class from the add-on sandbox. When you throw an extension on a page, it doesn't really get full access to the DOM. It gets a proxy relationship in there.

Anyway, the little sandbox that I get launched in, inside of Chrome, even came with little issues with getting a custom element to render. But Firefox, there's an open issue. I'm in contact with their engineers there. We would love to get VisBug everywhere because, again, VisBug, all it cares about is where is your mouse and what's the DOM underneath it. It will tell you stuff about that element or it will give you the ability to change those elements.

Chris: Yeah, it's almost a strike against wanting to use whatever protocols Chrome dev tools has for pushing its changes through that first.

Adam: I'm resisting.

Chris: Yeah.

Adam: Yeah, because right now I have no allegiance to Chrome other than the RAD individuals and they gave me an opportunity to make VisBug….

Chris: Yeah. Well, I mean, the cool thing I think you would get is then if you have local overrides enabled. Then you really do have -- all of a sudden, these changes can be more real in the way that local overrides makes real changes to real files. It can, you know.

Adam: Yeah.

Chris: Which is cool, but I'm not sure how people have dug into that yet or what kind of workflows are--

Adam: There's some cool stuff. There is a Netlify engineer, Sean. He was working on getting the changes that you make pushed up. There are plugins in VisBug, so you can make a plugin that downloads the current page as a zip, pushes it up to Netlify, and creates a new deployment that matches all the HTML and CSS you changed.

Chris: [Snickers]

Adam: So, there's that. You've already seen me do it with CodePen.

Chris: Yeah.

Adam: Where I just spin up a blank CodePen. I start copying and pasting CSS and HTML from a whole other page into CodePen.

Chris: You're saying it does it with inline styles. Does it un-inline style them before you do that or whatever; makes a little chunk of CSS that overrides or does inline styles come along with it?

Adam: The inline styles come along, yeah. I think all he was doing was document.outerhtml.

Chris: Sure.

Adam: Stick it in and post it.

Chris: Yeah, right.

Adam: But there is another really fun one, too. The concept of a webpage being downloaded as a file and then being able to open that file up and work against that like it's a local file. Then you could stick that file in drive and blah-blah-blah; share it like you do a current design file, but it's actually a webpage that you're working on locally.

Chris: Right.

Adam: There's that workflow as well.

Chris: With this big caveat that's like, nobody treat this as a production thing, right? It's just a comp to be looked at.

Adam: It's just a comp.

Chris: Yeah.

Dave: That's fun.

Chris: Cool. Because you built it without any allegiance, it's just -- what'd you call it? It uses Web components internally.

Adam: Yeah, it's just a Web component. It's vis-bug in your DOM. You can go look.

What's cool too is, as you hover around, that custom element creates a bunch of other custom elements. It's like a virus. No, just kidding; it's not a virus.

All the interactions that you have, the whole illusion that you see on that page that it's an artboard, those are all just custom elements I'm creating at the size, height, and width of the element you're hovering over. I'm positioning it absolutely in the DOM.

Chris: Yeah, it sits overtop of it, so it eats up any hover events or whatever that the original element has to some degree, yeah?

Adam: To some degree. That's one of VisBug's struggles. If VisBug became a proper dev tool, then I could intercept all JavaScript events, whereas right now I put listeners on there for click. When you click something, I'm saying, "Use capture." But if use used capture before I used capture, you can't double stamp and triple stamp.

Chris: Mm-hmm.

Adam: Anyway, the long story short is, I actually can't steal the event because you captured it first. There are scenarios where VisBug can't do certain things because it's just an element on the page and it doesn't have a promoted status anywhere.

Chris: Yeah, it's so funny how you designed it, though, because it feels like the browser is helping you but it's not. You've totally replicated. [Laughter]

Adam: Dave, I want you to click on an element in the center of a page and just hold delete. It's very satisfying. Yeah.

Dave: Clicked on an element. Let's see here.

Chris: [Sucking air] It's like a little black hole that sucks everything up.

Dave: Ooh.

Adam: It'll do it at the repeat rate of whatever you have at your computer. If your computer is set to a really fast repeat rate, in like two seconds you can just clear a page out. Poof!

[Laughter]

Adam: It's toast and you're like, "Yay! I got power!" It's just fun.

Dave: I did a murder on the page.

Chris: [Laughter]

Dave: I cracked open my page because I'm vain and that's the first thing I do. I was just like, oh, let me move the postdates above the titles. Let's just see what that does. You know? It's like, okay, I kind of like that. I don't hate it, I guess. I could kind of experiment before I even touch the code.

Chris: How did you do it? Was it a Flexbox alteration or a margin moving?

Dave: No, it was just the position. I clicked the D pad.

[Laughter]

Adam: Yeah.

Dave: Is that what it is?

Adam: It is a D pad.

Dave: D pad.

Adam: Yeah, that's the move tool.

Dave: You do D pad and then you just drag. You just drag the element. They've got a little handlebar in the middle and you drag it around. I can put my header at my footer. That actually looks kind of badass, actually. Hold on. Wait. [Laughter] Hold on.

Adam: What you're doing right now, these goosebumps you're feeling are when I knew I had landed something interesting. I was using VisBug on just a CSS Grid and my grid was kind of masonry. What I realized is that, by moving items left and right in that grid, I was exploring new layouts. I was exploring layouts with my real content in a way that no design tool has ever been able to do before and, really, no design tool could do.

I had real CSS Grid being the real renderer against my actual HTML and watching that shift around and play. I was like, I'm playing. I'm playing and experimenting and nothing really makes it this easy to play. I was like, "I made something fun! Yay!"

Dave: Yeah. No, it is. It's fun. It's that old, like--I don't know--I'm just going to mess this up. I don't know. Chris and I had a show before the ShopTalk Show called CSS Riffin.

Chris: [Snickers]

Adam: Nice.

Dave: Where we'd get a little inebriated and just mess up people's webpages.

Adam: [Gasp]

[Laughter]

Adam: I love this.

Dave: This has that spirit to it. Yeah. No, it's fun.

Adam: I'd like to talk about Chaos Design too while we're talking about how fun it is to break stuff because I agree; breaking things is fun. There's a positive side to breaking stuff, like when you're making a component. This is super important, I think, in design systems. We build components that are very ideal. It's like, "Ah, yes. My component looks great with this title that's a very normal title," but then a client or a user shows up and they write some crazy long title and it breaks your layout.

With VisBug, you can go look at your components and chaos test them. What I mean by that is you double click the title text, and you just go, blahhh, and you start typing your fingers all fast, blahhh, and you just spew a bunch of text in there. You're like, how does that handle it?

you're like a little troll in the DOM. You're like, "Okay. Well, what if I take this button and I do this to it?" [Snarls] Then you can go log a bug and be like, "I … your website and it didn't work." Anyway, in Chaos Design, you can do a lot of fun chaos testing, which I think is super valuable -- reliant components.

Dave: Do you hit any roadblocks? I'm thinking of, like, JS apps in particular, which construct a VDOM and then any change will just trigger a whole re-render of the whole component tree. Does it struggle against those sort of things?

Adam: I have seen scenarios like that, yes. There are a couple of struggles there. One is if you've got a ton of really long hash-based class names. If you use VisBug on Twitter Lite, for example, it will list all those class names. It'll be like, here are all the class names. You're like, ah, that's not very useful to me.

What becomes interesting in that particular scenario is you can hover over each of those class names and see all the other elements that match that class. You can find the one that you want, click it, and select all the elements and change them all at once. You can still do those previous workflows. It's just not very legible to your eyes, but VisBug doesn't know or care and it kind of gives you ways to work around that.

The other question you asked about, I saw this recently on GitHub.com. I was looking at the project competition meter bar. I love that I can say "meter" and you guys are like, "Yeah, I know what a meter element is."

Dave: Yeah.

Adam: Anyway, it's just fun. [Laughter] It was a meter bar and it had blue, pink, and purple. It was all cute and it looked good. I was like, I want to change those colors really quick, so I clicked them. I could see the colors. But when I changed them, they had no affect and that's because of what you're talking about. They were continuously being overwritten by whatever it was I was changing, so my changes had no affect because they were being driven by a data model. Every time something changed, they just reapplied the data model, which put it right back to where it was.

Chris: Hmm, yeah.

Dave: Wow.

Chris: React.

Adam: React. That scenario can happen, but the inverse happens too where you can use a really robust, single page application, drill in six crazy states, and then launch VisBug. Now you're actually designing against a very rich moment in your application that otherwise would have taken you a long time to recreate. You can now leverage any state.

VisBug doesn't know what states are. You can fly open a menu, like a little dropdown menu, and then launch VisBug.

Chris: Right. True.

Adam: Then edit all the options inside of there because it doesn't know. VisBug is stupid.

Chris: Yeah.

Adam: Part of its superpower is how dumb it is.

Chris: Gosh, I feel like, at least once a week, I have, like, it's not even a snippet, although I should make it a snippet where I have to go into the console and I type a set timeout. Then in the set timeout, I set it to about, oh, three seconds or so. Then I just type one line. I type "debugger;" and then I hit return. Then I go on the page really quick and I open something. Then I wait for it to hit. Then it locks the page because that debugger statement is a dev tools thing that locks the page in a weird way, but in a way that you can still interact with it and play around with stuff. [Laughter]

Adam: Yeah.

Chris: So like if you have a dropdown menu, you put that in the console, hit return, go up, open the menu, and wait. What might happen if you didn't do that is that the menu has a click outside detector. I don't know how many apps you've all worked on that have a click outside detector but, oh, my god, I feel like every app I ever have. Now, on CodePen, we even have a React component that's literally called Click Outside Detector.

[Laughter]

Chris: It's like, if you click inside it, it doesn't do anything. You click outside it, it fires; it does whatever you want. Right? It's just a super generic function.

Usually, what it does is close a menu, close a modal, or close whatever you're trying to do. It's almost like a UX expectation. Things have been closing when you click outside of them forever on operating systems and websites. It's kind of a tricky thing but, if you have coded that, which is this user expectation, it's hard to use dev tools sometimes because you come down to dev tools and click something and the fricken' menu closes. You're like, meh. Anyway--

Adam: Wait, wait, Chris. Do you know about DOM breakpoints?

Chris: DOM breakpoints? No, I guess maybe not.

Adam: Dude! Okay, so this exact scenario that you're talking about, you would find your select element or whatever it is that's triggering the dropdown. Find the parent element that manages that. You can right click on a DOM node in the elements panel and say, "Break on," and you can break on attribute changes or children changes. Basically, you will get the DOM breakpoint as soon as the thing gets the attribute set to open. You don't have to time or do any tricky stuff.

Chris: Oh, I see. You've got to find whatever attribute, class name, or whatever you're changing in which to open that thing, which you probably are. Yeah.

Adam: Yeah, you just need the node. You say, "Hey, break whenever you change. Hey, node. If somebody manipulates you through JavaScript, I want you to break."

Chris: Is it an attribute only or anything?

Adam: It's anything, so you can break on attribute changes, which includes class name changes, but you can also break on--

Chris: (Indiscernible)

Adam: --children being added and removed and, like, a few other things.

Chris: Oh, I see subtree.

Adam: It has saved my bacon so many times because I don't know who wrote the JavaScript that's making that thing open, but I can set a breakpoint and go straight to the line of code that's saying, "Open," and now I have the whole rest of the logic flow right there.

Chris: I'm trying to get it to work.

Adam: (Indiscernible)

Chris: You go on CodePen and you click on the search menu. It opens the search menu, right? But as soon as you click anywhere else, that thing closes. What would I select here?

Adam: Probably the dropdown element. If it's not a child of the search bar, find the dropdown component.

Chris: …attribute modification. Open.

Adam: Yeah.

Chris: Ooh, then it paused it before, but I can hop over one, right? I'll have to work on this.

Adam: Yeah, I see what you mean. It paused before it actually rendered.

Chris: Yeah.

Adam: Because it paused at the attribute modification.

Chris: Maybe I have to select a parent or something.

Adam: Yeah, you can step through.

Chris: Ooh, I think I got it, though.

Adam: Interesting.

Chris: You just step forward a bunch of times. [Laughter]

Adam: Yeah. Anyway, yeah, DOM tree breakpoints, they're super cool. They save my bacon all the time.

Chris: That's a good one! I like it. Thanks for the tip, man. Break on!

Adam: Hey, break on.

Chris: I like it.

Dave: Sweet tips.

Chris: Yeah. I've been learning more and more about dev tools. Even that local override stuff I was talking so confidently about, I fricken' just learned about, like, two weeks ago. Maybe I had heard of it, but I hadn't used it a whole lot. You're in the network tab. I feel like that's one of the more useful tabs, the network, because it gives you the big tree. You can sort by which kind of attribute it is.

Anyway, I'll find the JavaScript file, click it, and be like, oh, here's the response. Let's see. Just … screwing stuff up. Whatever. But then you can right click that and say, "Open in sources panel," which is the one that you need to have it open if you intend to edit it.

Adam: Yeah.

Chris: Then it's so weird. Immediately, you open it and you can edit it. But then you're like, "Why?" It's already executed.

Adam: [Laughter]

Chris: The beauty part is then you click that "Unable local overrides," and all those edits are saved then, which is so cool.

Adam: And they get applied before the new page will render, so I've used local overrides to figure out what was destroying performance by commenting them out one-by-one or whatever it was I was doing.

Chris: Right. Yeah.

Adam: I think in one case I even added. I added a bunch of preload tags so that I could prepare it for the assets that needed to come down the wire and could do a before and after in dev tools and prove what the change was doing on production. I was modifying production.

Dave: Exactly.

Adam: Right? Yeah. Amazing.

Chris: Literally, on CSS-Tricks, there's a broken functionality. WordPress ships with a script called comment-reply.js. It's for comment threads. If you have threaded comments enabled on your site, it's generally loaded on the page. You click that reply button and it takes the whole comment form and it moves it up to, like, a child of that comment. It's a little UX thing where you're like, oh, you want to reply to that comment? Let me move the form right there so it visually looks like you're replying to a comment.

Adam: Yeah.

Chris: It's nice, but it also does whatever magic it needs to do to tie it programmatically together when you submit the comment. It's kind of not optional. It needs to do its thing, so the comment becomes programmatically attached to the parent comment. Anyway, it just stopped working on CSS-Tricks. I have fricken' no idea why.

Adam: Stupid dependencies.

Chris: Yeah! It turns out that I just did what you did. I was deleting lines and figuring it out. Then putting console.logs and it functions to see what was firing and what wasn't. I eventually found out the little part of the function that wasn't firing. It turned out there was some logic. It was waiting for document.state to be ready, document.ready ready state or whatever, like the new DOM ready.

Adam: Yeah. Yeah.

Chris: The new DOM ready just was never firing. I didn't actually learn anything because this is documented. Obviously, this works on millions of sites that it runs on, so what's so weird about my site? I never found out why, but if I just replaced it with the jQuery DOM ready, which of course is just slightly more robust for whatever reason, it just worked fine. But then it put me in this crappy situation where now I have this hand edited version of this script that does work but then I have to override WordPress's core file with this one, which never feels good, right?

Adam: Oh, yeah. That's like reading into node modules and you're like, I'm just going to go modify my dependency really quick.

Chris: Tell me about it.

Adam: Fix a bug.

Dave: Congrats. You're now an open source maintainer for the rest of your life.

[Laughter]

Dave: And everyone is mad at you already.

Chris: I used to have this Sprite workflow that I needed to change one line of a node module. I was just like, okay, I guess I'll put it in the Read Me and nobody ever NPM install.

[Laughter]

Chris: Which is obviously untenable and not the way it is. Instead, you have a file called monkeypatches.readme. [Laughter]

Adam: Just check in node modules. Just push that to GitHub. It's all good. Then they don't have to NPM install.

Chris: Oh, god. [Laughter]

Dave: That is one way people solve it.

Adam: [Laughter]

Dave: It's not my preferred way, but--

Adam: Hey, Dave. VisBug has a lot of interest in good accessibility tooling.

Dave: Yes.

Adam: And so, I would like to know where it can be better. It's like if you hover on stuff, it'll tell you roles and it will tell you color contrast. It will soak up alt text and stuff like that so you don't have to really dig in. I feel like the concept of plugins and even maybe just more information on hover could help people make better decisions and just empathize and realize more about, like, what's happening.

Dave: You know one thing that might be cool because this is a very common issue is if you could figure out the algorithm to what this element reads as, like how it's going to be announced to the AT. Maybe that's a little bit different. You have alt text, but even like I'm on VisBug homepage and you have the GitHub, Chrome, and JS icons. It's like, do those announce? What do those announce as? I think it's sort of like ARIA label is greater. You know, you have ARIA describe by and things like that too, but you'd have to kind of do some work to figure out how the browser does it. That might be a cool thing.

Adam: I like this idea. Yeah.

Dave: …titles or labels because that's one. That's one of the biggest issues, sort of. You know like form labeling. A classic issue and, if it doesn't have an associated label, maybe it outlines red or something. Maybe you don't want to outline, but just maybe there's an X. You add a tiny X for the color contrast too. Maybe it's labeling. Does this have a label? X or something. Should it? You know, so that would be one thing.

Adam: Yep. It could even be like a sweet plugin. You could say -- I don't know. The plugins are basically slash commands, so you could slash command announceables or something. It could highlight all the elements that it believes are announceable that you could be announced. Then if you hover over them, maybe they announce.

Dave: Yeah.

Adam: It sort of gives you this forest view of everything that could be read to you and then you can go hear each of them individually.

Dave: Yeah, you could use the speech synthesis API to kind of fake a screen reader. That'd be kind of cool. I think that, too, I mean coming back to make it easier for everybody. [Laughter]

Adam: Yeah.

Dave: I personally believe it'd be great if everyone could use Web Inspector and everyone could use a screen reader, but not everyone can. Maybe we need dumb tools to start surfacing some stuff like how this stuff works, what it sounds like, or what it maybe acts like. I think this would be a perfect opportunity. Maybe it's a different tool, like Fake Screen Reader, or something like that, or Visual Screen Reader, or something like that because it's like, just show me the headings on the page. Okay. Now I have the headings. Just show me the buttons.

I was talking to a friend. He works at Texas School for the Blind and Visually Impaired, which is a school where all the kids, non-sighted kids, will come to one school in town in Austin. Then they go back for the weekend. Usually, it's people with more severe forms of blindness or no assistance in their town or something like that.

They come and he gets the opportunity to evaluate software with people. He will run it by kids or even people who work with him. One guy was like, "I do links and buttons. Those are my first two. When I open a page, I go for links and buttons."

For me, I was just like, "Oh, wow. Okay," because I'm usually tab, tab, listen, tab, tab. You know? It's like, no, actual screen reader pros will just be like, "No, just the headings and links buttons to see if it's interesting and then peace out." That changes my whole vision of how a page should be authored.

Chris: Wow.

Dave: Or like, oh, you've really got to get the buttons and the links right. You can't just have "learn more," "learn more," "learn more." I know that's a problem, but now I understand why it's such a problem.

Adam: Yeah. Very nice.

Dave: Things like that, like flagging repetitive text or something. You could probably even go to that WebAIM Million because 97.8% of websites have errors and you could just kind of go through. Low contrast was the biggest one. Missing alt text; you could find images without alt text or something and highlight those. Empty links; you could find those. Missing form labels; you could find those. Missing document language; that's pretty simple, but you could report that. Empty buttons; you could report that.

Again, It's kind of like knock out the top problems and then we can start building better websites for everybody.

Adam: Cool. Love it. That's kind of where VisBug is at. It lets you do the topmost easy tasks even easier. It lowers the barrier of scary, hopefully, so that even a PM or anybody could go doublecheck contrast and say, "Hey, this isn't right."

I even have a plugin idea where I want to simulate color blindness. You have a JavaScript plugin that just runs down the page. There are already things that do this but, yeah. I want to have VisBug help you empathize more. This could change the page that makes it feel like how other people feel it and then use that as a design surface. Now a designer is not just recreating that world. They're almost stepping into it and then using that as a moment. Anyway--

Dave: Yeah. I mean I think there's opportunity. It's that you're kind of making, right now, the technical stuff, the CSS manipulation, the style manipulation. You're making that easier in the UI and maybe there's a chance to do the same with accessibility. It may be another tool or something, but a visual form for accessibility so that not everyone has to go through a screen reader and learn how to do that. Anyway--

Adam: Yep. That's awesome. Do you know the Tota11y plugin? The Total11y, that one?

Dave: Yeah, Tota11y.

Adam: VisBug will launch that on a page for you. You don't even have to have the extension. It's a slash command, so I just inject all the scripts. It's a great plugin, and I was like, "How about instead of me redoing what this plugin does so well, I make VisBug a proxy for that experience?"

Dave: Yeah.

Adam: And so, if you just launch VisBug, go to the search bar and do /Tota11y or you can just find it in the dropdown suggestion menu, you can launch it and Tota11y comes with six or so really nice tools, one of them of which I think it slurps up any text and tries to tell you what a screen reader would say.

Dave: Okay. Yeah.

Adam: Ooh, I really liked your notion there, though, of where VisBug is very good at manipulating HTML and manipulating CSS, it could behoove it to have more powers in terms of attribute modification and making attribute suggestions. There's just sort of like a little bit more granularity in terms of HTML. I like that idea. I will noodle on that, Dave. Thank you so much.

Chris: [Laughter]

Dave: Well, yeah. I'm not a product manager or anything. [Laughter] You don't have to do what I say.

[Laughter]

Dave: I think it's that stuff. Us who listen to the ShopTalk Show or, I guess, host it as well, but we don't often -- we can't. You almost can't empathize, like the beginner, the learner, or even the person who doesn't just hand off their CSS. I think you have to take a step back and be like, what do most people need? Most people, it'd be great if they could hop into dev tools and crack around, but most people really just need answers or help.

Adam: I'm glad you brought that up. Yeah, I feel like a lot of tools come out and they are newer, more advanced versions for people who are already advanced.

Dave: Mm-hmm.

Adam: It's almost like making the gap even bigger between getting started and doing pro stuff. VisBug kind of went this opposite direction where, instead of making more tools for more advanced people for Silicon Valley, I made a tool that a four-year-old has fun with. That's something that brings me a lot of joy in that a child can launch my tool and it's almost like MySpace where things become tangible and I become interested because it's so easy to get started. I can break things and make it look terrible. It's not necessarily always going to improve a site, but it can rejuvenate or create some excitement for folks that don't really get a whole lot of exciting tools for them. I thought that was interesting.

Chris: Well, it's pretty awesome. I have so many more questions, but I'm afraid we're at an hour, man. We're going to have to get you back another time. Who better to be on the show than Google's official CSS expert?

Dave: CSS….

Adam: I have many thoughts. Yeah, I'd love to come back on. That'd be great.

Dave: All right. Well, thank you for coming on the show. For people who aren't following you and giving you money, how can they do that?

Adam: Send money to your favorite local charity or someone that you know that's just getting started. Don't send it to me. I don't need it. Google does very good.

If you want to follow me on social, just find me, @argyleinc on Twitter. That's A-R-G-Y-L-E-I-N-K. I'm tattooed, so just think of an argyle tattooed guy. Anyway--

Dave: Perfect. All right. Well, thank you and 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 tons of tweets a month.

If you hate your job, head over to ShopTalkShow.com/jobs and get a brand new one because people want to hire people like you.

[Laughter] Chris, do you have anything else you'd like to say?

Chris: No, just, ShopTalkShow.com.