Things I Learned Doing Responsive Web Design
It looks like the web is being born again, again.
Here are some things I’ve noticed about the web:
- Designers have realized the need to design for mobile devices and tablets, and they’ve come up with responsive design rather than doing special mobile versions.
- CSS3 and HTML5 are gaining support, and they make possible some things that were difficult or practically impossible before.
- There’s an explosion of technologies: LESS, Sass, Compass, and Bootstrap for CSS; CoffeeScript for JavaScript; app frameworks such as Backbone.js and Ember.js; server-side technologies such as Node.js, Sinatra, and nginx; and interesting new databases such LevelDB and CouchDB. And more — plenty more.
- Web fonts are finally practical: see TypeKit, Emigre Web Fonts, and Google Web Fonts.
- Flash is finally losing ground, and developers are replacing it with standards-based technology.
- There’s a renewed interest in design of all kinds — very much including web design. See Dribbble and Ui Parade. Native mobile app design ideas are coming to web design, and designers are experimenting.
- Deploying applications is cheaper than ever, thanks to virtualization and to Amazon Web Services, Heroku, Azure, Engine Yard, and others.
- Collaboration has gotten easier due to Git and Mercurial — and perhaps even more due to GitHub and Bitbucket.
- While the giant companies are busy rediscovering the America OnLine model of walled gardens, while Congress is debating the Stop Online Piracy Act, developers are remembering the web as the open garden of free speech. And they don’t want to lose it.
I haven’t done serious web work — HTML web work, that is — since I last worked on Manila 10 years ago.
I’ve done some small things — the system that generates this blog, for instance — but I haven’t had the chance to use almost any of the newer web technology. I’ve never written a Rails app, used JQuery, or deployed to a virtual server.
So when I had the chance to re-do the websites for our company and main product, I was excited — because it meant I could try some of the new technologies and learn some things.
The plan: re-do four sites
I wanted to re-do SepiaLabs.com and Glassboard.com — their home pages and blogs. That’s two sites, but in practice it was four sites.
I did them in this order:
I had two main goals:
- Make them look at least credible.
- Make them work on tablets and mobile devices.
I don’t claim these as exemplars of design, and there are bugs and nits to fix — there’s plenty of room for improvement. Tons of room.
I’ll talk about #2 — responsive web design — and what I learned.
Breakpoints
Responsive design works because of the combination of CSS layout and CSS media-queries. You can change the layout for different sizes.
When I first started, I created two breakpoints (where the layout changes): one for iPad-sized screens and one for phone-sized screens. It seemed logical.
Later on I figured out a better way: create breakpoints when the layout breaks.
I just shrank the width of my browser window until the design broke in some way, then I dealt with it, either by changing things or by creating a breakpoint and changing the layout at that point.
This made more sense because I was working with the design rather than thinking about specific devices.
Layout
It was kind of like working with toothpaste.
When the layout broke and I created a breakpoint, I worked from the top down to fix the layout. The more narrow the screen, the more the layout became vertical, and the more often I relied on centering to make things work. I also hid things (via display: none) that were nice at bigger sizes but that weren’t needed at smaller sizes.
That’s not the most sophisticated approach, but, given the time constraints and my goals, it worked.
Why not design for mobile first?
As I was finishing the sites I read some advice on the web: design for mobile first, then build up to the desktop size.
I like this advice because it forces you to think about what’s utterly necessary from the start, and it makes sure the mobile size is not an afterthought or something done in a hurry when the project is due.
That’s not what I did, but I think I’ll try it next time (whenever that may be).
CSS Transforms
Sometimes I needed to move something from where it would naturally be to somewhere nearby. Sometimes the traditional way of doing it would make for bad code: divs-within-divs-within-divs, or worse.
One way to move something a little bit is to use translate, translateX, or translateY. Simple.
I kind of think of this as a bit of a cheat — certainly something to be used sparingly. But it worked.
Tools
I started by doing CSS by hand, just me and a text editor. I got about halfway through before I switched to Sass and Compass.
Sass is wonderful. (I’m sure I’d like LESS no less.) Just having variables alone would be enough for me to love Sass, but it has a bunch more (functions!) besides.
The way it works is that you launch a command-line script that watches for changes in your .scss file (the file that you edit). When it changes, it compiles a .css file. It happened so quickly that I never noticed the compile time.
JavaScript
Though the sites have some JavaScript, none of it is used to make the sites work at different screen sizes. I didn’t think it would be necessary, and it turned out I was right. (Using JavaScript for this would make the sites harder to maintain, I reasoned.)
Testing
Testing on my desktop was easy: I used Safari, Chrome, and Firefox. I also then uploaded the sites to a staging server and tested with IE 9 on Vista and Chromium on Ubuntu (via VMWare) and tested with an iPad and an iPhone. Other folks in the company tested with other browsers and with Android devices.
But testing was absolutely necessary. Though adoption of CSS3 has progressed, this is not quite standards-based Eden.
Version control
I created a local Mercurial repository whenever I started a project. I have not yet taken this all the way. I should have a repository that other folks at the company can access, and I should have a deploy script for staging and live servers.
This is made somewhat complicated by the blogs: they’re WordPress blogs, and I don’t know if changing a theme is scriptable. (Maybe it is. I haven’t looked yet.)
What have I not learned?
I’ve dipped my toes in: I’m a novice. At this point in learning new technology I try to get a rough idea of the size and shape of everything I haven’t learned yet. I also assume that I’ll look back to now and smack my forehead.
But there’s an important thing I did learn: I learned that this work is fun.
I was reminded of how the Cocoa world felt in 2002 — those days felt like early days again. There was so much excitement for what we could make and what would come next.
And now it feels like that for the web. Again.