On products, services, and the trouble with Twitter

Much of the buzz this week among online geek types has been the latest step in the gradually unfolding revelation of exactly where Twitter (the business) intends to take Twitter (the service), and just how stark the difference is between that place and where these same geeks — who have been largely responsible for the establishment of Twitter as a successful platform — would like to see it go.

The latter place can most easily be summed up as, “where it started out,” but the details of where it started out, and how far it is from where the company now wants to take it, reveal a lot about the nature of the Internet as a place for commercial business, vs. the way most users see it, as a medium for communication.

Most people who use the Internet have little knowledge of, or interest in, how it actually works. Even those of us who make our living building it don’t always have a firm grasp of the technologies that make it all possible. But understanding those details, and understanding the differences between a service and a product, for lack of a more effective yet equally succinct description, can shed light on the current trouble with Twitter.

The crux of geek anger towards Twitter of late has to do with Twitter’s ongoing efforts to shut down a number of its APIs that allow third-party apps like Tweetbot (my personal favorite iPhone Twitter client) to interact with data from Twitter’s servers. Without these APIs, these third-party apps can’t function. The specifics of the situation are a lot more complicated than this, but I’ll leave the reader to investigate further; Dalton Caldwell’s post from yesterday, Twitter is pivoting, is a great place to start.

All of this may seem supremely geeky and esoteric to most Twitter users, though I suspect anyone who’s been using the Internet for more than two years would take pause at the fact that Peter Chernin, who was deeply involved in the downfall of MySpace, has just joined Twitter’s board of directors. (Especially since he chose to tweet it in a way that reveals a profound lack of understanding of how Twitter works.)

Which brings me to the topic of products and services. As I am using the terms here, a “service” is what we on the geek side of the Internet refer to as a protocol. On the Internet, a protocol is a technology, built upon a publicly documented specification, which allows particular types of interactions between devices over the Internet. A protocol is inherently public, open, and decentralized. That’s the only way they can work. Each protocol tends to have a strange acronym associated with it, some of which the creakier, older parts of the Internet may have failed to shield you from: things like HTTP (the web) or IMAP (email). All of these protocols are built upon a more fundamental, lower-level protocol: TCP/IP.

Protocols are what make the Internet work. And they’ve existed since well before anyone saw (or at least fully exploited) the Internet’s potential for profit. Protocols as services are so ubiquitous and inherent to the experience of using the Internet, we don’t even realize they exist, or what they are, or how exactly they work. And we tend to assume that anything we interact with on the Internet is kind of all the same. We might have a vague sense that something like Facebook or Twitter is a commercial enterprise, but even the geekiest among us who actively use these services products don’t often think about just how different they are at the core than things like email.

In contrast to these protocols/services, we have commercial products like Facebook or Twitter. These are not protocols. While we are all by now painfully aware of how open and public the information we share on them can be, there is nothing whatsoever that is “open” or “public” about how they actually work, and their functionality is entirely centralized within the competitive, secretive, for-profit businesses that own them.

Facebook has taken a lot of flak in recent years for its aggressive commercialization of the user experience. The information you share is not only overly public, it is parsed by their ingenious algorithms to allow them to put highly-targeted advertising in front of your eyeballs. (At least, that’s the theory; in practice it doesn’t always work so well.) As the saying goes, if you’re not paying for it, you’re not the customer… you’re the product being sold.

While it’s been easy to see how Facebook is monetizing our online interactions, the gradual creep of Twitter’s monetization has been quieter, and more insidious. It’s been easy enough to ignore promoted tweets and trending topics, and they’ve even backpedaled on occasion in response to negative user reaction. (Remember the Dickbar?) But eventually, true to the cliché, there’s a straw that breaks the camel’s back. And the latest API deprecations may represent that last straw.

You see, you can only change a product so much before eventually it ceases to resemble in any meaningful way the thing that it once was, the thing that appealed to its users in the first place. And for Twitter, the business, it is entirely their prerogative to make those changes, to “pivot,” into something completely different. But in so doing, they reveal the true nature of their product, and the fact that it was never really the service its loyal users took it to be.

