Building off of my Re-introduction post I wanted to share some of the things that I learned as I built the new, responsive edition of dmolsen.com. I figure that my experience with doing this might provide some insight to other folks looking to integrate new techniques and technology into their own projects. The source for the site is on GitHub. All projects start with requirements...
Dropping WordPress & Going Static with Octopress
I've been toying with the idea of dropping WordPress for a while. While it was easy to get up and running it never seemed like it was a good fit for me. It has to be updated constantly, the post editor is a serious pain in the ass, and it sucks down RAM. Between not really getting enough traffic to justify my RAM-driven hosting costs and the fact that the post creation process was more of a hinderance than a help I decided to make a big change with this redesign. Out went WordPress and in came old-school static HTML.
One big plus of using a CMS like WordPress though is having the ability to use templates. To make sure I still had this feature I looked for a good static site generator. It would give me the flat files I wanted but, hopefully, make it easier to maintain my site. I finally settled on Octopress.
To be clear, Octopress definitely has its own drawbacks. Upgrading Ruby on my Mac was a serious headache and I'm not a big fan of Liquid-based templates. That said, I feel like I'm back in control of every aspect of my site. I was able to quickly stub out my own templates and design. I can now write my posts in Markdown, a format I love, and I can write whenever I have the desire too because the files are all local to my computer.
The 50K Performance Budget
The second major decision was setting my performance budget for the basic template for the site. Both Tim Kadlec (@timkadlec) and Clearleft (@clearleft) have written on this topic recently. See Setting a Performance Budget and Responsive Design on a Budget respectively. This is a technique that our team had used for our 2011 responsive holiday card website (sadly, it's is no longer online). The budget for that had been 100K. For this site I wanted it to be 50K. A very aggressive goal but, hey, why not?
If you don't count web fonts the basic template easily fits within my 50K budget. My CSS, JavaScript, images, and mark-up only add up to 39K. Cut out Google Analytics and Gaug.es and the page weight drops to 23K. Unfortunately, I'm a sucker for web fonts. Because of my lack of design skills as well as the large blocks of text that naturally make up a blog I knew type was going to have to be an important visual component of my site.
I ended up using two fonts, Roboto and Roboto Condensed, that total 69K. Combining that number with the other assets the total weight for the basic template for my site ends up being around 109K.
Did I blow my budget by including the fonts? Sure. But performance optimization is, like many things, a compromise. The type face makes a huge difference, I think. The 50K goal was completely arbitrary and aggressive but having a tight ceiling made me think more critically about design and feature choices. In the future my performance budgets will also include things like total number of requests and a max time-to-document-ready threshold.
Sass is Snazzy
Sass, a CSS pre-processer, has blown up in our office. Between being baked into our new CMS, a Build Responsively workshop, and the introduction of CodeKit it seems like everyone here is using it. I hadn't had the opportunity to use it but, since it is included as part of Octopress, I figured I'd give it a whirl. I love it. Here is how it helped me:
- Being able to have a large number of SCSS files organized by which region of the page the styles affected that get merged into one file in production made the whole process of remembering where styles were and tweaking them that much faster and easier.
- Variables meant that I could tweak a breakpoint and be assured every element affected by the change would be updated.
- Nesting reduced what I had to type and, again, helped me organize my styles better.
- I only used one mixin in my project but I can see how, for example if you needed to create cross-platform gradients, it could make your life a whole lot easier.
My site is simple and I barely scratched the surface of what Sass can do. And, to be clear, you don't have to use Octopress to take advantage of Sass.
SVG: A Different Kind of Logo
One of the challenges that I set for myself when I started redesigning this site was to try to create a logo that required only CSS. Unfortunately, using CSS to clip text to a circle isn't very well-supported across browsers. Once I had settled on the clipped look, though, I really wanted it so I looked at another solution, SVG. Within two hours I went from basically not knowing anything about SVG to the hot logo that you see today. It's really just a simple text file with a linked web font.
While straightforward to build I don't think I've made the best use of SVG. The web font works on most SVG-supporting browsers but fails, for example, on the default browser on Android 4.2. This results in a shortened logo. Also, by linking to a web font I took what is a nicely performant 0.7K text file and essentially turned it into an 18K text file-web font combo. An image would be way better in this case. That said, I think SVG offers promise as a format. Being high-DPI and responsive-layout friendly are definite plusses. By the way, take a look at the source for the header and you can see how I provide a fallback for browsers that don't support SVG at all.
If you're interested in learning more about SVG and how you might be able to take advantage of it check out David Bushell's (@dbushell) two SVG articles, A Primer to Front-end SVG Hacking and Resolution Independence with SVG.
Other Interesting Bits
This post is getting quite long! Some other things that I found useful/interesting as I put together the new version of my site:
- HTML5: Rather than use a JavaScript solution for backwards compatibility you might notice that I actually use
<divs>nested within the HTML5 elements. All of my styles hook into these elements. It's not the most semantic solution but relying on JavaScript seemed odd to me. - nth-child(): This pseudo-selector melted my brain for a little bit (for the son of a math teacher I really suck at math) but once I got a handle on it was incredible useful. The navigation at small viewports is completely driven by
nth-child(). Chris Coyier (@chriscoyier) has a great write-up about it on CSS Tricks. - :before & :after combined with 'content': I had no idea the CSS property
contenteven existed. Again, Chris Coyier with a good overview. The bars in the nav and pips for lists use it. Blockquote also usescontentbut it uses theopen-quotevalue. Note, if you use theopen-quotevalue make sureblockquote:afteris set tocontent: no-close-quoteso that other<blockquote>s get the appropriate type of opening quote. - HTML5 Canvas: One requirement that I gave myself was that the image on the right must randomly change when the site is being viewed in larger viewports. What better way to achieve this than
canvas? After some false starts I ended up usingtoDataURL()andbackground-image([the JavaScript](https://github.com/dmolsen/dmolsen.com/blob/master/source/includes/js/canvascircles.html)). If you look at the source for this page you'll see a lot of random gibberish in the#canvas-containerdiv. That's that image. - @-ms-viewport: Last but not least is the use of the @-ms-viewport rule for Windows RT. Tim Kadlec recently did a good write-up about issues with IE10 on Windows RT, IE10 Snap Mode and Responsive Design. I found it really useful for getting IE10 to properly register the viewport on device rotation.
Wrapping It Up
This article is primarily about the requirements that I set up for myself as I developed the new version of this site as well as some of the technical features I implemented. What's missing is anything that is really about responsive design. Their is now a follow-up post, Media Query-less Design, Content-based Breakpoints & Tweakpoints.