Category: Computers & Technology

  • Class reunions in the Facebook era

    It’s a sunny August morning. I’m sitting in front of my computer in a t-shirt, shorts and Converse sneakers, listening to Rush.

    You could easily assume the year is 1992. I did spend a lot of the summer of 1992 that way. But of course, no… it’s 2012. The music and attire may be (almost) the same, but the computer is not a Tandy 1000 EX with 640 KB of RAM. It’s a MacBook Air connected to a 23-inch LCD flat panel, with 4 GB (4,194,304 KB) of RAM.

    So, the more things change, the more they stay the same. (Or, as Rush and the French say, “plus ça change, plus c’est la même chose.”) That saying will be put to the test tonight when I attend my 20-year high school class reunion.

    The last time I will have seen many of these people is 10 years ago, at our last reunion. But a couple of significant things have happened in the past 10 years.

    First, we are now 20 years out of high school. Which means that, for the first time, we are gathering having lived more of our lives after high school graduation than before it.

    My biggest fear: I won’t recognize someone who recognizes me. There was a time in my life, even some years after graduation, when I could confidently name every single one of the 200-or-so people in my graduating class. But now I look at our class photo with only a vague recollection of a lot of now-nameless faces. Even among the people in the photo I do still remember and can name, will I recognize them with all of the changes 20 years have brought? Will I recognize them without teased perms and mullets?

    Second, Facebook.

    Like it or hate it (or both, as seems to be the case with most people), Facebook has had a profound impact on how we keep in touch with the people in our lives, especially those on the periphery of it. And few people occupy the periphery of our lives quite like those we spent 13 years with in public school and then haven’t seen since.

    There are plenty of people with whom I was at best a passing acquaintance in high school, but who are now, by Facebook terms, my “friends.” Facebook keeps us in contact with a wide network of friends, family, coworkers and acquaintances past and present in ways that were never before imaginable. But for the most part these contacts are profoundly superficial. I might know that you went to the beach last weekend, or what you had for lunch, or that you have too much time on your hands to spend looking at cat photos, or that you and I have divergent political views. But when’s the last time we actually saw each other face to face? When did we go out for a beer or come over to each other’s houses for a barbecue or work together on an exciting new project? Facebook defines trivia, in the worst possible way.

    Sadder though than the superficial connections Facebook creates with people I only ever had superficial connections with in the first place, are the superficial connections Facebook creates between me and the people with whom I was actually close friends in high school. Sure, many of them are now scattered across the country (or the world) and we couldn’t really hope for a more “real” connection than what Facebook offers. But a handful of my good friends from high school currently live in the same city as I do, and yet we only have those same trivial connections on Facebook. We could get together any time we want, not just when our entire class converges on our hometown to mark the frighteningly fast passage of time.

    But we don’t.

    Over the past few years I’ve been looking forward to this reunion with uncertainty. What kind of impact was Facebook going to have on it? Are reunions even necessary in the era of Facebook? Now that it’s (almost) here, I’m getting a better sense that, yes, reunions do still have an important place in our lives. Because while Facebook might keep us connected, it doesn’t really keep us in touch.

    It does make planning the event a lot easier though.

  • State of browser/OS/device usage on Underdog of Perfection, June 2012

    I just had a look at my Google Analytics stats for this site. I made some interesting observations.

    First, I saw iOS, iPhone and iPad showing up as separate devices. I wondered if iOS was a composite of both, but I realized Google was actually counting them separately. Looking at the daily stats it was clear that they made this switch on May 29, where before that date iPhone and iPad were being reported, and afterward it was just iOS. I’m not sure why they did that, but I am sure there was a very deliberate reason behind it.

    Anyway, uncovering this switch was not relevant to my data observations, so I changed the date range to only encompass dates after the switch, June 1 to 20.

    Here’s what I found:

    True, I am a Mac user, and have for a long time favored Safari (although I recently switched my default browser to Chrome). But I don’t really spend that much time admiring my own work here on the blog. (Yes… not that much time.) So I don’t think my own activity skews the data here too much.

    Do I then think this reflects the Internet as a whole? Absolutely not. I’ve learned over time that most of the people visiting my blog are stumbling upon specific posts based on a Google search, and these are almost always posts that are about diagnosing and fixing particular Mac-related problems. So, Safari’s dominance is logical (especially if Mobile Safari for iOS is lumped in here, which I have to assume is the case).

    It’s nice to see Internet Explorer under 10%. And that’s all versions of Internet Explorer. But… what the heck is RockMelt? Yes, I am asking the two of you who use it.

    Yes, even despite my blatant and unrepentant Apple bias, Windows still slightly edges out Mac in the stats. Interesting, then, that Safari is the most popular browser, since I suspect there are even fewer Windows Safari users than there are RockMelt users. But of course, we’re back to iOS. If you combine Mac and iOS, the total is well above that for Windows, and explains Safari’s #1 spot on the browser list.

    Among mobile operating systems, iOS demonstrates a Windows-in-the-late-’90s level dominance. This despite the fact that Android famously holds greater market share in the US. Yes, my content will naturally skew my stats Apple-ward, but this data also, I think, reinforces the idea that iOS users actually use the web a lot more than Android users do.

    BlackBerry and Nokia… how cute. Where’s Windows Phone?

    And finally, we have mobile screen resolution. Now that Google doesn’t separate iPhone and iPad anymore, this is pretty much the way to distinguish between them in the stats. These resolutions are not the actual resolution of the screens but the pixel-doubled effective resolution used in the web browsers on Retina Display devices. 320×480 is the iPhone (even though the iPhone 4 and 4S have 640×960 screens), and 768×1024 is the iPad (even though the new iPad has a 1536×2048 display).

    0x0? Really?

    What I think is most significant here though is not the iPhone/iPad split at all, interesting as it is. It’s the fact that once you get past those, there’s no standard whatsoever on Android. That’s something to remember for those of us working on Responsive Web Design.

  • Dr. Heckyll is his own little guinea pig…

    Much like “Dr. Heckyll” in the Men at Work song, I am my own little guinea pig.

    This week Facebook released an official WordPress plugin that promises deep integration. Vaguely lewd as that may sound, it’s something I need to pursue. I keep Facebook at arm’s length, but as a web developer I cannot deny that it is by far the most popular — nay, ubiquitous — social network out there. Social network integration is a big part of what my clients want with new websites, and the more we can take advantage of these kinds of tools, the more we can achieve those goals.

    And so, here I am, finding myself trying out just about everything the Facebook WordPress plugin can do, right on my very own blog. Eventually I’ll probably turn off most or all of these features, but before I do that I need to find out what they do, so I know which of them are right for my clients.

    Update, about 3 seconds later… I’ve already turned off the first of the “features” of the Facebook plugin: comment integration. I have already been happily using Disqus for my comments, and Facebook (unsurprisingly) doesn’t play nicely with it.

  • 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.