Ayn Rand’s (in)famous novel Atlas Shrugged ends with capitalist Übermensch John Galt tracing the sign of the dollar with his finger. But when the dollar sign becomes the ultimate symbol of human achievement, money is the only thing in life that has value. This may be a rather heavy-handed reference (she is the most heavy-handed writer of the 20th century, after all), but profit as the primary motive of a business can easily corrupt or destroy any other values the company has.

Twitter seems to be following the standard arc of a startup, especially in the Internet age: a group of inspired geeks build something cool, it becomes a hit, venture capital comes pouring in, the founders sell out and “management” moves in, the focus of the company shifts from building something cool into turning that cool thing into a way to make money, the thing ceases to be cool (or even very useful), people move on to the next big thing, the company dies a slow death.

We’ve seen it plenty of times before (again, MySpace), but with Twitter something seems different. Twitter has become a deeply ingrained part of the Internet experience for its loyal users in a way that no other product from a for-profit business has before. It’s as essential to how many of us experience the Internet on a daily basis as email or the web itself. But while it’s just as essential, its essence is entirely different. And now the foolishness of investing so heavily and personally — in time and passion, not money — in this kind of product is becoming painfully obvious.

So, what are our alternatives? This summer, Adam Curry (yes, that Adam Curry) wrote about the value of RSS as a Twitter alternative. I think for one way Twitter is used (as a means of disseminating links to interesting news/blog posts), RSS is great, and I am a die-hard RSS user along with Twitter. But RSS can’t replace Twitter’s role as a microblogging platform.

Enter Dalton Caldwell’s (remember him?) App.net. What is App.net? It’s basically an effort to do Twitter right. For a small annual subscription fee, you get access to an ad-free social network that functions almost identically to Twitter. (The main distinction: each post is limited to 256 characters, rather than 140. Those of us who do a lot of work with databases are probably thrilled with the implications of that particular number.) Many of the geeks who were early Twitter adopters are now prominent members of the App.net community. Many of the developers of third-party Twitter clients have gotten on board with App.net sibling apps (like Netbot).

