Takeaways from Breaking Development 2012

Breaking Development 2012 logo

I went to the Breaking Development 2012 conference in Orlando last week. There were a lot of great topics about the evolving mobile landscape, responsive web design, and content delivery. This is my (longer than expected) overview of my takeaways from the conference. Brad Frost has some great notes on the individual sessions, which I’ve linked to at the bottom.

Content Is King

It’s all about content. To be successful, you have to deliver good, valuable content. A slick website is great, and a slick app is great, but don’t lose sight of their purpose. They are simply interfaces to your content. “Build an app” is not a business strategy, as this alone means nothing.

Once you realize that it’s about the content and not the interface, then you start to see content as a device-agnostic commodity, which is very much aligned with the current evolution of the web. Read on…

The Device Landscape Is Changing

Mobile web usage is expected to exceed desktop web usage within 2 years. Many people use their mobile devices as their primary access to the web. 28% of mobile web users never or rarely use desktops to access the web. The perception that mobile users only want a limited, scaled-down experience is simply not true. For example, eBay sells 2,500 cars per week via mobile devices. We can no longer segment mobile users off into a second-class category.

It’s Not Just Mobile

So, yes, we need to cater to mobile devices. A lot of companies already know this. But to be future-proof, you have to think even further. Remember when browser sniffing was commonplace on the web? This tactic was sustainable when we only had 2 major browsers to worry about. But with 5 major browsers today, this is just not practical.

History is repeating itself with devices. We used to be content with just desktop and smartphone support. But recent years have seen a surge in tablet usage. And now there are web-enabled TVs on the market. Cars and gym equipment are web-enabled. The list is growing.

So what can we do to prepare for this “impending zombie apocalypse” of devices? To me, this is better asked as 2 questions: How do we get our content to all these devices? And how do we keep up with creating interfaces for all these devices?

Create Once, Publish Everywhere

How do we get our content to all these devices? In a word (or 3), APIs. Put your content into a single source, then use APIs to share to all your applications. Furthermore, opening your API to the public could yield unexpected bonuses. NRP adopted a “create once, publish everywhere” philosophy when creating their public APIs and saw an 80% increase in pageviews as a direct result.

Of course, there’s more to it than just “make an API”. Your content needs to be well-suited for it. This means having clean, well-structured data that is platform-agnostic and completely disjointed from your presentation layer. It must be truly portable.

Responsive Web Design

How do we keep up with creating interfaces for all these devices? There is no absolute answer to this question, but there is a really popular one: responsive web design. A single well-crafted responsive site can serve any device, on any platform, with any sized screen, as long as a decent browser is installed. All with a single code base, without having to learn platform-specific programming languages.

Responsive web design is not the undisputed solution to every problem ever, but it does show a lot of promise as a cost effective and highly sustainable option.

Session Notes

As promised, here are Brad Frost‘s notes by session:

There are 2 more sessions that didn’t have notes, but the slides are posted online:

Making Coder’s Block Responsive

Coder’s Block v4 was my first full responsive web design project. The concept and basic mechanics of making a site responsive are simple enough, though a lot of my expectations and assumptions changed during the project. Responsive web design is definitely an art, and I have certainly not mastered it in one try. That said, I wanted to write about my experience and what I learned from it.

I’ve mentioned responsive web design before (here and here). I won’t rehash an introduction, but if you’re new to the subject, then I highly recommend the obligatory article over at A List Apart.

For visual context, here’s a single page from Coder’s Block v4 as viewed in mobile-sized, tablet-sized, and desktop-sized windows:

Coder's Block v4 responsive mobile screenshot
Coder's Block v4 responsive tablet screenshot
Coder's Block v4 responsive desktop screenshot

Notice how all three show the same content, but with differing layouts that are appropriate for the space available? Hooray for responsive web design! Alright, moving on…

Mobile-First or Desktop-First?

Responsive web design depends on CSS media queries to dynamically apply styles as the viewport changes. For example, as in the screenshots above, your page might be a single column layout in a smaller viewport (mobile), but become a 3 column layout in a larger viewport (desktop).

There are two ways to approach this: mobile-first and desktop-first. With mobile-first, you start with your mobile layout and then add styles to it when the viewport gets bigger and needs to be filled out more. This is done using min-width in your media queries to specify the pixel-width “breakpoints” that trigger the additional styles.

Here’s an example that makes header text bigger once the viewport is at least 640px wide:

Desktop-first is just the opposite and uses max-width to specify breakpoints as the viewport shrinks and the layout needs to be reduced.

I started with desktop-first because I already had a desktop layout in mind. Some would say this is wrong, that mobile-first is better because it forces you to distill the layout and focus on what’s important in it. I don’t necessarily disagree. I did end up switching to mobile-first, but for a different reason: the CSS. Conceptually, adding CSS to increase a layout made more sense to me than adding CSS to reduce a layout.

No Universal Breakpoints

I originally decided on three nice, round, mathematically significant widths to serve as my breakpoints: 320px, 640px, 960px. I then tried to force all responsive style changes into only those three breakpoints. That simply didn’t work. What I learned is that the breakpoints you choose depend very much on your particular layout. Don’t be afraid to use whatever numbers you need.

The Full Spectrum

