Notes from my “Web Designer’s Workflow” Workshop at Interlink 2012

Avatar of Chris Coyier
Chris Coyier on (Updated on )

I was just at the Interlink conference in Vancouver, Canada. I did my first ever workshop: a 3 1/2 hour romp I called “A Web Designer’s Workflow”. We literally went from nothing (creating a folder on the desktop) to a totally deployed website. We covered a lot of ground so I thought I’d write up some notes. And hey, why not blog it eh?

  • We started with absolutely nothing. Just made a folder on the desktop called “Interlink Workshop”.
  • We opened up the folder in Sublime Text 2 and made an index.html file.
  • We looked at a couple of websites we were going to base ours off: UXMad and BarCamp Tour. They both have a gridular, modular kind of structure.
  • We hand-wrote the HTML structure. Basically a doctype, basic <head>, and some divs for columns. We didn’t use any HTML5 (other than the doctype) just because there wasn’t anything that warranted it yet.
  • We set up a very simple three-column grid using percentages for widths and gutters. We discussed using a last class to deal with the right-most column where we wanted to remove the margin, but ended up using :nth-child instead since last has no semantic value in a responsive enviornment where that column man not always be “last.”
  • In case we needed to use padding within those columns, we used universal box-sizing border-box to make sure the padding wouldn’t expand the columns and destroy our grid. We also covered why it’s pretty much awesome all the time and we’d marry it if we could.
  • We needed some content inside some modules so we used HTML-Ipsum to copy/paste some stuff in there.
  • We started to write a bit more complicated CSS, so we decided to start using Sass. We made a “scss” folder in our project and made a global.scss file.
  • To make Sass trivially easy to start using, we used CodeKit. We simply drug the folder into the CodeKit window then told CodeKit to process our global.scss file into a global.css in a “css” folder. That CSS file is what we linked to from our index.html file.
  • We made sure CodeKit processed the scss into “compressed” format which is the most efficient way to serve CSS and also as a reminder to anyone accidentally opening the file that they shouldn’t be editing it.
  • Windows users that can’t use CodeKit, check out the Beta LiveReload. Linux users, you’re so fancy you don’t need any help here.
  • We watched as CodeKit injected new CSS styles into the page without reloading, which is wicked sweet for stated applications.
  • We set up some typographic styles for our modules. Part of the fun was making the module header bars, which we used negative margins to pull back out from the padding in the modules.
  • For fonts, we showed how quick and easy it is to use Typekit to use lovely custom fonts. To make it easier to download and use at home, the final version is using Google Fonts.
  • We made sure to watch which font weights we were using. We picked as few as possible to accomodate our needs, keeping things fast, as the file size of font files can add up quick. We specifically declared font-weight to exactly what we have available to avoid gross faux styles.
  • We used a little bit of CSS3. At first, we wrote our own mixins.scss file but then decided doing that would be problematic long term and we switched our project over to use Compass instead, which was very easy in CodeKit.
  • We made a special file for variables we could then use in our CSS. We set up some colors and a special number value, $globalPadding, which we used all over the place to keeping spacing nice and consistent.
  • We needed a sexy subtle background, so we went and got one.
  • We had to fart around in the Finder a bunch, as you do, so using the split screen feature of TotalFinder was nice.
  • We thought we had a good start and was about time we got started with some version control. Because we are good-looking, we went with Git.
  • We were thinking about GitHub, but GitHub doesn’t help with deployment, so we made a git repo on Beanstalk instead.
  • Beanstalk is nicely integrated with the Mac app Tower, which we used to work with Git locally.
  • We looked at GoDaddy, where I bought the domain from. All we had to do there was get through the 56 up-selling dialog boxes and buy the domain for 12 bucks or whatever. Then we set the nameservers to point at Media Temple, where I have some hosting we could use.
  • I logged into Plesk, the server management software that comes installed on Media Temple (dv)’s and created the domain there, so we get an FTP username and password to log in to.
  • We could have used software like Coda 2 to log into our server and deploy our files. But then we decided that an FTP workflow is too dangerous. #FTPBOOFOREVER.
  • Instead, we set up deployment with Beanstalk so that every time we committed to that git repo, it moves the files over to our server for us. Doing this means we’re in a great place for working with a team, rolling back changes, and all the other awesome stuff that version control affords us. Here’s a screencast on that.
  • We started putting some images into modules. We found some neat ones searching Creative Commons licenced stuff on Flickr. One image was too big and broke out of its module. We dealt with it by applying some simple fluid images techniques. We didn’t get too fancy, but we got the images resizing and maintaining aspect ratio. We could have gotten fanicer.
  • We dropped a video into a module as well. We tried to use the same fluid technique as images, but unfortunately it didn’t work so well.
  • To solve that, we loaded up jQuery on the site (copied the script from ScriptSrc), loaded up the FitVids.js plugin, and called it.
  • We explored some of the JavaScript features of CodeKit. It can check our JavaScript with JS Hint, which will find errors. We also figured out that we can drag-and-drop scripts in the UI of CodeKit which will allow us to combine (append or prepend) scripts, minify them, and create a new script for us to use. This allows for a nice JavaScript workflow similar to what were were able to do with CSS preprocessing.
  • With another image, we played around making it responsive by setting it as a background image in CSS and using fancy CSS3 background sizing.
  • To round out the whole responsive aspect ratio thing, we played around with padded boxes, which we learned was the same concept that FitVids.js uses.
  • We got into the idea of using icons to enhance the design by adding them into header bars. We looked at Pictos Server and saw how easy it was to create custom hosted icon sets. We talked about how in production it’s probably best to self host. We also looked at IcoMoon, an awesome icon set and even awesomer app for creating your own icons fonts with any base icon font set. The final version of the site uses this.
  • There was a question about forms, so we looked at how Wufoo can help with that. Even if you don’t need all of Wufoo’s features, you can design a form in Wufoo and download the HTML/CSS/JS for free. The structure of Wufoo forms is fantastic for environments that need to be highly adaptable, for instance, being able to change around label placement or deal with right-to-left languages.
  • Every once in a while we needed to Google stuff, and we looked at how adding ” mdn” to the end of searches often gets you to the Mozilla Developer Network which is some of the best documentation out there for front end stuff. Heck you could always search on CSS-Tricks too =).
  • We looked at the HTML5 Boilerplate. We didn’t start our project with it, but we looked at the index file line by line and copied stuff over from it that we forgot to add ourselves.
  • We looked at Normalize.css and discussed how it does both more and less than CSS resets and how the workflow for it is much nicer (i.e. download, don’t remove anything but change or add stuff, @import into global).
  • We made a logo for the website. The new HF&J font Idlewild just came out so we got that and used it in the logo.
  • The logo used a bunch of fun colors that were inspired from a sweater I saw on my walk over to the venue. Remember inspiration comes from anywhere.
  • We worked for a while just opening our index.html file in a browser at a file:// URL, but then after a while that became problematic so we set up a proper domain in MAMP so we could work on a local server at a “real” domain.
  • MAMP gave us the ability to use PHP, so we switched the index.html file to index.php so we could use server-side comments which are cleaner than HTML comments. We also used server side comments to give us a blank module template we could copy and paste, without worrying about cluttering/bloating the HTML.
  • We touched on how using PHP includes on simple sites can allow us to work in smaller chunks of HTML just like we’ve been doing in CSS and JS.
  • We organized a table-like structure for a time table by using an unordered list with strong tags inside. The strong tags were set to inline-block and right-aligned.
  • We touched on the idea of Opt-in Typography, that is, using a class on a parent element to identify when we want to apply typographic styles that don’t take effect otherwise.
  • Eventually we published the thing. I also chucked it on GitHub if you wanna snag the files from there for any reason.

Annnnnd that’s all I can remember. YEAH. That’s a lot of stuff. I probably should have trimmed it down a bit and focused more on the content (both on the fake site and of the workshop itself). But hey it was my first ever and i had absolutely no idea what I was doing (sorry about that).