Personally, I was one of those App.net early adopters (member #5,644). But I will admit I’ve found it hard to break my old habits of working mainly with Twitter. Partly that’s because I’ve relied on Twitter’s functionality as the glue between my various social networks. I can post photos on Instagram and, via my existing Twitter-to-Facebook link, easily share my photos to both social networks with a tap. I used to have LinkedIn in the mix too, before I more-or-less abandoned it. The point is, up to now Twitter has been a geek’s paradise of a social network, with a wealth of APIs that could be used in innovative ways to do all sorts of cool things.

But Twitter doesn’t want us to do all sorts of cool things. They want us to do the things that put our eyeballs on their sponsors’ messages, because that’s the only way they’ve been able to think of (or willing to try) to make money. I would gladly pay a subscription fee for Twitter, to cut out the ads and retain access to those awesome APIs they’re so aggressively shutting down. But since they’re not interested in taking the business in that direction, a door has been opened for App.net to do all kinds of things Twitter could have done, but, it now appears, never will.

Why I’m voting no, twice (and I think you should too)

Tomorrow, finally, is Election Day. One of the most excruciating and interminable campaign seasons in modern memory will in a matter of hours be behind us. But the decisions we collectively make tomorrow will shape our state, our nation, and our world for years or decades to come.

Everyone who cares at all about any of this is watching the presidential race, to be sure, but here in Minnesota the big story is two proposed amendments to the state constitution. I believe these amendments are deeply, profoundly wrong for our state, and I will be voting NO on both. Here’s why.

The Marriage Amendment

The marriage amendment would insert a sentence into Article XIII of the state constitution, which would read as follows:

“Only a union of one man and one woman shall be valid or recognized as a marriage in Minnesota.”

What does this mean, exactly? Well, essentially it means that gay marriage — which is already illegal in Minnesota, by the way, and would remain illegal even without this amendment passing — would be far less likely ever to become a reality in Minnesota, at least in our lifetimes, because it’s a lot harder to change the constitution than it is to change a law.

So, why should gay marriage be legal? I’m not saying it should. (Well, OK, I am saying it should, but that’s not on the table here.) The legality of gay marriage in Minnesota isn’t even the question. By changing the constitution as such we are saying two things:

1. We don’t want to recognize legal marriages from other states where gay marriage is currently allowed.

2. We want to take away from future generations the right to decide the legality of gay marriage for themselves.

This last point is key to my larger argument about what’s afoot with both of these amendments, but I’ll get to that in a minute. For now, let’s focus on the impact this amendment will have, specifically on Minnesota’s same-sex couples and their families.

I have friends and neighbors who are in committed, long-term same-sex relationships. They own houses together, they have kids together, they will grow old together. They are great friends and neighbors, and they are just like our family, except for the genders of the adults in the household. That difference doesn’t change the love they feel, or the commitment, or their engagement with the community. But it does affect a lot of things large and small in their daily lives and long-term futures that heterosexual couples take for granted. Buying a house together. Having kids together. Paying taxes. Getting health insurance. Sending the kids to school. Growing old together. Visiting each other in the hospital. Saying goodbye. Every step in the journey of life is met by unnecessary hurdles and challenges, simply because of who they are.

Sound familiar?

Imagine if in the 1940s Minnesota had passed a constitutional amendment banning interracial marriages. Seems pretty absurd today. Well, in another couple of decades this constitutional amendment will look just as absurd — unless it passes tomorrow. Then it will endure as the law of the land. This is a civil rights issue, and on civil rights, though we have struggled mightily along the way, our nation has always moved forward, not backward. Let’s not start now.

Voter ID

The text of the question on tomorrow’s ballot pertaining to voter ID reads as follows:

“Shall the Minnesota Constitution be amended to require all voters to present valid photo identification to vote and to require the state to provide free identification to eligible voters, effective July 1, 2013?”

Seems logical and fair, right? Many of us, in fact, are quite surprised when we arrive at the polls and we don’t need to show a photo ID already. Instead, we simply state our name and address, the volunteer looks us up in a big binder, and we sign on a line next to our name, indicating we’ve shown up to vote already, so we can’t come back again later.

Curious. Why aren’t we required to show a photo ID to vote? And why shouldn’t we be? The answer is quite simple: Not everyone who has a right to vote has a photo ID. Senior citizens, full-time students, low-income residents who don’t own a car… these are just a few of the groups of people who do have a right to vote in Minnesota but may very well not have a valid form of state-issued photo identification.

But wait, you say, the text of the proposal specifically stipulates that the state must provide free photo ID to all eligible voters. Problem solved.

Great… how will that be implemented? What is the process for these citizens to properly identify themselves to obtain the ID? Where will they go to get their pictures taken (and how will they get there)? Who will pay for all of this? (“Free” is great but this is going to cost somebody some money, probably a lot.)

So here we have two arguments against the amendment already: 1) plenty of eligible voters don’t presently have a valid photo ID, and 2) the process by which those voters would obtain said ID is not specified, nor is there any consideration of the cost of this unfunded mandate.

But before we even bother addressing those two arguments, let’s go back to the beginning: ostensibly the goal of this amendment is to reduce voter fraud, specifically in-person voter impersonation (which, after all, is the only type of voter fraud photo ID could possibly prevent). Plenty of information has come forth this year indicating this type of fraud is “virtually non-existent”. This amendment is a solution in search of a problem.

So if voter impersonation is virtually non-existent, and photo ID would place an undue burden on both voters (at least, a subset of voters, who typically tend to lean heavily Democratic) and on state and local government (and, indirectly, on taxpayers, who would need to fund the process), then what really is the motivation behind this amendment?

In fact, what is the motivation behind both amendments?

What is the motivation behind these amendments?

Up to this point I have focused on the details and implications of the amendments themselves in explaining why I am against them, but I don’t think we can honestly discuss the nature of these amendments without addressing the climate in which they were created.

In 2010, as part of the “Tea Party” movement that swept over America in the midterm elections, Minnesota wound up with its first Republican-majority state legislature in… well, as long as I’ve been alive, at least. The Tea Party movement was ostensibly, like the Boston Tea Party which inspired its name, about taxation without representation, or at least something about taxes. Small government. The kind Grover Norquist wants to be able to drown in a bathtub. The kind that stays out of people’s private lives and just does what the government is supposed to do, which is… you know… the military, and… well, that’s about it.

