Prototyping for Web III: Design with HTML and CSS

1. Trailer: I'm Erika Heins. I'm a web designer, web developer. I've been working for over 10 years in the field and USA. This class is about simple web development. So really each known CSS for designers. You'll be taking the mockups for a website that you've already designed and you'll be converting them into a responsive website. I think this class can serve both beginning web designers that want to learn how to take their designs into code or maybe to have to take a step back and plan them a little bit more clearly before they jump straight into their visual process. This class is good for students starting out who want to understand responsive design and the whole planning to development process or experienced designers who want to adapt their process. Being able to make websites and maintain websites to understand how they work, how to make them more powerful or the fact that it's just one of most valuable skills. 2. RWD, CSS, and HTML Prototypes: Welcome to Simple Web Development. In this class, we'll take the mock-ups for our responsive website and turn them into real HTML and CSS. The methods we'll use are appropriate for prototyping or for starting a new website. This class optimizes the front-end development process for designers. Whether your designer learning how to code wanting visual explanations or a current hybrid one and wanting to improve your workflow or adapt it to the responsive web, this class will give you a good process and a full set of resources. Because building sites makes us better designers. As Steve Jobs said, "Design is not just what it looks like and feels like. Design is how it works." When you build stuff, you see designs in their actual medium of HTML and CSS. You reveal additional system needs, you can visualize and test interactivity, and most importantly, you can add gifs. You can consider this project a prototype or a site. The former is typically thrown away. It's just a clickable mock-up done as fast as possible to see how things look. You'd focus more on speed and presentation. A proper site has all the alt tags, fall backs, and optimization for production server. You'd focus on solid, scalable, maintainable systems. We'll be going through a process that's helpful for both. Because responsive web design has changed all of our work, we often need to make things faster and in smaller chunks. We'll talk through current philosophies in the industry and the pros and cons of different techniques. My process is to assess the situation, then organize my materials, to customize them as needed, to test everything thoroughly, and then to document as much as possible. The kit that I use for prototyping or production is Coda for writing code, Sass for CSS extension, Hammer for templates and compiling, Bourbon for mixins and grids, and SourceTree for git commits. So, go get your tool setup. Download the free trials of Coda or whatever other text editor you'd like to use. Hammer or some other Sass compiler, and SourceTree or some other GitHub client if you'd like to use one. Also, download the resources for this class. There are some source files and references. You should already have Sitemaps and mock-ups. If not, you want to take the first two classes in this series. 3. Assess the Situation: The first step is to assess the situation. The state of the field and the state of our project. We need to always be learning, this field is constantly changing. So, if you haven't done something in six months, you need to research because there's probably a better way to do it by now. This is a field for people who love to learn and who love new things. But protect your own process. Tools will come and go, so don't disrupt what's working well for you are already. New tools are disruptive. Hopefully, in a good way where you're cleaning up your process, but it could be in a bad way if it distracts you and hopes you up. So, confirm the project requirements. What's the real purpose of this site? What's its lifespan? How long do you need it to be up? Do you have any time or financial budgets you need to hit? What devices do you want it to display while on? What browsers you have to support? And what type of screens do you want to support? High definition, retina screens. Go through and ask what resources do you need. What level of polish do you need on the code. You could use a GUI-based coding app if you just want something quickly and not for real. The generated code is usually pretty verbose. If you don't need all the features of HTML and CSS just the popular ones that the app provides, it might be fun to just drag and drop elements around the page. Also if you're not planning to continue coding and you're just building or you're just making a site for the short term. Dreamweaver is the old standard, Adobe also has a newer project called Edge and there's upstarts like Web Flow and Macaw. The benefits of this nice interface, that you can quickly get basic layouts and that you can revise pages visually. But again, you're limited to the particular feature set of the app, the code generally still needs tweaks and you don't really use it in production and many of them are still buggy. So, why would we want to do straight HTML and CSS coding? Because we get access to the full capabilities of HTML, we're not limited to the features of whatever prototyping app we're choosing. We can see the actual elements, the topography and the page speed. We can determine breakpoints on real devices and all our source files are non-proprietary which means we can transfer this code to any other app we want to use. You can polish up your prototype into production which saves you time and you can build a site in a matter of hours or days if you're fast. But it is tricky to go to the keyboard as your main design tool if you're coming from a design background. So, the app you use makes a big difference. Sublime Text is really popular, it's really customizable and it has a cool navigator view on the right side for your code. I use coda which lets you have code clips that you can drag and drop into your pages. It also has called code folding and coloring and a split window preview or you can use the diet coda iPad app to live generate a preview at each time you save. You can open up a terminal window right in the same app and there's also lots of reference manuals to help you out looking things up while you code. But we're not going to code perfectly straight HTML and CSS, there are some key tools and methods to save a lot of time. Plug-ins and extensions can give us extra features that we want and need. For example, Emmnet is CSS shorthand, you can type a few characters and have them expand into full HTML or CSS. Then Sass ai a CSS processor that gives us variables, mix-ins, libraries, if then statements and all sorts of things that a smart programming language would have. I love Hammer. I find it to be the fastest way to make static sites. You need a compiler if you're going to use Sass and Hammer does that for us and it also includes the Bourbon library of mix-ins by default and best of all, lets you do include some variables that compiled a regular HTML. So, again, the benefits of hand coding things are that you can use HTML and CSS pretty much anywhere, it renders the designs and the actual medium, you get the full capabilities of the browser and it's open-source or non-proprietary. The only thing is that, yes there's a learning curve, yes you have to invest some time In coding all this stuff and you have to browser test it. So, frameworks can be a happy medium. If you're an expert developer, you might be thinking about Node.js because you're making apps but if you're if you're at that level you probably don't need this class. Framer Node.js is another one that's focused on prototyping and animation. The next level down we could say is Bootstrap. It's very popular for apps in production, it gives you all kinds of elements in interactivity. For me there were some deal breakers because it's built-in Lass and Sass. Though there is a port if you want to use Sass and there's lots of default styling, so for me it was too much stuff to overwrite. It gives you buttons, it gives you forms, it gives you default headings and textiles, so you have to go in and write all the CSS to overwrite these styles if you want your site to look unique, which takes a little time which is why you see a lot of sites using Bootstrap that all look the same. Foundation is another framework that's similar to Bootstrap. I do prefer its structure a little better. It gives you a lot of default templates. So, you wouldn't have to code these kind of layouts from scratch and so it's good but it's it is bulky, there's a lot of extra markup when you're doing these kind of column layouts and you get class names all over your markups. So, I find that you can get the same things with less work. Compass is another popular one, it's a huge library of CSS mix-ins. It's pretty big and it it can add some weight to your pages, so I lean on Bourbon which is way simpler than Compass it's the same sort of idea of a library of CSS mix-ins, so you don't have to write them and maintain them all yourself and I find it's documentation to be much easier to read. You can also use Bourbon Neat to go with Bourbon and it's a simple semantic responsive grid and we'll talk more about that later. So, all these frameworks mean that you have less derived from scratch that you get additional functionality that you might not be able to make yourself and hopefully they're well-tested. The drawbacks is that you can have a lack of control, you have to follow the standards of the frameworks you're using. There is a learning curve of learning the particular syntax and capabilities of each framework and it's specialized knowledge, it's not as applicable to other tools if you decide to switch frameworks later. So, if you're trying to keep up with stuff like these, wondering how you hear about these new tools, decide which ones are the best. News.layervault.com is pretty good and of course Twitter. I made a list of recommended people in the Design and Technology field, so you can get a lot of information from people who are really keeping up and trying to be on the top of their game about this stuff. So, decide how much you want to learn for this project. Skim some of these apps, skim the documentation, watch some tutorials and then get setup. I'll be using Hammer and Sass, Bourbon and Bourbon Neat, so I suggest those if you want to follow along, but of course if you want to learn Bootstrap or Foundation or anything else you've heard of you could set that up for your project too. 4. Save It: Our next lesson is on Version Control. This is a valuable and essential skills. So, even if you think you don't need it on this project, let's go ahead and learn a simple way to do it. If you're working in the digital world, it's super important to save your work in multiple places. Version control backs up your files, as well as all their previous versions. We're all familiar with the concept. At level one, you're just using file names, -v1, -v2, -FINAL-FINAL-FINAL. Level two, you move to a Version Control system. There are apps like LayerVault for Photoshop, and GitHub is the big one for code. My dad is a programmer and he always says that until you use a version control system, you're an amateur developer and not a professional. But still, GitHub is a little scary. So, browse the Explore tab to get a sense of all the things you could do. You can backup your files, so you always have two copies. You can easily undo tasks because it saves each minor version. You can test alternate ideas because it allows forks and branches. You can collaborate with other people on the same pages because GitHub manages the merge conflicts. You can share your work because open-source moves us all forward. You can also use a private repo if you want. So, read all the tutorials. That's always the best way to learn a new tool. But I did all of this, and I'm still confused and scared by GitHub until I found some visual tools. So, there's a GitHub for Mac, but I prefer one called SourceTree. It's also free and it has all the commands right in front of you. So, I'm just using the main ones, like commit, pull, and push. You can see there's this button. So, I don't have to remember the particular syntax. Terminal is just there's no undo, there's no color coding to show when you've typed in error. So, it always was just a little too stressful for me. But once I started using SourceTree, I was totally confident in using Git. So, how do you get started? First, you need to get her account. So, go to github.com and create an account. Then on your profile or from the homepage, you want to create a new repo. So, I'm going to call my demo. I'm going to make it public so you guys can all see it, and I'm also going to check the box that says initialize this repository with a README. So, that let's you go ahead and use the repository because it's a required thing to have a README file in there. So, you're forced to write an intro explaining to other people what this set of files is. So, now you see my repository. It's under my username. Energy7/demo is where you can find it. You can see that this README file just has the title and I haven't added any content. I'll do that at the end of the project. So, if you go to the right side of the screen, you want to copy this clone URL where it says SSH. Then you want to go into SourceTree. So, go to your Bookmarks panel. You press Apple B if you can't see it, and you click the Plus button to add a repository. You're going to clone a repository. Because you've already created it on GitHub, you don't need to recreate it, but you're just going to clone a copy to your computer. So, the source path is that you copied from GitHub, and then pick a folder. I keep all my repos in my user folder in a subfolder called Sites. I'm going to call my repo folder the same thing as it is on GitHub, which is demo, and then it will look like this. You'll see this is the SourceTree window. So, there's no files that we've added locally yet. So, everything is blank, but you can see all the buttons at the top. Then on the left, you can see we're just connected to the master branch, which is like our main repo. There's all kinds of other stuff that you can dive into if you're working in a professional environment. So now, I'm going to go to Hammer, and I provided some source files. I've provided a Hammer template for this class. So, it's called Demo Template. So, in my same repo folder, I'm going to create a demo site using this Demo Template. When I click Save, Hammer is going to compile all these files. They're all pretty much empty so far, but Hammer sits there and watches, and every time you save, it compiles again. Then if I go back to SourceTree, I see that all these files created by Hammer, that are part of the template are now in my working tree, which means like in my local hard drive. So, I'm going to drag and drop them. I'm going to select them all and drag and drop them up to the top half of the screen to stage them, which means these are the ones which I'm ready to share. Then I'm going to click the Commit button, the first button on the left, and I'm going to write a message describing what I did here. So, here, I just created the site files from my Demo Hammer Template. I'm going to check the box at the bottom, that says push the commits immediately to origin. So, committing is just like a save, but it's just locally. It's not doing anything to the repo on GitHub. So, you have to push the files if you want them to go out to GitHub. So, once I do that, now you see that I've got my demo site folder up in the public repo too. So, you've done it. You've pushed the GitHub. So, if you're ever in a job interview, and they ask you, can you use Git, you can say yes now. SourceTree is also nice because you can see in the middle of the screen, above the Pull button, there's a little badge that tells you there was a little red five. So, that tells you if somebody else is working on the project with you, they've made some changes to the repo, and you want to pull those, you want to download those changes that you're working with the most up-to-date files. So, always look for that and pull before you start working in any case. So, the basic syntax for Git is that pull is like download, that you're merging changes into your files. Commit is like save. It's like a mile marker that you can return to later. Push is like upload where you're merging your commits back into the repo. Revert is like undo, where you need to go back to a previous commit, which makes you very glad when you have lots of commits to choose from. Fork is if you find a repo that you want to use as your base, if you want to maintain a link, so if like, say, they update their header, you can merge the upstream branch and you can also use that updated header. So, it looks something like this. Here's a good illustration from Jessica Lord. There's an original project that's a giraffe, and you might fork it, and then you can change it however you want, and maybe you add a tiger head, and then you would upload it back if you have access rights up to the original repo. So, now that's part of the main repo, this tiger head giraffe. Then, somebody else can fork that new code and add some feathers, and then they can push it back to the repo and merge those changes too. So, you guys could even collaborate with each other on this project in this class. You could use the same repository and share files. So, go ahead and create your repository. Download SourceTree if you don't have it, and Hammer as well. Create a GitHub account. Create a repository and then get your repository setup in SourceTree. 5. The Bones: Now, we're ready to start building pages. Our background reading is again by A Book Apart. If you're a web designer, just go ahead and buy all their books. The best overviews of each topic, and they're short enough to read on a plane ride. So, how are we going to get from these flat mockups into code? Luckily, our nice designer has mocked up all sorts of breakpoints, so we're not making layout decisions ourselves, and we have a sitemap to show us which pages are multiples and roughly how many there are in total. So, it's now all about pattern recognition, and Hammer helps us with that. Default templates come with an includes folder. You'll see header, footer, and nav here. You use includes on any large sites, so you don't have to paste the header five times on five pages, but they require a dynamic server-side language like PHP or Ruby. Hammer compiles these includes to regular HTML, which you'll see in the Build folder. Then, the Assets folder, you'll see the CSS subfolder has a style.SCSS. This is a SaaS file, which also gets compiled to regular CSS in the Build folder. While we're here, look at the template I provided. In the CSS assets, there are several subfolders. We'll talk about those later. It's all about designing modules, not pages. Again, we wouldn't want to code a header five times for five pages, and so you want to think about call-outs and other features in the same way. So, make a list of your templates, not necessarily your pages. You can just do this in a text file, and you want to describe them at the largest breakpoint because mobile layouts are generally single column. So, if you described your mobile templates, they'd pretty much all be the same one, but think about where you have complex three column or two column layouts. Now, it's a question of semantics. Semantics just means to assign elements based on what they are, not in how they look. Is this piece of text a paragraph or a list? So, HTML is the alphabet of web design. You want to learn all these letters, so you can spell more words. You won't necessarily use all of these. But again, the more you know, the more you can, do and that's another thing I like about Coda, is that it comes with books on several languages. So, within the same app, you can just look things up. So, if I wanted to use a site tag, I can go to the book and look up the proper attributes and what it's used for. So, you can also start using shorthand to work a bit faster. Markdown, a shorthand for HTML. It helps you focus on the semantics of your content instead of the look. So, you have to say this is an H1 this is an H2, et cetera. You can write Markdown in an app like Stackedit to see the HTML preview rendered side-by-side, and then you could download HTML to have your content on all marked up and ready to paste into your templates. Emmet is another kind of shorthand for HTML and CSS. It comes as a plug-in for your code editor. You write code using the Emmet syntax, which looks like this line on the top, and then you press "Control E" to expand it, and you get the full HTML or CSS like at the bottom. Again, it's one one thing to learn, but when I'm heading into a phase where I'll be coding for several days, I go back and learn it again. It really feels like magic. The other thing that's super helpful is to do Clips. When you've coded an unordered list for the 100th time, you start to wonder is this really necessary? No, it's not. You can build your own personal library of code. Here, encoder, there's a tab on the right for all your clips. You can see my HTML5 clips, my Hammer clips, et cetera. You can make folders of clips for any framework that you use, and then you just drag and drop them into your file to reuse your code. There's a code Eclipse site which has lots of samples, both simple and complex for many systems and frameworks, and Pears. It's P-E-A-R-S. It's a site which has a lot of simple HTML and CSS patterns. Look also for the responsive patterns on Brad Frost site called This Is Responsive. He's been super generous and created tons of useful patterns like responsive navigation and images. His latest effort is called Pattern Lab, and it has the same modular approach that I've talked about. Instead of the alphabet letters, he talks about atoms. So, this might be, you have a color or a font. That's an atom of your website. You would combine those into a molecule. They might make a headline, and you would combine several molecules into an organism, which might be a header or a sidebar. Then, these organisms combine to form template, which might be your single column template, your grid template, and then you would use these templates to make individual pages like your welcome page or your profile page. So, check out that system, and you might want to explore it if you're interested in continuing on in web development, but be sure to backup your clips. The saddest thing that ever happened was, I had a computer crash, and all of my clips were lost, and it was so many years of work, all compiled, and it was not backed up anywhere, so lessons learned. So, as you're writing your HTML, you're going to start adding class names, which is where you're going to attach your CSS to. So, there are all sorts of approaches for how you name your classes, but here's my basic approach. Your container wants to have a short class, simple short container name is great. So, you can have child classes after hyphen. So, this section I've called intro, and then my subsections are intro-hero and intro-blurb, which again are semantic, and that they refer to like what it is, not how it looks. So, it's not the top row. Because in a responsive layout, that top row might move over to the left, but it's the intro row, or whatever else you want to call it. The popular methodologies, these are people who spend a lot of time trying to think about for big systems, how you need to name your classes. One was OOCSS, which is object-oriented CSS by Nicole Sullivan, and that was kind of one one the first abstract styles into modules. So, you would write a kind of seeing styles of logos that you combine on different elements by putting a whole bunch of class names in the markup, but Sass does this now. Again, it's not so nice to have all the classes in the markup. Another popular one is BEM, which is Block Element Modifier, which just means you use a.class for the main thing. Then for a child, you use two underscore, and then for a subclass, you use two hyphens. So, that's pretty recognizable when you see someone who's using BEM. Then, SMACSS is another one one I like, which stands for Scalable Modular Architecture, and that says you want to split your CSS into five basic sections. One is like your base elements. Two is all the styles that make your layout. Three is all the modules. So, call outs or reusable pieces that we've talked about. Four is the states. So, it is selected or it is an error, and five is the themes, which means if for big sites you often have a theme sections using the same code as other sections. So, we'll use a similar. I use a similar breakdown to organize my folders of partials, but I'm not strict about following Sass to the latter. Major lessons that I've learned when I was picking my class names, one, is to not use IDs because they're very specific, and they'll overwrite most other CSS. So, if you do need to tweak some existing CSS, you have to use a ton of specificity or an important statement, which is a problem. So, you want to do a class equals user profile, and not an ID equals user profile. Then also, when you're writing your markup, you want to reduce dependencies. So, that just means like you don't want a change in your CSS to break your JavaScript and vice versa. So, it's great to use class names that are assigned to each. So, for JavaScript hooks, I use IDs, or data attributes, or class names that start with.js-, and then all the other classes are just for styling. So, that way, I know that I can make as many changes to my CSS as I want, and I'm not going to break the JavaScript. So, that's kind of an advanced lesson, but I'll go ahead and tell you. Okay. So, you're going to start coding your demo pages, and it's going to be really tempting to go in and start styling them, but focus on getting all the elements into the page. So, writing your markup, figuring out how the content should be coded, and what order it should go in on the page. So, it's helpful to look at your mobile wireframes to figure out what order the HTML elements need to go in, and then we'll go into responsive styling shortly, and figure out how to get them side-by-side on the bigger layouts. So, start your HTML pages by marking up your containers which might be sections, articles, divs, or something else. You'll add your texts, your headings, your paragraphs, your lists, and you'll mark up your media. So, images, videos, audio, whatever else are in your layouts, and keep committing and pushing to Github as you go just for the practice, or if you're collaborating with other people. 6. Flexibility: My next step is to make these templates responsive, so everyone can see how the content will re-flow on different devices. To do this, we're going to need Sass so we can use the Bourbon Neat grid. Again, A Book Apart will give us a great overview. We see features like nesting; to keep your code organized, dependent classes can be stored inside their parent classes. Variables to avoid find and replace, you can write a config file for each site that acts as a theme, so you can have the unique colors and sizes for that site all in one place, and then just use that variable which begins with the dollar sign everywhere else in your page in your CSS. Also Mixins to handle complex logic, or to avoid writing long CSS fall backs like vendor prefixes. For example, we can just pass a value of 10 pixels so this one line border radius mixin, and it will generate the four lines of CSS and our final file. We don't have to write all our own mixins, we can use libraries for the common stuff, so it gets updated when the browsers do. Sass files can be split up into partials, so you don't have to scroll up and down a 3000 line CSS file looking for something. Then you compile them, Sass's CSS extension language, so we need a compiler to turn it into actual CSS. This is another win for Hammer. You can compile Sass with JavaScript on the server, but that's a little bit slower for your visitors. You can use an app called Codekit which is really great, but Hammer again helps us just use as few tools as possible it'll compile our Sass for us. So, here's an example config file that is basically, a theme for our site. That here's a sample color palette, and we can set our variables for our grid like the number of columns and all sorts of things. So, look in the sample the demo template and see how a config file looks. You want to keep your files organized. So, people do this in different ways but, my folders for prototyping are a base file, excuse me, a base folder where you'll see your normalize file and also this config file I mentioned with all your theme variables. Then I have a folder of all my mixins which are, might be the libraries, the grid and any of my custom mixins that I'm writing myself. Then I have a folder of all my partials this is by far the largest folders, and sometimes it gets split into multiple it might be your header, your footer, I also include my states here so it's broken, excuse me, it's an error, it's on it's off that kind of stuff, and then there's the plugins folder so things like fitbits or jquery plugins, that might get removed later, it's nice to have that CSS split out, so you don't again you don't have to route through the length of your CSS file for each particular styling but it's all in one place.So, then you just import all these different partials, using your style.scss so this is how one tends to look. So, first I import my base, setup so that's this normalized reset and then my config on my variables, then I import all these libraries and mixins that I'm gonna use an all my different partials. Then I'm importing my different partials, and the order in which you import them is important. So, things that you're importing later are not available to partials that are imported before. So, you want to do all your base elements like your typography needs to come first, and then you can use those typographic styles in say your buttons, or your menus which are called later. Then my last one is all these plugins again, these add-ons that might get removed later. For updates on Sass and CSS and all this stuff follow Chris Coyier CSS-Tricks is his site, and he's really cutting edge on all this stuff. Onto Responsive web design and the requirements there. Our background reading here is by Mr. Ethan Marcotte who is a great friend to follow on Twitter as well. It comes from this requirement of or this fact that we can't design for set sizes are proportions anymore. We can't design just for the Apple users anymore. When smartphones were coming out for a while we're just like oh! So, now we just need, iPhone styles and then iPad styles and then desktop and now there's all sorts of people with all sorts of tablets and smartphones, so we have to be a little bit more creative. So, one thing that helps is some people put together what's called the Goldilocks approach. Which is just the device independent way to look at Responsive web design. So, you think about small, medium and large layouts or single column, two column, multi column layouts, that's a good start. Then if you want to get more granular, think of it as content-out layout. Where, you're trying to make these breakpoints, you're trying to make these layouts based on the particulars of your contents. So, a site with a lot of text articles is really different from a site with a lot of videos, so you want to separate breakpoints, not based on iPad but based on when your video no longer has higher resolution, or whatever. So, you come up with these breakpoints by starting small. You start with your mobile layouts, your mobile code, and then you enlarge the window until you start to see it look bad, and then you add a break-point and then you repeat. So what do you mean bad? So, this article on content-out layout, that's a really good reference by the guys that made Gridset. Talks about you get these patterns like sevens where the associated caption is hanging off of the image and it is not really, looking nice next to it anymore. Drifts with the white-space things, you see that the images in the left column are making a strong vertical block but, they should actually be more associated with the content to the right of them. Then pinches where your margins or your gutters start to break down, so you see that a lot of the headlines and images it's not clear what's associated with what. So, that's where you start to say, "Oh, there needs to be a break-point" or "Oh, this layout is not really showing my content." The other thing to look at, is line length. If your text is stretching all the way across the page, 45 to 75 characters is considered optimal, 90 characters is still okay, for quick reading but, when it gets really long a break-point would improve the readability. Then also if you have a single column layout and you kept stretching this wider and wider, obviously that spaces underutilized, and you could once you have enough space, float those nav items next to each other and get more content up on the screen for the visitor. So, that's when you add breakpoints. So, you see layout something like this, with grids. You don't always have to use grids in web design but, when it comes to development and especially responsive development, they make things so much easier, by you just then make these containers and these templates responsive instead of making you know 100 different individual items on the page responsive. So, the way that you add breakpoints is through CSS media queries. They look like this, it's just usually there at the very bottom of a CSS file and, just start with @media and then you set your parameter it could be min-width or max-width, I'll talk about the difference, and then you just say when it gets to 768 and higher you know I want to change that block to be narrower. So by default, a block would be 100 percent width so then you would say at this point I want to go down to 75, at this point I want to get under 50 or, however, else you're planning your layouts. But we can also do media queries as, or breakpoints as Sass mixin. We can also do breakpoints as a Sass mixin. So that looks like this, it's a little bit overwhelming up top, but really handy when you're implementing it throughout the file. So, we set a function called breakpoint and we pass a variable called point, and then you can see later down there's another placeholder that's content. So then, throughout our CSS in our example class of intro dash hero here, we would say include this mixin of break-point and we would pass it the variable of medium, and then our content is that width equals 75. So by setting up this multi-line mixin at the beginning, we can just have very clear and simple mixins later. So, one though is that there is some discussion about, if it's okay to put media queries inside classes like this. It does make the compiled CSS a much longer but in my experience it's much easier to maintain and it's better because the responses styling doesn't get forgotten. Especially for sites with plugins, it's when you remove that plugin later a lot of times there's legacy CSS sprinkled throughout the file and if you've got it all within the same class you're sure that you're keeping things clean. So, follow Ethan Macrcotte again on Twitter, he's written about this and we'll see what the latest practices turn out to be. Okay. So, now that we've got that all set up, we can use our grid which is Bourbon Neat. On the Bourbon Neat site you can see some examples, so here's a sample layout. So, you see that our container div just needs this one line mixin of include outer-container. Then if we wanted to do two columns underneath that, we would just add this line of include span-columns and six out of 12 columns, is a 12-column grid. On each of those two classes and they would just float right next to each other, and you can put any number, so from one to 12 in there. Then you just need to put on the last on the right hand column you would want to put include omega just to clear the margin on that last div. So, that looks like this, in your CSS. Again the container has to include of outer-container and for me, I'm going to remove all the gutters in my grid so I'm going to use this include row equals table. Then my hero image on the left, I'm going to say it's going to be full width on mobile, and it's going to be full width on tablet. But once I get to like the desktop break-point which I call large, I'm going to say let's just use eight of those 12 columns let's make it two thirds the width of the page. That way, I'm going to fit my blurb on the right, so that gets the include of span-columns of four, so it's one third of the row. Then I also give the intro-blurb this include of omega so, since it's the last section in that row. So, go to the Bourbon Neat docs to see the details. Again, it's one more thing to learn but in my experience it's super, it's the simplest way to do grids, it's semantic, it keeps all of your grid classes in your CSS, instead of having them scattered throughout your markup, like some frameworks and it makes responsive easy to reflow layouts. You might have noticed earlier I did min-width instead of max-width on my media queries, and this comes from a Mobile-first approach. Luke Wroblewski has contributed so much to this idea, and it's really handy because a Mobile-first approach, creates less CSS in them because, you're using the simplest layout as your base. So, you don't need floats in a mobile layout if you're around a one layout and so you're only adding them if you need them in larger layouts, so in the end it creates less CSS. It forces optimization discussions because you're dealing with phones, and you're thinking about page load and asset sizes. You're using this approach of progressive enhancement, that we start with the simplest environment possible, and then we add stuff for more and more capable devices, versus this old school, older methodology of graceful degradation. It also acknowledges the reality that more and more people are on phones. Global users tend to beyond phones so if we keep thinking of our sites as desktop sites where we were a little bit misguided. Again, the one column layout going Mobile first forces you to resolve your information hierarchy, by laying things out in a linear order. So, with all of that, let's do our Responsive styling. So, go to your templates, make them responsive by adding these media queries. Don't worry about typography or colors yet, it's really tempting to go ahead and do the easy stuff of filling in backgrounds, and filling in fonts types, but try to do this tricky stuff so you can get your prototype re-flowing. Again I've given you an example template for Sass files, so it should go a little bit more smoothly. So, get your Responses styling set up. 7. The Guts: Okay. Now, we'll get all the pieces of content into our layouts. The tools you will need will depend greatly on your design, but I'll give an overview of the main players. The first thing is typography. You used to have to slice every fancy headline as an image, but a bunch of companies have now figured out the technical and licensing complexities of fonts on the web. So, hopefully, your mockups were designed with fonts that have web font versions available. Typekit was one of the first and best. The kit is easy to set up and it tells you how much each font will add to the file size. They give you all the sample CSS, and you can change your mind and switch fonts later if you want. Google is also super simple, and it gives you a good sense of the page weight with its little speed dial. Like Typekit, you just have one line of JavaScript that you paste into your header, and then you have the sample CSS that you use throughout your Sass or CSS files. Font Squirrel is another really useful site. You can generate all the code you need to host font files yourself, and it's good for finding or uploading and converting open-source typefaces. Icons have likewise gotten a lot easier. If you're using an icon set that you purchased or downloaded online, you would, typically, slice it up as images, or now you can make it into an icon fonts. You can change the size, color, and other CSS properties whenever you want. I've been designing with Symbolset, which has a lot of great icon families, and does this magic thing where you type the word, like love, and it turns it into the icon, a heart. This is true for both mockups and code, so it's fast and semantic. When you purchase the font, it'll come with the sample CSS that you need. An IcoMoon is really fun if you want to create your own icon font. I worked on a site called Riffle, where I made a custom font for our 20 icons. You can also find and use open-source icons there, and you can download them, and modify them, and then recreate them if you want to, again, put together your own icon font. There's also a vector format that works on the web, SVG. So, you can make vector graphics and sketcher illustrator and use them on the web. This is great for HD displays and for file size. So, just follow the tutorial and CSS tricks if you want to do that. As for videos, responsive videos are actually pretty simple. Usually, you're not hosting the video file on your own server using Vimeo or YouTube, so that you're not dealing with all the bandwidth issues, but you still need to figure out how to make it responsive. But, again, it's pretty simple because there's really just one main option. It's this awesome plugin called Fitvids. So, you just download the file, you add the JavaScript file to your assets folder, and then you call it from your HTML pages and apply it to your video mockup. Images are probably the most time-consuming part of asset exporting. Maybe the designer is providing slices or maybe the developer wants the source files to just make those decisions on their own. But, whoever's doing it, of course, you want the images to be as small as possible, while maintaining the best quality possible. So, the Save for Web palette in Photoshop is the default place to do this. You can see here the four up view, where you see the original in the top left and you can judge if you can get by with this JPEG on the bottom left, which is less than a tenth the size, or do we need the full color quality of the PNG on the top right, which is only half the size. So, you make these decisions here and you can tweak them as you want. I don't worry about retina images for prototyping, but if you're making a site for real, you'll want to look into it. You would also do that here. You would export JPEG at twice the size for the HD display, and you can get by with like 40 percent quality on that. But, again, look into it. I, typically, am doing prototypes for smaller sites and not retina-ready sites. If you're optimizing for page load, you also need to consider CSS Sprites. Here's an example from Google search results file. Every single graphic on the page is part of this one image. So, the user's browser just has to make one phone call to the server and not 30, which is a big savings in page load time. There are tools to help you create and maintain these sprites because it's kind of a pain. If you're working in Sketch, you can export the PNG's by just dragging and dropping any file, any layer into Finder, and it'll export that layer as a PNG slice. Or, you can click on the layer, and if you see in the bottom right, there was a button that says Make Exportable and then it comes up with these options that you can set particular export settings. So, Sketch is really great once you're transitioning into building the site. So, again, in Photoshop you would do Save for Web or you could also try this app called Slicy, which will auto-generate slices from all of your layers. Sketch is great because of the "drag and drop" and also the particular settings, and use and save all of these images in your assets slash images folder. If you're doing responsive images, you need to think of two parts; they're scaling the image and then they're serving it. Scaling is just setting the image width and percentages. So, that's pretty straightforward. But if you're being kind to your mobile users, who don't need that high-res hero image, you'll also serve them a smaller version of each image. It's like Fitvids in that, there's one real way to do it at this point, although the tech is changing as we speak. So, this is called Picturefill, and it's another HTML, CSS, JavaScript combo, where you just follow the instructions and paste the appropriate code into your pages. But this one will actually become part of the HTML language in the future, so you're learning in advance. Otherwise, you're just going to export your images for desktop sizes and use percentages to scale them down and make all your mobile users very sad when they get their bandwidth bills. So, go ahead and do that. Prepare your assets, select your webfont service, and add that script to the head of your page so you can start using the CSS in the next lesson. You'll do the same for any icon fonts you want to use, and then export all the rest of your images at desktop size. Use SVGs where you can and try to optimize everything else as JPEGs or PNGs if you need them. 8. The Skin: Okay, now, we're finally going to let ourselves really get into the styling of our pages. So, our background reading for this would be the CSS3 book by A Book Apart. Again, we want to think about modules and how this could apply to styling. So, we want to remember that websites are made out of systems. So you don't just have it a million different pieces of text. You have an H1, or an H2, or an H3. So, you want to code those first and then make as few variations as possible. So, not all these millions of individual styles but modular systems of styles. So, in each of your partials, so for example, your menu partial, you want to go from general to specific. So, first you do your base styles for all of that element or the default class for that element, then you do your modular styles. So, those are the reusable pieces that you'll have on different pages and templates, and then, you'll get into the page specific templates if you have something that's a custom layout. So, always be thinking about how you can make something a modular style instead of a unique style. So, Getting started. You have a website that might look something like this. It's responsive but maybe the grids aren't quite perfect yet and you don't have any of the styling setup. But the code looks better. If you have it organized, indented, you can see we've got our semantic class names on there. It's all ready to be styled. So, this part will go really fast if we set up our markup and responsiveness correctly. So, you're just going to select each one of these elements so the promo row or the promo retreat div, and then go through and apply whatever properties it needs. Just like html, it's a big vocabulary that you can build. These are all the letters you can use, and you'll just use the main ones to start, background, border, color. But there are some novel ones like flexbox that are coming that'll make your life a lot easier, so that's why it's fun to keep learning these. Again, Coda has books built in. So, if you're not sure how display block or display inline work, or display inline-block, you can just look it up right there, or of course, you should always be googling. You can use sites like can I use to know what the browser fall backs are and just how new that property is. Then you can also use various type of selectors to be more specific. So, you've probably seen a colon focus or a colon hover to indicate a link which is been selected or link which is being hovered. But there are all kinds of other pseudo-selectors where you can do nth child to grab every third item in a list, or last child if you want to hide the bottom border on something, on a list of items. So, again, keep learning these. They can make your life a lot easier. There are also some new tools to help convert your source files to code. If you're using Photoshop, there's Project Parfait, a new thing from Adobe, where you upload the PSD and it'll give you the CSS for each element. Then in Sketch, you can select any elements and copy the CSS, right click on it and you'll get a Copy CSS panel, and then that'll give you something like this. You see on the right, it's told me the font family, the font size, the color, and they did it in RGBA because it's semi-transparent, and then the line height. So, it gives you the basics and then you can build from there. One thing to know about CSS is that, there are still some discrepancies in a lot of the browsers. So typically, you would have to put different prefixes on properties like border-radius like for Mozilla, or for Opera, or for all the other major browsers. That looks something like this. For WebKit, here's the version of the animation property of the background property. So, it does seem quite tedious. So, do we really have to do all of this? Thankfully, no and that's another benefit of Bourbon. So, when you use these mixins, again, you can just use a one-line mixin and pass the variable for your border-radius and then the library will generate all the vendor prefixes into your CSS as needed, and the best part is that, when the browsers change their code or when you no longer need to do vendor prefixes, the mixin is updated, so you don't have to keep track of which vendor prefixes are still needed or not. You can rely on the library to take care of that. Again, CSS-Tricks will give you some other options. I use Bourbon. I use a library. But there are some tools like Grunt or Autoprefixer if you're building more complex apps that you can use. So yeah, keep learning CSS. There's a lot of resources online. There's all these media queries are part of these app rules, font face when you're doing web fonts, that's part of these app rules, so why not learn the rest of those, and then pseudo elements are where you can do a lot of cool things where you can actually in your CSS put content into your html. So, if you ever want to add an icon in front of a link, you can do a pseudo before element and then style it with your web font and add an icon. Again, that's CSS, it can be colored and sized, all without changing your markup. So, the Mozilla Developer Network has a great CSS reference manual, so you can check that out. After that, we can think about more effects. When you're going into animation and transitions and other sorts of effects over time, you want to remember your brand guidelines. So, if things are just appearing or sliding in, it should be consistent with the initial personality you set out for your brand and ideally, your designer would be style guiding this too. Although, it often gets forgotten. So, I use jQuery mostly. This is the most popular animation library. It's been around forever and so if there's pretty much everything I want, I can usually find in jQuery just simple fade in and out for hover layers. Sometimes some slide down or slide up. If you see a single-page site and it's doing a scroll to effect where there's a top nav and you click and it scrolls halfway down the page, that's usually done with jQuery. So, this is where you can just go and search the field here to find whichever particular effect you need. There's also, for some of the common facts, there's tutorials or libraries which have been put together. So the Parallax trend that was going around with these single-page sites, where the front layer and the back layer would scroll at different rates and create this video game effect, that's called Parallax. There's demos based on the original Nike Better World, the first site that did that. So, you can look into libraries and systems of files to help you do those sorts of things, or things like this gridded layout that's used on Pinterest and other sites. That was developed by David DeSandro. It was originally the Masonry plug-in and he's now got a couple, there's Isotope and Packery. So, you can look at those JavaScript libraries and that'll give you the ability to do complex layouts. This is one where just like Bourbon need, it makes an easy grid but with Masonry or Isotope or Packery. Packery lets you drag and drop those elements into other sections. Isotope lets you filter them so you can click and watch the grid re-flow based on your sort criteria. So, it just gives you more complex interactivity. So, that could be another whole class in itself. So, start looking into some of that if you're interested. So, from here, just go in and start styling your pages. A start with the CSS properties for your containers, and your text, and your main assets, and add some responses styling for each breakpoint as shown in your mockups. Remember to go from general to specific. So, try to make universal classes as much as you can, and then modular classes, and then last resort is individual classes. So, have fun. 9. Testing: Okay, we're in the homestretch on this and now to everyone's favorite part which is testing. It's really important to circle back on your project requirements and remember what you agreed to on what devices have to be supported, what browsers have to be supported because it's really different across platforms and across devices. Just like building, testing makes us better designers because we understand that not everyone's on an iPhone and we understand how different all the different proportions are and interfaces are and it makes us better designers. So, Jacob Nielsen talks about usability and how as you keep iterating each time you test you probably will fix something or change the interface a little bit and that's an iteration. So, as you do this you're going to find all kinds of bugs and things where people aren't seeing things or they're not working as expected or it doesn't work on that particular device and so you're going to get rid of so many interaction bugs that just exists because the websites are a complex medium and eventually you'll even reach to a place where you start reconceptualizing the interface that you realize that the user's mental model maybe is totally different and you can rebuild it in a different way and streamline things. So, it's something it'll be a continual process of building and testing and building and testing. So, if you try to test different devices, ideally you're testing on real devices but we don't all have a million phones. You might have one or two old phones or you'll be able to borrow some from friends but bigger companies will keep a whole device lab in-house. Because there are a lot of emulators but they don't render the code in the exact same way. So, if you really are doing proper coding, you'll want to have access to a device lab. So, the first thing is just you can start thinking about the different widths. So, we might stop at 320 because that's where iPhones are but some devices are even narrower, so we can look at those and here's a simple thing that Matt Kersley built about it just has them all in the same window, so you don't have to go to different devices but you can at least see some break points for your layout all side-by-side and start to make some plans there. You can also use Edge Inspect if you want to be one level more serious. This lets you set up a profile across that works across any sort of device that you link up to it. So, you can then use your debugging tools on any of those platforms and it's a little bit of setup but it's a really helpful tool if you're trying to deal with the universe of devices that are out there. Then of course browsers. Browser stack is my main tool where you can log in into a virtual machine. So, you can login to Internet Explorer, older versions and even Firefox looks different across platforms. So you really need to do a lot of testing and again this really depends on if you're prototyping and how seriously you're prototyping or if you're getting a site ready for a launch, it's very very different how much work you have to do here. So, this tool lets you actually navigate in a virtual machine which is handy if you don't have access to the actual systems. But for me the main testing that I'm doing is also with users. Again, we all have this Malkovich Bias where it's really hard, we all imagine that people use the Internet in the exact same way that we do. I talked a lot about user testing in the first class in this series. But for now we'll just say that at this point in the process usertesting.com is the most helpful tool you can send, you post a series of tasks and then you can choose from their pool of testers and you can specify age, skills, a platform they're on, it's like $40 per test, it's well worth it and then you can play back the video of the test at like 150 percent, like 1.5 speeds so that you can watch them faster it does take a while if you're doing a ton of testing usually you want to test like three, five people on each iteration but you can speed up the playback. It looks something like this you go through and in the top right of the page you see this user the first half that we've given them and we can write comments, we can time-stamp the notes on the right for us to go back as we we're reviewing the testing. So, this is absolutely an invaluable tool when you're doing when you're in the thick of development and when I worked in Agile development we would do user testing every single sprint. So, we would build something and then send a few people through it, that let us test across multiple platforms and see how it really looked and how users were really understanding things. We would do that every single sprint. So, the way that you prep user testing is with scenario. So, again I went through this in detail in the planning class in this series but you basically just identify the most important user stories like a returning user is trying to contact support and then you phrase them as scenarios for the test. So, this helps the person who's doing the test to put themselves in that mindset. So you would say, you found an error in your account and you need to contact customer service and then from there you could do particular, there's all kinds of tests about what do you see first on this page or where would you go to see how they're interpreting your layouts and your site. The last type of test to really focus on is page load. If you're into this and optimizing speed and again for prototypes it's not always a variable but for production sites it's a huge variable. So, watch Paul Irish did a great talk explaining page load and how it works and it really makes you understand how the Internet actually works. That the things affecting how fast your page load in order of importance are number one this thing called speed index which is how fast the stuff above the fold loads. You really want to optimize, you can do like crazy techniques to inline your CSS for just the stuff above the fold like really advanced techniques if you're really getting serious about that stuff. The second thing is that you want to reduce the number of total requests, like we talked about with images, each file that you're linking is like a phone call to the server. So, that's why you would do a CSS sprite because it's one phone call instead of 50. So, reducing the number of requests you're making and then it's about your image transfer size. So, of course image optimization is huge, you want to cut your jpegs, cut your photos down as much as you can while maintaining the quality and that is about total transfer size. So all the other things your JavaScript, your CSS, they add up, they're much smaller than images but they do add up and then the number of image request. So again, CSS sprites this kind of thing. So, this is again, for really if you're going pro on your site, for prototyping this just it's fun to know because it helps you understand the Internet but you might not be spending too much time on it for a quick process. So, the main tools for this are you go YSlow, is the best and it's just that you can do get like a Chrome extension or a bookmark on it and just click the button and it will analyze your site and then of course the Chrome Dev tools, dive into that and you can see timelines of when each element on the page loads and then there's also a site called web page test that'll go through and do an analysis for you. So, YSlow just looks like this and it's fun to do just because again it gives you a sense of like how the Internet works that it's giving me an error this is an analysis of twitter.com and it's saying even Twitter gets an F. Supposedly, they're not using a content delivery network or they're not using expires header. So it gives you a sense again, a vocabulary for the technical language of the Internet, which is pretty interesting. So, go through and outline your tests, go back to your project requirements and make a plan for which devices you need to test and how you're going to get a hold of those devices or virtual devices, which browsers you're going to test and again, how you're going to do that, what user tests you want to do. Is that about a certain flow that you want to do? Is it about seeing how these screens work on different platforms? Again, run some speed tests just for fun and if you're working on optimizing your site, go back and work on making your assets smaller and more concise. 10. Documentation: Okay. We're at the final step in our Web development process which is documentation, and yes for others, but definitely for yourself. This is essential. The number one thing is comments. You'll thank yourself so much when you go to edit your site a month from now and your code is well commented and it's easy to figure out what classes applied to what sections and what pages. The big test though is that can someone else read and use your code. It's very rare that a site is just worked on by one person. So, there's almost always someone coming in later. Especially if it's a client site and they need to be able to understand how the site works. Commenting your code is another thing that separates professional developers from amateurs. You don't have to worry about adding too much bulk to your files and in Sass especially, you can do the single line comments which are just lines that start with two slashes and those will get stripped out of the compiled CSS. So, when you open the Sass file, they'll be there to help you, but the CSS will not get increased in size at all. And then there's also regular ones which are between the slashes with the AsteraX and those are multi-line comments. Those will get preserved, so if you wanted to have some important thing about your sources, or about your sections, to still appear in the CSS, that's fine, but again users really too. It really doesn't add much and the file size, and you can even set out your minifier to strip out all the white space and strip out all the comments too. So, you don't have to worry about adding too many comments just write all your notes in there like crazy. Then you definitely want to go in and fill out your ReadMe file. So, you can see here I've gone back and told you what folders are in this demo, repository and in my GitHub account, there's a template, there's a default and then I'm working on that demo site. So, go back and fill that out. So, it's easy to understand again for yourself and for others, and the next level is to make a style guide. So, this will serve you well as the site grows. If you plan for this to get bigger then you might want to consider a style guide, and it's necessary because we're not designing a static element. Poster, it's like it's all locked up you send a depressant it's done, and a book you have to be a little bit more systematic, you want to make sure that the titles of each chapter are the same size and position and whatever, but size are infinitely more complex. So, we can't prescribe, we can't make specs for every single page. They change, they are responsive, they're flexible. So, a style guide is really the best way to preserve the look of your site because it makes it easy for developers and designers to continue on with the work that's already been done. Alist Apart as always has great articles on this. They just had one on creating style guides by Susan Robertson, who's a great front-end developer. She put together a whole list of examples style guides. You can see how these tend to work and how they tend to be useful for Web developers and Web designers. [inaudible] as always, is a great reference for branding and this kind of stuff and so here's an example of what a good style guide looks like for a Website. So, on the left you see all our navigation. We've addressed all our major elements. The grid, the typography, if we've got forums, navigation tables, where they've even got custom things that they call slats or Freddy's special, Freddie icons and here's an example of their feedback messages. So, as a designer if you're designing a new paid for the site and you need to pop an error message, you shouldn't be designing a brand new one. You should be using the stuff that's already there. So, when we have a style guide, I can just go browse through this, I can see how it's going to look, so I can mark it up in my design comps, and then there's even code and it's description of how to use their particular classes. All in that same page. So this is great and very helpful. Yelp has another huge one where they've spent some time showing you all the headers, the main typography, all the different buttons and the classes you would use to generate that button. So again, somebody's not going to code another small orange button from scratch, but they know that there's already one existing. Here's one I made for riffle where it was just about, here's our main color variables that we're using and then I went through all the, even the JavaScript patterns and some of the QA patterns that we were using, was really helpful to have that all codified. They get pretty huge as you can see on the left, this is how long that style guide ended up. If you're just doing a small prototype, you don't need to do this, but if you're doing any sort of site, if your site is going to have some longevity then going ahead and doing this will make your life easier in the long run. The basic gist is that you're covering all the base elements of HTML and then any special call-outs and any special modules that are replicable for future layouts and for your brands, online personality. Again, Brad Frosts' pattern lab, site is a cool example. A cool resource that you could use as an example for this to create your own style guide. So, go through and clean up, comment your code, and then you can download. I've included a style me page from Simon Cox's pin hammered template, that's really handy, has all these HTML elements. So, you could just go through and make sure that looks as you expect it too and make sure all those base elements are styled and then add any further elements and create further style guides if you wish and then make sure you fill out the ReadMe.markdown for your repo and you can edit markdown in stack edit or files like iA Writer on your desktop and then just reupload it using source tree. So, that's it. We've done it. You've built a whole Website, you know a good process and hopefully, you'll continue to make it your own and find the pieces that work the best for you and always keep learning. So, if you have anything else you'd like to learn or any questions about all this, it's a lot of stuff. Feel free to tweet at me and let me know what you think or what you'd like to know more about. Yeah loved it, love to talk further. Thanks so much. 11. What's Next?: way.