Miriam Suzanne on Developing the Future of the Internet | Now What? by Wix

Whatever it is that you need, you should be able to bring your needs to the web and have them respected. And that's all of us have different needs at different times, and we should be able to interact with technology that respects those needs. That just seems like a fundamentally important thing to me that the tools we build respect the people that need to use them. And why would we not?

Hi everyone and welcome to now what the podcast from WIX about how technology is changing everything. I'm your host Rob Goodman and in this series we're talking all about evolution in business, design, development and beyond. On today's show, we're joined by front end developer, author, artist and educator Miriam Suzanne. Miriam has spent her career designing and developing the next phases of the Internet. She builds websites and applications, works on making the web more accessible through browsers, and pushes the boundaries of the technology that is the foundation of the web itself. Miriam is the co founder of Oddbird Web Agency and an invited expert on the W3C CSS working group. Those are the folks defining how CSS will evolve to shape the web. She's a co author of SitePoint's Jumpstart Sass, a staff writer for CSS Tricks, and was a founding teacher on the Mozilla Developer YouTube channel. Miriam is also a playwright and a musician. She joins now what to talk about why the Internet looks the way it does and how to change that, why designers and developers need to move in lockstep with one another, and how the future of the web needs to be built around inclusivity and respect. Now, before we dive into our conversation, I want to mention that this is the last episode of our first season of now what. Thanks so much for tuning in. If you missed any of our episodes, now is a great time to go back and listen. Or you can listen again to some of our amazing conversations with folks like design leader Aaron Walter, crypto entrepreneur Ire Adirnakun, brand leader and co founder of Red Antler Agency, Emily Hayward. You can hear Richard Jennings at WarnerMedia talking about inclusivity in the design industry. Joy Cho of OH Joy. Talking about building a company on your own terms. So many incredible conversations that will give you a glimpse into what's to come in business, design, development and E commerce. But also share the knowledge and know how that you can bring into your work to better your teams, products and working practices today. Oh, and please do share the show with a friend or colleague. And if you like what you're hearing, drop us a review on Apple Podcasts too. Okay? Get ready for A conversation all about the future of the web from one of the folks helping to define the path we take to get there. Let's get started with Miriam.

Suzanne. Miriam, welcome to the now what? Podcast. So great to have you here.

Thanks. It's good to be here.

So why don't we start off hearing a little bit about what is keeping you busy these days? What you're working on, what you're studying, what you're teaching.

Sure. These days I get to work a lot on CSS specifications with the CSS Working group and interacting with the Chrome team quite a bit on what they're building into the Chrome browser. So that's been a lot of fun and that's taking a lot of my time and focus.

And when you talk about the working group, just describe for listeners. That's the W3C kind of web consortium working working group for CSS. And you've been invited in as an expert on CSS.

Yeah, that's right. So the W3C is sort of a shared organization of all of the companies that have some stake in the web. So you can imagine all of the browser vendors are there, right? Representatives of Mozilla and Apple and Microsoft and Google, but then lots of other companies as well. It's a large list of companies that are involved, have some stake. Adobe is there, so on and so on. And then they also invite some people who work on the web to come and help provide expertise as a developer. So it's a lot of different people involved. And the CSS working group is the part of the organization that's focused on, well, what's happening with css? Where are we going next? What features need to be added to

the language, and what is the process that happens in those rooms behind those closed doors or virtual rooms? What is a typical discussion like and what are the decision points that are made and how does that then roll out to web browsers and the folks who are kind of at the gates of how people will actually interact with the web.

