 Thanks for that. So yeah, welcome to improving your responsive workflow with StarGuides. That's a bit of a mouthful. The reason I'm focusing specifically on StarGuides today is, I think, I gave, who was here at last, Drew Burnett, under last year? Yeah, that's cool, not too many. But I did overall talk about responsive design, but it was actually called future-friendly design. And I kind of went into how to do it, like some of the slightly technical things, but then mostly an overview. And then I went into some of my workflow about it. I think I've seen over the year a lot of people doing that sort of stuff, and I hadn't started seeing people start to go a bit deeper into the parts of techniques that they were doing. So one of the things that I was doing that hadn't been talked about much as StarGuides. So this is kind of just around that topic and how I've kind of iterated through the year and since I've been using them and the different sort of challenges I've come across in different things. So just a bit of a background to me. I'm work at Glow Digital. If I sound a bit tired or groggy, it's probably because I've spent the last week up late nights getting that launched by two nights ago. We've sort of been doing responsive sites for almost two years now. So we've got a bit of a background in trying new things. I mean, this is very quick and sort of hashed together. We cut down a lot of features. So if you do go on to this and see any bugs, let me know, because we're trying to iterate really quickly on it, but we want to just get something out there. That's kind of what I'm seeing a lot of people do in responsive design is making it more collaborative, more iterative, and agile sort of focused, whether or not you get it out early or not. So I guess I think we'd all believe that the web is inherently fluid. I think we've kind of all started to understand that. Or responsive, you could call that. Or adaptive, or flexible. I mean, you could come up with so many different names. But basic fact is we can't control web pages. And if you're in Jason's talk yesterday morning, you kind of would understand that. He's had started to talk about that sort of area. I think we kind of get that now. But designers don't really like this. It's sort of mock-ups as deliverables don't really work, unless you're a masochist, in terms of you have to actually create. If you're going to do mock-ups for, say, like six different screen sizes, you're creating them all up. And then you take them all the client, and then they're like, oh, I don't like this font or this color. And then you got to go back through all these PSDs and different things and try and change them all. I think we already are getting to that point. But the other thing is that from the technical perspective, people are still just thinking of as responsive web design. But it's more than just that sort of thinking. It's not just, oh, yeah, work some desktop and kind of would just make it adapt a little bit for each sort of thing. It's more than just fluid grids, flexible images, and media queries. I think it goes back, like I'm sure you've heard all this sort of stuff before, but it goes back to the side of the web. And there's a really good quote. The power of the web is in its universality, accessed by everyone in regard to less of disabilities and essential aspect. Now, he uses the word universality. Does anyone know who made this quote? It was, sorry? He's been around the last few days. Yeah. So yeah, he said that from the beginning. Like, it's about using this versality. So I'd rather think of what we're doing with design and the web as a universal system that we're building with a consistent experience that pulls that all together. So we're designing systems, not pages. And it's exactly what Jason said yesterday. And the other part, though, of designing systems, is we're not controlling the pages, but we are creating the part that we can sort of bring together is a consistent experience. And Jason mentioned giving things meaning and hierarchy and things like that. But I think there is sort of a method to creating this system and creating this consistent experience. And so there's two main things that are at the core of creating a system, what do I think? Part of it is content and Eaton's talk. Did anyone go to that yesterday? Yeah, so if you haven't seen that, go check that out as well. This is maybe one other part to do with that. Like, so here you cover the content. I'm kind of going to go on the design side of creating a system. But that was really good in terms of content. So you need to create useful, structured, consistent data. That's sort of, I mean, that's all part of, like I'm doing usability or user experience stuff all through that content as well. Because if you've structured your content well, that's what provides the meaning and everything as well. And then you know what you're meaning. You need to get across in your design. You don't just come straight out of it with design. You've thought a lot through of your content before you're sort of doing too much with your design. I'll mention design here. The second major thing with the system, it's not just typography and color and layout, but actual visual hierarchy of things. And that all typography, color and layout all sort of come together as part of visual hierarchy. And then the interaction between different devices and things as well is also going to change, but you still want it to be sort of very similar. Like, people these days, like they've talked about, we've talked about people going, looking at for a holiday on an iPad and then going and booking it on a computer. If they go between the two things and they're completely different experiences, they're going to find that a lot harder, whereas if you can create consistent experiences, they go between the two or a phone to a desktop or vice versa. They kind of, if you can already know like what you're expecting from different things, it's a lot easier. So in terms of my design process, I'll just give you a quick overview. I sort of start with, one of the things I start with is atmosphere. I have like the deliverable as style tiles, but I kind of experiment with a lot of things. Pattern sheets is what I would call developing little components that would go on your website in Photoshop or something like that, just to try and try things out. And then I say, don't create mockups. Sometimes I'm just like, I really want to figure out what it might, everything might look like in this one thing. I don't show any clients any of this stuff, but I do it for myself just to be able to like get my head thinking right. So that's kind of a way around it. It's very dangerous though if you go and start showing clients that because then they kind of expect exact things, but then you can pull out the patterns from that and pull out things from those things, the colors and stuff you like and put them into a style tile. And then that's what you can present to a client as an atmosphere. Now the design structure, now that's just structuring the screen and the components of your website. So through all your content strategy and usability stuff earlier, you kind of would already have an idea of how users are going to flow through your website, what sort of content they'd be getting to, but then you need to like start structuring like possibly layout or different like wireframes and things like that. I kind of go off, start with sketches of things and then as a deliverable to a client, I'll give them sort of a gray box HTML wireframe that they can actually see at different sizes. I might send it to them in say, one of those like responsive bodies or something like that so they can sit there and cause they don't really do the whole browser recording and we all do. They kind of can find it easier if they go, they want to just hit the iPhone or iPad which is horrible, but that's what they do. And then combining them all together with prototypes. So you're taking the atmosphere, you're taking that structure and you're sort of combining it all together but at this stage you kind of, it can get a bit messy. You sort of, I do a lot of designing in the browser but it's because I've got all these other things that I've done before this that can help me design in the browser. I'm not designing from scratch. I've got like an atmosphere, I've got structure and then I start pulling it together. But then trying to keep things efficient and consistent like once you can sort of create a couple of pages in a prototype but if you have to start replicating stuff out sometimes if you're not careful it can get a bit messy. So I've thought, how do we design efficiently and how do we keep it sort of consistent? And that's where I've come across Star Guides. So I think a lot of people would have heard of Star Guides but they're not just like a cut and dry thing like I'm gonna make a Star Guide like what sort of Star Guide are we gonna do? Like so a lot of people would have just be thinking of Star Guides as like for brands. So say, Melchimp has a really good one. It's just their brand and it's got their logo, how to use their logo, topography and stuff but more so just as their brand not like how it's used all across the websites just specific basic stuff. And like what people have sort of who has the idea of like a Star Guide is kind of like this is what their idea of a Star Guide has been in the past or print from print or anything. No, that's good. Because well most of us are from the web so this is kind of like even though this is a website sort of branding books and things come from sort of the print side of things. The other type of Star Guides is editorial. A list apart has this and this is kind of where Star Guides came from. It was like late 1800s I think. They actually came up with Star Guides for how to write content and rules about actual language and how we write things. And it's good, these are really useful even today on websites for sort of specifically for editors, for like just content editors and like with a web one though you would include like how to use certain tags but also the language you should be using tone of voice, things like that. And then there's coding ones as well which Asaba has a really good example. They've included like their JavaScript, CSS, HTML all their coding standards so if people come onto the team they can sort of like Star Guides for developers that they can come in and understand how to do that. You might have even seen our own one, the Drupal. We have our coding standards and that's basically a Star Guide for all that code. And I think for most of it that works pretty well. But that's still not the type of Star Guides I'm talking about. What I'm actually talking about is you need to use your interface Star Guides. So has anyone seen the BBC's gel? This is probably like the most thrown out there like everyone uses this example as a user interface Star Guide. And it's because it's really good. Like it is, they cover a lot of stuff. They even put some tone of voice stuff in there. Their goals like a lot. But it's also the thing that stops other people creating Star Guides. Cause they're just like holy crap. Like how am I going to create something like that on my sites and nowhere near that big. I don't need this. So I thought what are some other examples that people are sort of more used to? Actually there's another point. The other thing I thought about that was they call it a global experience language. And so I thought about what I was very earlier and sort of global that kind of sounded, it's very similar to universal, same sort of meaning. Then we've got, we're looking at a universal experience. And it's also language and system. By the Oxford dictionary, language is a system of communication used by a particular country or community. So when I was thinking about Star Guides to a design system, it's kind of like the dictionary for a language. It's sort of you to sort of understand how language works. If you want to find out a word, go look in a dictionary. But if you want to understand how a component of a website works, what if we had somewhere to go to understand what its purpose was and what it was used for? So the other examples of these that people are sort of more used to is things like foundation. Has anyone heard of Zerb's foundation for framework? Yeah, so it makes it really easy to put together like a basic responsive website. And they've done really well in documenting it all. But they've also thought through how to pull apart all these components, how people can reuse them. And it does make it really easy to build stuff quickly. And sometimes in the past, have used this for doing the wireframing stage. It's really useful for. But I still try not to use it for any actual sites. I don't know if people have heard of this one before. Bootstrap, does anyone? Does anyone? Yeah, this one's, it's just crazy. Like both of them are both massive libraries that people get a lot of use out of. But I dare say, if you went to the site and there was just a bunch of stuff on the page, like use this library and go look at the CSS and try and figure it out, not that many people would have used it. It's not sort of that easy to use without all the documentation that they go through and explaining how to use things and why they use it. So what can we learn from Bootstrap and Foundation? So the main thing they do is they abstract these components and then they like sort of decouple them from the layout. There's no hash sidebar dot block. There's no like actually tying components with their containers or with their layout. And this is what you really need to do with responsive design or designing a whole system is being able to build components that can be used all throughout wherever you put them. So you don't have to keep repeating code and you actually understand how these components will work in different situations. So it's also a thing that's come across in these sort of methodologies of SMAC's O, O, CSS, and BEM. I'm sure has anyone heard of any of these acronyms? Anyone been using this sort of methodology? Yeah, for you guys? Any of, like, these aren't like really rigid sort of methodologies. At least that's not what I take them as. But they're basically flexible, sort of dry or don't repeat yourself systems. They kind of all have similar methodologies which is basically being able to reuse stuff and try it out. Just kind of looking at your designs, breaking them down, seeing rather than creating a teaser and an event teaser or something and creating whole new CSS for each of those, how can you just extend that out and reuse most of what you've already done and just do slight variations? Things like that is how you can use it. So the advantage that you have of building these systems and things like, well, the actual using Bootstrap and Foundation is they solve a lot of the basic problems that you would come across and develop, like say, I need a button for this, I need, you know, I need a hero unit or something like that. And then it's like really easy for the designers to, I mean, so developers just go in and grab bits and build things really quickly. It's predictable and it's consistent, like people that all use it, it's like, yeah, just go use Bootstrap and use this little component there and be able to do it, which is what makes collaboration easier. Like I was saying, you can test ideas quickly, you can, people build sort of whole apps just on Bootstrap, but the problem with it is they are, because they're built for everyone, they are very general or originally they were very close to what Twitter sort of ideas were, but there's not a lot of meaning behind some of the things. They don't know what your content could be. And they, because of this, this is why I probably class them more as a pattern library than a style guy because there's no purpose, like no specific purpose to each of the components like, yeah, it's a navigation element, but or a nav bar or there's certain things like that, but a lot of it doesn't really always come across well if you're just trying to create good experiences for your particular product. The designs you pretty much know when you've gone to a site made by Bootstrap unless they've customized it a lot, in which case, usually I'd have to code to their sort of standards and like keep it similar or you kind of just hack at it and then a lot of people don't really understand what's going on behind there. They kind of just go, oh, I need this to work and then they just add their own little bits on at the end and it's those bits of the bits that get sort of harder when people try and come in and go, why isn't this working? And there's like lots of very right. So it still has a lot of problems to Bootstrap. So what if we could create our own Bootstrap? So I thought about this and then the main, when a lot of people think about it, they're like, well, that documentation took a long time to write. They had to figure all that stuff out and my project isn't big enough for that sort of thing. Like you might like say anything, say most of us here wouldn't be making like one page marketing sites or if they are, then that's like a whole different thing but most of the time we are building what is usually considered a system with using Drupal but the thing is, it's not usually the project isn't big enough, it's probably just that Starguides take too long to create. And so I thought, how can we build one quickly? And this is kind of my process that I've been going through all through a year. I've been trying a lot of tools and a lot of them we tried and what you would expect happen that they either were too slow to create in the first place or once we did create them, they were really like hard to update or didn't stay updated. So things like static image based Starguides, they're just not gonna happen, like creating screenshots, writing, doing anything in Photoshop, having to manually do all that sort of stuff, it's just not gonna work. And something like a pairs or a patternry, I mean pairs we wouldn't use that because it's WordPress, but patternry or something like that, you sort of go to a website, you put in your code and you save it and then you sort of build these libraries by kind of pasting it all in, but then you've got, what if you wanna use it across things and sort of have your base stuff interact with it, it kind of, it's more like a copy and paste job, it's almost like including snippets, but you get to see what they look like. Then Nile Style Sheets was like the first one that really sort of struck me is this could be really useful, but I mean it involves steps of you creating a template for one component and then you're creating the actual CSS for the component and then you're creating documentation and they all have separate sort of areas and then you gotta manage them all and that was actually created for use for GitHub and it works sort of well for them because I think they're so huge and they can sort of take the time to go through that, but if you're trying to build a site really quickly, it's not as useful and also it kind of had a build process and it was a lot of sort of barientry for some people and that's why I kind of went across with pattern primer, which is something Jeremy Keith created, just a PHP script that looked in a file of HTML files and then it would create, put them all on a page for you. I kind of did my own little version of that called pattern response and then I made it so it actually got those files and created a menu structure so you can navigate through it really well and have a few extra features and search it, but that was sort of what I used for a little while, but then even that was still getting a bit cumbersome because I was creating extra HTML files. So what I sort of came to is I needed to just remove as much fiction as possible, but there was two tools that I found that could actually do rapid star guides and the ones that sort of came up the most was Star Dock-O. I use this for a little bit and I still think it's a really good tool. It can actually generate stuff from SAS and less and it actually generates a very similar way and the next one I'll show you. It kind of creates this navigation structure of files and I'm still like, that's the sort of thing I'm trying to work off. I want this system that's going to be really flexible as well. So the second one I came across was Calais Star Guide. So that's actually just like CalaisStarGuide.com, I think. And this is probably the, this is what I'm using now, and it's the closest I've come to. I'm actually working, the other developer is also in Brisbane, so I'm actually working with him now to try and build off this, redesign it all, add in all these things I'm thinking about. But for now, this is probably the best thing I've thought of. I still don't like the structure of how it pulls in files, but the reason I like these tools is I'll give you an example. So we wanted to create this part on our Star Guide. This is straight out of the Twitter Bootstrap. It's got the name of the component, then it's got like the heading of that one particular area of component and then it's got an example and then it's got some code. What if, so to create that, you would think, oh, I'll go create other, just put all that into HTML and then actually create it. As a separate file. Whereas with something like CalA, I can actually, what it uses is just straighten your CSS just above whatever you're writing. You put in CSS comments and then in Markdown, you can write, just like, you can just put, so you can just write in Markdown, like a H2, H3, put in a sort of description. I know, who knows Markdown here? Yep, cool. So it's sort of a lot easier to sort of read and then you can kind of put in actual HTML code straight into CSS. And it does make your CSS way more verbose but you would never actually use this in production CSS. I use SAS, would just do a sort of completely compressed version at the end. And so it just strips out all these comments so we don't use any of these in production. But this can be, this is what is referenced by these style.co and CalA. And so you've got your information, you've got your actual element in HTML and then you just put your styles below it. And then you do that for all your different components and areas. And so, what it actually creates then is, like the example before is, it sort of will output exactly that sort of information on a page. I know style.co actually puts the SAS or CSS next to it. I don't think that's really useful in a style guide. But CalA just will, you don't even have to build anything. You just point it at that file and it'll generate it on the fly with JavaScript in the browser, straight from CSS. So you can actually start loading, you can save your CSS, reload your style guide and all your stuff will be there with components. I'm editing. Yes, which I will get to. So I thought I'd try and explain a bit more practical stuff and go back into sort of how the theory, because it was hard to figure out the structure of how to make people understand it. So in terms of the advantage of this is you're creating it as a code. There's like no extra file that keep me not going between different files, which means like your CSS is easier to read, but then if developers come back in and like, oh, like I want to just change this thing. Even if they've forgotten about that there is a style guide, they go in and they go, oh, that's right. And then they can see the HTML element there. They can see the code, they're using it. You can see your description of what it's used for. And then they can understand like, oh, maybe I should just, maybe I shouldn't change that. Maybe I should create something like a sort of sub component of this, or maybe I should just, this is how I should use it and just remove this element. You can kind of start testing things out in terms of if you're building a prototype, sometimes you don't want to start chucking a bunch of components in there because it kind of gets messy and then it sort of doesn't always make sense. Whereas you can add new components straight into a style guide, refresh a page, and you just design a component by itself, like without any of the other stuff around it, you can use the sort of style guide, test out things like screen sizes and other sort of contexts, which I'll go into later. And, oh, sorry. This is the parts also that I've been using. I've sort of designed all the way up to theming. Sometimes I'll do the theming, which then I don't know if I worry as much about it, but if I'm passing it over to somebody to do some theming, and we sort of start collaborating together, we can kind of use the style guide. He'll be like, oh, I need to make this element that we haven't sort of created yet. I'll just sort of create that, save it, and he can just, this is updated on his style guide straight away. He can sort of see what I've been creating. He can just grab like, just like in Bootstrap, you'd be like, oh, I need that little bit of HTML. He'll just grab the HTML, put it in, out, put that in the template, and it all starts working sort of together to make it really easy to sort of collaborate and he can give me other ideas and he can go in there, change the style guide just with CSS. And if you've got a whole get sort of workflow, it works really well as well. And then in terms of when using SAS or any sort of preprocessor, if you've got all these partials, I mean, if you haven't learned any SAS stuff yet, John Album's talk yesterday was like, actually awesome at this, and he sort of talked about most of SAS stuff, but you can kind of see where partials come in real handy when you're creating separate partials, but different components. And then say you want to create the editorial style guide for your editors, rather than redoing all this stuff, you can actually be writing in a separate style sheet or something, all the documentation they need to know for them specifically. And then when you need to, pull out elements from this one as partials, just import them, and then it's pulling in exactly the same code that your developers are editing. So every time they change it, it updates on the editorial one as well so they know how they can see the different elements they needed to use them, which really probably shouldn't be if you're listening to, in any way, which is basically just HTML elements. So yeah, before I go more, the things I want to change with this is the usability of them is still not great, but they're still usable, but I want them to be a bit more navigatable, easy to find things. I want to be able to start designing more components in the browser separately from a whole design. So things that I don't see a lot of yet is context sort of altering. What I mean is obviously screen size and people have been doing a lot of that, but actually things like modernize, I've been able to turn on and off modernizer classes, like touch and no touch and swap things off like that, see what can this do when it changes context. I want it to be file agnostic, so it's all based on markdown, creates a structure from that. And then I want to be able to, when I'm getting a component, be able to see I just want to just try to look at this one particular component and then you can just sort of hit a little target of this component and it'll go to another screen and it's only that component on the page. You just keep saving, you see it's just sort of designing with that component, give you some sort of things to drag and play around with it, almost like a canvas is in Photoshop, but with a component. So that's the technical, oh, there's a bit more. That's the how to document it. But then it's sort of like a bunch of, that's still just bootstrap. There's still not a lot of meaning and rules around this. So I sort of start with settings and that's kind of where you base all your design atmosphere. So things like typography, colors, baseline, and then your common breakpoint, you can set them all in a settings file, then put comments in with them. So other developers can come along and see in the style guide, like I use this variable for these colors when I need to like redo it, or you like reuse the elements, all this sort of stuff you can put in as variables, so they're accessible to developers to use further on the style guide. The elements, anything that's just a pure HTML tag, you can document these things. You sort of, I start with maybe some sort of normalize, if you need to comment that, do that, but mainly adding all this atmosphere from the settings then into these sort of elements, and then you can actually, I reuse a lot of this stuff basically from project to project because they're basically HTML elements, and then you start your next project, you just load up your style guide and be like, oh crap, I just want to fix up all this typography, like you've sort of changed your atmosphere, and then you've already got all the elements. So a lot of the time you start creating prototypes, there's no content or something, or you're doing certain elements, and then you might launch a site, they put in a table, I put something in and they're like, oh crap, we didn't even style that. It sort of gives you a big inventory of everything you need to style before you do, and if you've got basic stuff that you've already included, it kind of helps as well, and then you can, just by changing some of your theme variables at the beginning, I'm getting a bit technical on SAS, everyone should use SAS. But then the next thing I go through is like layout. So stuff like grid structures, and then anything, besides grid, maybe just like different classes that would actually affect layout, but mainly they all really still need to be completely separate from any sort of, like components or elements, you shouldn't really be mixing them together, because that way you can actually, it's the best way to create sort of a universal sort of system where it doesn't, nothing relies on anything, you should be able to chuck a component in anywhere, and it will adapt to its own situation, not just the whole website adapts like pieces of it, you don't need to be able to adapt. So this kind of adds another context as well, rather than just being screen sizes, well, how does a component adapt to different containers? And sort of you're kind of using the wireframes that you created earlier to create these sort of layouts or allow for you to create these sort of layouts, which you'll do mostly in prototypes and things like that. Now the components part is the biggest part that I work on, it's basically where I'm adding most of my code. And if you probably, yeah, this is a very smacks-like structure, I know there's a bof after this on smacks, if anyone wants to talk about more and that sort of thing, but it really sort of helps you decouple code and build things better. But it's really sort of where things start to get interesting, because it's where you need to think about a lot of your meaning in your design is in these components. So we're using everything we learned from content strategy stage and the sort of how the user should do things, what they need from sort of different components. Like if you're doing wireframes, there's like big boxes, if you're doing gray box things, it's sort of saying what components need to go there, but you haven't explained really what they need to do yet. So you're kind of getting, bringing down that meaning and trying to put it into specific components. And then I'll actually sketch them out before, if I haven't already done that earlier, like actual individual components, I might sketch them out and actually put them into code. So navigation elements, I'll try and figure out how it's gonna work all these different contexts and then change that. In terms of, the first thing I sort of work out when I'm looking at a component is its purpose. So like what does it need, what's this component gonna be used for and sort of what tasks will it need to perform? Like a really obvious one is navigation. So this is really basic broad sort of stuff, but you can get very specific when it's a specific project, but say navigation needs to allow easy usable way for users to access the content they need, but it also needs to convey the sort of where they currently are on the site. So they actually get a sort of context of what page they're on and how they can navigate away or go somewhere else. So that's kind of the first thing I would include in my comments at the start. And then I would include, I'd start thinking about context, like where could this component be put? Where should it be put? What sort of screen sizes does it need to adapt to? Like say, where should it be put? Like does it always have to sit, like only ever put this in a banner in the banner or only ever put this somewhere. Should it have different interactions for touch devices or for, if it doesn't have CSS transforms, should there be no animation? Should it be a fallback for this? Like all these different contexts when you think of not just width of a screen size and like the container of like, say you put something in a sidebar, but then also it could go in the footer in another block or something like that rather than doing specific IDs for these areas, be like, there's like the standard size and then it's like when it's, I have a constrained class or something like that. So it like adapts to that class and then you create you like sort of allowing it to do all these different things. And the adaption part is like, what is it gonna do? When it reacts to a context, like how is it gonna sort of change? What's the structure gonna change? How's the size of it gonna change? How's the content gonna change? Which could be simple things like maybe the teaser text gets a little bit shorter. There's still a way to get to it, but it's like to allow a bit more room, but you gotta be really careful with the content side of things, you don't wanna be hiding things and not allow them on smaller devices. And then the interactions will definitely change, say on navigation. So you sort of context causes adaption and that's what you sort of thinking about as you design all these components rather than thinking of it as the like, earlier on you might think of it as a whole page, but then you've gotta think about these components and how you can build these systems. And when you're thinking about the actual components, is there patterns that exist safe in navigation? And then kind of break them like early on when responsive design people were using select menus for a menu and it was, people started using it more and more, but it was never a really best practice, but they saw it happening until people started going, that's just crap way of doing it, change how it does it, like you don't always have to keep to the same convention to see, try new things and try them out. So in terms of an example that I might have used with all this stuff in it, it's kinda gonna be hard to read all that, but then I've got an actual rendered example. Let's say the nav bar, you've got the purpose at the top and then you've got sort of a few points on how all the different context and how it reacts. This is a lot of content, usually I wouldn't have this much, but the nav bar is probably one of the fundamental things that you use on a website that needs a lot of thought about it because it's gonna be used differently. So that's got all the, I left out the actual CSS there. But the next, so this is how it would render. So just from all that, it's just basic markdown and then now above my actual navigation, I've got it, so you can kinda see that I've got the purposes right there and it's like on small screens, items are hidden and toggle link is displayed and an icon font, as an icon font, unless font base is not detected in which menu text is fullback. And then it kinda goes on to explain more stuff that's happening on the small screens but I've sort of, you can choose whatever you want. The one thing I've sort of started doing is bolding things that are context and then like italicizing things, how it adapts and then you can kind of go back there and understand you're thinking about how you created that sort of component. I hope this isn't zoomed in. Cool, and so after I've done that, I kind of start thinking about the dependencies on things. So you might wanna put as a little notes at the end of things that they do depend on JavaScript for drop downs or something like that or you wanna put a link to the actual partial file that it actually was created in so people can find that easily cause sometimes I will create a whole another style sheet just for the style guide and it will actually be one big style sheet separately with all the comments in it cause that's, and then you've got all of your sort of headings and it's the easiest way to sort of get it into something like that Calais. So even fonts or images that relies on you sort of can document in there. The other areas I'm not that concerned about cause usually it's not a big thing but in terms of smacks there's states and theme or skin or whatever you wanna call it but I have a very minimal state sort of partial and it sort of just mainly includes some JavaScript classes and how they were hacked and you can document them in however you need but it's not as sort of important as your component documentation sort of thing. So from all this, we kind of get a more agile workflow. It sort of helps you optimize your code by giving designers and developers a sort of great understanding of what's happening. It's kind of a really big advantage is document with the site as well as like coding standards if you can do all this together and then you sort of file that site away you need to come back to it to a client. You can pull up the style guide that was created with that site even if it's a year later and be like oh, that's what we were thinking. What the hell were we thinking? And then you can sort of get back into it or if you build a site a year later you've got all new developers they can come back in and see these are the coding standards we had at the time. These are like the style guide for this whole UI and understand how it was built. And I mean even for small sites if I create a small site I can straight away take all those HTML elements sort of automatically start generating a style guide maybe it doesn't have that many components but it's got like a style guide there that you can sort of reference even like clients can reference if they want to be able to start looking at how what you're designing and then sort of seeing the purpose of different things. So basically from all this we just need to know that we're designing consistent systems and experiences. You're sort of using the atmosphere and structure that we sort of came up with earlier in the design phases and the biggest thing is trying to create a collaborative workflow for responsive design because designers really need to work with developers a lot. Designers really need to know how to code but I probably don't have to tell anyone hear that. We need to make the systems easy to build and maintain because otherwise that won't happen. A lot of the time people just get impatient. I find developers usually are very impatient with designers sometimes. So being able to build these things in quickly and not have to go on and on about it is good. And by building it as well like a lot of components I'll reuse across projects but then just slightly adapt them and I don't have to keep going in and changing things. I'll use variables at the top of the component to like certain things. If I think I might want to use it again I'll put some variables at the top of the things I might want to change and then I don't actually have to change any of the CSS and then I'll put that all in as part of the style guide and it's so easy to just go in, change it and then you've got these new components. I think the form styles on Glow Digital we did that so quickly and I pulled some of that across from a new project. I completely forgot about the forms. We were about to launch a site and went to the contact page, created the stuff and then it was like, oh, that looks good. And I didn't have to actually do anything yet but because all the sort of theming variables had been put in, the colors had changed. It didn't look like anything I'd done in a previous site but the sort of everything was there already done. And sort of, yeah, so just remember to sort of abstract these components and think about the purpose and the context and its adaption and how they'll work in your whole system. And that's everything I have and it's like node A4-3 and that's the slides on GitHub that you can get now. Cool. Yeah, the theme. Yeah, so what theme am I using to implement this sort of stuff? We basically, we tried even some base themes at the beginning when we were doing responsive stuff and everything just seemed to sort of stop us doing what we wanted. So we basically just write stuff from scratch every time. Now we might pull in like template functions and things that we reuse specifically to rewrite classes in Drupal but a lot of, yeah, maybe we just sort of we build off a past, whatever the last site was we pull stuff out of that, build a new one. It's kind of otherwise it's never gonna keep up because if you're building stuff, if you're not annoyed with what you built six months ago you're probably not moving fast enough. So, is that helpful? Yeah, cool, nothing. Yeah, yeah, so actually I didn't mention that in terms of where, how I put in the context into the actual CSS. So I'm mentioning it all in the top in the describing what I'm gonna do with these break points but then in the actual CSS I use the break point module with compass for each component. It's usually like every time I open a nesting sort of area I will do all the default stuff from mobile art and then I'll start doing context. So then I might do the modernizer classes and I'll do them as parent selectors so dot no touch and then an and symbol and then after that I'll start going from small, medium, large, huge screen and whatever like that but I'll put them all related to that component within it so I'm not creating whole style sheets for each different screen size or I think they're all in the component so you kind of see them all. No, yeah, that's cool. It's not a service, it's just a GitHub project. It's just Kalei style guide. Yeah, it's just local. Yeah, it's written with like, I didn't write it but it's written with like underscore and a few other different libraries, like a crap letter libraries in there is used but I don't know how he's doing it but he's like rendering it on the fly in the browser just going like looking at the CSS file and yes, so I actually have one. I'll try and, so I'm zoomed in. Sorry, I think there's a zoom thing on there. I think this thing is zoomed in. What the hell is going on? Yeah, okay, sorry, I'll go back to that page. So we're still building this as well so this is actually some of our, so you see it's loaded the styles there and see this down the slide is what I'm trying to improve because it's actually only loading in all the H2s or in H1s is one big list. What I'm trying to do is make it all into parents so that's what I'm trying to, and I don't like the look of it at all but things like this colors thing, that's where I start at. I've actually created sort of little classes that I put in the CSS, so that's in the comments. That's actually an example that I'll put in and I'll be, I could actually open it up in that setting of my directory. Yeah, so that's just like basically, it's just in another folder, the project and it's called slash style guide or whatever. And then it's, that's where I put the actual project off GitHub. I put it in there and then there's a config.js file. I go in there and I just change what CSS file it's looking at. Usually it's based off, oh no, it's got it's own one so you do have to go in and change it. But basically you just tell it whatever CSS file you want to look at and it'll do it. At the moment you can also do like add imports in the CSS files and that's how it'll do these extra menus but I want to change the whole structure of that. But, so if you want to follow me on Twitter or whatever I'll be working on this hopefully. I've already designed part of it and passed it on to him so we're trying to like work more on it. But you can sort of start at least using this part of it now. Let's see even things like you sort of type I've got like font family base heading and then you start including things like headings. I don't have a lot of meaning behind all this sort of stuff yet but it's sort of, you've got other things like classes for, I put them with like say heading one, heading two. Look exactly the same because every time a client wants to use like I want to look like a H4 but it should be a H2. You can do things like put that in there and just use that, but use a class to make it look like it but it's actually still semantically correct. Anyway, things like that you can kind of put them in there. I know that's just sort of how it generates it's got when hover over here it's got the actual HTML so you can kind of select that out. I'm sort of, the design that I've done is sort of changing that to be you're hiding this menu and it's hiding all the code and it's just so you can start it looks like a really nice style guide and then you go through it and it's just got tabs to code and then it's got little elements across but yeah, it was that, sorry that was sort of a lot of, yeah Snug, yeah. I have seen, I downloaded that actually and I was trying to look into, oh sorry. Yeah, so our toolkit by Snug, yeah. I saw that on GitHub and I downloaded it and was looking at it. I don't know if I looked at it thoroughly enough to know I think was it based off Ruby or? Yeah, yeah. It was one of those ones that kind of looked felt like it was starting to do two specific stuff or be, at least for me be too hard to set up every time. Oh, okay, yeah. Yeah, yeah. Yeah, so yeah, it's sort of, it's interesting how everyone's doing it and I mean, that's what like the style docker, it's all running off node and you have to do a build and tell it which files to look at every time it builds. So you have to go save your CSS, then you have to go build again and then reload it. It's just another step that I didn't like doing. I mean, I'm using grunt.js as well and that's generating, I just using running grunt and then it's, I'm using compass inside of grunt and that's giving me sort of two different settings instead of using config.rb, I'm doing two different settings in grunt and then it's creating a fully compressed CSS and it's also creating the style guide one as well and putting it in a different spot. So it's a bit more automated in that sort of way, which is what also keeps it up to date on production as well after you go. Yeah, normally it's live, it might be an older one on the Glow Digital one at the moment, but so you could go and have a look at that maybe but don't tell anyone I said that. And they stopped recording this, right? Yeah, so what I kind of see is what I want to do with these sort of style guides is not just be for CSS either, you could go create, like that's what I want to base it purely of markdown and heading structures. You could go create in like a markdown format just your whole documentation with code examples. Yeah, yeah. Yeah, well at the moment there's some weird sort of CSS I'm doing to do that as well with like buttons and things. Style.co can do that if you do put a class in your examples with like a semicolon, like hover or something like that. It'll do that. You can kind of go and put it in your own style guide with like this like a slash 30a or something. There's some sort of thing you can do to make it actually. The style.co one does that. I think we're trying to implement that in this CalA one as well. But yeah, effectively I would like it to work on anything. It doesn't have to be on CSS comments, but you could point at a JavaScript file and have comments in it possibly. And I don't know, it would comment, you just create a style guide for your JavaScript if you wanted to. It'd do it for anything really if you got to that sort of stage. And it's because it only gets the structure from markdown. At the moment it doesn't do that. It gets it from semi file header sort of weird thing. But it's getting there. Like hopefully if he doesn't do it and he doesn't want to do it that way I might just try and find someone else and build it myself that way. Yeah, yeah. Yeah, anything. That's sorry, sorry, yeah. Is it tied to SAS? Or does it need to be, or can it be used with straight CSS or less or something like that? That's part of the reason I do like using it. I mean, and that's why I use that syntax. I know style.co can work with all of them, but it'll look at partials as well. Whereas I think they just started making less work in CalA, but it doesn't work straight with pure SAS anyway. I actually generate the CSS file. That's why I use grunt and do a few different things to create different CSS files. But I kind of prefer it that way because who knows what prefixes and different things we'd have, but I want it to be as universal as possible so anybody can use it and you can just use CSS, you can use SAS. I'm more the SAS side of it is about designing components and the more smacks methodology, but it doesn't mean that you can't do it that way. And that's also why I don't use silent comments in my SAS because I want to output in the CSS. And then if I actually want to do any specific comments that I don't want in the style guide, I can use silent ones then and then they won't go into the style guide, which is what I found in some others. They put everything that's in silent select is in the style guide and then I'm like, what the hell is like all this crap in my style guide? Yeah, cool. No. So yeah, in terms of what am I showing to the client in terms of the design process? This could be a whole nother talk in itself, but I've actually found it really useful. I've got hardly any sort of back and forth. I don't know it's because like mockups, generally they go, they think of, they get this one idea in the head and then they stick with that. Whereas I show them bits and pieces along the way and I kind of, I do a lot of the content strategy stuff and usability stuff with them and I'm talking through it all and a lot of the ideas are going into what I'm building and they're seeing bits and pieces every time. It's very iterative, but then I'll show them like the style guide so they see, oh, here's the design atmosphere, then I'll show them gray box sort of wireframes and they'll be like, oh, here's sort of how the structure might work. And we don't even sometimes always stick to exactly that, but they can kind of get an idea of what we're trying to do and then we'll show them maybe a couple of pages of prototypes. If it's a bigger site, we might have to show a lot of prototypes, but generally I like to go, if they're sort of agreeing with what we're starting to do in prototypes, that's kind of like your mock-ups, but a couple of pages. And then because it's already in code, we start like, and we're doing the style guides to do all the extra components that aren't in the prototype anyway, like you can put those in as well. I'll also still be working on the style guide and creating components as we start theming it up because sort of from the structure phase and content strategy even, we're starting to build a Drupal site as well with no theme or anything because we've got that data model there of how it should start to be working and then we can bring in the theme. He can start putting in all this sort of CSS from the style guide that I've been building into the prototype at the same time sort of thing. Yeah, and then once it goes into a theme, that's kind of where it also has been a bit of a downfall in the past with the style guides. Once we start putting into a theme and then we switch the CSS from the prototype to the theme, the sort of style guide sometimes wouldn't be getting updated anymore because we'd have to be doing this weird thing whereas this way I've got like, I don't know, you could probably figure out something that, I don't know, I use grunt and that's why it's got, I'm still generating the prototype CSS, the style guide CSS and the production CSS that goes straight into the theme all in one go. I'm like saving and it does it to all of them, reloads the page and does all the different stuff and I have my browser there, reloading it as I'm doing it, so it's almost like Photoshop for me but in code so that's kind of how I'm doing it. But yeah, sorry, yeah. Yeah, sometimes the smaller stuff I don't show clients much of the style guide, it's usually the bigger ones where they kind of are missing some things from their site that they need to see and if it's important to do it before we go into Drupal then they'll do that but sometimes we can, we start building at Drupal and then we show them that as well but generally I have not had a client yet after going through the whole style tiles, then going through wireframes and then a prototype, there's been no major changes that happened along the way, they changed layout stuff at wireframe time, they changed design stuff at atmosphere time and they only tend to make very small tweaks at prototype time and so I don't usually have to restructure a lot of code but then even the way I do it with all the variables and components, they do change things, it's so easy to pull stuff out, things fill gaps and you can, because it's a system it kind of builds it. No, no, no mock-ups but the, yeah, like this stuff. Yeah, the atmosphere stuff. Yeah, the atmosphere and the structure and the wireframes. Yeah, yeah, pretty much. And the other thing that I do in the content strategy stage is I will document screens. I'm sort of going into my whole workflow thing here. I've actually got slides up online. Yeah, I've talked about the thinking behind this on I've got a .NET magazine article that was about future-friendly workflow if you look that up. But that's a very basic over-broad thing and then I've done a presentation I think last August, it's on slide share and on speaker deck of like future-friendly workflow but I do all this content stuff which involves screen description diagrams, so figuring out all the content that goes on different screens in like sort of order of meaning, like priority and different things like that. And then that sort of is deciding things there as well. So I'm not deciding the content. So that's, even the wireframes is not so much a content, it's like containers for content in the wireframe part of it. So yeah, I've just been, you have to just really communicate to the client on all these little points and I've found that they've had because they've had that interaction all the way along and I don't know if it's just the way I explain it to them but I haven't had any massive problems and then if they wanna change a font here or a small thing there, if it's at those different stages they usually do it at the right stage and yeah, it's actually been, we've been, ever since we've been doing it, we've been doing everything way faster. We still, there's a project we started before we did any of this and it's still going and all the other ones are finished.