Given the stated motives of the Tea Party, I find it curious then (OK, not really so curious, since I’m not so ingenuous) that the only readily apparent accomplishment of Minnesota’s Tea Party legislature in the past two years has been to foist these two stinking amendment proposals upon our state, which in my lifetime was still a bastion of 20th century midwestern progressivism. (When I worked downtown I would gaze with pride every day upon the statue of Hubert H. Humphrey in front of City Hall. The statue is life-sized, because Humphrey was a man of the people.)

Neither of these amendments has anything to do with what, as I understand it, the Tea Party movement — or small-government, libertarian-leaning Republicanism in general — is supposed to stand for. These amendments are regressive, invasive social engineering at its worst. Sure, you’re letting “the people” decide. That’s democracy, right? But with incomplete and deliberately misleading information, and only a simple majority needed to pass, the Tea Party has seized upon its brief window of opportunity in the legislature to push their backward-looking agenda through before it’s too late. They’re desperately trying to save a vision of a fading “golden age” in America that never really existed, unless you were upper-middle class, white, heterosexual and healthy.

And this is where these amendments come back to the presidential election, too. This year’s election is, perhaps more than any other — even 2008 — a fork in the road the country will take for the rest of our lifetimes and beyond. Are we moving forward, or are we moving back? That’s the choice we’re making tomorrow. But really, it’s a false choice. Because “back” isn’t there anymore. (And, honestly, it never was.)

To learn more about the VOTE NO movement for both amendments, please visit mnunited.org and www.ourvoteourfuture.org.

Responsive Web Design: A Practical Approach (Part One… Again)

With exactly three posts here all summer, the last being nearly two months ago, it might be reasonable to assume this blog had been abandoned. Wrong! I have simply been so busy, building so many responsive websites, that I haven’t had time to gather my thoughts to share in anything longer than 140-character bursts.

“‘Responsive’ websites?” you say, and I hear the internal quotation marks in your voice. Yes. If you don’t know what responsive web design is… well, let’s be honest. You found this post, if you found it at all, when you googled “responsive web design” so I suspect you have at least a passing familiarity with the term. So let’s get started.

(Actually, before we get started, a quick note: astute observers may… um… observe that I wrote a seemingly identical post to this one back in June. And yes, that’s right. But after a summer immersed in this stuff, rather than continuing from there with “part two” it felt better to start over from the beginning with a more in-depth introduction.)

Getting Started, or, rather: How I Got Started

I’ve owned an iPhone for about 4 1/2 years now, and one of the first things I noticed shortly after it became the hottest thing around was that everyone was suddenly creating mobile websites. There were even services created just to help you convert your website into a mobile website. But it was always a separate experience (usually with a domain name that started with m.) and invariably an inferior one.

A lot of websites still do that, and it still sucks. It’s two separate websites, which is bad for users — often content doesn’t make it to the mobile site, and when that happens there’s no easy way to get to it on the desktop version — and it’s bad for site owners — double (or more) the work.

But about a year ago I started to notice a new approach, one that didn’t require two separate websites, and one that, owing partly to how quickly it caught on with the superstars of web design, usually yielded much better looking results: responsive web design (which I will henceforth lazily refer to as RWD). RWD uses CSS3 media queries to detect the window/screen size the page is displayed on, and changes the layout of the page to suit the screen. On the fly. Same page. Same CSS.

So there is no mobile site, no desktop site. There’s just the site. And it looks great on any screen.

In theory.

Of course, this solution is not perfect. But it is better in so many ways — standards compliant, future-proof, user-friendly, easy to maintain — that it is clearly the optimal solution for mobile websites today.

Getting Started (you, this time)

Before you delve into RWD, there are a couple of things you need to know: 1) HTML5 and 2) CSS3. More specifically, you need to embrace the concept of semantic HTML fully, as a well-structured HTML document is essential to the responsive approach.

I assume if you’re thinking about RWD, you’ve long since abandoned table-based layouts, and you probably don’t even remember the <font> tag existed, right? Right. But for RWD to work well you need full separation of your visual design from your document structure.