Yeah, it's super interesting because there's parts of the process that are really formal and have sort of set steps and need sign off in particular ways. And then there's lots of aspects of this process that are really spread out among the browser vendors. The people actually building their browsers make the final decision. Right. They get to decide whether they put something in their browser or not. And there's lots of conversation always too happening. Most of that is totally open to the public. And on the CSS working group drafts GitHub, there's just thousands of open issues being discussed at any one time, some of them more actively than others. And I mean, if you try to follow all of them, that's some sort of fire hose, right? There's no way you can follow everything that's happening. Exactly. But you sort of pick out the ones that you're most interested in and anybody can go onto GitHub and contribute to those conversations. And then we also meet weekly and have some bigger meetings a couple times a year, and those aren't open to the public, but the transcripts are open and most of those are posted back to specific issues on GitHub. So when you're reading through those issue threads, you'll run into transcripts of the group discussing the issue. But then those ideas come from anywhere. Anybody can present new ideas. There's lots of discussion, lots of them interact. There's a lot of like, why had this idea and you had this idea, how do they fit together? And people make proposals. And then browsers can even at that proposal stage, start experimenting with it behind a feature flag if they want to. So browsers will sometimes start prototyping really early on in the process. But then the formal part of the process is the entire working group agreeing that all of the browsers are okay with this, all of the browsers are willing to ship it. This will work for accessibility reasons, this will work technically. And then that process of actually writing down the specification that everybody agrees on, that becomes fairly formal. But along the way, browsers can sort of do what they want in terms of starting to implement at whatever phase they want to. And you have some totally complete specs that have never been implemented and some implementations that have never quite been spec'd. It's a bit of a mess and also a very formal mess.

So you have a front seat view of where the web is going, and you also have a hand in shaping it and kind of pointing it in a certain direction. Can you take a step back and kind of at a big picture view, describe where you see the web going from your perspective?

Well, it's a little bit hard to say if I actually have a front row and where the web is going. The working group can be in some ways reactive. In some ways what we're building is ways to pave the cow paths that developers and designers have already started pushing on. So we're listening to where are the complaints, where are things not quite working? Or sometimes it's like there's new hardware coming out, so foldable screens are coming out and we have to react to that and figure out how does CSS handle a foldable screen? I would say in some ways I can see five years down the future of css, but that future is really driven by what people are already trying to do and just running into issues with it.

Speaking of css, I've seen a lot of new developments happening in css. Can you describe for listeners what is actually going on with css, what's happening today in terms of changes and what you're expecting to do come next?

CSS has gotten really active in the last couple of years. I don't know exactly what kicked it off. It seems like something around the time that grids came out, that's when there seemed to be a lot of energy that started to build. And I don't know exactly what triggered that, but there is a lot of activity. And it seems to me that there's a lot of browser interest and there's a lot of developer interest in new features. And what we're able to do constantly changes. So there's some features, like container queries, that we've been talking about for 12 years. This idea came up at the same time as media queries. It's not a new idea at all, but it finally feels like we actually have a path forward, and that's because of a lot of people doing a lot of work to get us there. And it's also just processors get more powerful over time. Right. So we're able to play with new things.

Yeah. Can you describe what a container query is for the audience?

So we have media queries which let you look at the size of the window, the size of the browser, and respond to that and say, okay, when the browser is larger, I want this different layout that fills that extra space. But when the browser is small, I want things to flow in a single column or something. I don't need as much layout. So we've been able to do that since 2009, 2010. Sometime in there, media queries became really broadly available. But what people really want is to say, okay, but I've got this one component. It's my, I don't know, calendar component, or it's my article card. It has an image and a title and the summary. And I want it to lay out differently, not depending on the size of the overall window. But is it in the sidebar? If it's in the sidebar, it needs to be small. If it's in the main area, it can have more space. So what is the size of its container and can we respond to that container. The problem is actually one of the coolest features of css, which is that CSS does this back and forth layout where the size of a parent can influence the size of the children in terms of nested DOM structures. So you put something in the sidebar, the sidebar affects its size, but that sizing influence goes up the chain too. The sidebar can get bigger because you put bigger things inside of it. So these containers and their contents are constantly negotiating back and forth. So if you try to query the container and then change the size of the contents based on that query, you could end up creating an infinite loop. So that stopped us from ever doing it, but people sort of over the years started putting features in place for locking down that loop and also making it okay that you do the loop once, as long as you don't do the loop more times. So that's where we are now. And now the feature is possible. Now we can do it. It requires a couple new tools and a couple new ideas that people will have to learn. But it's possible now and we're working on it.

And why does all of this new kind of evolution in the web and CSS specifically, why does it kind of cascade down to the end user in a way that is going to make an impact on their experience on the web and even impact businesses in terms of what they can build and how quickly they can deliver? Talk to me in those terms of the impact of all these kind of evolutionary steps happening right now.

