Journalism in the Public Interest

The ProPublica Nerd Blog

How We Made Look Better on Your Smartphone


Today we're launching a new look for people reading ProPublica on smartphones.

In order to make our site more welcoming for the increasing number of you who read us on your smartphones, we've redesigned and re-engineered the site so that people on small screens will automatically see a version of the site optimized to fit them. If you're on a smartphone, you've already seen the new look.

You don’t need any app or special URL to see it. Just go to If you’re on your phone, you'll see our optimized site. Readers of our website using desktop browsers shouldn't notice a difference.

The new pages use HTML5 as well as a technology called "media queries." We used the approach first laid out by Ethan Marcotte in his article "Responsive Web Design" (and later, the book of the same name). We also took as inspiration the remarkable new Boston Globe site.

Why this approach? Put simply, we wanted to make the site look and work great for readers on smartphones. But down the road, we see the mobile web becoming a more common reading device, and we want to make sure ProPublica's journalism is everywhere our readers want it.

We also believe that building a site that adapts to many screen sizes is a good long-term bet. Dedicated "native" smartphone apps are great (and we've got them for Android and iPhone), but a responsive site has some distinct advantages.

Primarily, it's just easier to develop for desktop and mobile simultaneously when you're just dealing with a single template and markup. Dedicated lightweight mobile sites tend to be based on special templates that are separate from the templates that are used for the desktop site -- and mobile "app store" apps aren't even web pages to begin with -- so recreating interactives for them is a big undertaking. Consequently, dedicated mobile sites and mobile apps tend not to contain all of the material in the regular website. But on our new responsive templates, most ProPublica's stories, graphics, videos, and news applications will be available simultaneously on all devices that can get to our site.

Another advantage of responsive design: If you click on a link you'll see the right version of our site, no matter what device you're using. Links don't work with mobile apps; there's no way to engineer a link so it opens in a "native" mobile app. We think this explains a phenomenon we’ve noticed -- that though we’ve had huge uptake of our mobile apps, we don't see very much day-to-day usage compared to the number of people who come to our site on their smart phones. It's our hypothesis that it's because people have to remember to open up the app to see what's new every day.

Likewise, a dedicated lightweight mobile site requires browser sniffing and URL redirection that's complex enough that failure is common -- so much so there's a web site dedicated to it.

Responsive web design solves these problems. If you're on a smartphone and click on a ProPublica link in a tweet or an e-mail, you'll see the right thing no matter what size screen you're looking at.

Design Is Never Finished, Only Abandoned

We cringe at calling anything "in beta," but we're going to be tweaking quite a bit over the next weeks and months, working closely with our designer, John-Henry Barac.

We're also aware that, with the enormous range of smartphone browsers in the wild, our site is surely going to fall short in places. If you see something that looks wrong on your smartphone, e-mail and we'll get it right. Make sure you tell us what device you're using and what browser you're using if it isn't the one that came with your phone.

OK, nerds. Go ahead, try it: resize your browser until it's about 480px wide and you'll see the browser switch between stylesheets. Aren't media queries grand? Of course, we didn't build the new stylesheets for people resizing their browser windows, so things might break in strange ways when you do that.

Also, let's clarify something: the new site isn't completely "responsive." They don't have fluid widths or automagically resizing images, and the page doesn't shrink to fit an infinite range of screen sizes. We call our approach "adaptive," or "switchy."

We decided early on that we really wanted to laser-focus on ~320px screen sizes like iPhone and Android browsers, which make up the huge majority of mobile web browsing in the U.S., and that for our particular use case, the widths in between smartphone and desktop were lots more work than we could realistically take on given the likely short-term payoff. Your mileage (and audience) may vary. We are under no illusions, though. We can foresee a time when we'll need to come up with a middle-range "break." The 600px-wide Kindle Fire has already staked this middle ground. For now, we're showing the full site to that browser, and sticking with smartphone and desktop widths.

Our slogan during this process has been "one website." We don't do any browser sniffing at all. Virtually all of the switching functionality is handled by media queries. In the few cases where we really need JavaScript to change the behavior of an element on mobile, the JavaScript detects window width on page render, and never asks what kind of browser you're using.

You may have noticed that there aren't any app-like behaviors like fixed-position nav and sliding page transitions. We opted not to do these because they're deceptively hard to get right, especially across all of the mobile browsers, and because they don't buy us genuine ease-of-use improvements for readers. The similarity to "app store" apps they provide tends to be pretty shallow, and we would argue, superfluous and faddish. The web has done pretty well so far without sliding page transitions, so we think readers on smartphones can browse happily without things like that.

Some of our news apps (like the maps that go with our redistricting stories and Dollars for Docs) are already adaptive, and as we have time we'll retrofit more of them. New news apps from here on out will be adaptive.

There's been quite a bit of talk about "mobile first" development and about the different information needs of somebody on a smartphone vs. somebody on a desktop browser. We don't disagree with any of it. Our goal with this redesign and engineering upgrade was simply to make the experience of reading stories and user interactives on our site better for smartphone users. There will be opportunities to use location services and the accelerometer down the road if a feature really cries out for it. But for now, readers should find reading our often lengthy stories less of a hassle.

Developer Jason Das (who deserves special praise for his work on this project) re-engineered most of the site using HTML5. There are almost no div tags on the homepage. See for yourself -- we're using the new HTML5 tags like and to make the code as semantic as possible. We also switched our stylesheets to SCSS, which makes it far easier to make complex stylesheets.

cool, but not working on my windows phone

Joshua Benton

Dec. 6, 2011, 9:46 a.m.

Looks great, Scott—congrats to you and your team.

Just curious: Did you consider giving readers the option to go to the full site, in case they were trying to get to something that’s in the sidebar/footer/etc. and thus not in the mobile version?

I ask because I built a (never released) responsive version of back in the summer, but I didn’t pull the trigger in part because I thought I wanted to add a “Full site” option that would undo the media queries. (I hate it when I want to click on something I know is on the full site and I get stuck with a mobile version with fewer options.)

I built something with url parameters (?mobile=false, that sort of thing) and started dropping a cookie, but I never finished it. Anyway, I’m still a little torn about how best to do it.

Todd Huss, Two Bit Labs

Dec. 6, 2011, 11:26 a.m.

Nice work!

I’m a huge fan of responsive web design. That kind of work is imminently reusable in your native apps too since you can then embed those pages in web views for certain parts of the app experience.

To your point about links taking a user into your native apps, on Android you can setup your app so that when a user clicks a link to your domain from another app (like mail) it offers your native app as a choice. On iOS you have to use a custom scheme before the hostname which makes it of more limited value.


Which version of Windows phone? We test in Windows Phone 7.5 but versions before that didn’t support media queries so we can’t really target those.

@Joshua Benton

There shouldn’t be much missing. The exceptions fall into roughly three categories: Things that are already built into mobile OSes, like the email-this-page button; things that are probably rarely done by people on their phones, like print-me buttons and the republish-this-article button; and things that didn’t make launch but are on the roadmap, like the Officials Say promo box, article sidebars (going live in the next day or two), etc. You’re right that it’s incumbent upon us to make sure we’re not leaving anything out that’s important to us and our readers, but for now we’re showing the best stylesheet to the right device and not giving the “full site” option. CSS without a net :)