My personal preference is to take this to an extreme: I never even use <img> tags except in body content. All visual elements of the layout are contained in my CSS, even logos, and I avoid using images wherever possible. By taking full advantage of the visual effects offered by CSS3, and accepting “graceful degradation” in older browsers (or, in reverse, “progressive enhancement” in newer ones) — a topic we’ll get to in a bit — you can create a lean, well-structured site that is ripe for the responsive treatment.

Building Blocks

Nothing starts from nothing. (Whoa, that’s heavy.) And certainly a responsive website doesn’t (or generally shouldn’t) start from scratch. There are three building blocks that I now include in every site I build out:

reset.css

Created by CSS guru Eric Meyer, reset.css is a handy little file that removes all styling, which can vary between browsers, from all HTML elements, allowing you to “reset” the design and start with a clean slate. Just remember that it means you’re going to have to redefine everything — I guarantee your CSS file will eventually contain strong { font-weight: bold; } and em { font-style: italic; } but that’s the price you pay for complete control.

html5shiv.js

Developed (or at least maintained and expanded upon) by Remy Sharp, the purpose of html5shiv.js is to enable support for new HTML5 elements in older, but still widely used, non-HTML5 browsers like Internet Explorer 8 and earlier. You don’t have to use the new tags like <article> and <nav> to do RWD, but it’s fun, and feels like the future.

jQuery

There are a handful of popular JavaScript libraries out there whose goals are generally to 1) standardize inconsistent JavaScript across browsers, and 2) make working with the DOM easier, so you can do cool, standards-compliant, cross-browser compatible animations and interactivity with just a line or two of code. jQuery is arguably the most popular of these, and is my personal favorite. Again, this is not strictly required for RWD, but I use it all the time, and often in ways that enhance the capabilities of my responsive layouts. (One specific example: it’s great as a foundation for resizing complex elements like slideshows… of course, for that matter, it’s great for making the slideshows in the first place.)

Finding Your Break(ing) Point(s)

The grand vision of pure RWD is a fully fluid layout that scales dynamically to any screen size, and a grand vision it is indeed. But we are living in an imperfect world, with many factors to consider.

In my case, I typically work with outside designers. Designers who appreciate and support RWD but are not immersed in its intricacies like I am. And I don’t want them to have to be. So as a hybrid developer-designer, I make use of my somewhat unusual but not especially unique skill set to handle the responsive adaptations for them. They just deliver a “regular” web design to me, I build that out, and then I adapt and scale and shift things around as needed for the smaller screen sizes, doing my best to stay true to the spirit of the original design.

There are two keys to making this approach work:

  1. Get the designs in Illustrator format, not Photoshop. (No, seriously. You’ll find out why in a bit.)
  2. Be prepared to start thinking about break points and accept that a perfectly fluid layout is not in your immediate future.

To understand break points, you need to understand common screen dimensions. You also need to understand the importance of margins to an aesthetically pleasing layout.

For years the target screen size for web design has been 1024×768 which, delightfully, is also the effective resolution of the iPad. (Yes, the newer iPads have a high-resolution “Retina Display” which is 2048×1536, but CSS pixel measurements are “pixel-doubled” on these displays, so you don’t really need to think about high-res too much, except when it comes to images, and we’ll discuss that in a minute.)

So, we can (still) start with 1024×768. But that doesn’t mean your design should be 1024 pixels wide. You need margins, both for stuff like window “chrome” (borders, scrollbars, etc.) and also just to give your content a little breathing room. A commonly accepted standard width to use for web designs is 960 pixels, and I still stick with that.

This can sometimes cause some confusion for designers who are used to the fixed palette of a printed page. Your content can/should go all the way to the edges of that 960-pixel layout, and you still need to think about what comes outside of that area. So it’s good when you’re designing to think of foreground and background. Have an arbitrarily huge background canvas, with a 960-pixel-wide by whatever-pixel-tall box floating top-center over it, where your foreground content will go.

But I digress. We start with 960. That’s our maximum break point. (OK, if your audience is primarily looking at the site on 30-inch displays, you might want to consider an additional larger break point at 1200 or so.) Then we move down from there. I like to think of it like this:

