Technically Included (The Best Kind of Included)

Hello there, everyone. I am so happy to be here. Thank you for joining me in the illustrious 4.20 time slot here in Amsterdam. I'm going to be talking about being technically included and what that means, how by incorporating other team members into your projects, into your code, you're going to be able to reach better results, better UIs.

So just a quick word about me. As mentioned, over a decade at Wix feels like I found my tribe. I started off as a web developer, did that for a couple of years, then moved on to help found the Wix R&D Academy dealing with internal trainings, but also with building the engineering brand for Wix where I got involved with a lot of community efforts, a lot of open source, and helped organize You Gotta Love FrontEnd, a major conference back home. After that I found myself missing the code just a little bit so I came back to that side of things, helped lead styliable IO, our own open source CSS preprocessor. I would love to talk to you about that at another time.

These days I'm the head devrel for Codex, which is our mandatory plug for this part of the discussion. Here you can see Codex is a visual development environment. It is an application you download and install just like any other IDE but it is meant to run on your React and TypeScript code. It fully integrates into your local environment and is not meant to replace your IDE but rather work side by side with it. If you scan the QR code, you'll find the demos that I'll be running later on, the presentation, as well as all the links to all the Codex stuff. But all this is just to say that I really love building things, and I really love the web. The openness of it, the inclusivity, the ease of getting to visual results, and the best way that I found to work in that regard is to work in cross-functional teams. Working in small tight knit units that involve multiple personas from different aspects of the project, representing the design, the UX, the product, the business, analysts, testing, and so on.

But it's not that that goes without any sort of challenges or struggles, right? When you're incorporating that many people, you're facing that constant need to sync things. There are handoffs and meetings and documents and specifications. And as you're kind of going, you end up reaching the state of this endless back and forth of implementation, review, and fixes. And you keep doing that over and over again with your designers, with your product managers, to make sure that things are aligned correctly. But eventually, usually, time runs out, right? And the compromises start to happen. To steal a joke from our designer friends, this is kind of how they feel about it sometimes, right? They put all that effort into creating a bespoke experience, a bespoke design, and in production, their expectations are being let down. But I think it wasn't always like that.

So I'd like to invite you to go back in time with me a little bit. Let's go back to 2007. This is back when Britney Spears was still in vogue. This is when YouTube redesigned their homepage to this sexy new layout. And this is when the iPhone came out, which would end up changing a lot of things for us as well.

So what did we do back then, right? Essentially, we had a browser, we had a notepad, plus plus, and with that, you could go really far. Developers were kind of in this together, getting to a visual result was simple, there was a lot less to do. And our focus at the time was also different. We were busy handling browser compatibility, right? Making sure that Internet Explorer and Chrome and Firefox and all the rest are playing nicely together. And of course we had a lot less to work with out of the box. Less APIs, less capabilities. But we did have memes back then as well. So if you've ever had to support Internet Explorer, you're probably going to feel that one. And at the same time, our designer friends were also trying to figure out this new frontier. What can they do? What is possible? What is this strange web and what is it all about? And as they were doing this, they were finding out the gaps between their legacy tools that designers would use and what the web offers and supports. And it was really easy, for example, with Photoshop, to create designs that are simply not possible to create on the web. But despite all of that, the distance between us was a lot smaller. We shared the language, we were playing in the space, the same playground, and we were exploring this new frontier together.

So things continued to evolve. And with the technology and with the time, all sorts of things started to manifest. Browsers became a lot more standardized, right? These days, it's a lot less of a problem. You don't usually have to close that gap. And yearly, they have the interop process that they do in order to make sure that even all of the new features that are coming into HTML, CSS, and so on, are being supported in all of the browsers. Package management entered our world and suddenly we had dependencies. We were able to incorporate code from other developers, from other projects, into ours in a fairly easy way. Modern frameworks like React came and standardized how we do things across the industry. It was easier to jump across projects, across companies, and make sure that you're finding a familiar ground. And lastly, the working groups themselves and the tech committees kind of changed their approach and started releasing a lot more features a lot more fast. And for us, on our side of the development world, the languages and the runtimes drastically changed. Suddenly we have TypeScript and we're writing statically typed code.