Yeah, it's interesting. And we won't always know exactly what the impact is. Some of the features that we're building are specifically to make it so that things that are hard for developers now, but they're doing anyway because their site calls for it, their app calls for it. Some of those things are difficult. So they're spending too much time reinventing this problem over and over resolving the problem. And so we're coming up with features that are just going to make it quicker and that will help companies bottom line, that will help developers be more efficient. So that's great. And then some of those features also, when we build them into the browser engine, they'll become more reliable, more robust, and also more performant. They can be handled internally by browser processes, which are highly optimized. And often those are problems that we were solving with something like JavaScript. JavaScript sort of has two performance costs. One is like the download of the script, and then the other is the processing and running of that script. And it has to run on top of all the browser processes. So it's just a slower thing to do. And if we can move all that logic into the browser, it becomes consistent for everyone. You don't have to rebuild it, you don't have to think through all of the edge cases because the browser thought through them for you. It's built into the main processes and can perform better. So we get a lot of bonuses there. And that performance can trickle down to the end user who's coming to your site. It's going to load for them better, it's going to perform better. It often improves accessibility because developers aren't thinking through all of the accessibility edge cases and the browsers do have to think through them. And then some of the features are also things that you couldn't quite do with JavaScript or anything else. So it's like we've had this idea, but it was never quite possible the way you'd want it. And so actually putting it into the browser even makes that new thing possible. And we can ship dark mode more easily for the users that need dark mode or something.

And one of the things that I really enjoy in your talks is as a web developer, you also are kind of a historian in a lot of ways of the web and understanding where the web has been to kind of know where it can go. And I love the ideas that you talk about in terms of the web needing to be fully forward compatible, backwards compatible and sideways compatible. And I want to hear a little bit in your own words what you mean by that and how that's even possible. It seems kind of like a stretch.

Yeah, it definitely is a stretch. And it's sort of this ideal that we can never quite perfectly achieve, but it's always an underlying vision of everything that we're doing. But yeah, in terms of the history, I think the early documents are super fascinating, the way they talk about this. If you look at the first website that Tim Berners Lee and the team at cern launched in 89, 90, 91. It was somewhere in there. 89 was their first proposal. 91, I think, is when it went public. That initial website says this format needs to work everywhere. And since different devices have different capabilities, that means we'll never be able to do design on the web. Design on the web will just never happen.

Wow.

Because design assumes that every browser, one is visual, is a visual browser, and that's not true. There's audio browsers, and two, that all of them have the same font capabilities, all of them have the same color capabilities, all of Them have the same size. So it's just not going to happen. So the first attempts at style sheets were all on the browser side. It was just browsers adding style sheets and each browser would have their own style sheets and you would just provide the HTML and the browser would decide based on the device and its own capabilities how to style your site. But nobody was quite happy with that. I mean, you can imagine.

Yeah, that doesn't sound too fun here. Go ahead and make it look like whatever you want. It's just my stuff, just my information or my livelihood. Just do what you want with it.

Right, Exactly. Don't worry, I won't provide any branding. And there was also a problem where as soon as you, if you make those restrictions and then you allow images, people just started making websites that are just an image. And so there was this real fear that the web is going to become a fax machine where we're just sending around PDFs, and that's not ideal either. So we need to somehow solve this style problem. And right away the first browser was released for the next machine, but that was a graphic interface. And to prove their point, they immediately released a second browser just for text only terminals. So those didn't require a mouse, it didn't require any graphics, etc. So right away we have two browsers competing from the same team. They released both of the first two browsers and fundamentally different in what they could do.

Right.

But yeah, CSS came out of. There was really probably like 15 different design proposals. Around 93, there was sort of this race to come up with how are we going to provide styles that browsers can ignore? And that's the fundamental vision of css. We need a way to provide styles that we can provide. Branding. We can say that my branding is important here and browsers can also say that's cool, but we don't support that. Or on this device we have to do it differently. And so the entire cascade of CSS is that. And the term cascade comes from this sense that there's going to be several people providing styles. Us as authors will provide branding, users will provide preferences. And they still do. They don't do it through CSS usually anymore, but users can still set font size preferences, etc. And there will be the browser which sort of knows everything about the context, it knows what the device can do. The browser will sort of provide reasonable defaults and then finalize what's possible. So the cascade is a cascade of style sheets. We've got a cascade of these three Origins of style sheets.

I love how on your website you actually have controls in the top left to. I think it's font size, spacing between the characters, light and dark mode. I was like, oh, I really want this. This is so cool. It's fun to play with. But then of course, it's functional for the user.

