 The truth is if we want to evolve the material design system, we need to be able to build on top of the code, and each layer of that code matters. The convey about is designer works on something, developer takes it, and developer screams. Because there was no conversation, I think that's one of the biggest challenges. One of the challenges in the beginning with material on the web was there's so many different implementations, and getting the single source truth. So you had Angular material, you had Polymer, you had MDL. How have you found solving that single source of truth? Yeah, originally we had a unique team of developers in both Android, or I'm sorry, Angular, and Polymer, and all these other web frameworks building their own implementations of material design. But we found that we couldn't keep that going at scale. Like we're iterating on the material design system so quickly and we couldn't keep a single source of truth with these other component libraries. So we started developing a technology where we would write our JavaScript once, and abstract its interaction with the HTML. So you wouldn't directly reference a DOM element, and then we would wrap that JavaScript in individual component libraries. It's not a perfect solution. We're still working on making it faster and better, but we found that that creates these components that look like they belong in the framework. So any framework developer who's working there, they look seamlessly like they're part of the environment. One thing that we struggled with, with material design like, was there was a lot of black magic going on in the DOM. So you check developer tools and there'll be like these random elements. And that was like an opinionated decision. So I mean, how do you go about developing a new framework where you have to have an opinion? It has to be like this is the baseline of what we're doing. Without impeding on what the developer just wants to do, they just want this component to work or this widget or whatever. Yeah, I try as much as possible to avoid black magic. And whenever I'm reviewing any code that any of the designers on my team are writing, we try and avoid anything that's, maybe it's a little hack and it makes it slightly more performant but the truth is like if we want to evolve the material design system, we need to be able to build on top of the code and each layer of that code matters. So we try and like steer away from any black magic and just have this one source of truth that works with all the component libraries as much as possible. In terms of like working with existing frameworks, I mean, what's the relationship there? Because like React is a thing. You have to, it's the real world, right? Oh, like WordPress is a thing. Like you have to work in that world. So there may be certain things that you can or can't do as a result of that. Like for maintaining a framework where it's not Android, it's not like a single, it's like the web is all about relationships between different code bits. I mean, how do you manage that? It gets really tricky and really funny. So we tend to prioritize them in terms of what developers are already using. So React is a great example. There are a ton of code bases already in React. It's super popular. So we want to prioritize that one first, which is why we're making an MDC React library for React in particular. But then there's other libraries like Angular and Polymer that we want to start using as well. But we tend to prioritize them again based off whether or not developers are already using them. In terms of like keeping all that functioning and sometimes you end up like one framework wants it to do it one way and another framework wants it to do it another way. It's just constantly compromising. Like we work with these developers on the Polymer team or we like talk to the React community and try and figure out what's the right way to figure it out. And we just sort of settle on the right compromise and stay there. We do it as well with browsers. So for example, we tend to develop first on Chrome because it's kind of the best and it works nice, but we have to support Safari and Firefox and Edge as well. So we tend to test IE at the very end. And we want it to work, but there's sort of like graceful degradation sort of things that happen. As long as it happens like carefully and gracefully then it tends to be okay. And I think we do the same sort of thing with platforms. You know, maybe it doesn't perfectly work in every platform, but as long as we can kind of gracefully degrade that component in that situation, it'll work out. Yeah, I know the BBC have like a term they saw cutting the mustard. So basically they will have like a baseline where things have to work. Yeah. Like with this, and if it doesn't work or doesn't support this technology, they say, you know what? You're not going to get these experiences that we're designing. I mean, how do you feel about that as a concept? Yeah, we've had to use that already. So there's some new things coming out material design around shape. And on the web platform, no matter what technology you're in like what web platform or what browser you're in, rounded corners are really easy. Like cut off corners, impossible. Just straight up impossible with the existing technology. And so we kind of had to go back to our material design team and say like, look, we can update the CSS spec today in 2018. And then three years from now, our children's children will like have this feature, but we're not going to be able to implement it right now. So there are some features we just kind of have to draw the line and say, we can't do this feature without it being a confusing story, without it being some sort of hack that no one would be able to use. About how about SVG? But I mean, I suppose when it comes to animation, the challenge with SVG is like performance. Yeah, SVGs and then the shadows on top of them and the scroll performance underneath those SVGs. By the time you like try and support all the browsers and all the situations where that component would be, it gets really confusing quickly. I mean, very complicated. Yeah, very complicated. That's quite interesting because the conveyer about his designer works on something, developer takes it and developer screams. Because there was no conversation. I think that's one of the biggest challenges that developers face because if you just talk to me, then I'll be able to explain, especially for designers who have no coding experience. So, and I know we've spoken before and you've mentioned stress testing the design, which is a new concept for me. It's my concept. How does that work for your stress testing a design? I mean, I think there's a limitation in designer tools that make them want to force everything to sort of this pixel perfect mock. And that's gorgeous. It creates some gorgeous assets, but it doesn't always work in a real world application. And a developer's job is to create something that works in a real world application, right? Ours is the stuff, the code that's running live. And so many problems come from a design being pixel perfect for like one language, one screen width, one set of content. And when you go to build that, you can build sort of a dummy site quickly, but once you start populating it with real content, all these problems come up. And I think most designers, if you go and talk to them and say like, hey, I have this problem, they'll help you. They'll like show you how to change the design and tweak it in this situation. Like they're very receptive to that feedback. They want to make their designs better. But if you don't know who your designer is when you have this problem, then you just have this bug that says, doesn't work in German, like what do you do? And you have no idea how to fix it. So yeah, I think there's like conveyor belt problem of designers who sort of like design something, but then leave the project and don't collaborate with the developers as they're building it. It makes it really difficult for the developers to make the product better over time. So how do you think designers can actually improve their process to make that relationship better? And what is it really down to the most obvious, you just need to pair program or pair together. You have to talk to the person. That's really the best way to do it. That is the best way. I mean, I think that can be really difficult and certain if you don't have enough time and resources sort of dedicate like one person, one designer and one developer to every single feature. I think there's ways in the middle to do it. So for one, make sure that you know each other's names. Like if you're remote, make sure you know how to deploy your code somewhere to staging so your designer can work with it and make sure your designer has a way to send you like iterations on mocks. Another sort of quick and obvious thing, I think for designers is to internationalize. The moment you like take all the text from your mock, put it in Google translate, put it back in the mock and see what looks horrible. German. Yeah, German or even like CJK languages, just pick a language. It doesn't matter if you translate it, right? Just like do that first step because you're gonna run into all the width and height problems that a developer will run into live. And I think it's good for designers, right? It helps you make your product better to like get feedback about what sort of languages do I need to support. And that's especially important in like user generated apps, like the content. Could be 10 pages or it could be two lines. It's not like you always get the mock because the name, the avatar name is perfect. Yeah, but what if the name's like, you know, four words long? Is there anything else that they can do like to stress test it? Or is it just really? Internationalization is a big one. I think different screen widths, at least if you're on web is helpful as well. Like making sure that the obvious break points work but also sort of smaller ones or bigger ones. But yeah, it just comes back to like be there when your developer runs into a real problem and help them fix that problem. I think most developers want to fix problems. They want to like code that out. They just wanna like get on their headphones, like get the code out that'll fix the problem but they don't know how to redesign the site, right? We're not gonna, if you make a developer guess how to design a site, we're gonna guess really poorly. So you need to help us as designers. If you spent loads of time polishing your like amazing prototype, then you suddenly become very like, you know, reticent to throw it away. You kind of like your baby, you kind of like polish this too much. And so that's dangerous because then you're not using prototyping for prototyping's like real purpose, which is to learn.