We had Node.js, which means we are server developers now. And these days, things like Benno and Bun and many other runtimes are coming around in order to try to close various gaps in the technology. Our responsibilities also kept growing. All of a sudden, there's tests and server-side and responsive accessibility. All of those things started to creep into our domain and were part of what we were doing.

All of a sudden, we had a build pipeline. You had to wait for things to happen before you could see things. All of those increased the technical complexity of what we were working on. Our designer friends were not left empty-handed. For them also, all sorts of things started to happen. The professions themselves were shaping up. Trends, themes, usability, responsive, touch capabilities, mobile devices, all of that suddenly became a lot more of a concern for them too. Design tools evolved.

That was definitely a good thing. And I think it's still happening. So if we started off with Photoshop, somewhere along the way we got Sketch. And Sketch was already being kind of mindful about what CSS and the web actually enable and actually support. These days, Figma, Framer, even more modern solutions are coming out there with plugins, with dev extensions, with all sorts of capabilities to try and narrow the gap between the designers and the platform that they're designing for. But none of these tools are native web tools in and of themselves. And so, it always leaves something to be desired. As each role professionalized, this gap kept growing.

Like two ships in the night, we started drifting apart, each group kind of centering in on their own silos. So how can we bring back the love? How can we get that relationship back up and running? I'm not sure a bubble bath and some candlelight are going to do it. And so I'd like to suggest a different approach. I think we're starting off in a really good place, right? This handsome fellow, Marshall McLuhan, coined the phrase, the medium is the message, back in 1964. And essentially what this means is that it doesn't really matter what sort of message you're trying to convey to a person, to a user, to a customer. Whatever that message might be, it is severely impacted by the medium on which you're delivering it. So, for example, an ad to sell a car in a newspaper, or on a TV channel, or on the web, would need to be fundamentally different in order to reach the desired result. And the better you know the capabilities and the limitations of your medium, the better you're able to tailor that message and that experience. The way I see it, code is truth.

What do I mean by that? Well, it's nice, and some would say imperative, that other stakeholders in the project also handle their stuff. So, let's say the designers have created impeccable designs, the product managers have covered the specification from end to end, and everything is perfect. If it's not implemented in the code, it's not going to reach any user. And so that is the only source of truth that matters at the end of the day. And you, dear people, you're the keepers of this truth. You decide what goes into it, you decide which persons have access to it, who can even see it, and you get to include, or not include, whoever that might be. And you know how annoying it is when you're relying on a different stakeholder, like a server developer to open up an API endpoint, or a designer to fix something before you can actually implement it, and you're left kind of in this place where you're struggling, and you want to do the thing but you're waiting. And so, you don't have to be this Gandalf. You want to let them pass. You want to bring them closer, not create those sort of annoyances. You want to be this Gandalf. You want to be about collaboration. You want to be building on other people's work in real time, and across time.

So how can we welcome them back into our world? How can we bring them back closer to the realities of the code, and the realities of our production? Well, I think it's a three-part process. We're going to talk about tools and process, we're going to talk about how we can build a common language again, so that we're not talking about different things, we're not using different semantics, and we'll discuss how to embrace change and rebuild that trust. This relationship is not meant to be adversarial. It's meant to be symbiotic. When they succeed, you succeed, when you succeed, they succeed.

So in regards to tools and process, ideally, you want to find the shortest feedback loops as possible, right? If you end up finding that the design is wrong, that the behaviour is not matching your expectation, in production, that's too late. You want to catch that a lot sooner. One of the ways you can do that is by incorporating staging environments, right? So if you have work in progress, as you're kind of going through the process of developing something, you can start creating these staging branches, staging environments, this is an example from Netlify, but Vercel and other companies offer similar capabilities, to let other stakeholders, the less technical perhaps, access to the thing as you're building it. This allows you to get feedback much, much earlier, and to tweak the experience and what you're expecting to receive. Now, you can go further than that, and even set up local development environments for each member in the team, that's what we do at Codex, but it's important to state that it's not just about access to the code itself, it's also about the management of it, right?