Yeah, I'm glad to hear you like it. I was reading through the first proposal for CSS and he actually has a diagram in there of like, if you're getting styles from the user and styles from the author, what if you had little sliders where you could go back and forth and do like 75% of the author's colors and 75% of the user's typography or whatever. And it's just sort of theoretical. There's no detail on how that would work. It's just sort of like, what if we could do this? And immediately there's some problems there, like, what if I want yellow text on a blue background and you want it to be blue text on a yellow background and we average those to get green text on a green background doesn't work. And how are we going to average times? And Helvetica, what's the average? Exactly, exactly. But there are some ways that we can do this. So, yeah, I built a few under my site. Ways that the user can retheme it how they want.

Yeah, I think the idea of collaboration and connection and this middle ground between the user and the author is, gosh, that is so interesting just in terms of creative artwork on the web and experience and yeah, there's like a push pull there, but certainly I could envision projects that are built for that. Built to kind of be messed with, to be played with, to be broken in some ways just for that collaboration to take place. And that sounds incredible.

I come out of a theater and performance art background and I feel like this vision of the web as this collaboration between browsers, authors and users all having their say, and somehow we're going to create a design based on that. That's a fundamentally weird, radical performance art thing. And I love it when people play with that and release little artistic code projects that play with it.

Is that part of your philosophy around web development and as a creative person, are you thinking kind of from that vantage point as you're making?

Yeah, definitely. I mean, I think that's sort of what I'm interested in, is this idea of being able to make art and technology that respects the queerness of the user. It doesn't assume all people are the same, doesn't assume everybody wants the same thing and really tries to embrace that. I can set up a few settings for you, but I don't really know what you'll want. What if I give you more options than I think you might need and let you play with it and figure it out yourself and I still get some control over those for my site, right? I can set up the parameters, although because it's an open web, people can just go in and break the styles on my site for themselves, right? You can view source, you can turn off styles, whatever you want. But yeah, that back and forth, that's always front of my mind. I think it's what's really interesting about the web. It's like how do I give you agency while interacting with my content?

Hi everyone, I want to tell you about Velo, the full stack development platform from Wix that empowers developers and agencies to rapidly build, manage and deploy professional web apps to their customers. With Velo you can harness your creativity to turn your ideas into incredible working products. From an enterprise level E commerce site to a social network or API, Velo has the tools you need to build it. You can save time and money by accelerating your development workflow, cutting typical cycles in half. And with Velo zero setup environment and visual UI editor, hours of coding and maintenance time disappears so you can deliver faster. Velo offers peace of mind with WIX cloud hosting fully maintained and monitored for you. One click and you can scale securely and seamlessly simplify your development experience from testing to deployment. Debug, release and monitor your web apps with built in tools or integrate with services like Google Cloud Operations. You can use the drag and drop editor to create your UI and then add custom functionality with standard JavaScript and Velo APIs in the built in integrated development environment. Instantly create dynamic sites and collaborate on any type of content and you can easily add custom event driven functionality in the front end and back end. Open up a whole new world of animations creating striking visuals and interactions with the Velo Timeline Animations API. Velo also makes it easy to integrate with your favorite third party tools and services with APIs for Twilio, Stripe and more. You can learn more about Velo right now@wix.com Velo now let's get back to the show.

One of the things that you and I have talked about is the intersection of design and development and as all of these new evolutions are happening on the web and in css, what do you think the right process or collaborative intersection should be between designers and developers so that one can keep the other informed of kind of where the web is going and the possibilities and kind of bring that collaboration to a faster speed.

Yeah, I mean, I think collaboration is the right word. There's not exactly a right answer because different people have different skill sets, different interests. There's no one solution that's going to work for everybody, but I think they have to be intertwined. Development and design on the web, it's an interactive format and what we're able to code influences what we can present visually or interactively. There has to be that back and forth. So on our team, our primary designer doesn't write a lot of code. So then for us it means often pairing. So we'll have a designer and a front end developer sitting together looking at the code and the developer is writing the code and saying what's possible and the designer is answering questions about how should this move, how should this change? You can't tell that from a mock up. Usually like, okay, but what here is related to what? And when the browser changes and when the user scrolls, when they change the size of the window, how do things move? And it's hard to think through those things without looking at them. So we'll often do sort of a static sketch of like, this is roughly the UX we're going for. And then a developer will roughly code a prototype of that sketch. Here's roughly the pieces that we need and then we'll sit together and we'll pair, program the final steps. How does it actually move? What are the actual finalized styles of it? But there are lots of different ways to do that, depending on the people and the skills. The important thing is that you don't have those teams separated, you don't keep them apart. So how you do that, details of the collaboration, figure it out team by team. But there has to be that tight back and forth between design and development.

