UNDERDOG of PERFECTION - Page 72 - a blog on technology, music and geek culture from room34

Blogging pro tip #2,749

Aside

I’ve inadvertently taught myself an important lesson about blogging this week: Never publish “part one” of a multi-part blog post until you have “part two” almost finished.

Three days ago I posted Practical responsive web design, part one fully expecting to write and post “part two” later that day or sometime the next. At this point I still haven’t even begun to write it, and it’s looming over my head.

I’ve blocked out my whole calendar next week though, so maybe I’ll get it done. (You know, like there’s no other work to do.)

Near misses

Last night, while driving in a relatively unfamiliar area in the northern suburbs of St. Paul, I nearly died. Well, OK, I’m not sure I was that close to dying, but a fraction of a second was the difference between today being another ordinary day and being one spent in ICU or the morgue.

I was heading west on Ramsey County 96, about to make a left turn onto the southbound I-35W onramp. Highway 96 is a 4-lane divided highway at this point, and with some construction in the area, the interchange has recently been made into a 4-way stop. As I approached the intersection I stopped, observing a semi slowing to a stop in the oncoming right-hand lane. I arrived at the intersection first, so I began my left turn. Just as I was entering the intersection, an SUV blew through in the oncoming left-hand lane, oblivious to the stop sign, obscured by the semi. I slammed hard on my brakes (and almost as hard on the horn). They honked at me too, apparently blaming me for observing the stop sign they were unaware existed. I escaped unscathed, though I’m not sure how close we came to a collision. 4 or 5 feet, probably. Not a razor-thin margin, but with the SUV traveling at least 50 MPH, it was still too close for comfort. (And I don’t mean this.)

We all encounter varying degrees of “near misses” every day. Only rarely are they so clear and obvious that we are shaken by them, and even then, things quickly return to normal. We are a resilient species. We have to be, to survive. But there’s a downside to that resilience. It’s easy to forget just how precious our days are, and how soon they will be gone.

My near miss last night has me thinking more about what’s really important, and wanting to spend my time only on those important things as much as possible. That doesn’t mean working crazy hours or having life-changing experiences every moment. But it does mean spending less time worrying about things that don’t really matter, and making choices that make each day better instead of worse.

Don’t worry, and don’t regret. Take chances. Go after opportunities. Make things happen.

I’m still here. For now. And if you’re reading this, you are too. Let’s do this. Don’t stop. Except at stop signs.

Oversharing and paranoia

Oversharing is an inherent part of social media. Just ask anyone who’s made the mistake of clicking a Socialcam link on Facebook.

But oversharing takes different forms, and the most potentially dangerous type is one many people don’t even realize exists: the copious logging of your online activities by the social networking sites you’re logged into. Thanks to their “deep integration” with other websites, you may be “sharing” your browsing habits with Facebook, Twitter and Google even when you’re not on their sites.

Have you ever been on a site and noticed a little corner of the site looks like it’s been invaded by Facebook? That sickly blue, the font, the little profile pictures of your friends who’ve liked or commented on the page you’re currently viewing?

How did that get there? It’s because the site is integrating with Facebook, and through the magic of cookies, Facebook’s servers can tell that it’s you looking at the page and deliver content customized to your profile. Maybe you like that, but I find it a little creepy. Twitter and Google do it too, even if it’s not as obvious.

Google may be the most insidious, with so many of its tools now consolidated under a single login. If you use Gmail, and you keep your account logged in, every Google search you do is logged. Ostensibly this is to help deliver “personalized” results. More crassly, it is used to put “targeted” ads in front of your eyeballs. But that data is being collected, and regardless of what Google says their privacy policy is now, the data is there, and could stay there for a long time. Someday Google might change their policies or sell that data or the government might subpoena it or just come in and take it.

What’s worse, Google Analytics is everywhere. Heck, even paranoid old me uses it. Google says Analytics isn’t tied in with your Google account, and maybe it’s not… yet. But why assume it will always be that way?

Fortunately, there’s something very simple you can do to combat all of this data collection. It’s the online equivalent of a tinfoil hat, except it actually works. Log out. And just to be safe, clear your cookies.

I’m trying something out right now that takes all of this even a step further. It all hinges on the fact that in all three of these cases — Facebook, Twitter and Gmail — the web interface is probably the least usable, least satisfying way to experience these services. I’ve never really been a user of Gmail’s web interface; I’ve always preferred using the Mac’s built in Mail application. But now I’m also strictly using the Twitter app on my Mac. (I already use Tweetbot on my iPhone.) And I have made the decision not to use Facebook on my computer at all. I already hated the Facebook web experience anyway, so why bother with it? Now I am only going to check it using the Facebook iPhone app.

