 Hi, my name is Roy, thank you for spending your time with this session, I'm hoping it will be worth your time. Just to get a quick idea of who's in the room, who would consider themselves a designer or interaction designer, information architect, and who's on the receiving end of the output of these people, front-enders, back-enders, etc., so who's all of the above, none of the above, okay, yeah, so I'd like to talk a bit about prototyping and how that might be a good idea to add to your toolkit, both in design and development, but first, about a hundred years ago, artists got fascinated by movement, speed, technology, these were the early days of mass production, mass communication, and this group of artists called themselves the futurists, and they wanted to celebrate modernity, liberating themselves from the weight of the past. This group, the futurists, a lot of them were in Italy, and this is Dynamism of a dog on a leash, Giacomo Balla, from 1912. So similar, even more famous one, is also from 1912, Michel Duchamp, nude descending staircase. So these are 100 years old, and especially this one was an infamous piece of work. It's a classic now, but when it was first rejected by the other group of artists, the Cubists, Picasso and France, as being two futurists, it created a big controversy in the States when it was displayed there for the first time, and people just fell over each other in trying to mock it, and ridiculing it, but yeah, it stood the test of time. But what they were doing, even with this fascination with dynamics, movement, speed, the end result was a static image, and there's a lot of movement going on, or visualized in that image. The end result itself is a static impression. And in user experience design, we have a similar thing. Some of the main deliverables that are output that want to capture how people move through a digital product, be it a website or an app, still use static images to project what will happen in this interactive product. Of course, sitemaps and wireframes are the two most well-known pieces of output that come from this process, and especially the sitemaps, the wireframes. So I'm thinking there's people in this room that have wireframes delivered to them, and it did not quite tell them how it was supposed to work, because, yes, static deliverables are static. And so there's a gap there, because if you're using static paper often, images printed out, there's a gap there in how the deliverable projects the system and how the system will actually work in the end. And yes, I think prototyping can be a help there in closing that gap, or making that gap at least a bit smaller. It's a useful definition, and I highlighted some key terms there. It's early. An early example or a model of the product. It's built to test important, and as such is a thing that can be learned from. And we'll hit on each of these three aspects as we go. So first I want to spend some time talking about why use prototypes. We'll get to the nuts and bolts a bit. I'm not myself, a deep front-ender guy. The code level of this will be minimal, but we'll look at our setup later. Let's discuss why a bit. One of the main benefits that you get when you use an interactive prototype is that you give people something that actually works. It becomes easier for your stakeholders and your team to understand what the end result is aiming for. You must have experienced that people find it hard to discuss sidemaps and wireframes because they cannot make that jump between wireframes and the actual end product. And this results in discussions that can be shortcut if you give them something that actually works, so that they can click through. And that's really quite huge because it makes it easier to understand. This results in better feedback because people respond to how it actually works. And that makes it a lot easier for people to agree on something because it works or does not yet work as intended. An important part is this. Yeah, so I'm mostly talking about HTML prototypes. There's different ways to go about it. And if you go to HTML route, then you'll have a responsive prototype as well. I mean, responsive is required right now. We still mention it as a thing, but it has to be there for 99% of the cases. And by using the same building materials as will be used in the end product, HTML, CSS, JavaScript, you can manage the expectations better of what the responsive behavior will be in the end. The prototype will have some of the same quirks as the end product will have. So managing expectations there and just having something that works on any device that people want to use it on is a big thing. And as opposed to wireframing statically, you don't have to create those small, medium, large variations for each of the screens you'd be drawing. So it could save you a lot of work there as well. Not a big thing. Especially when working in HTML, you can quickly iterate on it. Even when discussing it in a meeting or with clients or testing it in your team, you can quickly iterate on it. Ah, no, that's not exactly why I wanted to be, yeah, okay. Sometimes I'll demo it and do just a fire bucket a bit of it and just an adding text or removing items to quickly give an impression of what the next version could look like. So quick iterations, that's an important aspect to get to that better solution. And easily shareable. By publishing to just a given URL and keeping that URL the same through the process, it becomes really easy to always have that latest version available for the team and for your client. There is a bit more work to exporting your wireframes to the PDF and the annotations that go along with it, emailing them off, oh, the file's too big, I've shared it somewhere as well, and then just wait for people to open it email and go through the wireframes once more. So just having it easily shareable at a single URL is quite practical. And, right, and then they can use it on their iPhone, their Android tablet, or their laptop, or whatever. All reasons where the prototype becomes more real than the actual more abstracted wireframes, etc. What I found is that it also forces me to use actual content. In drawing wireframes, I found that it gets easier to hand wave the content and put in some lorem ipsum or whatever in there. Because you're prototyping and you intend to show it off to people so that they can test it, it forces you to use actual content. And the actual content is another way to identify the participation with the client because the client is often the subject matter expert, right? So they'll get more involved in tweaking the right texts and putting the right images there, etc. Yeah, it forces you to use actual content and that's a good thing because we all know that if you don't start hammering on what is the real content, please, soon enough then we're working on a shell which we don't know really what content will come into it. And then we cannot really be sure that we've been making the right thing, right? Because it might break because we didn't gotten the real content in time. Similarly, when drawing wireframes, I found myself sometimes making words blue and underlined without really thinking about what would happen if I click on it. There's little room for that when you do an HTML prototype. You make it an anchor, you got a link in somewhere. So forcing you to use actual content and be prudent about which links you add to it is a good thing. Besides that you're giving the project team and client stakeholders something specific and concrete to interact with, you can also use the prototype to test it with the intended end user, with your audience. In UX work, you want to establish a clear picture of what the business goals are, which you also want to uncover, what the user needs are. And the prototype can serve both of these sides of the story. By creating interactive prototypes, you get something that you can give to people to use and then you get to observe how well the prototype actually performs. And of course then this means that you can quickly iterate and improve on the prototype and how it works before starting to write actual production code. So improving before starting to actually build is another big thing. And this reduces risks and business stakeholders want to reduce risks. And wireframes and sitemaps don't give them an idea of how to reduce risks. So it plays on many levels. We've heard now some tactical advantages, but it plays at a more strategic level as well. I'm not going to read it out, but prototyping even makes it on the Harvard Business Review blog. And taken together, it's a bit of an acceleration. But when images worth a thousand words and a prototype can help you skip some meetings, because the actual feedback from actual users is much easier to digest and accept as something that we need to act on than lots of different opinions that you often get in the meeting room. We can all do it with less meetings, right? So a quick recap, easier to understand, so you get better feedback, quickly iterate, responsive, forces you to use real content and be prudent about your links. You can usability test it, and all of these together makes that you reduce the risk and improve the chances of getting towards a successful product. Feel free to ask any questions in the meantime, if not, I'll continue. So that was the why, so let's look a bit at when in the process. It's a good idea to start using prototypes. Of course, there's as many process diagrams as there are agencies out there. This is not ours, but there's a lot of similarities between them. Here it's called empathize, the first stage called empathize, which means that you research both the business opportunity as well as the user needs. From that analysis, you can derive the definition of what you actually want to build so that you get your requirements. And from that, from the requirements, you get to generate multiple ideas. What ideas do we have that might solve this problem or fulfill this opportunity? And then after generating those multiple options, you get to choose one or two that look especially promising, and those you want to build a prototype for. Build a representation of your solutions. That's a good description of it. And of course, yes, that prototype can be tested. And yay, we've got a loop, so we can iterate. UX 101 basically, but if you look at it again at a bit more strategic level, this is from Peter Meholtz, one of the founders of Adaptive Path. Once more, a UX process. He calls it a double diamond for obvious reasons, and he splits it into definition and execution. Strategy is in the definition part and answering the why and how questions. And you'll see prototypes mentioned here. So what I said, you generate options and then you narrow down to a specific solutions. First, you do that based on the initial insight, the opportunity that you've uncovered. So you start to empathize. This is the research part we just saw. From that analysis of the research, you can start to roughly prototype what the solution needs to be. From there, you can define, okay, the strategy, this is how we'll go about this, and that makes that we have a plan. So from ideation and generation, we narrow it down and have defined our requirements. So there's a plan, but that's not the solution, actual solution yet. Once again, iterative design, explore multiple options, sketch your options, prototype the solutions, and test those prototypes. So prototyping is here, but this is the core part of the process where the prototyping happens. And after you've sufficiently tested your, the right prototype, you can further define it, refine it, and actually build it and ship it. There's a user experience focus in this diagram. The building is in details now. We know it's not, but yeah, sure. So what type of prototyping do you see happening in the first time? I've been curious about that as well. I've heard people describe it as the business prototype. I'm not that sure myself, but I would imagine it might even be a spreadsheet where they put in the right numbers to get the business case in place. Yes, yes, it would definitely be high level and focusing on the big parts. If anybody else has ideas about this, speak up maybe later. Yeah, there's a difference there, but I'm assuming it's a more high level approach to, okay, so that might even be just being the decision about whether we need a website or an app, you know, making those more high level strategic decisions. So we walk through this. But maybe this is a more truthful representation of the process that you go through. And that's okay. That's why you want to iterate, especially in complex problems in big sites or new apps or innovative products. You only have an idea of where you want to go. Yeah, there's only a hunch or an insight that you want to pursue. And in the design process, then you have to allow for these explorations before you can pick a direction and go for it. This is actually the official squiggle. There's no other squiggle than this. There's a site for it and there's a download for it for InDesign and Illustrator. It's true and we can package it in nice double diamonds or nice loops and dots, but we have to allow, find space and time to do that iterative process so that we may find a right direction. Again, to reduce the risk later on. What should you be prototyping? I mean, sitemaps can be big, right? Sitemaps want to cover everything that's in the information architecture. Wireframes will focus on at least covering all the different templates and the different page structures that will live in the site. So if you're focusing, if you're building a prototype, you have to be a bit more specific about what you're going to pick. And that, yeah, focus on the essentials. From your user research and the analysis, you'll have found the main scenarios. People, 80% of the people come to your site to achieve X. So focus on creating the path and optimizing the path for achieving X on your site. So main scenarios and crucial interactions. If people have to sign up on your site before they can get the thing, you'd better take some time and create a good registration process and reduce the friction there because the business relies on people signing up. Which also means that you focus on what it does and not how it looks. I mean, I gave it away in the title, right? It's about the interactions here. And that is what you have to focus on. You'll never really escape the discussion about look and feel. People will discuss wireframes as looking a bit grayish. The same will happen with your prototype because it's not necessarily the best place to iterate on the actual visual design language. You can, but it's a different exercise sometimes. So focus on what it wants to do, and less so on how it looks, which does not mean that you disregard the content hierarchy and use headers 1s and 2s and 3s when they're applicable, but don't go overboard in styling it. Let's get a bit more practical. Let's look at some different ways you can go about creating your prototype, so the how. Yes, I've been using paper prototypes, interactive wireframes, and leave the office quit unexpectedly. Yay, open source. Let's try that again then. So just a reminder, this is in the process where we want to build our prototype. This is where we're focusing on. There's a lot you can do to discuss the difference between sketches and prototypes. People have been doing that. But basically, the sketches for exploring the multiple options and the prototype is choosing one of those options and flashing it out a bit more so that you can get the benefits of a prototype that can be tested and get feedback. So one way to go about it, which actually to me sits in between the sketching and prototyping bit, is paper prototyping. I see there's a very generative way to create wireframes or multiple options for wireframes and pages, because you have your website, and you've established which are the main path through this website. So you create your information architecture, and you know that the red path, for example, is the one that people will be going for 80% of the time. So define that flow that you want to prototype. And the flow means, OK, getting people from the home page to the thing that they are coming for means that they'll have to work through different types and certain types of screens. That may be your home page and landing page, then the listing page within those product sections and then the actual product or the actual thing that people came for. So main prototyping or generating options for these, you first have to define, OK, these are the screens I want people to work through. For each of those screens, this is the sketching phase. For each of these screens, you generate multiple options. So this is for sheets where we, for each of the screens, try to generate at least four, five, six ideas for how that layout might be. Then review it and say, OK, if this is a good idea for the first screen, then this one makes sense as the second step, et cetera. So from each of those screens, you decide, OK, this one looks more promising. Then the rest of these, let's go one step more detailed next. And then basically, sketch out the different components that would live on each page. Because you've defined the page, you've sketched out different types of content that should live on this page. And by doing that in loose bits and pieces of paper, you can quickly generate multiple options for your wireframe. Again, this may be something that you do internally with your team. It's not the prettiest deliverable, although I've been doing this with the client as well, and they actually enjoy it. It's, oh, wait. Oh, but then we can. What if? And that gets people thinking about this process. And this is another way of helping people to understand what we're working on, the tools. Right, the shared canvas, you mean, digitally. No, but I haven't pursued that yet either. So maybe somebody next. So paper prototyping is very low fidelity, right? It's for roughing out big chunks on the page and generating those multiple options. Of course, I'm not done with drawing wireframes in Azure or whatever tool you use. And all of these tools provide options to link different screens together, right? And that's still a viable option, although I'm not digging too deep in this. Right now, I'm not keeping track on all of the tools anymore. For me, the last time I checked, it was still hard to simulate or a lot of work to simulate responsive behavior in prototypes. And that was one of the reasons I'm not going down this path too much. There is a session this afternoon? In, I made a note in the slide, sir. Yeah, there's actually a prototyping session later today. What happens is that these tools basically provide UI for JavaScript. Because you get to define all kinds of triggers and events and clicks, and you can, in advanced tools, you can load different data sets so that you can work with actual data, et cetera, which to me is a lot of workarounds for not doing it in HTML and CSS and JavaScript, which, for me personally, is still useful because I'm not that proficient, especially in the JavaScript part. So if you're alone and you want to work through that specific interaction of that small form transition, et cetera, it's still a useful way to go about it. But it becomes to me, it becomes a wireframe if you can progress through different screens and test that flow. And then wireframing tools provide the options there. And I've seen people using Keynote, especially for its animations and for its, I think people, not myself, but people using it to prototype mobile apps, et cetera, who has? Nope. But yes, the HTML, CSS, JavaScript part, and a bit of PHP. Sana, raise your hand. Sana's my colleague at Wunderkraut. He's the front-end designer, and he's transitioning to be a UX developer. Together, we've been working on our prototyping process. Because of all the reasons stated, we wanted to look at HTML, CSS, and JavaScript prototypes. And what we're now going to be showing is just our first version of the set of tools that we're using, which is all quite lightweight, but it could be useful. So first off, it's not Drupal. We're building Drupal sites, but this prototype is not an actual Drupal site. What we did decide to do that is to use our own starter theme and have it in the folder in our prototype environment. And that means that we can, so Wunder theme is our, Wunder theme is our starter theme or base theme. And in the prototype directory, the Wunder theme is just there. These are all the different pages that we've built. These are simple PHP pages. And what we do is, in the header, this is simple PHP include that is used in all these pages. In the header, we import all the CSS and JavaScript files from the Wunder theme, which gives us the typographic resets, the responsive behavior, and just a nice clean slate to work with and lots of CSS classes we can apply. So that was our first trick release. We could still use our theme and use the same classes and benefit from all those resets. And I have a good starting point because our Wunder theme is a gray, basic looking theme without any styling, just the user resets to make everything generic looking. And you probably have your own Drupal theme that you base your work of. Use it to import all those useful stuff that gives you a good starting point. So each of these pages include that header and then we have a simple HTML in the page and there's the footer which loads the other JavaScript, et cetera. And in the body, in that box, we just write whatever we think should be on that screen. Because the styling is done in SAS and it's already compiled and I don't want to work around with, don't want to work about with SAS too much. Sonnet, smart idea of just have a project name, .css which gives me one place to brute force my hamfisted attempts of putting things in the right place or giving it an extra accent, et cetera. So just by adding one style sheet, I can override stuff and tweak things and make the design specific to what I want to achieve. So that was another trick I found useful. And then, yeah, what you want to do is focus on building that screen. So you might have used the wireframe or the paper prototype to create the inventory of what should be on the page. And you've written some actual text for it and you've collected or got the right image to use on it. Focus on building that screen. Don't fall in the trap of wanting to build components yet or work on production grade code. One in the beginning, we were thinking, maybe we should have this pattern library so that we can drag and drop or include all kinds of little chunks of functionality so that we have a login form or a listing and a table, et cetera. But that immediately creates the overhead. And it's too abstract. It's too abstracted. So focus just on creating that page. And don't worry too much yet about making it reusable. The prototype is basically to be thrown away in the end. And that's what it's for. So focus on building those screens. And then there's some other guys at the job who really, really would like us not to use FTP to upload the latest version, which of course is also manual work, which slows you down, which is error prone. So the DevOps folks gave us a way that once we push it to master, it triggers a build and the stuff gets uploaded to our prototyping URL. Sana, correct me where I'm going. But I think I got the gist of it, which is useful. Git is managing. Git is not necessarily easy, but just having these benefits of version control and automatic push to the prototype side made me make that jump and go for it. So yeah, who? I give it away, but this is definitely more of a teamwork thing than you normally have if you are the interaction or the information architect, where you can use your prototyping tool and put in your headphones and go through all the screens and define and describe the requirements and draw your wireframes. So it really helps to at least have somebody as good at the analysis and the research phase getting towards that plan and somebody who can help you actually materialize those ideas into a working prototype. UX developers, I think. So challenges. It's not all sunshine, roses. The teamwork is not necessarily a problem, but it does mean that I sometimes have to rely on Sana's availability or skills to get done what I want to get done and vice versa. So it's definitely more a teamwork thing which may create a bit of an obstacle sometimes in getting things done quickly. It's not the design. I already said, people, you won't escape the discussion of, oh, it's a bit gray looking. And you left it for wireframes and you'll have it for the prototype as well. Just be clear about that this is not the design that we're focusing on how things work, not so much how it looks. And I think it's advisable to keep those concerns separated and work on your visual language, maybe even in Photoshop, right? Before transferring that to the prototype, maybe you don't even want to apply the actual final design to the prototype. The final design might be more useful, expressed as that pattern library and component style guide, that you want to apply to the production part of this design. Yeah, it's a bit early day still for us. We've done it two, three times now in this fashion. And we've seen that, yeah, starting from 20. Oh, sorry, it's not the visual. Yeah, it's not the style or the branding. You know, don't, yeah. So what do I call it? Yeah. Yeah. What do you? Yeah, a functional prototype. That's, do you mean how do I call the design part or the prototyping part? Yeah, I'll do you. Yeah. Yeah. Automate things. Physically, yeah. It's the prototype. Yeah, we refer to it as the prototype in which we flesh out how it will work. So yeah, it's a, yes. How do you go from that? Or you invested some effort then into actually building it? And the question is, do the same people then just spend more time on it? Or do you hand that off to somebody else? We've explicitly not made an effort yet to produce a prototype that will have reusable bits, because we think it will slow us down and might just make things more complex where we want, complex where we want to iterate quickly mostly. So prototype to throw away, basically. We've not done it enough times yet to merit the effort of looking how we can make things reusable. And so the prototype becomes the spec where we have the URL available to the developers as well. And they can look at the prototype and derive the functionality from it. Annotations is another thing, not really fixed yet. There's different kinds of tools that let you create another comment based on inside the HTML tag that will render that. And you can make it clickable and having color dots, et cetera. Annotations and comments are a bit of a challenge still. We've not focused yet on reusable stuff yet. We're spending the time we would be wireframing on the product. We're spending that time now prototyping. So the idea is that we're not eating into production time, just spending our design resources in a different balanced, different way. Yes, that example here, what you just saw, it was, yeah, that example what you just saw was not that complex a site, but that we work through that in a day. And in that day, we collected our input from interviews and people we spoke to, created the sitemap, picked out the main flow, sketched those options, and created the paper prototypes as a wireframe. Yeah, I think that's why a frame is in the browser, in that sense, yeah. It's the use experience design part brought to the browser in a way that, yeah, good clarification. Thanks. So yeah, it can become unwieldy if you have many pages and all the manual stuff will get repetitive and then we'll be forced into looking how we can make things more reusable, et cetera. We've not quite hit that limit yet, but we're starting to see it. So yeah, if you're thinking about doing it, these were the benefits we've discussed. And just the best advice is would be to see a picture being taken, try it out, and start small. I think you can all get an idea of how you could go about this in a lightweight fashion. Reducing the risk argument is a useful one if you need to pitch it internally. And I'm curious to hear what you find out. Thanks. I did not know the name of the room, but today if you want to learn more about how Azure lets you prototype interactions, Danny, another Drupal UX designer, we'll walk you through it. People have more questions about it? Maybe use the mic at this point. Do you always work with full-screen prototypes, or do you also sometimes just put parts here or put rights? Like just a dropdown menu or just some other thing? The prototypes in HTML we've built were for the full thing. I find that if I want to quickly dive into a detail, I mean, I work on Drupal Core as well, and then we're discussing how this form transition or this option should work in the admin. Then I find I quickly jump into a wireframing tool and just build that little component there. So not yet, no, not necessarily yet. The benefit to me is that you demonstrate the thing in full, right? And me myself, I'm not that proficient enough in the JavaScript part, especially, to be able to quickly mock up something as an example. If you want to fill a big structure, like a big menu with a lot of example links, do you use some PHP routine and just an array to fill this stuff, or do you just click this copy and paste this together? What say you, Sanne? OK. So if you then decide I want every menu link should have another class at it, and then do it again. So yeah, mostly just for the recording, mostly copy and paste and maybe add another include so that we can use it again somewhere. OK, last question. The place where people look at the prototype is at the Drupal site, where you just pull in the prototype stuff or? No, we've set up our own URL prototype.testsite.com. And then people get their own project name URL there. And it's a HD access behind it so that they get up to it. So that's just a PHP script or just an HTML page? Let's just sort this. PHP in this case. Yeah, it's just this bunch of PHP pages that you can click through. Hi. I understand you're using this for responsive wireframes in the browser. Yeah. I'm still slightly unclear as to how the visuals start working and look and feel. So you've kind of said, no, no, no, no, no. But how does that actually work in your design and development process? Yeah, so deriving the visual design, you saw that when we decided this is the flow, these are the screens that we need. The same paper prototype or wireframe would be the input for a visual designer. OK, so this is a home page, right? Because you need to do a style exploration as well. Before you can do 20 designs of all individual pages, which you likely not want to do at all. But you need a home page, a landing page, a listing page, and a detailed page, et cetera. And either the paper prototype or the actual, so the paper wireframe, say, or the actual prototype, is input for the visual designer as well to say, OK, this is how it works. This is about the hierarchy and the balance we're looking for. Take it away. So that could still be Photoshop, designs, or comps. Right, OK. So you're not skinning the prototypes these days? No, not yet. And we're not sure if it's the way to go. OK. Hi, as a freelancer, I often get an email from a client. And the client says, OK, we're ready to start development. We've got some great designs. They look fantastic. And it's a tricky situation, because they're invested in time, money, emotionally. Is there anything that I could do at that point, or do I just have to wait for the next time round and be more proactive? Is that because you see the problems already in those designs? Almost always, the designs aren't done by a Drupal savvy agency. So they're just designs for what they would like. It's like a big shopping list on a page. So is there any way of going from that to prototyping in at that stage at all? Well, what you could do is that part of taking on the job is try to make room for that quick exploration of checking if these designs will easily map to what you can actually build with the Drupal tool set, or which is doable with the Drupal tool set. If you see something happening, oh, guys, you're really daydreaming here about how this will work, then maybe that quick prototype of quick mock-up of that sequence and showing how that might be a problem, maybe because of responsive or because of small screens, might get you to foot in the door and get you some leverage to rework the designs in a way that makes them better fit to the actual implementation plans, et cetera. So you think you can respond to a design with a prototype at that stage and have that conversation. It works. Yeah, yeah. I think I don't know if you should, but it does tell you. It does tell that you care, which is a good thing. And that you're just not, oh, I'll have it, and I'll take it, and I'll do my best to build it as well. But if you can, that's why the prototypes work. They surface problems, right? That's why we try to build in the usability tests at least once because we know that the first version will have obvious errors because we're working from our perspective and the end users on a different perspective. So trying to build in that check. OK. Can I add something, J.P.? Financial to save money or to make money. So you can speak to their emotions through their wallets and ask, so these designs, are they going to achieve your business needs? Are they going to make you the money? Do you know that? If they don't, then you can talk about testing. The minute you're testing, then you can start talking about prototypes and ways of testing, whether their assumptions that this will make or save the money are actually going to happen. Because otherwise, you can say, well, we're going to do all this, and you're going to throw that all away, or it's all going to be useless if you don't achieve your business needs. So that can be a way in to a conversation. And if they're still too much married to the stuff they've done, and they're not willing to adapt, that might be your cue to not take on a project because it will be not going well. OK, thanks. It's good to ask for an example. Now, do you have an example where you've wondered? Right. Oh, I mean, nothing specific comes to mind, but it's always been, I guess, it's almost the initial contact. If the initial contact comes with a design, then later on, it's clear the design has not been thought about, Drupal. So that's really handy. Thanks. Thanks. Can you explain the process of migrating the code you've written in prototyping to the actual production code? Like, do you start from scratch building your theme? Or do you copy, paste the parts you can reuse over? Or do you use a smacks component style and then apply the classes to your elements? Or how do you do that? Or do you end up rewriting every single template there is to accommodate the structure you had in your prototype, in your production environment? Yeah. So yeah, back to this one. Yeah, exactly. And there's the tip of it, because I'm working directly with somebody's focus on the content to make this prototype. In the Drupal development process, that's backwards, because there's a design and there's a spec. And then you give it back-end developers. And they start to build reviews, and et cetera, and the database integrations, whatever. And then slowly, stuff bubbles up. That becomes available for theming. So that's one of the reasons why we've not looked into a reusable, working in a way that sets us up, that the actual theme will benefit from what the work we've done in the prototype. Solving this issue would be a big game changer, I think. Yes. We've not done it enough, like I said, times to merit the investment in making that library part, or something that lets itself transfer to production theming. We've not moved all of our design process over to this prototyping thing. But yeah, it would definitely be an interesting goal to pursue. I mean, imagining there would be a tool where you could create the theme, where there was a living style guide inside of it, like it provides you with some tool set where you can say, OK, I have a content type, which I want a theme, I have a form, I want a theme, and create these components, and make them reusable later. I am so looking forward to your contributed module. No, I don't think I will be able to make this. This is basically the major issue we have with this approach, and then building the site. Yes, yeah. Like I said, we've. Yeah, OK. I was going to say, if you're using a CSF framework, like Bootstrap, and your developers manage to take control of the HTML, and they really can have the HTML that they want, and not that Drupal wants, then you have the problem solved. And actually, this is possible. There's maybe some limitations, but there's a lot of ways that you actually can get over this stupid Drupal-specific HTML that says, this is a view, this is a panel, this is something else. Then you don't care if it's a view, it's a formator, or something else. It's just the same HTML sets, like a slider. You manage the HTML for a slider, and then you can implement this as a view, or you can implement this as a field formator, where it's just image fields or something, or flex some field collection stuff. And it's still the same HTML. And if you look in the source code, you don't even notice that's a view. So if your developers manage that, and they should, then you get rid of this problem. Then you can write the HTML before, and then you can reuse that later. Sounds great. We have some practical experience with doing front-enders just going ahead and doing basically building front-end semi-finished front-end stuff with HTML, CSS, and JavaScript, and then having a themeer come through in a second step and connecting it. It is, that's where the expense and the effort lies in, because you're basically building, but you are kind of building production-ish code in terms of CSS, at least. The JavaScript's harder, and the HTML is always then up for negotiation. We kind of start with a mix of what Drupal brings and then some ideal solution, and land somewhere in the middle, but that's where the extra effort is invested in bringing the two together. But the front-end people can go ahead and go way ahead on creating somewhat production-quality code for CSS. If you negotiate ahead of time, where the sort of what they can decide by themselves. Right, because I imagine not being clear about how to weave together might make that process brittle as well. Right, you need to have someone who really knows Drupal theming to sort of set the boundaries for that. And then, I think this is actually way better than our wireframing process, so totally gonna take that. In terms of how do you build a component library, we haven't really solved that either, and I'd love to collaborate with someone on how we can have maybe wireframe screenshot or live wireframe snippet, then in a separate tab for each element have example content, or like that plus live HTML, right? In a highlighted format, so people can see it and copy and paste it. And then in another tab, maybe how do I use this in Drupal? Like here's my theme function or my theme call, or here's my templates, and it links off to a live page where we've got like a style guide module that shows us exactly where it's being used. And if people are interested in working on that, then I'd be interested in doing it because we're at the process of deciding whether we want to do a Drupal specific version of this or whether we wanna say no, front ender should be just front end code, and we're not gonna use PHP, we're not gonna use Drupal, we're just gonna use, instead of having PHP includes, we're gonna use like HTML5, HTML includes because that's all like, it's all front endy and stuff, but basically we haven't gotten to the point yet where we have a good solution to a style guide, so if anyone's interested, maybe in the comments on this session. Yeah, I was going to ask where do we go. In the comments on your session, right? Rate this session. Or above, yeah. All right. Sorry. Thanks, thanks. I actually have an answer to that question about style sheets. At All Company, we use Paddle Lab, which is a style guide kind of framework. Yes. You build however you want with your own structure of your SAS, your own structure of your components. By default, it uses the atomic design pattern, and it makes it a lot easier to not only prototype your stuff, but you can also reuse a lot of your components, a lot of your SAS, and we have found that this process is actually easy also to convert to a Drupal site as well. Really? So this was just an answer to the problems. Paddle Lab. I think we've looked at Paddle Lab, and at least for the cases, the projects we've been prototyping for, it was to fine grained the molecules, atoms, molecules, et cetera. It was so much split up in such small elements that we ran into that problem, but it won't necessarily help us create those screens. No, of course not. That's why this part of the process was focusing on. And the Paddle Lab actually allows you to do whatever you want. You don't have to create those small elements. You have your own structure anyway. That's the whole idea of Paddle Lab. I think we didn't hit that realisation then, yeah. Yeah, OK, thank you. Thanks. Thanks all. You're off.