So if we're talking about how we manage our code and our tasks and our to-dos, we personally in the Codex team use GitHub projects and GitHub issues. Not because GitHub is the most robust task management system. There are others that have a lot more capabilities, but this keeps all of our stakeholders close to the reality of production, close to the bugs, close to the successes, close to the work in progress. Okay. Next up, how can we build a common language? The first thing I think is important is to avoid misaligned internal names, right? This component can be called a drop-down, or perhaps a select? Maybe the project manager calls it a combo box. That's already a small snag in communication, so maybe we're using a different name. What happens if in two months or three months we decide to add a combo box? We have a collision in terminology, in established understanding, and so that is crucial to avoid. Also, there is the aspect of naming pitfalls in the tools themselves. On the left side, you can see a screenshot from Figma, and on the right side, the developer tools from the browser. The closest thing that Figma probably has to a div is a frame, so already there's some disconnect there in what do you mean, and what does it, what sort of semantic meaning it might carry as well. Even when we're talking about the capabilities within those tools, right, so on the left side, this is the stroke controller from Figma, and on the right side, an MDN screenshot of some border examples. Not everything that you can create and make with the border radius as the spec defines it, as the browser supports it, is reflected in Figma. Not even close. Designers are left not knowing what they can do. Perhaps there's a better design there. Perhaps there's a better way. Some suggestions. First off, you can think about adopting an alphabet, right? Building a design system from scratch is a lot of work and a lot of effort, and sometimes it's easier to take something that's already well established. One example is Open Props. How many people here have heard of Open Props or used Open Props before? Please raise your hand. Okay.

Great. Then I'm super happy to tell you about it. So Open Props is a set of subatomic design tokens, essentially CSS custom properties, CSS variables that you get to use in your project, in your code. Side note, there's an excellent video here by Adam Argyle and Jason Langstorf, a tutorial, one and a half hour session that kind of takes you through the ropes. Really, really good. But the building blocks of this are these atomic units, right? So I have these properties, these custom properties, and I have colors, I have gradients. All of these were already fine-tuned to work really well together with each other. Light theme, dark theme, all of that goodness, including some things that you might not usually find in a design system, like easing functions, like all sort of complex borders, and you don't have to use all of it. You can find the pieces that you like, and only adopt those parts.

Moving back. So if Open Props was our alphabet, so to speak, what happens if we're trying to think bigger? Well, we can go further and adopt a vocabulary. Let's think in words, let's think in larger design tokens, so to speak. So Tailwind CSS I'm sure needs no introduction to this audience. But let's think about what we actually can see. One thing I remember, sorry, and that's for the Open Props, if you're using it, it's really important to have both sides of that discussion, the designer and the development, both being reflected, so that if, for example, you have something like this being developed, being worked on, this is Codex running in the background and showing us this example, then I can very easily just select the node that I want, find, let's say, the colour property, the designer can come and look and say, oh, this feels wrong, this looks wrong, perhaps a lighter colour, a higher contrast.

With Tailwind, you're doing a similar thing, but this time instead of using these subatomic units, you're using atomic design tokens, right? So each Tailwind class would have a number of different properties that you're seeing within it and that you can play around with. So once more, if you give access to your designer earlier on, then they can take a look at this component and say, you know what, this part right here, I'm not so sure about, something about the contrast, something about the look and feel, and they can start playing around with it, and they have the Tailwind documentation, sites and examples, all of those, so they can say, OK, maybe that sort of shade, no, that's probably too dark, let's try something in the middle, yep, and they'd reach the result. And the idea is to let them figure that out. You don't want to be the person who's shoving pixels around on the screen just to move a button five pixels left, five pixels right, and have that process happen over and over again. So bring them in, bring them closer, let them do some of that for themselves. So if we've adopted a vocabulary, now we can think even bigger. Perhaps entire sentences. That would probably be something like a component library, a design system, fully baked, ready-made, things like React Spectrum, Mui, Chakra, but in this case, let's talk about Fluent, a design system by Microsoft. You can see that from the get-go, right, from the very first moment, they are talking to you and to designers at the same time. They're making sure that both ends of that process have tools that they can use. So if, for example, we'll jump into this Figma file, and we'll zoom in just a little bit so you can see this nice message component over here, then we can, the designer already has these building blocks, right? They can take them, they can play around with them, and compose them as they like. And then when you get to the code, they are no longer surprised. They know what they're expecting to see. Now, the keen-eyed amongst you might have noticed that the version that we see here in the code and the version that we see here in Figma are not exactly identical, and that's that gap that I mentioned earlier, right? There's always going to be some gap there if the design tools are not native themselves.