Another fallacy is to fixate on pleasing very specific viewport sizes. This is very much against the spirit of responsive web design. Your site should look good on the full spectrum of pixel widths, not just the ones that line up with popular Apple products. Furthermore, you may find a stray scrollbar throwing off your carefully chosen breakpoint, but if you have the full spectrum covered, your site will still look good despite that unexpected -20px.

Prepare for Math

I used a percentage-based 12 column grid layout, as many people would recommend. The 960 grid system didn’t quite have the column to gutter ratio I wanted (I wanted bigger gutters) so I crafted my own numbers. On top of that, I also had some places with nested columns, which meant accounting for multiplicative percentage width divs. All of this to say… There was an unbelievable amount of math involved. Here’s a screenshot of the Excel spreadsheet I created to get all the numbers right:

grid formulas

I don’t feel like reliving all that math here, so I won’t go into detail. But maybe one day I’ll share the spreadsheet (and its formulas) that I came up with, as I found it incredibly helpful.

Not Everything Scales

Going into this, I had the impression that pixel measurements were absolutely forbidden. Every width had to be a percentage so it could scale with the viewport. Well, I ultimately decided that this wasn’t the best advice. Things like mini-icons, single pixel borders, and some spots of padding looked best at fixed values, regardless of the viewport size. It’s all about good judgement.

It’s Fun!

When all the pieces fall into place, and your sites renders beautifully on any device, you feel like a wizard. Making a layout responsive is definitely harder. It feels like you’re playing with multi-dimensional CSS. But the payoff is very nice indeed.

Coder’s Block v4

I am happy to announce that Coder’s Block v4 is finally live. Coded in .NET 4.0 MVC 3. It took me a ridiculous amount of time (4 months!) to make. I guess that’s what happens when you have a personal project with no deadline and an endless stream of tangents to go off on.

CBv4 is going to be a big source of blog fodder for the coming weeks. I learned a lot of new tricks and built a couple nifty things that I really want to share. But for now, I’ll just give some highlights.

Responsive Web Design

The entire site was built using mobile-first responsive web design. This means that every page is naturally mobile friendly. When more screen space is available, the pages will automatically adjust their layouts for a better viewing experience. Go ahead, open any of the pages in a desktop browser and then resize the window to be bigger or smaller. You’ll see what I’m talking about.

SuperFeed

One of my earliest ideas for CBv4 was to pull my activity from various sites around the net and show them in a single combined “super feed”. I built my own custom solution to do exactly that. It runs as a continuous server-side process, grabbing feeds and mixing them together. This is something I plan to release as open-source very soon.

Update: Super Feed on GitHub.

Social Icons

I decided to try my hand at making my own social icons. You can see one set I made in the super feed, and another set in the footer. I crafted them using Illustrator and Photoshop. Eventually, I want to add a few more icons for other popular sites and then release both sets for free.

Update: Mini Social Icons on Dribbble.

Image Fix

Some images on the site (like my Flickr photos in the super feed) needed to be dynamically scaled and cropped to fit into the layout. So I whipped up a little utility that could do this on the fly. Simple, but very useful. This is also something I plan to open-source.

Why I Left the Mobile Team

First, a little backstory. I’ve been on CareerBuilder’s mobile development team for the past 9 months. I wrote our official Android app, which was a great experience. I also did a bit of iOS programming… which I’m less fond of. Regardless, I’ve realized that my true passion remains with web development. And so I naturally became “the mobile website guy”. I embraced this niche and life was good.

And then responsive web design came along.

If you haven’t heard of it, you really should check it out. It’s kind of a big deal. The basic concept is that your pages should be fluid, flexible, and “responsive” to whatever screen space is available. Done properly, this means you’ll never have to create duplicate versions of the same page, because each page will look great on any device.

A couple weeks ago, the mobile team had a meeting with some of our customer service people to review our mobile products. When it came my turn to go over the mobile website, one guy in the room eagerly stated that he never uses the mobile site. “Why would I use the limited mobile site when I can just scroll to the bottom, click the view full site link, and see everything?”

I was just confused. Why would anyone prefer a huge unwieldy page on a tiny mobile screen? Isn’t it worth giving up all that extra stuff for a better mobile experience? Since then, I’ve realized that my question is flawed. It’s not a matter of features vs. mobility. Our users wants both. The real question is, how can we reasonably offer all/most features to our mobile users?

Which brings me to one of the huge perks of responsive web design: you are no longer playing an unsustainable game of catch up with your mobile audience. You are no longer creating a desktop website, and then asking what features should be copied to the mobile site, and when you have time to do it. Instead, you create one set of responsive pages. Everyone gets all features, responsive design keeps things looking nice on big and small screens, and everyone is happy.

Of course, responsive isn’t a magic bullet that everyone should use. For some businesses, it still makes sense to have separately developed mobile pages. Us developers at CareerBuilder, however, have decided to go the responsive route.

So if we’re taking the responsive approach, and no longer making mobile-only pages, then why am I still on the mobile team? Well, I’m not.

Friday was my last day on the mobile team. Today I start on the job seeker development team, which is basically the team that does development for our public-facing website. I’ll be doing my best to lead the responsive approach on this team, which will still benefit our mobile users.