Device/Screen Type Screen Width Content Width #wrapper CSS
Large computer displays (optional) 1280 and up 1200 margin: 0 auto;
width: 1200px;
Computer/iPad (landscape) 1024 960 margin: 0 auto;
width: 960px;
iPad (portrait) 768 720 margin: 0 auto;
width: 720px;
Small tablets/phones Varies Fluid margin: 0 auto;
width: 90%;

The “small tablets/phones” layouts typically collapse to a single column and are the only truly fluid layouts I use; the larger break points go to fixed widths, which makes for easier scaling of columnar content.

Note that I typically follow the convention of placing everything inside my <body> tags inside a <div id="wrapper"> tag, which allows me to apply CSS to the overall page body and separate CSS to the foreground content (what’s inside the “wrapper”).

Occasionally I will split “small tablets/phones” into two separate break points, with small tablets somewhere between 500 and 640 pixels. I may also change the content widths somewhat to suit the specifics of the design.

Mobile-First Sounds Great, but Let’s Be Honest: It’s Really IE8-First

Earlier in the year, Luke Wroblewski took the idea of RWD a step further with his inspired vision for Mobile-First web design. Initially I wholeheartedly embraced mobile-first, but I’ve since reconsidered.

What is mobile-first? It’s RWD, but instead of starting from the desktop layout and using CSS3 media queries to adjust the layout to smaller screens, it starts from the small screens and works its way up. The main benefit of this approach is that it allows you to prevent mobile devices from loading unnecessary assets (images, etc.) that they won’t actually use.

There’s a major downside to mobile-first, however, at least in my experience trying to implement it: there are still a lot of people using Internet Explorer 8 (and earlier), which does not support CSS3 media queries. So unless you create an IE-specific stylesheet (using conditional comments), IE8 and earlier users will be stuck with a strange variation on the phone version of your site.

So after building a few mobile-first RWD sites, I have abandoned that approach, and gone with what could be called an IE8-first approach. I am not really building to IE8. I work primarily on a Mac, and I preview my work in Chrome while I’m developing. But what I mean is I’ve gone back to that standard 1024×768 screen as the baseline for my CSS, with CSS3 media queries for the smaller screen sizes (as well as for print and high-resolution displays, the latter of which is next up).

Getting Retinal

Remember earlier when I said your designs should be in Illustrator rather than Photoshop? Here’s why: high resolution. Sure, you can change resolution in Photoshop too, but… wait, you’re not still slicing-and-dicing, are you? By working with discrete objects in Illustrator, resolution-independent and, when possible, vector-based, you have the maximum flexibility when you render these objects out as 24-bit PNGs with alpha channel transparency. (You are doing that too, right?)

Starting with the iPhone 4, Apple introduced the “Retina Display” which is their marketing term for, basically, screens with pixels too small for you to see. The goal is to achieve a level of resolution on an LCD screen that rivals print. The exact pixels-per-inch varies from screen to screen, and is not really too significant. The key point is that above a certain pixel density threshold, CSS treats all pixel-based measurements as pixel-doubled. As I noted above, although the current iPad screen resolution is 2048×1536, its effective pixel size in CSS is still 1024×768. There is a practical reason for this (if CSS stuck with the actual pixels, all web pages would appear absurdly tiny on such a screen). But there’s also a practical downside: most images on most web pages are now being scaled up in the browser to these pixel-doubled dimensions, resulting in a blurry appearance.

But here’s something really cool: you can specify the display dimensions of an image in CSS, and the browser will scale the image down on-the-fly. This has been the bane of many web developers’ existence for years, where people who didn’t know better would upload a very large, high resolution photo and scale it down in the page, resulting in ridiculous download times as the image slowly drew in on the page.

Used effectively, however, this characteristic provides an extremely easy way to make images high-resolution on displays that support it. By using CSS to scale the dimensions of an image to 1/2 its actual pixel size, the image will display in full resolution on screens that support this.

Of course, doubled dimensions mean quadrupled pixels, and depending on the details of JPEG or PNG compression, the high-resolution images may be more than four times the file size of their standard-resolution equivalents. So it’s nice to, again, use CSS3 media queries to only deliver these high-resolution replacement images to screens that can display them properly. (This will be demonstrated in the full example code below.)