Now, the keen-eyed amongst you might have noticed that the version that we see here in the code and the version that we see here in Figma are not exactly identical, and that's that gap that I mentioned earlier, right? There's always going to be some gap there if the design tools are not native themselves. They are mocking the web. They are trying to copy its behavior. And so here, very easily, the designer can come in, play around with the various interactivities, play around with the responsive behavior, and see kind of how things behave and what they do.

Alright. Last part, embracing change and building trust. So if we've sort of drifted apart over time, it's really, I think, crucial to dedicate some effort to kind of ease that learning curve, right? Every learning is an investment. We learn now so that later we can do something with it. Support your designers. Encourage them. Mentor them. Let them be a part of the discussion. And they're not coming for your code. They're not going to replace you. That super complex infinity grid component that you're developing, that's going to stay with you. You're going to get to focus on the things that perhaps drew you to this profession in the first place. The complexity, the interactivity. They're coming to the code. They want to be part of this technical discussion. And you've seen the evolution in the tools themselves. It's kind of where the industry is leading us. As we're professionalising, we're starting to bleed into each other's profession. To wrap this all up, I call for you to include them technically, meaningfully, in a real manner. Invest in their technical skills. Help them learn. Enable easy access for all team members throughout the entire process of development. Not just as a final step. Work together to establish your shared language, both in your tools and in your processes, so that miscommunication is avoided, mistakes are avoided, and you can build that trust between you both. And lastly, consider adopting tools that offer cross-domain solutions that cater to both of your needs. As mentioned, if you scan this QR code, you will see all of the examples, the presentation itself, links to Codex for you to take an interest in.

We have an assortment of tutorials on our YouTube channel for you to check out.

Thank you so much for joining me today. We've got a few questions that are coming in. Make sure you keep your questions coming in as well.

So let's start with the first question. You talked about shared languages and slowly ramping that up to shared tooling. And a question is asking Tom, how did you manage to bring stakeholders to GitHub? For them it's always hard, onboarded, and it failed and sent them back to JIRA. I feel your pain, whoever you are, when you go to JIRA. I'm sorry I felt that in my soul. But what was your experience? I've felt that pain too. We didn't start off with GitHub. We went through JIRA, we went through other solutions. We were constantly in this chase of finding the tool that best reflected our work. And as we were kind of trying out various solutions, we found out that they all miss that certain part. They all miss the connection to the code and to the reality of production. And I think if you need to convince other stakeholders within your project that that's worthwhile, start with some sort of demo, some sort of small project. Don't jump directly into the biggest, most complex part of your project. Take it step by step. And I believe that just like in our cases, they will see the value. You will have less conversations about stuff. They will be more updated and more connected to the real thing.

Awesome. Thank you. I've just got a quick request for those of you in the back. If you are switching rooms, that's totally fine. Do you mind just keeping your voices down so that everyone and maybe some people in the back can hear the speakers as they are answering questions?

Alright. We've got a lot of Kodaks questions. We are asking about Kodaks, the products. What I'm gonna do is I'm gonna pause. We're gonna do some of the design questions from your talk.

Sure. And then we'll give you some time to answer the questions about Kodaks.

So the next one's about Scrum. We all kind of know about sprints or these methodologies we use. How do you fit designers into them? So this person's asking, how would you fit a designer into a Scrum sprint? So I think if you're kind of helping them go through that hurdle, that initial learning phase, they become a partner. They become someone who's kind of swimming in your lane and trying to get to the same objective. And we use HL to a certain extent. We do sprints. We work with product teams. And our designers are opening pull requests. I get to approve a designer's fix for a part of Kodaks that was broken. This is incredible. It's so much fun.