Practical responsive web design, part one

I’ve been wanting to write this post for a while, but I’ve been too busy writing code instead. Plus, the techniques are evolving and changing so fast, that by the time I finish a project, the way I built it is already obsolete.

Now, with the Breaking Development Conference in town and a few recent responsive site launches under my belt, it seemed like a good time to write up a summary of what I’ve learned, what I’m doing, and where I think all of this is going.

First, a quick aside. I didn’t attend the conference. I would have liked to, but as an independent developer I never seem able to justify the standard $500-per-day rate most conferences charge. That doesn’t mean the conferences don’t have value; they’re just not for me.

Before we begin

There are a few caveats I want to lay down before I start talking about responsive web design:

This stuff is changing… fast. Anything I write here may become foolishly out of date by the time I hit the “Publish” button. Responsive web design is a work in progress, and there are no rules (yet).

What I’m doing may not be “by the book,” proper-name Responsive Web Design. The book is great, and there are “experts” who have much deeper knowledge of these strategies than I do. But as I said above, there are no rules (yet). I want to describe the practical techniques I am employing on actual live web projects, under often less-than-ideal circumstances.

Every website is different. The company is different. Its audience is different. The content and style and context where it will be viewed are different. The balance between showing off fancy new features on high-resolution tablet displays and supporting corporate IT departments that are still straggling with Windows XP and Internet Explorer 6 will vary. In short, what I am doing may not work for you. But I hope it can give you some ideas that will.

A practical baseline

My goal with responsive design is to get the biggest “bang for my (client’s) buck.” I recently read a about a study that found almost 4,000 different Android devices in a site’s access logs, with many of them only appearing in the logs once. It is not possible to account for all of these variations. And, after its primary goal of providing an optimal user experience across a variety of devices, not needing to account for each of them individually is the second biggest purpose of responsive design. (That’s also, arguably, its biggest practical benefit.) By building on a fluid, flexible structure from the beginning, a site will look good regardless of slight variations in its presentation.

But I’m not starting from scratch. I work with a number of designers who deliver their work to me in a variety of formats (usually Adobe software). They’re tremendously talented, but they don’t all have a full working knowledge of fluid grids and all of the other considerations that go into responsive web design. So my job is largely to translate these “traditional” web designs into something that works, more or less, with a responsive approach.

I’m targeting three basic screen types: computer (desktop or laptop, including iPad in horizontal orientation), tablet (primarily iPad in vertical orientation, but also smaller tablets like the Kindle Fire or the Nook Color), and smartphone (primarily iPhone, but also Android and Windows Phone). Additionally, I am trying to balance a Mobile First approach with support for Internet Explorer 7 and 8. (I am fortunate to be in a position not to need to worry much about IE6 anymore, and IE9 plays well with CSS3 media queries.) In some cases I am also targeting “very large” computer displays, those with a horizontal resolution of 1280 or above, with a scaled-up layout.

So, instead of accounting for 4,000+ different screens, I’m aiming at 3 (or 4) general screen categories. I am also accounting for two basic browser categories: IE 7 and 8, and everything else. (Yes, if you approach it in the right way, it’s really that simple. Almost.)

Fixed, yet flexible

With this “practical baseline” in mind, and working primarily with traditional fixed-width web designs as a starting point, I’ve established break points (widths at which the layout changes significantly) at around 700 pixels (varying by site between 640 and 720); at 960 pixels for the “standard” computer (and horizontal iPad) layouts; and, for the “very large” displays, at 1200 pixels. This allows for a traditional fixed-width web design approach to be used, rather than accounting for a completely fluid layout across all screen sizes. It may sound like a cop-out, but I find it to be a very helpful way to get things done when collaborating with designers who are not living and breathing this stuff the way I do every day.

For screens below my “around 700” threshold, I drop into a fully-fluid, single-column layout targeted at the smartphone user experience. In these cases there may be other significant changes to the layout, such as collapsing content blocks into expandable buttons, allowing users to quickly see what’s on the page without having to scroll endlessly. (This is not a radical invention of my own… it’s more-or-less how the mobile version of Wikipedia functions.)

In part two, I will get into the details of how I built out a pair of recent websites, including a few code examples, to show how the HTML and CSS fit together, and how I balance the seemingly incompatible worlds of mobile-first and IE8.