You Say Graceful Degradation, I Say Progressive Enhancement

The matter of graceful degradation and/or progressive enhancement (depending on how you look at it) is tangential to RWD, but it’s something you’re likely to be dealing with as you build a responsive website.

Not all browsers support all CSS3 capabilities, but that doesn’t mean you shouldn’t use them. I’m especially fond of box-shadow and border-radius, and in working with RWD you’ll probably get quite familiar with background-size as well. Remember that most of these newer capabilities will probably need to include vendor prefixes (like -moz- and -webkit-) as well. It’s cumbersome, and will probably be as painful to clean up as <blink> tags in a few years, but for now it’s the way to get things done.

The biggest challenge with progressive enhancement may well be convincing site stakeholders that it’s OK for the site to look (subtly) different in different browsers. Then again, if you’re doing RWD, that should be a given.

So, What Does This Actually Look Like?

As I’ve iterated my RWD approach this summer, I’ve inched closer and closer to a standard template I can use to start a new website. I feel it’s not quite there yet, but my basic CSS file structure is standardized enough that I can share it here. In a subsequent post, I hope to provide a zip download containing a full template file set for creating a new responsive website.

Here’s a rough example of what my typical CSS file looks like. Again, personal preferences dominate here: I like to write my CSS from scratch, and I typically organize it into three sections: standard HTML (basic tags), CSS classes (anything starting with a period), and DOM elements (anything starting with a hash mark).

The idea is that we’re going from general to specific. Within the standard HTML and CSS classes I alphabetize everything, so it’s easier to find things to change them as I go. Within the DOM elements I try to keep everything in the order it actually appears in the HTML structure. (I also alphabetize the properties within each element definition… but that’s just because I’m anal retentive.)

Sample CSS File

/* IMPORT */

@import url('reset.css');

/* STANDARD HTML */

body {
  font-size: 100%;
  line-height: 1.5em;
}

/* CSS CLASSES */

.column {
  float: left;
  margin: 0 5% 1.5em 0;
  width: 45%;
}

/* DOM ELEMENTS */

#wrapper {
  margin: 0 auto;
  width: 960px;
}

#logo {
  background: transparent url('img/logo.png') center center no-repeat;
  -moz-background-size: 250px 100px;
  -webkit-background-size: 250px 100px;
  background-size: 250px 100px;
  height: 100px;
  width: 250px;
}

/* CSS3 MEDIA QUERIES */

/* PRINT */
@media print {

  * {
    background: transparent !important;
    color: black !important;
    text-shadow: none !important;
    filter: none !important;
    -ms-filter: none !important;
  }
  @page { margin: 0.5cm; }
  h1, h2, h3, p { orphans: 3; widows: 3; }
  h1, h2, h3 { page-break-after: avoid; }
  pre, blockquote { border: 1px solid #999; page-break-inside: avoid; }
  abbr[title]:after { content: " (" attr(title) ")"; }
  a, a:visited { color: #444 !important; text-decoration: underline; }
  a[href]:after { content: " (" attr(href) ")"; }
  a[href^="javascript:"]:after, a[href^="#"]:after { content: ""; }
  img { max-width: 100% !important; page-break-inside: avoid; }
  thead { display: table-header-group; }
  tr { page-break-inside: avoid; }

}

/* LARGE TABLETS (UNDER 1024 PIXELS) */
@media screen and (max-width: 1023px) {

  #wrapper {
    width: 720px;
  }

}

/* SMALL TABLETS/PHONES (UNDER 768 PIXELS) */
@media screen and (max-width: 757px) {

  #wrapper {
    width: 90%;
  }

}

/* HIGH-RESOLUTION DISPLAYS */
@media only screen and (-moz-min-device-pixel-ratio: 1.5),
    only screen and (-o-min-device-pixel-ratio: 3/2),
    only screen and (-webkit-min-device-pixel-ratio: 1.5),
    only screen and (min-devicepixel-ratio: 1.5),
    only screen and (min-resolution: 1.5dppx)
{

  #logo {
    background-image: url('img/logo_x2.png');
  }

}

The Test Suite