Is there advice you would give for people who are trying to figure out what is going to work best for them? Like certain questions they might ask their team or different sides of the equation in order to get to a place where they can get a system in place that works for them?

Yeah, there's sort of a general framework that I have in mind which is like, how late can we make the final decisions about design? How far off can we push that? So if you as a designer, your process is sketches and then I wireframe it and then I do all the details, I pick the border, color and I make sure it's 8 pixels of spacing instead of 6 pixels of spacing. Whatever. How late can you push those decisions in the process? Start with that initial sketch and then already be going to developers and talking through the sketch. How often can you go back and forth and integrate development into that process? And if possible, can we wait to decide if it's 8 pixels or 6 pixels until we're in the browser, actually playing with it in space? So design doesn't have to happen entirely in the browser. It can, if that's your skill set. I find it easier to design in the browser sometimes because I'm fast with css. Not everyone is. That's fine. But we all have to look at it in the browser before we ship it, because that's the real thing. And that's what we have to make sure is working the way we intended.

And you mentioned your team. I'd love to hear more about Oddbird, which is your agency, I believe, started about 12 years ago, and you started with your siblings, which I feel like we could do a whole podcast just about running a business with your family. But talk to me about the kind of work you do there. I mean, I would love to hear the origin story of the agency, but walk me through some of the projects and some of the work that you're doing there.

Yeah, it was sort of a coincidental thing that we started it. My brothers and I weren't real close at the time, but we sort of realized that a few of us were starting to freelance on the web, and we were like, oh, if we did this together. My older brother is a Django developer, backend expert, and I was working on the front end, and we sort of started it. We were like, hey, you do backend and I do front end, and we're both freelancing. What if we had a brand? And then my younger brother came along and said, I would like to do this too. So he picked up JavaScript, and it's gone really well. And, I mean, for the first five years, it was the three of us, and we've just been doing agency client work, but a real range of projects, everything from very small businesses and nonprofits to Mozilla. We got a job with Mozilla a couple years in. We saw Mozilla as this big company that knows everything about the web. Right. But we were building internal products for their QA team. And Mozilla's QA team doesn't know how to build a product or a web app. They know how to do QA on a web app, right? So it was interesting realizing oh yeah, even working with the big players. We're experts in our part of it and it built from there. We started hiring a few other contractors and now we're a team of eight and still doing a lot of the same work, although more of the large projects. And it's a mix of building a new product from scratch. A lot of it is internal products for companies, but then also client facing products for new startups or mid sized companies that are moving their thing online. And a lot of it is building things from scratch, but then also coming in and helping them refactor, move from floats to grids, build in a design system that's been a lot of the work recently. Help companies move to a component library and design system, things like that.

Yeah, and I'm curious about kind of the past several years and the evolution towards widgets, components, plugins, like ways to systematize design and development in a way that you're not starting from scratch every time. You know, more rapid development, more APIs to plug in payments and things like that. How is that starting to change your approach to your work and just the value that that has brought to the ecosystem recently?

I find it really interesting and it's, I think also interesting for me because I've sort of specialized in doing custom work for people. When the frameworks out there don't fit you, we can do the customized thing that you need. And in some ways design systems feel like the opposite of that. Right. Like inventing the framework so that you don't have to do anything custom. And I think that's an interesting push and pull and I really enjoy it. What I liked doing about building the custom thing was thinking through, well, what's the system we need and how was the old system not appropriate? So that's what we get to do when we come in and help on a design system is think, okay, but what's your situation? What are the skills of your designers and developers? What is the flow of your process? And for me, design systems are not as much about the product as they are tooling flow. And how are we going to integrate this with your day to day? If it doesn't integrate with your day to day, it's not useful, you're going to break it. Patterns don't exist unless we document them. If we don't document them, they stop existing the next day. So it's all about that thinking through what are your needs? How do we build a system that fits into your flow? I think of design systems as very much like DevOps, but for the whole product life cycle, it's about day to day. Like, okay, we need a new feature. Do we have existing patterns for the designers to draw on? Let's go look at our design system. So right away, when the designer is starting on the new feature, it's part of their flow to check the existing patterns, check the existing design tokens, colors, fonts, whatever, and know what are the pieces that they're working with? Or do they need to invent something new? Is there something missing that they're trying to invent? So it ties in right away to the designer's process and can speed them up. They can get these Lego pieces to start putting together in a new way to build a new feature, which can help them skip steps, pull on existing work. And then also when it goes from the designer to the developer, it's possible that less communication is needed in that transition because we can just say we have this pattern of info buttons, I don't know, just use the pattern. And then the developer only needs a napkin sketch of the idea to start implementing, because they know what all the pieces are and they can just go grab them. So it can make that back and forth quite a bit more efficient. So that's sort of process stuff. And in the end you can get this advantage of the whole site is more consistent. Accessibility is baked into the components. You're not having to think about every little aria role at every moment. Lots of sort of steps you can skip once you've built the system correctly.

