For the first few years of my career I’d joke that I “type for a living.” That was selling myself short, though, I know—making websites is a complicated gig. It’s more accurate, I think, to say that I’m wrong for a living. I’ve been wrong about damn near everything about this job so far. I’m probably—no, definitely—wrong about plenty of things, as we speak.

I’m spectacular at job interviews, before anyone asks.

I should be more specific here: I’ve spent a good part of my career being wrong about matters of browsing context, but I don’t think I’m the only one. It hasn’t been all that long since the days of fixed-width websites, and the era of “looks best in Internet Explorer.” Back then, I was up to my neck in each of those industry-wide wrongnesses, sure that we were doing the right thing promoting the better browser and keeping apace with all the the hottest new CRT monitor sizes. It sure felt like I was right, at those times. It seemed like there were plenty of reasons to think so.

I’ve been wrong about context more recently than either of those—before web standards changed the way we think about browser support, and before responsive web design changed the way we think about our layouts. For a time—and with just as little realization of how wrong I was—I’d chosen a single familiar, comfortable context for the sites I’d build. I was building websites for my context: the browsing conditions that I was used to. I was doing my work on a fast computer and a high-speed internet connection—that’s what the web was, to me. I have the privilege of assuming high bandwidth and stable networks—I can assume that sending out a request will always result in something being sent back. But we can’t make assumptions about bandwidth that way, any more than we can make development decisions based on a cursory look around our offices, saying, “Everyone here has a pretty big display,” or, “Everyone here is using Firefox.”

I’m not the only one who made this mistake, either: not long ago, a full 72 percent of responsive websites were sending the same amount of data to mobile and desktop users, while only about six percent of responsive sites were taking significant steps in tailoring assets to mobile devices. Unfortunately, that last statistic doesn’t really track with reality: seventy one percent of mobile users expect websites to load almost as fast, or faster, than everywhere else.

The people building the web have it the easiest on the web, and perhaps as a result: the average web page is now more than 1.8 megabytes, with images alone accounting for a full megabyte of that.

That’s more than a case of us creating an minor inconvenience for ourselves. Building enormous websites means us shifting the burden of our mistakes onto every single user that visits our site. It’s us saying that we’re willing to build something that isn’t for some users, because that’s most comfortable for us—no different from “best viewed in Internet Explorer 5.5” or “best viewed at 600x800,” but much more costly.

That’s not what I want the web to be. That’s not what I want this job to be. The meaning I take from this gig doesn’t come from getting a div to show up in the right place—it comes from knowing that working just a little harder can mean that entire populations just setting foot on the web for the first time will be able to tap into the collected knowledge of the whole of mankind. That’s the philosophy that started the crusade for “responsive images.” Building massive, resource-heavy sites means excluding millions of users worldwide that have only ever known the web by way of feature phones or slightly better. These are users paying for every kilobyte they consume, already keeping tabs on which sites they need to avoid day-to-day because of the cost of visiting them, and not some nebulous hand-wavy “bandwidth cost” either—actual economic cost.

If every single one of you were convinced that this is a big deal, it still wouldn’t be enough—there are too few of us, and the steps to solve these problems in our daily work aren’t as clear-cut as they need to be. This is something I’ve wanted solved at the browser level for a long time now. I want a feature we could make a part of our everyday workflow—something we all just do as a matter of course, baked right into HTML5.

That solution is here, thanks to the efforts of developers like Eric Portis. In our latest issue, Eric’s “Responsive Images in Practice” forgoes the rocky history and web standards minutia involved in the search for a native “responsive images” solution and cuts right to what matters most: putting those solutions to use so we can build a better web for our users. Those users will never see any difference; they won’t care what combination of responsive image techniques we used or which use cases we needed to address. They’ll see images, same as they would before. What those users will notice is that the web feels faster.

Responsive web design is still pretty new, in the grand scheme of things. We’re all still getting the hang of it, myself included. There are plenty more things for us to be wrong about, I’m sure, but I’m excited to find them with you all. Because every time we discover we’ve been wrong about some matter of context on the web, we find a way to fix it together. And the web gets a little stronger, a little faster, and a little more inclusive as a result.

The fine folks at A List Apart

Comments are closed.