FWIW, there are some templates that won’t get the adaptive styles applied because they’re something that just won’t ever make sense on a 320px screen except shrunk down, like really wide tables or something.

@Todd Huss

Sure—and Android’s “Intents” are a system that’s starting to explore solving this problem. But what if you’re not on your Android phone but on your computer when you click our link? Or you’re on the brand new iPad you got for the holidays? How can something point to the right place every time on every platform?

I guess on some level, it’s hard to beat the hyperlink…

I don’t have or want a cellphone, but I’d highly recommend Jakob Nielsen’s usability articles at .

For the last few months, he’s been heavily focused on phone and tablet screens, doing some fairly instructive studies.  Over the years, I’ve gotten a lot of positive feedback from basically taking a couple of articles and pretty much applying the advice blindly.

Joshua Benton

Dec. 6, 2011, 2:58 p.m.

@Scott, yeah, I think that’s probably right. I guess I just always appreciated the NYT’s refusal to serve anything but the desktop page to smartphones (by default, there’s of course), and I’ve got a soft spot in my heart for making full desktop class available.

Re: iOS, you’d think would create an equivalent to apple-touch-startup-image that you could put in your html head that would say “if this page is being viewed on an iOS device, open app X and pass it variable Y so it knows what page to display. But in real terms, for news apps at least, the gain in quality in the app vs. mobile web is so small that it would mostly be viewed as annoying. (I know I’d hate it if viewing a NYT story on my iPhone launched the NYT app and made me wait forever for it to load.)

Oh, look at that.  I didn’t catch the resize comment.

The only suggestion I’d have is to kill the header image and maybe shrink the headline.  If I was reading on a screen this size regularly, I’d want to just dive into the article with as little “fluff” as I possibly can.

1) It looks great, this is an approach I was considering, great to see it applied on someone else’s site first :)
2) Are you still loading the ad in the smaller width?  I see some requests there but you’re hiding it - just wondering about whether that’s counting as an impression or not somewhere.  That’s been one of my hesitations about going with this method.

But on the whole, awesome!

The website viewing on mobile devices may have been improved but your iPhone app does not work. The only actual content that can be accessed is the podcasts. All other sections are blank.

Please fix it.

@Joshua Benton

A true responsive design - like the now famous, and soon to be ubiquitous Boston Globe - shouldn’t turn off any functionality when a viewed on a mobile phone vs. a desktop browser. It simply reformats all various items on a page to optimize it for a mobile phone.

Feed-based mobile websites suck, and when I see one of those, I often want to view the full website, like you said. Responsive design, IMHO, is the solution to that problem.

Joshua Benton

Dec. 8, 2011, 4:06 p.m.

Hmmm…I don’t know how you’d define “true” responsive design (I guess that’s up to Ethan!), but I don’t see any reason a tactical display: none can’t be part of a decent set of media queries.

For me, responsive design means the same HTML and CSS being served to different devices but appearing in ways that are attuned to the device. For me, if a busy front page has lots of stuff going on on the desktop (a reasonable choice) and some of that busy-ness gets hidden when the same HTML is viewed on a smartphone, that’s still responsive.

In other words, if went responsive, I sure as heck wouldn’t want them to cram in all the same stuff that’s currently on that page into a mobile format. Pruning is a reasonable choice, I think.

@Sam Bailey

We’re not loading the ad on inside pages (temporarily, until we figure out where it should go) but it’s on the homepage. Luckly, 300px + 10px padding fits perfectly in a 320px-wide screen!

Commenting is not available in this section entry.