Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Realigning & Refactoring UI - Jina Bolton48:07 with Jina Bolton
Often designers and developers see Markup and CSS Refactoring as a dreaded, monolithic task. Organization, architecture, clean up, optimization, documentation all seem tedious and overwhelming. However, if you're armed with the right tools and a solid foundation, you may find refactoring to be actually quite fun. Learn some Sass, markup, and documentation tips & tricks from a product designer's perspective. Start making refactoring a regular part of your design process and development workflows.
[BLANK_AUDIO] 0:00 So, I'm gonna talk about refactoring Web interfaces. 0:05 I'm gonna try to get through this as 0:10 quickly as possible so that we can actually 0:11 have time for questions and, you know, make it sort of a Q and A session. 0:13 Cuz it's supposed to be a workshop, but if not, if that doesn't 0:18 work out, you're always welcome to come find me and ask me questions. 0:21 So, I'm product designer at do. We basically are just a, 0:24 a productivity app to help people work better together. 0:30 I'm gonna start with a quote that says it used 0:35 to be that designers, made an object and walked away. 0:36 Today, the emphasis must shift to designing the entire life cycle. 0:40 I like to focus a lot on workflow and process. 0:44 Anyone else in here really into workflow? 0:48 >> Yeah. 0:51 >> Yeah. >> Yeah. 0:51 >> Really? 0:52 Awesome. A lot of people I know are just, 0:52 like, not into that. 0:56 [LAUGH] So re-factoring is a big part of 0:57 my workflow and I actually really love re-factoring. 1:00 And you know some people think that's weird but I love it, I think it's fun. 1:03 Anyone else? 1:08 Yeah? Cool, awesome, you're my people. 1:09 [LAUGH] Yeah so sometimes re-factoring kind of gets put 1:11 on the back burner Because it's considered busy work. 1:17 But I think it's really important and it shouldn't be put on the back burner. 1:23 [LAUGH] If you ever said you write code perfectly the 1:26 first time, you're a liar, and I don't believe you. 1:30 Because nobody writes code perfectly the first time. 1:33 I don't care who you are. 1:37 [LAUGH] It's not true. So the reasons we need to re-factor. 1:38 [COUGH] excuse me. So if you have a lack of clarity 1:44 in your code, it's gonna lead to a lot of confusion, 1:48 which is gonna basically slow you down, slow your team down. 1:51 And if you have no maintainability in your code, that's gonna lead to inefficiency. 1:56 And the more efficient we are, the quicker 2:03 we can actually spend time making cool stuff. 2:06 [COUGH] excuse me. 2:10 [LAUGH] So refactoring is to change the structure of 2:11 existing code without actually changing the behavior of that code. 2:15 And so that I think a lot of what people think about 2:21 when they think about re-factoring is like, getting rid of code smells. 2:24 And that is a big part of it. 2:27 For me, I just, it's not just about code smells, but it's 2:31 just about like, the general, like, work flow of, of everything I do. 2:35 Anytime I'm working on a feature or a new, whether it's a new feature or an old 2:38 feature there's always some sort of re-factoring involved. 2:42 I love Sass. 2:49 I don't think I have to be evangelical about 2:50 Sass because we're all at Sass conf, so I don't 2:53 have to tell you how awesome Sass is. But Sass is really awesome. 2:56 Is a big part of my workflow. I also care a lot about style guides. 3:00 And we've been hearing a lot about style guides, I'm pretty sure like, 3:06 there were like three or four different 3:09 talks that talked about style guides yesterday. 3:10 Back when I wrote this article on A List Apart. 3:13 It's just about like, an interface style guide. 3:17 At that point, 3:20 I had only been doing them on like wikis, or like printed like PDFs. 3:21 I hadn't really thought about like doing like a living style guide at that point. 3:26 But since then, I have and I've just realized 3:31 that Refactoring, Style Guides, and Sass are like perfect together. 3:34 Are like they go together so perfectly. [COUGH] 3:38 So a little while back when I used to work at 3:42 Engine Yard I wrote a blog post on their 3:46 blog called front end maintainability with Sass and style guides. 3:48 And this was basically not only my first time trying a 3:51 living style guide but it's also my first time using Sass. 3:54 And I was one of those designers that was 3:57 like, I don't need Sass I write perfect CSS. 3:59 I don't need it. Until I had to use it because I worked at 4:02 Engine Yard, and then I just found myself not being able to work without it, and now 4:06 I'm you know, basically promoting it constantly, all the time. 4:12 But the big wake up call for me 4:18 was like realizing how cool living style guides were. 4:20 And this is important, not just for building, but also for refactoring. 4:24 It works just like a QA system, you can check and see how things are looking 4:28 in your style guide, and if they're perfect, 4:32 or if they're broken here, they're probably broken elsewhere. 4:34 [COUGH] And it also works as a sandbox, so 4:38 you can build new elements and new components in there. 4:42 So basically, you've already done most of the work 4:45 because you've already built it in your style guide. 4:48 And so anytime I'm, like, building a brand new 4:52 component I'll often do it inside my style guide. 4:54 So I have that job already done for me. 4:57 And so basically. 5:05 The idea's obviously, not thinking about creating 5:08 pages, but to think about creating systems. 5:10 So I'm gonna go through sort of like the way, 5:14 I like to approach refactoring and like my personal work flow. 5:16 But I do, I, I want to have the discussion and see 5:22 like what you guys do then maybe we can like, share ideas. 5:25 So, I think it's incredibly 5:29 important that refactoring and documentation is 5:31 a regular part of your process and 5:33 not something that gets stuck on the back burner at the very end. 5:34 That you just squeeze in whenever you have like 5:37 t, t, time, or you know, just free time. 5:41 I, I think it just should be part of your process. 5:44 [COUGH] There's this really great quote by Nate Fortin that 5:47 says, a fractured process makes for a fractured user experience. 5:51 And 5:56 I believe a lot in this. 5:56 I, I think anytime, like you just have like 5:57 process breakdowns, like it's gonna lead to a poor UI. 6:00 So at work I kind of have this role as, like this CSS gatekeeper. 6:05 Basically all that means is like anything that gets pushed into the repo. 6:10 If it has any CSS in it whatsoever they'll like tag 6:16 me in the pool request and then I do a review. 6:21 And, I'm not necessarily saying you should have one person doing this, 6:26 because that could lead to a bottleneck. But it is very important that you have 6:30 a team of solid, front end people that really know their CSS review everything. 6:35 Even if you think it's just a tiny like, 6:40 but, like, a small change have somebody review it. 6:43 Because they might not just be seeing like areas 6:47 in your code that could be better, but maybe. 6:50 Because you're working in a particular feature or 6:53 a particular area, there could be areas that could be refactored. 6:55 That could be brought up at that time since you're in there anyway. 6:59 The key thing I think that is really important is 7:05 that you don't try to document everything all at once. 7:07 I've actually tried to do this and I understand like. 7:11 It, it seems tedious, and it seems overwhelming, 7:14 and you're most likely probably gonna give up. 7:17 I've been there, I've totally done that before. 7:20 Don't try to do it all at once. 7:23 Just do it going forward, as you approach things. 7:25 So if you're making something new? 7:28 You want to document it at that point. 7:30 And then when you're revising something, you want to refactor it and then document. 7:32 And then like during pull requests when like those code style preferences 7:37 come up, you know, just simple things like how you indent things or 7:41 how you name things, like all those like, style preferences that are on your team. 7:45 Those should be documented so that before you do the pull request 7:51 you can actually like make sure that you're adhering to those cell preferences. 7:55 And then it's great for like later code reviews, 8:01 you have something like, to kind of look at. 8:03 If you don't know what your code style preference should be for your team a 8:06 good starting point I would recommend is this book, Scalable 8:11 and Modular Architecture for CSS or SMACSS as it's called. 8:13 It's pretty good resource for like, how to organize like, 8:19 everything from like your sales sheets down to like, your selectors. 8:22 And your properties and I would say like, I agree with like, 8:27 90% of what is in this book because it sort of matches 8:32 with what I do. 8:36 So I feel pretty confident with like saying like, this is 8:36 a really great starting point to kinda, get comfortable with that. 8:39 So, like, at Do, this isn't public yet, but I've been 8:44 working on this style guide where basically I've just been writing all 8:46 these like, style preferences and 8:49 guidelines and every time something's brought 8:50 up in a pull class I'll come here and like document it. 8:54 So that's just basically like 8:59 making that part of your work flow but you also kind 9:01 of like need to know like where you're headed with things. 9:04 So I think it's really good to document what your ideal CSS architecture is. 9:07 It doesn't necessarily mean you're gonna start 9:11 moving everything right away but at least have 9:13 like a road map or like a game plan of where you want things to be. 9:15 So at Do we have our web application that's 9:19 like in a Ruby on Rails codebase called death, 9:23 we call it Deathstar. 9:26 And we also have our marketing website when 9:28 you go to do.com and we call that Kenobi. 9:31 We, we like Star Wars. 9:34 [LAUGH] Both of these sites actually live in the 9:36 same codebase, like the same Ruby on Rails codebase. 9:39 And it's just a matter if, if you're logged in or not. 9:44 And so trying take a look at like what 9:47 these two CSS files actually had. 9:51 And because, you know, it's the same team working on 9:54 both sites, there's always gonna be like those same patterns. 9:57 You know, the same way of doing buttons or the same way of doing typography. 10:01 And so I started looking at, like, how I could, like, consolidate those things. 10:05 And because they're in the same code base, you can actually share those things. 10:10 And, you know, using, like, imports through Sass, 10:14 which is awesome. 10:17 So it's like you don't have to like, do things more than once. 10:18 So the way we've got things organized is, We 10:22 have our vendor libraries listed first which is pretty standard. 10:25 Deathstar actually uses a little bit of Bootstrap. 10:29 But Kenobi does not, and so Deathstar gets that as well. 10:33 We're really into Compass, Compass is awesome. 10:39 Just does a lot of the work for us. Really into SUSY, SUSY's awesome. 10:43 I highly recommend these two frameworks. 10:48 If you're already using Sass, just go ahead 10:51 and start using these as well, they're awesome. 10:53 So the way I like to have things organized and I'd be very interested 10:57 to see if anyone like disagrees with this or like has a better way. 11:02 I like to list all my, what I call 11:06 dependencies first. 11:08 And some people call these constants or globals 11:09 or you know, whatever you choose to call them. 11:12 Basically these are the globally used variables, mixins, and functions. 11:15 If you were to compile these nothing actually gets output yet. 11:19 They're just things that you can use. 11:23 And I like to do it that way just, I 11:26 feel like it's more organized and these, I, if you look 11:29 at like frameworks like Bootstrap and such, like they will actually put like 11:33 everything like in their variables file, 11:36 even if it's only addressing one component. 11:39 And I actually prefer to put those you 11:41 know, component specific variables in the component files and 11:44 just like at this level I'm just talking like 11:48 site global stuff, like things that are shared everywhere. 11:50 [COUGH] So like basic things like color, layout, and typography. 11:55 And then I think about the foundation. And this is just your plain, simple HTML. 11:59 Like you know, paragraphs, headings, things like that. 12:03 I highly recommend using border-box. 12:08 It's gonna make your CSS life so much easier. 12:12 It makes the box model actually behave the 12:16 way you expect it to behave, which is awesome. 12:17 And I also recommend normalize over the reset because 12:20 I think the reset you end up fighting 12:24 against it more than it actually helps you. 12:26 But normalize just does what it needs to do. 12:28 And so like the way we do our type and our 12:31 lists and our headings, it's essentially the same for both sites. 12:36 So, we can share all that, but then like [COUGH] 12:41 so, Kenobi has a different font than Death Star does. 12:45 So we can let each site have like it's own style, it's own sort 12:49 of visual design but share a lot of the same, you know, styling. 12:55 And then components are you know, you're basic 13:00 like icons buttons, toggles like, all your different UI 13:02 elements and I firmly believe like these should be 13:06 like stand alone pieces that you can drop anywhere. 13:10 And the styles shouldn't 13:13 be reliant on where they live but should just be like stand alone pieces. 13:14 And then, of course, all the states of those pieces. 13:20 so, like, hovers and, you know, clicks and all that stuff. 13:23 But then, with regions, that's where, like, 13:28 I start thinking about the location based stuff. 13:30 So, like sidebars, footers, mast heads, whatever. 13:33 I try to keep components and regions like, 13:36 very separate from each other. 13:39 They would, there might be some places where maybe something changes the 13:41 way it looks based on whether it's in a sidebar or not. 13:45 I try to avoid that as much as possible, but realistically 13:48 that's gonna happen sometimes So those would live in the regions file. 13:51 And then my layout helpers, the things like clear fixes and grid 13:57 systems and you know, no real like semantic like components or naming. 14:02 It's just like things that help you lay things out. 14:07 In terms of like place holders selectors or classes, which ones should you be use? 14:11 I, I think it's all about what the output 14:17 is, and so usually I default to placeholder selectors 14:19 cuz I like that clean output. 14:23 But occasionally that might lead to a really long selector chain 14:25 of things that might be sharing whatever it is you're extending on. 14:28 So in those cases I will make that judgement call and 14:34 decide whether it's going to be a class or placeholder selector. 14:36 And then I like my responsive styles. 14:41 And, so I've actually kind of been going back and 14:45 forth on how to do this. 14:48 And so there's been a lot of blog posts about how Sass 14:50 doesn't have the ability for you to write your CSS in one file. 14:53 Like let's say that we're talking about buttons. 14:57 You wanna write all your button styles in one file called buttons. 15:00 And then you might have responsive styles for those buttons. 15:03 And you know, like if you were to use media queries nested 15:07 to keep it all in context. 15:13 It doesn't output at the end, it just puts it right there. 15:16 And some people are okay with this. 15:21 I actually just recently found out that 15:22 there's no performance impact by doing that. 15:24 Which is why I realize I maybe shouldn't care anymore. 15:27 [LAUGH] But I used to care and it, it is an aesthetic thing too. 15:30 It's kinda nice to have all of your media 15:35 queries at the end, like it just looks nice. 15:36 So, you actually can do that with Sass. And it's super easy. 15:39 It's just with mixins. 15:43 And so you might have your banner styles, and then some 15:44 mixins at the end that target screen or mobile or whatever. 15:48 And then in your screen media query at the end, you just include those mixins. 15:53 Super easy. It's totally possible. 15:57 It's kinda, I, I, when I sorta like, played around with that. 16:00 I was just, I felt 16:03 like I was like super smart and like a genius and that's when Chris 16:04 Epstein was like you don't even have to do that, there's no performance impact. 16:07 I was like, oh, okay. 16:11 [LAUGH] >> [LAUGH] 16:12 >> Well, it looks nicer. [LAUGH] [COUGH] And Finally I, I, I'll 16:14 have styles sometimes that are purely for development purposes. 16:19 Like grids, like showing baseline grids or turning on diagnostic CSS. 16:25 Like maybe you wanna call out images that don't have alt attributes or whatever. 16:30 What I was doing initially was I was commenting it in and 16:36 commenting it back out and commenting it in and commenting it back out. 16:39 You know, cuz I didn't want that stuff to actually go into production. 16:43 And so, what I didn't know was possible but apparently it's totally 16:48 possible, is you can can actually change the extension of your Sass file, 16:52 to add ERB if you're using Ruby. And then you can put Ruby in your cell 16:55 sheet, and it'll still compile a Sass. but it will also use, you know, Ruby. 17:01 Some people think this is weird to do and, 17:08 and I was talking to Chris about this yesterday 17:10 and he thinks it's kind of weird and iffy 17:12 which, I can understand but, it can be helpful. 17:15 And so basically 17:18 what this conditional does is just says when I'm in development mode, 17:21 you know, you just import this style sheet but if, you know, you're. 17:26 >> [INAUDBLE] 17:30 >> Oh that is so much better, [LAUGH] awesome. 17:30 But like if this were to go into 17:36 production, this style sheet would not get imported. 17:37 Which is really nice so now I don't have to 17:40 sit there and comment it in and comment it out. 17:42 I'm gonna show you a couple of other 17:44 tricky, sneaky things I did with ERB Sass files that, I. 17:47 I say it's sneaky cuz I've, I mentioned it to 17:51 Chris and Nathan to see what they thought of it. 17:54 And they were both like, no, don't do that. 17:56 [LAUGH] But it works for me, so I'm going to 17:58 show you anyway, but I'll get to that in a moment. 18:01 [LAUGH] So yeah, I have now, I have my documented CSS architecture. 18:04 Basically the game plan is to put new CSS in it's place, move old CSS as you 18:12 get to it and then if you have some tech that time you can more more stuff. 18:16 But if you try to do it all at once, in one sitting 18:22 again, you're going to give up, do not try to refactor everything at once. 18:25 You're going to give up, I, I can guarantee you will, because I've 18:30 been in that road so many times and I always give up because 18:34 I, it's too overwhelming. 18:37 It's better to just do it going forward in iterations. 18:40 So you refactor when you're adding something new, like a new feature. 18:44 When you're fixing an issue, go ahead and do a refactor. 18:49 And then of course like during those code reviews 18:53 when things come up like stylistic preferences and such. 18:55 We heard a lot about UI libraries yesterday as well. 18:59 I think these are awesome. 19:03 I really love the concept of object-oriented CSS. 19:04 I used to not really care for the implementation 19:08 of object-oriented CSS, cuz I didn't like all the classes. 19:11 But with placeholder selectors, you can totally do 19:14 all of that stuff and have a cleaner output. 19:17 So any time I'm doing my UI libraries, I kind of keep this idea in mind. 19:21 I really love I never thought I would say 19:26 this, but I really love the Android style guide. 19:29 They call out everything, like every state, every like variation on things. 19:33 So, like, they have, like, the icon button and then the button that has 19:39 the icon and tag, so maybe just tags or just the icon or whatever. 19:43 Like, they show every, like, variation of things. 19:46 And this is for mobile, it's not for the web, 19:49 but it's, the concept I think is you know, applicable and 19:51 it's a really well organized style guide so definitely check it 19:56 out if you're looking for inspiration for your own style guides. 19:59 So, the things that you're going to be documenting are 20:03 obviously your content, like your lists and tables text, navigation, status, 20:05 things like little alerts and pop-ups and such. 20:11 Interactive things and all the different states of that. 20:15 And, of course your icons, and I highly recommend to just go ahead and go SVG or 20:18 use fonts cuz I recently, threw work at this 20:24 retina, Mac MacBook Pro and realized everything looked awful. 20:28 And so I tried to do this whole like undertaking of like retinizing 20:32 all the assets. 20:36 And I just realized how really annoying and painful that is, even if you're using 20:38 like a really complicated function or mixin, that 20:42 like help make that easier, it's very frustrating. 20:44 So, if you just go SVG or fonts, you're gonna have a much easier time. 20:47 [COUGH] So again showing all the associated states. 20:51 I think it's really important that you keep the 20:56 documentation current and useful cuz otherwise what's the point. 20:57 You're wasting 21:01 your time, right? 21:01 There's a lot of tools out there that have come out recently. 21:03 One of them for example is styledooco. Styledooco runs on node. 21:07 And basically will read you style sheet if you use markdown for your commenting. 21:11 It'll generate a style guide for you. 21:18 and, you know, if you're using markdown headers like h1s, 21:21 h2s, and such, like it'll show you all that and 21:24 it's pretty awesome. 21:28 I'm kind of more of a roll your own type person. 21:29 Like, I like to make my own style guides. 21:31 But if you're looking for something to help like, kinda kickstart your 21:34 styleguide this tool's very useful, and there's other stuff out there too. 21:38 [COUGH] and I think it's really important that 21:42 you get to know the tools that you're using. 21:44 I tend to use a lot of Chrome's inspector. 21:48 I used to use Firebug a lot and 21:51 now I've, I just find myself feeling more at home in Chrome inspector, 21:53 and basically what I do when I'm refactoring or like fixing a bug, is I'll 21:58 start at that element, and then like work outwards from there. 22:03 And when it comes to like searching to see like 22:09 what, what my change might affect, which is really important. 22:12 I, 22:18 I use Sublime Text but even it you're not 22:18 using Sublime text, a lot of these tools are actually 22:21 available in other text editors, like Fusing Text Mate or 22:23 whatever you're preference is, it probably has these same features. 22:27 I love using Cmd+P to like, just, if I know 22:32 the name of the file I'm looking for, I can just 22:36 type part of that filename without typing all of it, and 22:38 it just, it pulls it up, it doesn't have to search 22:41 for it, it's just up immediately, it's so fast. 22:44 And then, I'm sorry? 22:46 >> [INAUDIBLE] Oh, Cmd+T does the same thing he said. 22:48 [LAUGH] And then like let's say I'm wanting 22:54 to see if a class can be safely deleted. 22:58 I like deletions. 23:00 I will use Cmd+shift+F to see all the results of 23:02 that class and if that selector or image or whatever it 23:05 is that I'm looking for is not used anywhere else in than 23:09 the spot that I'm looking at, then it's probably safe to delete it. 23:12 And that's, like, ha-, the happy zone for me, I love red pull requests. 23:17 Pull requests should like, well I wouldn't say they should always 23:23 be red but there should be some red in your pull requests. 23:26 I love red [LAUGH]. And then of course you check your style 23:29 guide to see how those changes you just made affects the style guide. 23:34 If that thing that you just did isn't even in the style guide, add it. 23:38 This is your time to add it. 23:42 And then you do your validation and testing. 23:44 Now occasionally you do get the time to do a 23:47 larger refactor like you're not just sneaking in a refactor. 23:49 I, Again I think it's very important not to try to take everything on at once. 23:54 Focus on one area at 23:58 a time. 23:59 And so like I might do like just a, a color refactor and 23:59 I don't touch type, I don't touch spacing, I don't touch anything but color. 24:03 And if you give yourself like that barrier, it actually will help 24:09 you be more efficient and just focus on what you're trying to do. 24:14 And color maintainability is awesome with Sass. 24:18 It's great, like, I like to just generate a very simple 24:21 color palette, and then let Sass do the work of making all the variations. 24:24 And, you know, as we know, it can do so much. 24:29 The lightening, and darkening, and saturation, 24:31 greyscaling, mixing, like all that stuff. 24:34 It's just so cool. 24:37 And so I will use Sass variables to 24:38 generate a living color palette in my style guide. 24:40 And it's great cuz but, back when I was doing, you 24:44 know, style guides before they were living, like I had to like 24:47 update it every single time I changed my mind and changed the color. 24:49 So I'll also, if I find myself doing a common like, Sass function on a color. 24:55 Like, I'm always darkening it by 10% or whatever. 24:59 Then I'll go ahead and store that in a variable as well. 25:03 And I'll document it. So this is an example of the style guide. 25:06 Very basic, like, beginner style guide that I did when I was at Engine Yard. 25:10 It's actually improved quite a lot since 25:15 my roommate actually works at Engine Yard now. 25:17 And she's like totally, made this style guide even cooler. 25:20 Which is awesome. 25:23 So there's the, there's sort of debate I've seen of how like to name your colors. 25:26 And it's like do you use color names so you'll know what color it is? 25:31 Or do you use semantic names? I say use both. 25:35 And I find that just makes things so much easier. 25:39 Sometimes it is good to know what color things are. 25:42 Like if, if it's blue or green cuz who really knows all the hex values? 25:46 You're weird if you know all the hex values, you're really weird. 25:50 No one really knows all the hex values. 25:56 Maybe just the grays. 25:57 Like I know the grays, but by writing out all my color 25:58 names I now have like a, a palette that I can use. 26:02 And then in my files, I will just reference those colors. 26:06 And this is really great for like finding and replacing. 26:10 If you want to change all the blue buttons to now be red buttons. 26:13 But you don't want to change all the blues cuz 26:16 blues might be applied to certain things that aren't buttons. 26:19 By doing this approach, you can just adjust the blue buttons 26:23 and not all instances of blue to be in red or whatever. 26:27 Which is really nice. 26:30 And so, I'll, I'll keep things in context so if it's a header, A color used 26:31 for the header, it'll go at the top of my header file but then this color colors 26:37 at CSS goes like at the beginning, so like all my files can reference those colors. 26:43 And I think it's a lot cleaner, like I was taking a look at like 26:46 how Bootstrap does it and Bootstrap just puts like every single color in one file. 26:49 And I just think it's like unwieldy and like 26:55 hard to really like, parse as I'm reading it. 26:58 I prefer to just have it simple and then use the those variable elsewhere. 27:01 If you want to know what Sass 27:07 is going to do with your colors before you like, apply it 27:08 and then refresh your browser, there's this really cool tool called SassMe. 27:11 And all you do is put in your hex 27:15 value, and then there's these sliders, and the sliders 27:16 will just show you what Sass is gonna do 27:19 to that color, which is really awesome, super helpful. 27:21 And so I'll use mixins to basically store common pairings of 27:25 like, background texts backgrounds, texts, and, like, if I'm using a text 27:29 shadow color. 27:33 It's pretty typical that you're gonna be 27:35 using those like, pairings like, quite often. 27:37 So like, put those in the mixin and then you have like, 27:40 a basically a list of themes that you can apply to your site. 27:42 So, that was color. 27:46 Maybe you're going to just focus on typography. 27:47 I think it's incredibly important to just choose a base unit. 27:50 I like four cuz it goes into eight, 12, 16, et cetera. 27:53 And I'll, 27:58 you know, generate my different like font sizes based on that. 27:59 And then I like to use mixins for my various type styles, like if I'm doing 28:02 the big fancy quote style or like the spaced out like small caps style. 28:08 I'll store those and document them so that they can 28:14 be re-used and not you know, recreated over and over again. 28:17 And then I think it's also really important to show your different layouts. 28:21 Like if you have variations on one column 28:24 layouts, two column layouts and things like that. 28:26 Maybe you have, like, a top level page style and 28:29 then a category page style, detail views things like that. 28:32 So, I really love Starbucks' style guide so, Starbucks actually puts, like, little 28:37 tools in their style guide where you can see how things are working. 28:42 And so, like, you can turn on the backgrounds of your 28:46 boxes and see, like, where they actually land. 28:49 You can turn on the baseline grid. 28:52 It's just this little, like, menu in the top right. 28:53 You can turn on the column grid if you want to see that. 28:57 And if you're feeling super adventurous you can turn 29:00 on all the things and see how they're working. 29:03 And yeah, it's really fun. 29:05 It's kinda fun to play with. 29:07 And again I use SUSY so I actually don't have 29:10 to do a lot in terms of like grid systems 29:12 cuz SUSY kind of does that work for me, which is really nice. 29:14 And I highly recommend doing a responseive iframe sandbox during development. 29:19 This like saves me so much time when it comes to responsive design. 29:23 I have basically, at work I actually have, like, two monitors set up. 29:27 And one monitor will just have this page setup with all 29:33 the different iframes and on the other monitor is where I'm coding. 29:37 And using live reload and, like, a URL string that will fill in 29:41 all the iframes immediately, like, with the page you're wanting to work on. 29:44 I make my change, all the iframes just change immediately and I can very 29:50 quickly see if something I'm doing is 29:55 gonna impact smaller sizes or bigger sizes. 29:56 It's really, really cool. 29:59 One side thing I wanted to mention, notice 30:02 the little like rainbow like striped thing This thing. 30:05 A, at work we call it the pop string. 30:09 It's kinda trendy. A lot of people have that. 30:12 I just wanted to show you a really cool function that Eric Meyer helped me with. 30:15 And it's amazing. 30:20 It's awesome. 30:21 Basically, like, you store all your colors in a, a list that you want to use and 30:22 it doesn't matter how many colors you use. You can have as many as you want. 30:27 And then he wrote this awesome function that basically will generate a background 30:31 gradient and it'll divide the stripe set by however many colors you've defined. 30:36 So you can have as many as you want. 30:43 It can go in any direction you want and so you just like pop this basically 30:44 like, if you have like, a class of pop stripe or something, you just like throw 30:48 this function in a background image. Mixin, and then you have pop stripe. 30:53 So awesome! It's so cool. 30:58 So I like doing things like that 31:00 to make things like, easier, and more maintainable. 31:01 It's like, rather than like, you know, if you 31:03 were to gen, generate that manually, like there's just. 31:05 That gradient code is like this big. 31:09 [LAUGH] So you know, because I love that thing so 31:11 much, I went ahead and threw it on the Sass site 31:16 too, because I thought that would be really cool. 31:18 And oh my god, was that the new Sass website? 31:20 [LAUGH] Yeah, that was. 31:23 Unfortunately I just checked and it seems like the DNS still hasn't propagated, 31:27 so it's not up yet, but it will be at some point today. 31:31 I swear. And it'll have a public style guide. 31:34 It's gonna be awesome. [LAUGH] But, yeah, last I- I mean 31:38 some- if somebody has it up, please tell me. 31:43 Is it up yet? 31:48 Ugh, I keep refreshing it on my phone like, wh, I hate DNS sometimes. 31:50 But it, huh? 31:56 >> [INAUDIBLE] 31:57 >> It'll be up at some point today I promise you. 31:59 [LAUGH] But here's the part where I, I talk about how I get super sneaky. 32:02 With my Sass and Chris doesn't like this [LAUGH] but I 32:09 am gonna show you anyway because I think it's fun and actually 32:13 I would love if one of you have a, have a better 32:16 idea or a better way to do this because I wanna learn. 32:19 Basically, I wanted to make my style guide truly living. 32:24 Right now, the way a lot of people have to do it, like, with color palettes. 32:28 Esp, this is a perfect example, color palettes. 32:32 You add a new variable with a new color, and now you have to go to your style guide 32:34 and add that swatch to your style guide. That, to me, is not really living. 32:41 Because if another designer is working on the project, and they add a color, 32:46 they might not remember that they have to go update the style guide, too. 32:50 And that's so important I mean, is that the style guide stays updated. 32:54 So I got a little sneaky, and I actually 32:57 stored my colors in Yaml instead. 33:00 And then, because remember how I mentioned you 33:03 can use an ERB extension on a Sass file? 33:05 I basically generate my variables. 33:09 [LAUGH] But then I also use that same code to so I, I, well 33:11 I, I generate my swatches and my markup. And then whoops. 33:18 Oh, did I, yeah, so I generate the variables 33:22 for my CSS, and then on my markup, I generate the swatches. 33:26 So I only have one place that I update my colors. 33:31 Please tell me if you know a better way to 33:34 do that, but for right now, that's how I'm doing it. 33:35 [LAUGH] I think, for, for style guides, it's also important 33:38 to only show the code you want people to use. 33:42 So if your site's built on Haml for markup, it 33:44 doesn't really make sense to show like all of the markup 33:49 that you need for a module if really all you need to show is just like a little 33:52 like Haml markup. Or like you don't need to show all 33:56 the different font size of, you know like values and stuff. 34:02 If, if you generated a bunch of, of mixins. 34:08 And you'd rather people use mixins. 34:10 So there's no point in showing the variables 34:12 cuz then they might just use the variables. 34:15 You wanna show the mixins. 34:17 So just show the code that you want people to use. 34:18 And again don't try to refactor everything or document everything at once. 34:22 You're likely to give up. 34:26 Just do it in iterations. 34:27 And refactoring basically helps you create better things in my opinion. 34:30 And so my last quote and then we can talk 34:35 if we have I hope we have more time available. 34:38 Is to 34:41 be regular and orderly in your life so that 34:42 you may be violent and original in your work. 34:44 And that's by Gustave Flaubert. 34:46 I think it's so important that you spend less time like having to 34:47 maintain things and managing your code and more time, like creating cool stuff. 34:51 And this is why I think workflow is so important and so awesome. 34:56 So with that, how much time do we have left? 35:00 Do we have time to discuss? 35:02 Yeah? Cool, so I wanna 35:05 hear about your workflows and things that 35:07 you've discovered that have helped you like, 35:09 you know, work better, work faster cuz I wanna learn from you, so [LAUGH]. 35:12 Does anyone have a really cool thing 35:17 they wanna share, like that they've discovered or? 35:18 No. Yeah. 35:23 >> For the breakpoint management stuff you were talking about, 35:25 >> huh. >> The breakpoint mixin. 35:27 On team stats. Just kind of like. 35:29 When you write, when you're writing your breakpoints, you're able to say, specify 35:33 for your IE style sheets, whether that break point will be included or excluded. 35:39 And then you could, you can bundle 35:44 that all together, and make a completely separate 35:46 IE style sheet, whatever it is. 35:48 So I find that that is, is a very helpful tool to minimize that last phase. 35:49 >> [CROSSTALK] Of pain If you write, like, in 35:54 that breakpoint mixin, it'll generate it in another style sheet? 35:56 >> If you want to. Or it can. 35:59 ... 36:00 >> That's cool. >> Or it can repeat it. 36:00 And to do the LT. 36:02 You know, LTIE9 class, you can choose what class to export 36:04 it, in addition to where it appears in the media query. 36:08 Maybe at the end of your CSS file or 36:10 whatever you like. >> Awesome. 36:13 That's really cool, I didn't know it did that. 36:15 Anyone else? 36:18 And like, if you have questions, feel free to ask questions, too. 36:20 I kind of want this to be, I want 36:22 us all to like learn about workflows and stuff, so. 36:24 >> Just make sure you get the mic first. 36:27 >> Okay. 36:30 No? >> Hey, how's it going? 36:34 >> Hey. 36:37 >> So, I saw when you were going through 36:38 slides and showing how you have your page regions. 36:40 >> Mm-hm. 36:42 >> Yeah, your regions, so it's like based on like the role in the markup. 36:43 >> Yes. 36:48 >> Um,so, I do something similar in mine, 36:48 where I have like a layout, a CSS file. 36:51 And that I basically have the regions or 36:54 anything that doesn't fall within like, you know, 36:58 area rows. 37:00 But there I define like just any like widths, percentages and all that stuff. 37:01 Anything that's not like visual, it's more just like structural. 37:06 And then I have kind of have, how you have your 37:10 regions for like the banner, content info, main and what not. 37:14 >> Yeah. 37:17 >> And there I define like, colors and all the other stuff involved in that. 37:17 >> So you separate your structure from your theming basically? 37:20 >> Yeah basically, so that like regardless 37:23 of whatever is going on with the header, like 37:25 background color or like, you know, fonts and whatnot. 37:27 Regardless of that, whenever that fits into the, 37:30 the layout defines like, the size of it. 37:33 >> Mm-hm. 37:35 >> And whatnot. 37:35 And how it lays out within like, you know, floated or what not. 37:36 And them the header or what file will define like, how it looks. 37:39 But I was wondering in yours. 37:44 Where, like you had one for like, you know, the banner and main, whatnot. 37:45 Are you defining like 37:49 a layout end, like all these items of how it's supposed to look in that one file or? 37:50 >> Well so I, I do have a grid.scss 37:57 file but it's very minimal because I'm using SUSY. 38:00 >> Oh, yeah, yeah, okay. 38:03 >> And so like I'll have like my containers and stuff. 38:04 outlined. 38:07 But when it like comes to doing like floating and such. 38:08 I usually just the SUSY mixins. 38:12 >> Okay. >> But 38:15 in general my, my banner CSS file is usually 38:16 background colors and font colors and things like that. 38:21 And if it's, it's a structural thing Chances are, 38:24 like, if I've already defined like list styles and 38:28 things like that, that's probably already been declared elsewhere, 38:31 but occasionally I might put layout code in there. 38:34 >> Okay. 38:36 >> Yeah. Cool? 38:37 >> There's some discussion 38:40 about things like KSS and DSS in some other talks. 38:42 What do you use to actually generate them? 38:46 Or is it somewhat of a manual process? 38:49 >> well, I, so I've played around with KSS and style.go 38:52 and so far style.go is my favorite of the generators I've tried. 38:55 But I find that a lot of them aren't really automated. 39:00 They say they're automated but I find like with KSS I 39:04 don't really care for the I have to actually make the layout file and number 39:07 it and then in my CSS, tell it I want you to go in section 1.2.4 or whatever. 39:12 I think that's weird like having to hand 39:18 number things doesn't feel automated to me at all. 39:21 So I end up just rolling my own most of the time. 39:25 But I do want to try combining, like styledocca or something with sort 39:28 of some of the stuff I've been doing to see if I can get the best of both worlds. 39:33 Cuz it would be nice to you know have the whole 39:39 CSS just sort of documented like that would be cool but yeah. 39:42 I, I know there's one that, I forgot the name 39:47 of it but it's JavaSscript based, it's like ca ca. 39:49 >> Kalaya? >> Kalaya, thank you. 39:54 And I just couldn't get it working, 39:56 but from what I read and have heard, like it's pretty good. 39:58 >> Yeah, cuz I've used I'd to build a style guide 40:02 that I couldn't really do a lot of the generated stuff. 40:07 So I did it manually, but I think that I used grant JS and 40:10 UMM with assemble and I think something like that combined with KSS or DSS. 40:14 >> Yeah. 40:20 >> It could be [CROSSTALK] >> Yeah. 40:20 I am thinking about, 40:22 still, maybe using one of those with the, like I have, I have 40:22 been working on this Sass style guide and a lot of it is just 40:27 you know, manual like I just made it myself but I, I could see 40:30 how they could like cuz you know, help each other out in some ways. 40:33 I just don't wanna hand number my stuff, like I think that's so silly. 40:36 >> Yeah. 40:40 >> [LAUGH] 40:40 Sam Richard has on GitHub a Yeoman and Grunt 40:43 style prototypes. >> Yeah, he actually. 40:48 >> Both serve as a style guide. 40:50 I'll look for the link. And let people know. 40:52 >> Yeah, he actually said he would show it to 40:54 me today in the M conference.I'm excited to see it. 40:56 >> Yeah. I think it's worth looking at. 40:58 It's a, it does a lot of magic behind the scenes. 41:00 >> Cool. I like magic. 41:04 Magic's fun. 41:05 >> So, if you're not using anything automated, you 41:08 know, and you're writing your CS or Sass files. 41:10 Do you put comments there and also repeat 41:12 them in the documentation, so you're duplicating yourself? 41:15 >> Or do you have some way to move 41:17 the comments into the documentation or anything like that? 41:18 We'll so, typically in the past, like I 41:22 would just because I haven't been using automation, 41:26 I would just do it in a style guide, cuz I didn't wanna do it twice. 41:29 But I 41:32 realize the reason I'm considering using some sort of tool like that, is because 41:33 I really sometimes people aren't looking at 41:38 the style guides, they're looking at the code. 41:40 And particularly with like the Sass one say the I know 41:41 there are gonna be people that are gonna want to contribute. 41:44 So I realized like I didn't really document any of my 41:46 CSS book comments and I started the style guide, but I 41:49 realize I probably will need to go in and like comment 41:52 everything and like, you know, the fact that I'm using SUSY I'm 41:55 probably gonna have to explain like what the mixins are doing. 41:58 How, you know, to get two columns or three columns and such. 42:02 So I would love to be able to have that, like, just in one place. 42:06 >> Yeah. >> And have it you, know, show in both. 42:10 So. 42:14 Yeah, I mean I was, I was considering Yaml for that too. 42:15 But if, again, if you guys have any better ideas, please, like share. 42:19 Do you 42:23 know if Sam's thing does that? >> Here. 42:24 Let me show you.It's all here. 42:27 If you just go to github.com/snugug. >> [LAUGH] It's the team Sass toolkit. 42:30 >> Okay. 42:36 I'll take a look at that. Cool. 42:37 Has anyone tried it? 42:40 Well, yeah, so. 42:43 >> Are you used to maybe using this in his next workshop. 42:44 Ask 42:49 him. >> Okay. 42:49 Awesome. 42:50 >> A quick note, >> Okay. 42:53 >> what. 42:54 If there's anyone that, I haven't actually tried it at all but I just heard about it. 42:55 Source JS. 42:58 I don't know if anyone's maybe played with it and has, could share experience. 42:59 But it's recent. >> Source JS. 43:03 >> Very recent. >> Okay. 43:04 Awesome. 43:07 So, so many style guide tools now it's awesome. 43:08 I love it. [LAUGH] 43:11 Okay, no questions or anything? 43:16 [LAUGH] Maybe I can come up with some questions for you then [LAUGH]. 43:18 see. 43:25 [LAUGH] Well oh, I guess like when it 43:26 comes to like, fixing bugs and like refactoring, 43:31 I would love to hear like, you know what methods and tools that you guys use. 43:33 So, so anyone gung-ho and like refactoring and 43:39 want to tell us about your way of doing it? 43:43 >> So, I work for Meetup, and we have a super old code base. 43:49 And our legacy style sheets keep hitting the IE style sheet limit. 43:55 So, there's like a big problem we have to deal with. 44:00 So, the way we've been working with this is we sort of created a custom framework 44:03 [COUGH] and this handles 44:08 sort of like the style guide. So, sorry hold on. 44:15 [COUGH] 44:20 [BLANK_AUDIO] 44:21 >> [NOISE] Smart, I could use some water myself. 44:23 [LAUGH] 44:27 >> Yeah. >> [LAUGH] 44:28 >> This is for you. >> Oh, thank you! 44:31 >> So what we actually do is we go through and, one page at a time, we turn 44:35 everything off but the framework. And [COUGH], then we can use that to just 44:40 like kill 300k CSS page by page >> Wow [LAUGH] 44:48 >> Yeah. 44:54 >> Do you have like, is that something that you're 44:56 keeping internal or do you a like, on GitHub or? 44:58 >> It's on GitHub. 45:02 It's called Sasquatch. 45:02 >> [LAUGH] 45:04 >> I'm not quite ready to like, present it yet. 45:07 >> That's fine. 45:09 But, like, we can take, it'll be up at some point where we can like look at it? 45:10 >> Yeah, yeah. 45:13 >> Awesome. >> It's actually public. 45:13 It's, github.com/meetup/sassquatch with 45:15 >> Awesome. >> spelled like Sass. 45:20 >> Cool. 45:23 >> Yeah, I might do a conference a little later about it but 45:23 >> You should Very unprepared and very nervous about talking about it obviously. 45:29 >> No, you should definitely do it. 45:33 I would love to hear it. [SOUND] Who else has some cool 45:34 tools or techniques? [COUGH] 45:38 >> So, as of like the last 45:42 year or so, especially with building responsive websites 45:43 one of the things that I've use now 45:47 constantly is it was created by 37 Signals. 45:50 It's xip.io. And it's freaking fantastic. 45:54 You basically, you can set up your [UNKNOWN] to basically hit this xip.io 45:58 site and you can actually do local testing on 46:04 any device in, in like your local wireless network. 46:08 And it can like load your local computer's website. 46:12 So like if you're like working on a site say, like, project.dev. 46:15 You can actually, basically, you edit your [UNKNOWN], so 46:18 that, it's like, project.dev, and then the wild card character. 46:21 >> Mm hm. >> So .wildcard, .xip.io. 46:25 And then on 46:28 any device. Like, on your phone. 46:29 On, like, a PC that's sitting next to you, or whatever. 46:31 You can just enter project.dev dot the ip for your computer, your local computer 46:33 .zip.io and it loads like your local site from your computer on any device. 46:37 >> Oh cool. 46:42 >> And it's been awesome for like just making sure that the stuff 46:42 that you are working on like to actually test it on the device. 46:46 >> Yeah. >> And what not? 46:48 It's pretty cool. 46:49 >> They like it too apparently. >> Yeah, I think they like it. 46:50 [LAUGH] >> Hi. 46:51 >> I don't know if anyone else has come across this. 46:57 Is this on? 46:59 Yeah. 47:00 problem, but I work on a large site and there's a base 47:01 theme and sub themes with concurrent front end developers doing different work. 47:05 And when a single file in the base theme is 47:10 being imported by multiple themes, sometimes all the themes don't get 47:13 updated, because the developer's just doing compass 47:16 watch, and they're just watching a single file. 47:20 >> Mm-hm. 47:22 >> So we had to write a, well the only solution I 47:23 could think of was writing a script that we could just run. 47:27 As a check before we, you know, did the push. 47:33 And, it, I made it a shell script. 47:37 I'm sure there's a better way for it, 47:39 but what it does is it looks for all 47:41 the SCSS files in like, the whole theme directory 47:43 and then just regenerates everything just so that we're 47:48 100% sure that all the sub-themes are up to date. 47:50 >> Oh, cool. 47:53 >> I don't know if other people have come across 47:54 this problem, but, you know, that's how we did it. 47:55 >> Awesome. Alright, well thank you guys so much. 47:57 [NOISE] 48:02 [BLANK_AUDIO] 48:03
You need to sign up for Treehouse in order to download course files.Sign up