No, for sure. For sure. And then the next one as well is about documenting a shared language. How to document a shared language so it's easy to access for new people in teams? There are many different ways, I think. You can go for a straight up classic documentation solution, stuff like DocuZero artists and the likes. So you just have your documentation, simple, indexed, searchable, that sort of stuff. If you're trying to cater to designers who tend to be a lot more visually oriented, make sure you're providing them with those sort of examples. And if you're using something like Kodaks, then they're able to jump in directly and interact with the things themselves, play around and see what it feels like. Understand that behavior.

Awesome. Okay. Now, let's jump in some of the Kodaks specific questions that a lot of people really loved at all. So the first question is, does Kodak support React Native? Unfortunately, at this point, no. React Native, while sharing React and its name is still kind of far in terms of functionality, APIs and all of that. We're kind of looking for it in the background, trying to explore if there's a way there. But no promises for anything soon. Awesome.

And then there's another question, which is about semi-automatic code generation from design. So we're bringing designers into these tools, and a lot of these tools say, oh, you can drag things. They promised a dream that Dreamweaver tried to sell me when I first started on my web development journey. But what do you think about these semi-automatic code generation tools? I'll actually start off with Dreamweaver, because that was a really interesting point in time. I know a lot of people who got their start in front-end development by using Dreamweaver. And sure, if you peeked under the hood at the code that was generated, it wasn't pretty to look at. But it still was close enough to the web experience that from there you could take some concepts on. Now, in regards to the generative side of things, I was trying to avoid AI in this talk, but I guess there's no doing that. Those offer great solutions. For example, in Figma, you have stuff like Locify, you have various plugins that let you export CSS variables and even HTML. Those are great in order to allow designers and less technical stakeholders the ability to flesh things out. It's not necessarily going to be the production-grade code, and it's not going to replace your implementation. But if they're trying to convey an idea, or if they're trying to make a proof of concept, then those tools can get you really, really far.

And then we also have another question, which is about testing. So it's great for products and design to get closer to the code, but what happens when it comes to testing these changes? Is that something that just falls on the hands of the devs, though? I think that kind of depends on how you're structured, how your team is structured. Sometimes it will be the devs, sometimes it will be more on the QA side, and perhaps the automation side. Again, when talking with designers, I think visual testing is a big plus, right? Because you want to understand when you went too far, or when something unexpected happened. So that, I think, can kind of help close that gap. But tests are still fundamentally technical in their nature. So at least for now, until we implement some sort of visual testing in CodeX, that sticks with us.

Now, I know that CodeX, there's a few other tools out there, and maybe some people may be familiar with other tools that maybe allow people to visualize some of these components and things. What is something that CodeX, that sets CodeX apart from having maybe a storybook or something else that designers can interact with? So first of all, CodeX is an editing environment, right? We saw this. I was making real-life changes, you saw the stage being updated. And those changes were not just selecting from a set of ready-made properties or controllers that I've wired. It's just the code itself. CodeX is fully synced to the same project that you have open in your IDE, so that whatever change you make in CodeX, you see in your IDE, and whatever change you make in your IDE, you see in CodeX. Both ways, real-time.

It's just the code itself. CodeX is fully synced to the same project that you have open in your IDE, so that whatever change you make in CodeX, you see in your IDE, and whatever change you make in your IDE, you see in CodeX. Both ways, real-time.

Awesome. All right, we'll do our last question before the fun one that I've saved for last. But someone has asked, collaboration versus the communication gap and behavior-driven development promises solving it, promises to solve it. Have you had any experience or do you have any thoughts on behavior-driven development? I think we've done quite a bit of testing using behavior-driven methodologies, even within CodeX itself, and that has definitely yielded good results. I think those results are still, within the testing world, more catered toward the developers, the QA engineers, the production engineers, and so on. But that still presents quite a lot. If you want to take it perhaps a step further in establishing that shared language, you can explore domain-driven design, where you actually get to strictly define the contracts, the behaviors, the language of how your project is going to be set up.

Awesome. All right, last but not least, you've got 20 seconds to answer this. Developers and designers are in a D&D party. What class is the developer? What class is the designer? I'm going to go with you. The developer is definitely the barbarian in that relationship. The designer, I don't know, maybe somewhere between a cleric and a bard, somewhere thereabouts. Very spiritual, very creative. I see that. I see that for sure. Folks, can we give Tom a massive round of applause? Thank you.