I spoke to a digital team at a large corporation a while back, and outlined some of the many challenges they were likely to face in creating, revising, and publishing their content so it would work well on smartphone, tablet, and desktop interfaces.
These included:
An attendee raised her hand and said “I’ve been wondering when you would mention responsive web design. We’re going to use responsive design.” I responded “Well, responsive design won’t fix your content problem.”
I recently posted a link to an article that called responsive design a “poor man’s content strategy.” Then my Twitter feed exploded with people heavily sighing and rolling their eyes, insisting no one would ever conflate the two. Why, everyone knows that the container and what you put in the container aren’t the same thing. Everyone knows that just rearranging modules from the desktop to make them squishy is not a content strategy for mobile. Everyone knows if organizations discover problems that go beyond the specific layout solutions offered by responsive design, that’s not the fault of the technique.
Except not everyone knows that. These are just a few of the anecdotes I’ve heard recently from people working on mobile websites for major corporations—projects with large budgets, committed teams, and executive buy-in:
Seems like a lot of people are laboring under the mistaken impression that using responsive design means they can make a mobile website without dealing with their content problem.
We told them so. And, okay, yes, they’re using some magical thinking. But straight up, we told them that the mobile website should be the same as the desktop, and that’s why they should use responsive web design. We sold them on the value of responsive design by promising that they could manage and maintain one set of content and it would work across all devices.
We also insisted there’s no good reason to serve different content by platform. We got twitchy whenever anyone started talking about sending different content or less content to mobile devices (rightly so). We pointed out that you can’t discern user context or intent just from knowing screen size or device type. We told them content parity was the first and most important goal when developing a responsive website.
Is it any wonder they assume (hope?) they can just take what they already have, wave a responsive magic wand over it, and have their existing content automagically work on mobile? Why should it be different? We said it shouldn’t be.
Even companies that want to take a “mobile first” approach can’t just throw off the shackles of their desktop content. For some, suggesting the organization “start fresh” with new content would be organizational suicide, touching the political third rail of stakeholders and competing interests. Others acknowledge it’s time for a new approach, but need processes that will enable them to clean up and restructure existing content to make it appropriate for a responsive design. Responsive design won’t fix their content problem—but content strategy will.
It’s time we acknowledged that every responsive web design project is also a content strategy project. For designers and developers who might not know what to emphasize, here are a few talking points:
Even though the long-term goal is to serve the same content to every platform, organizations can’t just use what they already have. Smart companies will seize this opportunity to do what they should have done years ago: clean up and pare down their desktop content. You’ll never get a better chance to fix your content and publishing processes.
The tantalizing prospect of responsive web design is being able to solve the problem of “mobile” completely on the front end. The front end is so much more malleable than the back end, so of course we want to start there. But many responsive projects require changes to the way content and data are structured and published from the CMS or other legacy systems. For some, an approach to APIs will be needed; for many others, it will be an overhaul of content management and asset management systems.
The chicken-and-egg problem of content informing design (and vice versa) just got bigger—call it an ostrich-and-egg problem. While smart people have talked about the responsive design workflow and how design deliverables and processes must change, the editorial workflow also needs attention. Planning for how and when the content team will migrate, edit, and restructure content will help everyone ensure that the content and the design work together. Design deliverables like wireframes and comps are evolving—content teams must also evolve away from reliance on Excel spreadsheets and Word documents to manage this process.
Even the most dedicated and ambitious teams won’t have the capacity to revise and restructure every page of their existing desktop website. Making informed and realistic decisions about what to focus on (and what to punt on) will help with overall planning, migration processes, and design decisions. Acknowledging this early will help get teams and stakeholders on board with the fact that not everything will be perfect.
Responsive design also won’t fix your design standards and governance model, but we still need to include long-term maintenance in our objectives. I heard a story from one group who said they convinced their company that it wasn’t possible to do responsive design properly unless they also created and enforced a design system. The same argument could be made for developing and encouraging adherence to content standards.
Responsive design itself won’t fix your content—no one ever said it would. But the opportunity to implement a responsive redesign is also the opportunity to fix your content and its underlying strategy. It may seem more complicated to edit your content and fix your processes and systems at the same time you’re designing a new site—but in fact, pretending you don’t have to solve these problems just makes the job harder. Smart organizations will see this as a benefit, not a drawback, and will use this chance to make a better website, not just a squishy one.
A few years ago, I asked on my blog what people would like from Google’s free webmaster tools. It’s pretty cool to re-read that post now, because we’ve delivered on a lot of peoples’ requests.
At this point, our webmaster console will alert you to manual webspam actions that will directly affect your site. We’ve recently rolled out better visibility on website security issues, including radically improved resources for hacked site help. We’ve also improved the backlinks that we show to publishers and site owners. Along the way, we’ve also created a website that explains how search works, and Google has done dozens of “office hours” hangouts for websites. And we’re just about to hit 15 million views on ~500 different webmaster videos.
So here’s my question: what would you like to see from Webmaster Tools (or the larger team) in 2014? I’ll throw out a few ideas below, but please leave suggestions in the comments. Bear in mind that I’m not promising we’ll do any of these–this is just to get your mental juices going.
Some things that I could imagine people wanting:
To be clear, this is just some personal brainstorming–I’m not saying that the Webmaster Tools team will work on any of these. What I’d really like to hear is what you would like to see in 2014, either in Webmaster Tools or from the larger team that works with webmasters and site owners.
The next version of Sass recently hit release candidate status, meaning it’ll be out in the wild any day now. There are some great changes coming in Sass 3.3, one of which should have developers extremely excited: sourcemaps.
Put plainly, sourcemaps are a way to map compiled code back to its native state. That may sound kind of odd, but sourcemaps will make every Sass-loving developer’s life a little bit better. Browsers that understand the generated map file will know where each and every line of code came from, down to the line number in the original Sass file, rather than the line number from the compiled CSS file.
Even in the pre-release state, sourcemaps are proving to be a big productivity boost for developers by cutting down debug time and making Sass code easier to optimize and improve. No need to wait for Sass 3.3 to be released officially: install the release candidate and try it out in your own projects!
For the folks that don’t know, I’ve been out for a couple weeks and I’ll be on vacation the rest of November. If you’ve tried to contact me recently and haven’t heard back, that’s probably the reason.
Blue Beanie Day is nearly here! On Saturday, November 30, web designers around the world will once again don a blue beanie (toque, cap) to show their support for web standards. Join us!
HTML, CSS, and JavaScript. Accessibility. Progressive enhancement. (Structured) content first. The more our industry and the technology we’re asked to support changes each year, the more these basics of the web standards movement remain the same. Which is why, each year, we set aside a day to celebrate web standards and the best practices it encourages.
As for the beanie, “the … blue hat is a nod to the bible-like Designing With Web Standards author Jeffrey Zeldman, who famously donned a blue knit hat in his author photo for the book” says Fast Company . But of course Blue Beanie Day is not about me, it’s about we. We, the people who make websites. We who value the open web. Who believe the web is a medium capable of sharing every human experience. And who work each day to make great web content and great web experiences accessible to all.
Apartniks who wish to show their support for web standards may do so my uploading a blue-beanie-wearing selfie to the Blue Beanie Day Tumblr. You can also post your BBD self-portraits to Instagram (hashtag #bbd13) and to the Seventh International Blue Beanie Day 2013 pool on Flickr. There’s no need to wait ‘til November 30th to post your pics to Tumblr and Flickr. Do it today!
BugHerd is a visual bug tracker that works like sticky notes on your website. With point and click action it’s so simple even your clients will like it! No install required and a 14 day free trial, you can start logging bugs right away.
Last year, the New York Times got everybody’s attention with the publication of “Snow Fall,” an experiment in pushing the boundaries of editorial design. They weren’t the first big content player to try to break out of the one-size-fits-all template box, but theirs was the one that got all the big news kids to turn their heads and take notice.
Fast forward a bit, and top-line pieces from the likes of Pitchfork, ESPN, Vox Media, and the Guardian now make regular appearances in our timelines and inboxes. And each one seems to meet with equally vocal waves of applause and pessimism.
As overdue experiments in art direction and editorial design for the web, these things are important. They’re also polarizing. People either love ’em or hate ’em (or hate on them, anyway). So more than a year after it joined the common news parlance, the question remains: is “snowfalling” worth it?
The biggest knock against “Snow Fall”–style pieces is that they seem to take a lot of time and effort to produce. Now, last time I checked, plenty of things worth doing take time and effort. But let’s give this argument its due. These stories can take a lot of time and effort to produce—at first. The more attempts, the better and more robust the tools become and the smarter organizations get about building them efficiently.
Those gains extend to the browser experience as well, though we’re not quite there yet. A few of these early experiments have been, oh, a wee tad heavy, letting poor performance and poor accessibility get in the way of the story. (Seriously, you can’t get much more “in the way” than building a page that doesn’t load.) Accounting for that needs to be part of the design process, and that process is evolving.
The real implication of the time and resources critique is that there isn’t an adequate return on all this investment. Turns out that creates a damn nice opening for dealing with objections over ads, too.
Since most of these pieces ditch standard ad units to give their designs a little elbow room, there’s a contention that they can’t possibly pay for themselves. The answer on that one is simple: of course they don’t. In fact, few news stories do. To repeat something I said earlier this week, the ad game for major news operations is played in aggregate. If these experiments drive more traffic, link sharing, and interest, they are in fact bolstering CPMs and the ad game for a publication overall. Unless they depend entirely on sponsorships and subscriptions (few do), it’s a net win.
But there’s a bigger picture that extends beyond debating specific executions and business models. These things are about experimentation: necessary design and technical experimentation, something news organizations need to shine at if they want to thrive. That means stopping to shake out how they think about content, again and again.
One of my biggest frustrations as a newsroom creative director was fighting dogma about what web pages should “look like.” Even five years ago, getting organizations to push past the “inverted L” as the One True Layout was a big deal. When you consider how young a medium the web is, that’s insane. It’s improbable that we could’ve arrived at the best and only way to present a story in such a short span of time.
What newsroom design shops have needed is a renewed interest in research and development, and that’s exactly what these pieces are delivering.
The benefits go beyond the plainly obvious. You need good R&D for the same reason you need a good space program. It doesn’t just get you to the Moon. It gives you things like memory foam, scratch-resistant lenses, and Dustbusters. It gets you the workaday byproducts of striving for higher goals.
The JavaScript libraries, design patterns, and tidbits these teams are building to get to a “Snow Fall” are getting repurposed, snapped out, modularized, and evolved in directions big and small. They’ll get used in ways and places we haven’t imagined yet. It won’t be all about scroll-tastic doodads, and it won’t be just for gussying up longform content.
Together with the responsive redesign of the Boston Globe, this represents the most significant progress we’ve seen in online editorial design in years, and by far one of the most “web native” developments in our short history. The “Snow Fall” DNA is already working its way through organizations. Not everything, but parts. And that’s exciting. The worst thing we can say right now is, “Don’t try.”
On April 21st, 2014, I’m going to run the Boston Marathon. If you want to show your support, please donate to a good cause for cancer research. Anyone who wants to give is welcome. 
So many people have been affected by cancer, including members of my own family. The Dana-Farber Cancer Institute funds basic and innovative cancer research. That’s why I’m trying to raise $9,000 for the Dana-Farber Marathon Challenge.
I’ve been running for a few years now (that’s me at the San Francisco marathon), but this is the first time I’m trying to run to raise money for a cause, and I would really appreciate donations. It won’t give you more PageRank or a higher rank on Google, but Dana-Farber is a great institution and I’d love to raise as much money for them as I can before I run in Boston. If you can, please consider donating to kick cancer’s butt. Thank you!
At yesterday’s Ampersand New York web typography conference in the Times Center at The New York Times, Font Bureau designer/technologist (and A List Apart columnist) Nick Sherman demo’d Size Calculator, a web application created to bring screen design a capability that print design has enjoyed for 500 years.
It is trivial for a designer to set type (or any artwork) to appear at a specific size in centimeters or inches on the printed page. But it is impossible to do so when designing for screens. Here’s how Zen it gets: if I use CSS to set a line of type at 65cm, it will most certainly not be 65cm tall—nor does the W3C expect it to be. Actual size will depend on the dimensions and resolution of the screen. (Perceived size will of course depend on viewing distance, but that is true for print as well.)
Likewise, if I want an image or a line of type to appear to be exactly the same size when viewed on different screens—say, on a smartphone and a desktop monitor—there’s no way to achieve that, either.
Size Calculator solves these problems by using JavaScript to do the math.
What it is good for: if you know the dimensions and resolution of your device (be it a wall screen at a conference, a digital billboard, or a specific model phone held in a specific orientation), you can finally do the things I mentioned in the paragraphs above. Same size type on different screens viewed at different distances? Achievement unlocked. Another thing Nick did in his demo was to “print” an exact size dollar bill on the screen in the Times Center auditorium. He proved that it worked by walking to the screen and holding the actual dollar in front of the projected dollar. He then printed a life-size image of himself. Fun!
What it is not good for: although Size Calculator is exciting, it would not be good for responsive web design, because RWD is about designing for a universe of unknown devices, resolutions, and capabilities.
But if you are designing for a limited set of known screens, the sky’s the limit—literally: your design can take miles or km into account. If you’ve always wanted to make a ten thousand foot letter display at 12pt when viewed from a helicopter, now’s your chance.
What will you do with Size Calculator?