Of course, all of this work means nothing until we’ve seen what it actually looks like in the web browsers on these different devices. To that end, a decent test suite is essential.

One cool trick about RWD, which is not only useful to dazzle clients when pitching a RWD approach to their websites, but is also helpful for quick testing as you go, is that the responsive approach works simply by making your browser window smaller on a computer. So you can shrink the window down and approximate what the site will look like on a tablet or a phone without actually having one in your hand at all times.

But before you go live, you do need to test it for real on different devices, just like you need to test in different browsers. The table below shows my test suite. It’s not comprehensive, but it’s practical, and it all fits in one small messenger bag.

Device Operating System Browser(s)
MacBook Air Mac OS X Mountain Lion Chrome (latest)
Firefox (latest)
Safari (latest)
MacBook Air
with Boot Camp		 Windows 7 Internet Explorer 9
Chrome (latest)
Firefox (latest)
MacBook Air
with Parallels Desktop		 Windows XP
(3 separate virtual machines)		 Internet Explorer 8
Internet Explorer 7
Internet Explorer 6
Firefox 3.6
Note: I only offer my clients very limited support for IE6.
iPad (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
iPhone (Retina Display) iOS 6 Mobile Safari (latest)
Chrome (latest)
Samsung Galaxy Player 4
(high-resolution)		 Android 2.3 Android web browser

Give Me Something I Can Print!

You may have noticed in the full example CSS above that I included CSS3 media queries for print. The need for decent print output will vary by project — different sites’ audiences may be more or less inclined to print out pages. In general I think of printing out web pages a bit like I think about… well, honestly, I can’t even think of a good analogy. You just shouldn’t do it. But sometimes it has to happen. I won’t be exploring the infuriating nuances of print CSS here, other than to say that if you do need to support printing, the code provided in this sample is a good place to start. (Sadly, although I use it regularly, I neglected to make note of its source. If you know where it’s from, please let me know in the comments.)

Where Do We Go Now?

OK Axl, hang on. I know I’ve dumped a lot on you here to think about, without necessarily providing enough specifics. But that’s kind of the point: in order to do this right, you really need to learn it for yourself and gain the experience of building RWD sites directly. This is what has been working for me but my approach is certainly neither the only nor the best way, I’m sure.

My hope is to follow up this post with a “Part Two” entry this time around, where I get into more of the specifics of an actual example website. In the meantime, experiment and discover! And be sure to check out the entire A Book Apart series, as they provide the conceptual and detailed knowledge needed to get started with this exciting new approach to web design.

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.

Sleep is now available

We all need more Sleep, right? Now you can download my latest album for free from Bandcamp.

Sleep began as a concept for my 6-year-old daughter. Last November, she asked me to record an album for her to listen to as she fell asleep. The first track I recorded at the time was what became “Rapid Eye Movement,” and she immediately declared it a failure… it was too creepy for her to fall asleep to, she said.

I quickly realized that any album I made about the concept of sleep was going to veer off into dark and mysterious territory not suitable for peacefully lulling a 6-year-old off into dreamland. And maybe that’s the point. Sleep is not just peaceful rest. It’s a dark and strange landscape where our minds confront their deepest fears and desires, where our subconscious comes out to play… or to wreak havoc. Sure, there are also moments of peace and bliss, but sleep is many different things, sometimes all at once. This album seeks to capture the essence of sleep in all its complexity.

After my daughter wrote off the album, I largely did too. Or so I thought. But over a period of months I accumulated a grab bag of musical sketches and partially-complete tracks, composed primarily late at night on my iPad as I lie awake in bed. Then in mid-June, my 9-year-old son drew a surreal picture he called “The Super Weird Face.” It had a strange, dream- (or nightmare-) like quality. Immediately I knew it was the cover art for the album, and it inspired me to collect all of these stray musical ideas I had been working on and turn them into the final collection of 17 tracks that comprise the finished album.

My one sentence summary is this: The album is a sonic journey into, through, and out of the landscape of sleep and dreams.

Please have a listen and let me know what you think! (If you really like it, you can also buy the CD for $8.99 from Kunaki.)

Front cover art

Insert art

Jewel case back tray art

CD print art