And at wix, we just released our WIX Accessibility Wizard. And I know accessibility is becoming more and more important on the web. And I want to hear a little bit from you about why that is so critical to expanding the web as we know it. Giving more people access, obviously, but what are the repercussions for developers and designers and ultimately for more people to experience what is possible on the web?

Yeah, I think there are several answers to that question. I mean, I would start with that sense of the web wanting to respect users queerness. Right? Whatever it is that you need, you should be able to bring your needs to the web and have them respected. And that's all of us have different needs at different times and we should be able to interact with technology that respects those needs. That just seems like a fundamentally important thing to me, that the tools we build respect the people that need to use them. And people have a lot of different access needs. And why would we not build tools that respect people's access needs? But you can Take that and then build on it and say, okay, well, also, if we're excluding people, that might hurt our bottom line, Right? And then we can take it a step further and say, also our government has passed laws that say there are specific accessibility requirements of public businesses, and those laws apply to the web as well. And so if you won't do it for humans, do it for the lawyers.

I'm curious. You've been hiring at your agency, you're interacting with tons of folks out in the web development space. What are some of the roles of the future that you're seeing are going to start popping up in terms of actual jobs and positions and new needs out there?

There's things like right now, I think people that deal with HTML and CSS are under respected, underpaid, under hired. There's a lot of companies that have 30 backend devs or JavaScript devs and one person that understands HTML and CSS. I don't think the balance is right there. I think we need to improve on that. HTML and CSS are design roles and are user interaction roles. They're the front of what your user is interacting with. And if we don't give those the proper respect, we're not building the web. We could. So that's something where the role already exists, we're just not using it. I think in terms of the work that I'm doing right now with the CSS working group and writing specs, there's sort of a lack of process to get into this role. There was no training steps. Like, I couldn't work my way up in the field towards being a spec writer, except just trying to pay attention to it. And that's sort of how a lot of people end up there. It's just you've been doing it for a while and you have some ideas, you talk to somebody in the group and they invite you to join. I think it would be really interesting if this was more of a role that we facilitated with a career path. Get involved in spec writing, learn to do it. Learn to think about the language as a whole. What if that was a job we had? I don't know what it looks like exactly, but I'd like to see it.

I love that. And it sounds like an amazing way to speed that evolution. You know, getting more people focused on like the core architecture and what can be possible with it.

Yeah, exactly. And make sure it doesn't feel like a black box. Decisions being made behind closed doors. Even I for a very long time assumed these decisions just get made somehow magically somewhere else and never considered that it was a job I could have impacting what comes next in css.

And you're publishing your learnings, your notes are on your website and you're very transparent. And as you said, the W3C is also about what's happening. So I love that the wall is non existent in terms of what's going on. And the idea that you can train more people to basically speak this language and contribute to what the future will be is an amazing way to kind of bridge that knowledge with action.

There's a thing that can be scary about it where even in the group we have different specialties. There's browser engineers and I am not a browser engineer. And so I'm presenting ideas from a developer author standpoint and saying like, here's a syntax that I think could work, but then the browser engineers have to come in and say, is that actually possible? Can we actually do that in a performant way? None of us know every single part of the system and that's okay. And people coming from the outside may feel overwhelmed that they don't know some part of the system, but together we figure it out.

And you talk about the passion you have for creating art and software that really focuses on celebrating the queer complexity of the human experience. Where does that come from? And ultimately what is the drive.