 Okay, I think we hit the mark. It's 14, 15, and I'm really happy to see all of you. Thanks for coming out. We're really being looking forward to talk to you today. First of all, I am Jenu, and I'm a UX designer at ADAPT. I spent my work life designing the best user experience possible. And when I have any time off, I love people watching. I love going around enjoying street life. I live in Copenhagen, so obviously I bike, but not because I worry too much about the climate, but actually because it's the easy way to transport yourself in Copenhagen. And that actually shows you a bit on my perspective, on my work in general. May gain it as concrete, as valuable for the user as possible. So that was me with me today. Hello. My name is Mastinus. I'm a front-end developer, and I also work at ADAPT. We work in the same team. In my spare time, I bike because it's very good transportation in Copenhagen. It's very efficient. And also I play music. I play in a band, should go check it out. It's really cool. No advertisement, just saying. And yeah, I'm just going to talk about ADAPT very quickly. ADAPT is a digital agency, which is located in Copenhagen, Denmark. If anybody didn't know. And it was established back in 1998. And since then, it have published over 2,000 digital solutions. And there's around 100 employees. As I said earlier, we work in client teams, which means that we have one different roles in the teams, maybe multiple. But we work together and we have the same role to communicate with, and that leaves a very strong bond internally. And today, we are going to talk about structure for creativity. And the reason why we are so passionate about this topic is basically how do we link the initial vision, the initial enthusiasm and passion for a product to the actually end result. Yeah. And to just give you a bit of an idea of what we're going to go over, so you know what to expect. First off, I'm going to take you through how to structure your vision and your user insights. And then afterwards, I'm going to be talking about how to structure your design and your user experience. And after that, Mass will take you through... I'm going to talk about how you make a project structure more practically the same way workflow. And I'm going to give some a few tips. Oh, I'm going to press this button so you can see what I'm talking about. And give some tool tips and examples on how I work every day as a front-ender. And as we said, we think structure is so important if you want to create a product of high quality because you will remain with a great overview. But what is quality really? We ask ourselves this, is it the material? Is it the design? Is it the refinement? Often it's very subjective what quality really is because it can be very different from different cases. If you want the product to be cheap, you don't want it to be leather or something of very rich material. So this way, the quality could also be something of really exclusive material, so it can really depend. But what really quality is very shortened is when the company uses their common sense as knowledge to create a product which adds value to the end user. That's really what quality is about. So what is creativity then? It's a matter of creating a disruptive product, creating a unique experience, or is it about aesthetics? Well, for me, creativity is when you see an opportunity for a product or service that has the ability to change user behavior and introduce new possibilities for the end user or for the market. So it's a matter of pushing yourself and your ideas forward and how do you do this? And that is where structure comes in to play. Why should we structure? It is because if you want to create with creativity and you want the high quality for your product, you need a structure to work with them. And there is kind of a conflict in this because for me at least, when I think about creativity, there's also an element of chaos into that. You need to be able to spin off ideas and don't lock yourself in too fast in a certain direction or a certain user group or a certain context. But if you don't create some kind of structure, you can actually end up being lost in your chaos. Because when you start out with a product, it might work as in right now with a little bit of chaos built into it. And we probably all tried this. But if you want to keep on building on it and actually take your product further, you need some kind of structure. And I don't mean just in code. As a user experience designer, I also mean it when I look at the user insights, how I structure the vision, how do I make sure that this is actually a format that people can keep on working with, where it's not set in stone and it's not determining a path for a product. I think the most beautiful thing is when user actually does something you do not expect them to do with your product. And in that sense, actually opening up for a creative loop that can keep you going forward. So yeah, one last point about this. When you have a structure that actually gives you the opportunities to navigate your different choices and map them out, you can also then prioritize in what you focus on. And to quote a guy who has a lot of decisions to make every day, I would say, he really inspires me in simple ways that for instance, he only has a blue and gray suits because he actually don't wanna spend his time making the decision of what he rears every day. And that is because you need to focus your decision making energy. You need to routinize yourself. You can't be going through the day distracted by terraria. And to actually implement that in your work, you need some structure. So how do we do this? This is all good ideas on paper, but how do you actually practice that in your everyday life? And this is what we're gonna be talking about for the next 40 minutes, where first I wanna show you this. You probably all seen some sort of variation of this model before. But it just to give you a highlight of what we are gonna focus on. So you start out understanding the vision and making it yours. I'm gonna elaborate slightly on this a bit later. Then you need to determine the desire users and what experience it is you want to create. Then you need to break it down and structure it into user stories, making it more clear what it is we're actually building. And then you wanna start experimenting in prototype. And this is not to say that this loop is timely necessarily in this order. These can be parallel to each other as well in processes. But the reason why I've highlighted this, a part of the circle is actually because this is where, from my point of view, a lot of knowledge gets lost. A lot of misunderstandings and this is kinda one of the weak spots in the loop. So that's what I'm gonna talk about. And then afterwards, Mass is gonna elaborate further on how you structure your prototype to actually have it going in to your actually development and your test phase and so forth. So this is what we're gonna be focusing on for this talk. Okay, you probably all met a client that have a pretty certain idea or vision for their product. And you sit there thinking, okay, I actually see a completely different perspective or idea for this product to evolve what it is you set out to do. So how do you actually meet this client and make it a vision that you can work on together? You need to understand the vision. And I've said this a couple of times, but what do I mean by that? I don't mean that you just have to listen and listen carefully, but that you actually have to make it your own. You have to engage with it. And how do you do this? How do you become so close to your client and believe it as well as they do? Well, you take your skill sets and then you start to challenge it because a client preferably came to you because you have something they do not have. So you wanna activate that and some of the ways that we do that is asking the questions from the user perspective. A lot of clients have a pretty clear expectation on, okay, I have this idea, this vision, this is how I expected to be met by the client. This is how I think it's gonna do on the market and so forth, but the reality might be completely different. And this is where you can really come into play by doing your analysis, finding the user insights for the user groups that they have identified or maybe find out that it's not the right user groups for this product after all. But you go into the market. You look at the business context, you do a competitor analysis and obviously you have in the back of your mind your knowledge about new digital opportunities that could come into play to actually realize this product. So what you can give a client by actually spending time on making the vision yours is a more clear definition that will make it easier for you to actually build what it is they want. Because if you keep standing on the outside of the vision and saying, okay, so this is your vision and I'm just here to make that a reality for you, there will be limits to how far you can get if you don't get into the mindset. And as an example, we worked with a game industry player who were collaborating with us to create a product for game developers to promote and share their games. And they identify a variety of user groups. Up in the corner we have the typical game developer from a small-sized, medium-sized game developer brand. We have in the middle the consumer who could, for instance, be your mom on a smartphone. We have journalists who will share and write about gaming news and so forth. And then obviously we have the big group who all the game developers are keen to hook up with for them to realize their dreams, basically. So how do you create a product that actually meet all of these at one point? Well, we sat down with our client and we really talked this through on which user group did they actually believe had the power to realize this product and who would they prioritize? And this is where this come in. You need to make some roadmap for how you're gonna build your product so you don't end up shooting in 10,000 different directions and not really hitting anybody. And prioritizing, I don't mean that that means that, okay, if we prioritize one, we do not prioritize the other. But if you're clever about how you prioritize your user group, you actually end up hitting them in the right order or maybe understanding the relationships between the different user groups. And in this case, we ended up identifying together with the client that, okay, our main user group was the game developer. And we actually figured out that, okay, if we make it easier for game developers to share more knowledge about their games and their game development, it was more likely for journalists to write about them. If journalists wrote about these game developers, the big brands were more unlikely to notice it. And we end up with the consumer that really don't care about game development. They just wanna have it easy and fast right in the app store, right? So when you prioritize, you also make the roadmap for yourself to say, okay, which one are we gonna take off first and who are we testing the solution for? So in that manner, you make it easier for yourself to take decisions later on. You limit your choices by saying, okay, I have this priority and I've done this priority with my open eyes. And it's not to say that anything is set in stone because obviously we know that that can change. But as long as you're clear on where you are right now, you also have the ability to change and actually change in a manner where you know what you're doing. So we know our main target group. Then you start to look into the different user sites for user, sorry, user insights, for this main target group you identify. And that can be all over the place. I mean, that can be the data from analytics. That can be qualitative or quantitative data that you pulled out from your analysis. I'm not gonna dive into the details here, but in terms of structure, there's just a really important step that I wanna highlight here. And that is to take your analysis and then make a top three or top five of, okay, this is my main insights that I wanna focus on solving with the solution I'm creating. Because also when you work in teams, it can be quite messy to stay down here and communicate all of this to your team. But if you have a top three, five, whatever makes sense, that can be easily translated and communicated all along both to your client and to your team. Another way to structure it could be in personas where you say, okay, these insights I've transformed into parts of my main user group where I can identify that to a person that can sometimes be easier for somebody to actually have Brad or Christina to reference to in day to day work. So that's another way to do it. And now we come into the funny part of breaking it down and structuring it in user stories. I don't know how many of you have actually started out creating a backlog for a new product, but it can seem a bit overwhelming of where do I actually start with this. And the reason why I've spent a couple of minutes highlighting the user groups and the user insights is because if you don't know these things just at least on the surface to some degree, then it can be really hard to start writing the user stories. Then it will probably be what's in top of mind for you. So if you have your user group prioritized and you have your user insights, they are actually tools you can really use when you start to create a backlog. And user stories. It's a beautiful format that many of you probably work with on a day-to-day basis just to wrap it up. It's actually a format that gives you the possibility to describe an experience instead of simply a specification. The format here is as a user type. I want to do something so I can experience or achieve a goal. And by defining it like this, you can easily link this to your user insights because you have the different types already planned out in, for instance, your personas or how you structure your user insights. And already there in the first leg, you help both your client and developers identifying who are we actually building this specific part for and so forth. And the reason why this is strong is obviously because it puts the user in the center, but it also gives the client an opportunity to prioritize between them. And to start off, you have the epics where you start prioritizing and by an epic, I mean an overall user story that is typically a feature or area of a solution that can be identified by saying it can't be built in a day. So we are in an overall perspective, but by actually creating these at first hand, you give the client a possibility to say, okay, I would suggest that this one goes on top and you have a structure that gives you the possibility to challenge that by saying, but actually if this user group is your main one, this should go on top and so forth. And then again, a structure for communication. When you have the epics, you identify the overall scope of what you're doing, you break it down into user stories. And these are what will hit development and take you all the way through until the end result. So they become way more specific and they can be built in a day compared to the epics. So here we actually specify with acceptance criteria and so forth what it is we are building. But in my experience, this seems like the clear way to do it, but that's just never what's happening when you work with a backlog. You usually get stuck a bit in between where you either broken it all down to user stories and you figure out, okay, this user story is actually quite an epic because it was way more complex than I initially thought. So you have to break it down again or the other way around. You maybe sit there, have sit with the client and said, okay, we are gonna prioritize these epics. And some minor details ending up being mixed up with like huge initiatives. So they are not quite on the same level. And that's the beauty of this. You can't foresee it all. So don't stress about not having the overview at the first hit because this is just a structure for you to be able to communicate. And as you move along into the process, you can easily, easier transform these if you do not set them in stone. And this you need to communicate obviously with the client and with the team because it's really, really important that you keep updating the backlog. So how do you structure your updating of backlog? Because a lot of information can be in this long list of user stories. So how do you make sure that none of the decision you made along the way get lost or it's not clear for the client or for the team? There's a few things that I've learned as I work with this and I wanna share those with you. And that one thing is that you need to keep your epics alive. And what I mean by that is don't get too far into the details without knowing why. Why are we building this exact user story? So on a, sorry, that was a different one. So there's different tools that we work to, we work with it adapt to do this. It's tools like easy backlogs simply for writing up your user stories. It's a easy and quick format to write them. And then when we start to work together as a team, we work in a tool called JIRA. I know there's a lot of other great tools out there to actually handle this. But for instance, you have the possibility to actually link your information together. And that can be by identifying different user type, make sure that the logic of your user types and your user stories is quite clear for the team, have an introduction of how you structured it. So they know, for instance with this client we work with, we had like the game developer who has locked into the solution, a game developer who hasn't, a journalist and so forth. So we had the representation of the different user types. And then you wanna link, sorry. And as I said, you wanna create the clear link between the Epic and the user stories it broke down to on a practically that could be done with a label that highlights which epics are you working towards achieving at the moment with these user stories making it again clear for both the client and your team what is going on. And then you can group the different user stories by components. And what I mean by that is that I've tried several times that when we start to build, start to form the backlog from the epics, it becomes clear that some of what we're building might overlap. And you want to make that clear. So instead of having repetitions of features you're building, you wanna actually make it one and then label it with all the different epics that you're trying to achieve. So keep on revising and as you learn more about what it is you're building and you become smarter and smarter, then mirror that into your structure. So you always have as much as possible and up-to-date backlog that actually mirrors where you are in the process. So keep your epics alive. And just to give you an example of the benefit of this in the project I was referring to before, we had identified our main target group as the game developer. From that we took on, we could prioritize some epics and break them down that was actually essential to this user group. And in the product that ended up in a focus on a creation flow for the game developer that this onboarding part of the product needed to be as clear and as simple as possible because our main user group actually had a few barriers to watch writing about their own games, sharing photos that were presenting their games in the best manner and so forth. So this was actually a part of the product that needed a lot of attention. And we could see that because we had gone through the process of saying, okay, this is the main user group that we're actually building to achieve. We're building this solution for, we're building this product for. And in that sense, it became very clear. And this gives you a chance also to always have in mind what has happened throughout your development that link the vision to the user insights, to the user story so you can always see that line making it way clearer for everybody involved. So on the last note, I wanna say that all of this can seem a bit dry if you don't validate it with prototyping. And Mass is gonna dive way further into the prototyping aspect of this. I just wanna say that for me, remember that prototyping doesn't have to be that complex. Pen and paper is your best friend to simply visualize what you're talking about, visualize what part of the solution you are talking about and testing it. And by testing it, there's obviously big initiative you can take and have a formal user test, which can be very beneficial, but already early on, it's really valuable to test your ideas on your colleagues. If you have access to some game developers, try that out in this case. And don't be afraid to show your work, even though it might not be done at all, because that is where you get the most honest input from your colleagues, your user group and so forth when they actually see a possibility to affect the product that you're making. So yeah, just to sum up before Mass is gonna take over, you need to structure your vision and user insights. And you do that by understanding the vision, make it yours, remember to challenge it with your knowledge, with your mindset. And then you need to prioritize your user groups and your user insights. Remember to sum it up and share it with your team so the knowledge doesn't get stuck in some analysis that doesn't actually end up affecting the product. And then keep coming back for validation to these insights. Have it in top of your mind. It can be on your wall, it can be in your head, it can be as your screen saver. Just remember to always come back. And then you need to structure your design and user experience. You highlight the logic of your different user types and how your epics are linked to the different user stories. And this gives you a chance to always revise and prioritize your backlog with your client and with your team, because we actually know which part we are talking about at all times. And then you need to do prototyping at all times, both from Lofi, but obviously taking it to code as soon as it makes sense. And this is where Mess is coming in to share a bit on how he structures to, for the development process. Yeah. Cool, thank you, Jana. Let's give her a hand. Jana mentioned just before prototyping and this is a very interesting words that we talk a lot about. It seems like the buzzword that's come out right now. First off, I would like to get an indication of how many are you a front-enders? Would you raise your hand? Cool, half, half, cool. So maybe the rest of you don't get too bored. It's very interesting stuff. I would get a very practical with maybe some bit code. But what is really prototyping? Because maybe not all of you are familiar with this term. For us, it's a really good way to validate some of the ideas we have. Because if you, when you start building the whole project, you're using a lot of different phases. There's a lot of roles involved. When you're building a prototype, you're just writing basic HTML and CSS. So instead of having to go through a lot of process, you just have this very fast, small project which you can test. And if it doesn't really work, you can just throw it out. What's really cool about it is if it actually works, you can use it for user testing. A lot of different ways you can test it to validate these ideas you really have, they actually works. Because I've seen some examples where you do a lot of user testing and you get a lot of knowledge. Okay, this works, this didn't work. And then you'll be stronger against the hippo. Which is this nasty fellow over here. Sorry bosses. I've tried multiple places where you have a lot of great ideas and you come up with a solution. But there's this guy just saying, okay, I want option B. But when you actually have done a lot of prototyping, you actually know what is actually going on. And you have arguments against this. So it's a really strong card to know, okay, maybe you want option B, let's clean it up. But nonetheless, you actually know this is a result and this actually gives a better benefit. So that's a really good way to it. Another thing that's really awesome about it is actually how you can try to smooth the transition between the different roles. Because we have the vision, we have the analysis, the design, and then the development. And I'm pretty far in that list. So the knowledge the first guy gets, how do I actually get this? And by actually having the designer and the UX designer on the prototype, I make sure that some of the knowledge actually being spent here are actually going into the final product. Because all the code I write, I can just paste into the project. So it's really a way for us to try to see if we can save some of the saver and use some of the knowledge that has been found in the analysis. And you can copy your work as I said earlier, but you can only done this if you have structured it correctly. So structure your work. I've tried one time when I went back to an older project and I was just looking at this code. It's like, who wrote this? This is horrible. So you do get blame and you just see your own name and you get very frustrated. It's not very fun. And this is always based on bad structure because this is all that you get frustrated, you get lost in your own code and it's not nice. So that's why I have these four points which I want to highlight today which I think is vital to keeping up a good structure. First off, I think it's way too underrated because you spend a lot of energy each day on trying to write a good code but if you just set the structure from the start you will stop wasting your time on trivia instead actually can use your energy on some of the fun stuff you actually love doing. One thing I think is really important is folder where you actually can, this is a really good way for you to keep maintaining the great overview. There's code structure which makes it easier for you to work but also to elaborate with your coworkers. And workflow, again, this is a good way to make sure that your workflow doesn't get too messy. And then also a standardizing. I will get into this a lot more. The first thing I wanted to talk about is folder structure. Cool animation, right? It was pretty hard to make, I'm just saying. First off, I think you should always organize your photos beforehand. Because if you do this, it's a really good way for you to actually make sure that all the components that are being built are already thought of. Because sometimes you build a project and you're just like, oh, where am I going to put this? Oh, God, I'm going to put it here and you have this MISC file which just get bigger and bigger and nastier and it's a really, really nasty way if you ask me. And then you created this beautiful structure that really works well and align it with your teammates. Because your teammate have the perfect structure and you have the perfect structure, but if it's not the same, you'll fail anyway. And then I think it's really important to think component-based. And what do I mean by component? Like on this page, I think you should always, wait, I'm going to say one thing before I jump. There, cool. So if you have this component folder inside of your source file where all your files are, you should always keep all the JS files and all the CSS files linked there in one folder. Because this way, it will be much easier to know what's actually a part of this component. So if you're going to copy it for another project, you'll make sure that there's not this dependency which doesn't come on. But what is a component really? A component for me is this thing on the page which it doesn't really care where it's been placed, it just cares like how it looks and how it is. So this could be Instagram footer, it could be put in the header, it can be put anywhere, but it's an Instagram feed. So that's how I think of component-based. So remember those folder structures. The next thing is a code structure. I think first off, I think it's very important at least I think it's a big part of being a funder is also to take the responsibility of being a site builder. Because I've seen multiple places where I got the markup and I was just, I didn't really like it. So you say, oh, redo it, I need something better so I actually can style this the right way. But a lot of the times it was just much easier if I just did it myself. So I think you should really take control of the markup and be the guy who writes the code yourself if it makes sense in your setup, of course. And this way is also a really good way to make sure that all the class names doesn't end up having a horrible name which is going to be really hard to hit or being too generic. So I always try to have these contextual so you know, okay, this is close button, for example. So it creates context and it's very specific. And then there's contextual documentation. Because I've seen some places where this is a contrib module, you're not able to actually change the code. So what do you do? This button, this close button, it just says modal and button. Like, okay, what is this? But if you actually create some documentation which gives the context, it will be much easier for another person that comes in later. Because maybe if you work on the project alone, you'll probably be fine, you know this is the button. But this will give a really good overview. And if you always work as someone else is going to take over your work, you made your own work a lot more safe. Also transparent nesting. It's a bit about the same concern about having a great overview. You should be careful, how deep you go. And yeah, try focusing on that. Then there's insight, I'm using SAS, which is maybe you know it. But you have this feature called extending where you can say, this appearance, I want it to be here as well. And that's really, really awesome. But I've seen people extending like the whole component visual design. So they extended it here because I had this appearance over here and I copied over here and everything was great. You can't really see that this is extended when you change the original one. So you made this, have anyone seen the inception? It's like ending up in limbo. Because you keep on going into and you just, it's not very nice. So I think you should never really try to extend the same appearance of a component. I made example, I would extend the paragraph text inside the box because I know the text will always have to look the same. This is like a safe way, but don't extend the actual appearance. Here I will use a mixing, because this has to be one moment. Cool, here I will use a mixing. This really gives a bit like the same features. You define how the code is going to be and then you include it into the selector, which actually gives the appearance. This is really strong, because you always have the overview of what actually have gotten what. But also it's so easy to make variations if you like this. So if, okay, I want this, but I wanted to have this mix with instead, it's very easy to just make a variation and change it. Okay, next slide. So that was code structure. Workflow structure, we love quotes. So here's another one. Bill Gates has says, I choose a lazy person to do a hard job because a lazy person will always find an easy way to do it. I think this is a really, really cool mindset and I think what he really means is you should always be critical on how you actually work. Because a lot of the time you just do the same work and maybe it's quite repetitive. But you don't really stop up and say like, okay, how am I actually going to do this? You will maybe just waste energy on something that doesn't really lead to any value. And this is one of my big concerns. Am I speaking too fast? Okay, cool. I feel like I am. Okay. So I use a lot of time inside of the terminal because I lose it for a lot of stuff. So I have this, there's this alias, a plugin called Omyshiz, which is really, really powerful because every day you spend a lot of time and you're adding stuff to Git and you're like using Git diff and you write a lot. So if actually if this Omyshiz really adds a possibility to write a lot less, so instead of writing Git add, you can just write GA. And this seems like not that big change, but if you write this 50 times a day, you really save a lot of energy. And this is really something that I don't want to write the same thing all day and press the up key to hit the one I want. I just want to write it right away and this is really, really efficient. But Omyshiz doesn't really have that great compatibility for Drupal. So I created the same thing as Omyshiz, but just for some of the things that I need. I will attach a link in the end of it where you can find it downloaded. It adds some things for Drupal, like I used to clear crash all the time and instead of having to write a drash, clear crash CA, you can just write DCA. Again, this really saves you a lot of time and it's really cool. And also add some support for Git. Go check it out. The next thing is a Mac. I'm really excited about it. I'm really used to working on a Windows machine. So the whole way the window works was very unfamiliar for me. I thought it was very frustrating at times because if you're in this window and you want to go to another software like Firefox, it's really easy. But if you want to go to the same window as the software you already have open, this is not really possible because you don't really have the windows as tabs. So here, you probably just have to drag the window down to find one and then like, okay, this is great. I'm on this page, but now I want to go back. Okay, so either I can press in the button to go up down and I don't think this is efficient, honestly. And I think it's not very good workflow and people always just continue to just drag windows down and you have this, sorry? I'm going to come to, yeah, yeah. Exactly, exactly, exactly, yeah. And there's also a software called Shifted which gives you a possibility to drag the windows and control them because this gives you some of the feature tracks to control the windows. And I also have changed the mission control to key bindings so you can use that. There's like these hot corners which you'd touch without purpose and everything blows away. So you also bind it and then set up the speed and then also there's a command for a next tap or something, a next window, which does the same thing. So go in and check those keyboards, key bindings, because it will really help you out a lot. And then last thing is, last thing of workflows is fundamentals. I might look young, but I have a very old man inside of me. That sounds very wrong, sorry. I really like Vanilla CSS because I think you have a lot of these different, a lot of these mix-ins libraries. So you have these add-ons which you use. So you sit and you have these four different windows, taps open to make sure that you remember all the different documentation I use and I just need you. But it doesn't really feel natural for me to write this. I just want to write the old stuff I did before in the time, but this is really made for a reason I like to make the prefixes to make it compatible in different browsers. But Post-SS does this completely same thing. So if I'm using bourbon, I can write include transitions to get the prefixes. But if you use Post-SS, you can really do the same thing with just writing Vanilla CSS. So I think this is, it doesn't really take you away from how you write your code and it will be a lot more consistent. You don't have to write the correct documentation and it makes my workflow a lot more easier and a lot more intuitive. So the output would be the completely same. And also it can, the width, it said before, said 100% divided by two and it can also calculate to find out what the number is. And it's really cool because it's just, it's just when it's compiling, it's just saying, okay, this 100% minus two, okay, divided by two. So it's very simple, but also it makes it a lot more easy for me to work with. And then people have told me that live demos will go wrong. So I'm going to do it. Can you see my mouse? No? Yeah, all right, cool. So I have this problem with the example for the way you're going to create a grid system. Often you have this, you come in, you see another person who made this grid system and he's saying like, okay, with 25%, 25%, okay, this is like four or there, he have used a specific add-on which you don't know, but sometimes there's a lot of media queries and sometimes he like clear the floats and he has a lot of different directions to achieve the grid he actually wants. For me, I think this is a bit unnatural way to do it. So I thought maybe I can just write one mix in which actually you put on the wrapper and it does the work for you. So, okay, hold on. I created this monster and this is just long because it has media queries which repeats the same thing. But what it really does is you write include, you write include and then you put the name of the mixing which is color and then you write four, three, two, one and that is going to be the columns on the different breakpoints. Then you define the margin in between those, the elements and then you define the breakpoints if you have the different breakpoints. So this is just a really, really easy way for you to actually achieve the same thing without having multiple lines. Wow, it's responsive, wow. Just to see this working, all right, cool. So if I go in here and I change this to let's say six, eight, just to be a seven, just to be an asshole, like there and then go back, change it. It changed the grid. And maybe this isn't like completely groundbreaking but it really, really makes a lot more transparent how the other persons did the work and this is not going to work everywhere but it will work like, let's say 70% of the time and this is really a efficient way to achieve the same thing. The same thing is with the, with Flexbox which is really cool, which will be compatible soon. I'll create something called, didn't come, oh my God, I'm sorry, there, all right. Which Flexbox, which really doesn't care about how many elements are there, so you can just put how many elements and it will keep on looking the same and great. So I created a mix-in which does the same but are compatible. I had this client which wanted an Instagram feed but they wanted also the possibility to change how many images was actually going to show. So I thought, okay, either you can do what you normally do, you make the module control the body class or the class on the extreme model but I just got this in D&I and I made it. Okay, the last thing I want to talk about is the standardizing. I think this is really important because a lot of the time you have this, you build this component but I think you just build it for this specific project you're sitting on and I think if you actually thought about this instead of something which could be used in multiple projects in different cases. So instead of just writing it and making it work just here, try to think it a bit more general, see if it somehow could make it so general that you can copy it and reuse it because a lot of the time you're writing the same code again and again and again, it does the same thing. So instead of you just pack it up and make it easy for others to copy and reuse, you can suddenly get a very, very efficient workflow like that and all the teammates can just borrow it and change it like they want. So if Steve would like to use Comic Sense and make it orange, you can do that. And the last thing I have to say is just, I think also about being a front-runner is also about keeping up to date. This field is really, really evolving a lot so I think you should really also be interested, like research, spend a lot of time on it because it's really awesome and just don't be afraid of falling and kick ass. That's it, thank you. Also just to sum up, I remember that. You should always structure your project and workflow by creating a stable overview. You should be critical on how you work. You should create flexible and global code. You should eliminate those limbo's and try not to tangle yourself too much. And then if possible, use fewer frameworks and libraries and more post assess. You don't have to call it again, it's good. Cool. Yeah, so this is the end of our talk and what we would like you to remember is nice. Structure the output of your analysis phase. So it is flexible and ready for development. Keep revising your product, your product backlog. Questioning why, why, why you do stuff? Be transparent and global and optimize your workflow. So one last point is none of this can be achieved without your team. We are on a team together and we obviously have very different perspectives on our work with the clients, but we're really dependent on each other. So appreciate your team, respect different professional inputs and work together on the same product. And by that, things like prototype and clear overview can really help you a long way. Yeah. So. Thank you. Thank you. We're going to be in the exhibit hall from four to six later today. If you want to talk, please just come in. We love to talk. And you can also find a recap of what we talked about in the website here. And please evaluate so we can know how we can improve. Thank you. Thank you. Is there any questions? Yeah? Yes, sir. What was that previewing tool you were using in order to show your responsive grid? It was actually just the native from Chrome. It's just Inspector, yeah. Any more questions? Cool, thank you.