Jason Kottke’s recent post The iPhone, an automobile for the mind, discusses the same Steve Jobs anecdote on man as a tool maker, that I used last week in Reset the Web. Jason points to a different—and much later—source of this story, illustrating how Steve Job’s ideas evolved as Apple developed.

My source was this video from 1980 which was posted as part of a Computer History Museum archive on Steve Jobs. I’m not sure who Steve is talking to in this presentation, but it feels like a local meetup somewhere in the valley. He arrives a bit late, complains about problems finding parking, then begins to describe the challenges of designing something completely new…all the while not really knowing what people will use it for.

This later interview is the one Jason pointed to. It’s an excerpt from the documentary Memory & Imagination. By this time, the bicycle story feels far more scripted.

I personally prefer the first video as Steve almost seemed to be thinking out loud…trying to explain (to the audience, and maybe to himself) why he felt the products Apple was building were so special, and why something truly remarkable would happen once everyone had one (…a computer that is…not a Mac ).

Still, it must have been hard back then to truly grasp what might happen next.

Musing about the future is always tricky when you’re so embroiled in the present. In a recent interview, Kevin Kelly (founding editor of Wired) said that initially, people thought the web would be “like TV, but better”. Looking back, this seems quite naive but i’m not sure that much has changed. Even today, do we really know what the web will be going forward?

I increasingly feel that we may be stuck in somewhat of a nether world when it comes to the web. We know the web is important. We want all the stuff the web has been good for so far, but we also want the stuff we think it will be good for later (or have felt was missing so far). All the while, we still frequently disagree on what those things actually are (and can only even conceive of them based on mental models we currently have).

“We look at the present through a rear view mirror. We march backwards into the future.” —Marshall McLuhan

Meanwhile, (with or without us?) the web marches on.

We may not really know what the web will become, but i’m pretty sure it’s one of the most pervasive amplification tools man’s created to date…affecting just about every human activity we can think of (the good as well as the bad ones).

And with another two thirds of the planet still set to come on line, the web is really just getting started.

“Nobody has any idea of what a new invention will really be good for. The crucial question is, what happens when everyone has one?” —Kevin Kelly, for the New York Times

A few days back Luke Wroblewski posted an excellent article outlining the pros and cons of Responsive design, standalone device experiences, and RESS (Responsive Web with Server Side Components).

This much needed (and long overdue) conversation is a bit like the web vs native debate. There is no single correct answer, and the choice you make will depend on a host of factors, including budget, content type, audience, usage patterns and overall business goals.

What was not implicitly said in Luke’s article (and I think bears discussion) is that choosing responsiveness, as a characteristic shouldn’t necessarily define the wider implementation approach. Device Experiences (i.e. standalone sites, aimed at a group of devices) can also be responsive, providing the flexibility to support a much wider range of devices. While this on the one hand seems obvious, far too many sites still design either a single width or generically stretchy web site.

Aligning business models with user journeys

For Netflix, Amazon, the BBC and other digital-first (or digital-mostly) companies, the need for device-led experiences may be quite clear. With business models that rely on digital (discovery, purchase, delivery, and consumption), the choice of device cannot help but intimately affect the experience. These companies also understand that—especially in this day and age, that media consumption is rarely linear. Ensuring the best experience regardless of the device (or stage in the consumption journey) is therefore critical to their business.

For a whole host of other organizations (e.g. government and municipal services, educational institutions, manufacturers of physical products, experience and destination companies) the correlation between device class and engagement may be far more nebulous. It may therefore pay to first prioritize access and usability….and let usage inform what future “best experience” groupings might consist of. (Worth noting that in some cases, the best experience may have nothing to do with the web at all).

Standalone…but responsive

For these types of organizations, a standalone, yet responsive site could be an ideal strategy. A strategy that isn’t specifically defined by a type of device (smartphone, tablet, desktop, TV, automotive) but by the growing need to enable pathways between our physical and digital experiences.

Responsive sites can be fantastically versatile, especially when they are conceived—and in this case even remain—mobile first (…or mobile-only). A smartphone appropriate layout can easily morph into a tablet appropriate one—all the while remaining lightweight, as the site was conceived that way to begin with (…a cheeky but sometimes viable way to side-step the responsive image problem).

Choosing a responsive design also acknowledges that device groupings are (and likely  will remain) messy and prone to interpretation. Is a (physically) large, handheld, call-enabled device with a resolution around 1280 x 800 considered a phone or tablet? Does the essence of the device somehow change once it’s paired with a TV, and interacted with from across the room? Or maybe paired with a keyboard, and interacted with for much longer sessions? And how should we consider the emerging class of mini-computers, designed to work with whatever screen and interaction mechanism you plug them into?

Mobile is an opportunity to reboot

Developing a standalone (but responsive site) provides an ideal opportunity for learning and experimentation. It enables you to re-focus your content, lighten and streamline your experience, and deliver real user value—without the (often all too real) burden of re-structuring your entire legacy web site.

Besides…a funny thing tends to happens when you engage in a project that compels you to work both responsively, and mobile-first. Somewhere along the way, it changes the way you think—all too often illustrating how out of touch that (legacy) thinking was to begin with. It also sets you down the path to change…but does so gradually, through engagement (and discovery), rather than dogma.

(A bit like that old saying about teaching a man to fish…)

This is vitally important people so listen up. The web now connects a third of our planet. Over 1.2 billion people [1] use the web on devices, and this number is rising fast. Mobile already amounts to close to 6.5% of web traffic worldwide, and large sites such as Facebook and YouTube routinely report mobile traffic of at least 30%. By 2015, the ITU predicts mobile traffic will exceed desktop traffic and the ‘mobile-mostly’ group already make up a staggering 20% of users in the US and UK.

For this ubiquity to truly benefit all of us (not just those of us with a high income, or the latest phone) we have to start building sites using solid, future friendly principles such as progressive enhancement…not just when it’s handy or simple, but all the time. Here’s a very timely example of why…

Last night Brad Frost posted a picture of the lovely sliding side menu contraption on Barack Obama’s new responsive campaign site. As shown in the image below, It looked quite nifty. You tap on the icon next to the word Menu, and the menu slides open from the left hand side. So I decided to try it out on my iPhone 4.

And the menu failed. Never even opened. Suddenly, the site was without navigation…at all.

On a hunch, I tried it on a handful of popular devices. The results were pretty devastating. These are the browsers (and devices) where the menu worked as expected.

• Galaxy Nexus (hot off the assembly line last week with Ice Cream Sandwich and a mobile version of Chrome)
• iPhone 4 (with iOS 5)

These are the ones where it didn’t.

• iPhone 4 (with iOS 4.3.5…the prior version of iOS)
• iPod Touch (still very popular, especially with youth)
• Nexus One (old but top of the line Google reference device in its day)
• Nokia Lumia 800 (brand new Windows Phone 7 device with Internet Explorer 9)
• HTC ChaCha (popular QWERTY phone with dedicated Facebook button and Android 2.3.3 )
• HTC Wildfire (very popular mid-range phone with Android 2.3.3)
• Huawei Blaze (brand new, £50 phone with Android 2.3.5 )
• Galaxy SII (top of the line device with Android 2.2.3)
• Galaxy Mini (cheap, low-spec phone with Android 2.2.1 )
• Blackberry 9810 Torch (one of their newest devices with WebKit-rich Browser 7.0)
• Blackberry 9300 (a slightly older 6.0 device with a WebKit browser)
• Galaxy Tab 7″ (first generation tablet with Android 2.3)
• Galaxy Tab 10″ (second generation tablet withAndroid 2.3)
• Amazon Kindle Fire (proxied Amazon Silk browser)

These devices are pretty new. With the exception of the Nexus One and the older Galaxy Tab, all these devices are for sale in the UK right now. Most are also for sale in the US. And at least four of these are top of the line, flagship devices for their brand. And to be clear, the menu wasn’t merely a bit flaky on these devices. It never opened at all (and this is a big, presumably important menu…with 20 sub-navigation items).

On all devices except the Galaxy Nexus, Kindle Fire, and 10″ Tab, at least a third of the content also loaded offscreen, resulting in a perpetual horizontal scroll. To make matters worse, the viewport meta tag had been set to ‘maximum-scale=1′ [2], preventing most browsers (and therefore users) from zooming to temporarily rectify the horizontal scroll issue.

We also tried the site on some lower end devices (70% of the US and about half the UK still use feature phones) but gave up. The site was too heavy and complex to render gracefully on many of these devices. (And incidentally didn’t load at all past the ‘splash page’ using Opera Mini on the iPhone).

This on a site whose goal was to reach as many Americans as possible, regardless of age or income level. As it stands the site only appears suitable for the Google staff who received a Galaxy Nexus for Christmas, and the maybe 5% [3] of Americans who own (and have recently updated) their iPhone.

I can’t speak to exactly what’s causing the menu to fail, but I can take a pretty good guess. I’m also fairly sure that a progressive enhancement approach (combined with a good dose of testing) would have solved (and certainly uncovered) all the problems we encountered. As a matter of fact, we’ve recently been working on a (still to be launched) client project with a similar (but far simpler) collapsible, sliding menu and went to great pains to ensure things like this didn’t happen.

First, we built the menu to fail gracefully. In this case, it meant building a menu that was open by default, and only closed once the page had loaded. If the JavaScript failed, the menu would simply never close. It might not look terribly graceful, but it would still be fully usable (to navigate…not to slide open and shut triggering fancy animations…that’s not the menu’s actual job.)

Secondly, we built the menu using ‘normal’ JavaScript rather than jQuery, as we’ve found jQuery still doesn’t work reliably across the devices we need to support [4]. We also tested the JavaScript based functionality all the way back to dinky, underpowered little phones like the Nokia N95. This served as a reality check and helped further minimise our points of failure. If it works on a 5 year old browser, it’s considerably less likely to fail on today’s devices.

And finally, we identified browsers with inadequate levels of JavaScript or DOM manipulation support and served an entirely different menu to this group. We swapped this out server side to ensure these devices didn’t receive the JavaScript at all, and newer devices didn’t have the client-side burden of negotiating the switch from one menu to the other. Incidentally, we also built the site ‘mobile-first’ (i.e. for the simplest device first…and no, that device is not the iPhone), so the ‘fancy’ menu doesn’t even kick in until you reach a screen size of 320 px (regardless of whether JavaScript may be supported). This may penalise the tiny number of devices that happen to be below 320 px in width, and have awesome JavaScript, but also minimises the chance that weaker, older devices will try to load the menu accidentally.

Despite all this, we still had issues, namely with general DOM manipulation flakiness and inconsistencies caused by device-specific events such as zooming, reorientation, or adjustment of Zoom settings (especially on Android…and especially on HTC). For this reason, we found that the calculations required to correctly trigger and execute the animation sometimes failed, resulting in an only partially open menu. So in the end, we removed the animation altogether (especially as this problem wasn’t limited to lower-end devices so it wasn’t possible to simply conditionally load the animation based on say…the browser version).

A final problem was the visual disruption caused by a menu that initially loads open, but then quickly closes. To be honest, we still haven’t decided what to do about this. This is a site with a strong accessibility (as in access…) mandate so the idea of shipping a menu that may sometimes never open doesn’t sit well with any of us. So we’re still discussing it. Given this site’s small proportion of traffic from low-end devices, and the measures we’ve taken to ensure the menu will work most of the time, we may still choose to chance it and go the other way.

These are complex problems. Problems that cause us to examine the true goals of what we’re building and very often greatly test our assumptions around the value of design. Even seemingly inconsequential decisions such as constraining the zoom level can have unintended consequences. But progressive enhancement doesn’t just happen. It needs to be planned from the start, then iterated and carefully discussed when things go wrong. And on mobile, the only way to know that things have gone wrong is to test on actual devices. Given that a good 80% of the Android devices we tested displayed content off-screen, we’d be surprised if barackobama.com had been tested on Android at all.

We have an opportunity to make the mobile web a million times more useful and relevant than the desktop web has been. The failure of the Obama site was not in the use of new techniques like responsive design, it was in forgetting that older principles and techniques still have an important role to play in building a better web. If anything, they are more important than ever before. Without progressive enhancement, responsive design is simply a site that looks pretty when you resize your desktop browser. With progressive enhancement, the mobile web truly becomes a tool, capable of reaching and connecting all of us. Which is it going to be?

—————-

[Update Jan 6: I'm happy to report that over the past 24 hours, the site has improved. The animated transition on the menu appears to have been removed. The menu now opens intermittently on my iPhone but during this time, the site is extremely sluggish. On the Android (we only re-tested 3-4 devices), as of this morning the menu opens, but the incorrect viewport is still a problem and now also impacts the menu which on some devices opens partially off-screen. Oddly, on initial load, the viewport is now correct, but within a few seconds it snaps into the wrong state. We'll try testing again next week.]

—————-

[1] A statistic from analyst Tomi Ahonen’s awesomely useful 2011 Phone Book.

[2] We’ve been getting reports of some people not seeing the max-scale value in the meta tag so did some further snooping. See my comments to Nicolas Gallagher below for details.

[3] 5% is an educated guess. Current Nielsen figures show US smartphone penetration at 38%. The iPhone is 28% of that 38%. The number of people with an iOS 5 capable iPhone is smaller, and the number who will have upgraded is smaller still.

[4] See my comments to Scott Jehl for additional context regarding use of on jQuery Core on mobile.

(…reposted from a lengthy comment on Zeldman’s blog…)

“I love “content-out” as a strategy…setting a series of breakpoints based on ems (based in turn on font size) could create lovely context-based layouts that move fluidly from one state to another. They won’t match with device sizes but they won’t be trying to. There is a lot to think about and play with there.”

- Zeldman, State of the Web: Of apps, devices and breakpoints

There IS a lot to think about and designing content-out is quite liberating, but it’s also important to remember why we’re doing this.

Designing content-out works quite well. We’ve used this approach for a while now and have found that if there are wonky/awkward spots when you test by resizing the screen on the desktop, they will in most cases end up just as wonky on devices. An approach that is working quite well for us at the moment is to design using major and minor breakpoints. (More of this in our Pragmatic Responsive Design presentation ).

The major breakpoints create the broad stroke changes that are required when moving from the small(er) screen (‘mobile’), to a much wider one (often a tablet-like device), to an even wider one (often a desktop but increasingly there can be higher breakpoints for TVs etc). These major breakpoints are set using media queries in the document head. The minor breakpoints live within those 2-4 style sheets and provide (mostly) the tweaks needed to remove awkwardness. This in effect creates media queries within media queries and provides huge flexibility while keeping it clear why each breakpoint has been set.

As noted by others in the comments to Jeffrey’s post, these ‘tweaks’ most often include adjustments in font-size, line length, line height, gutters, padding and other elements that make the layout feel more balanced and improve legibility. Other useful tweaks are adjustments of the overall font size to ensure button/menu touch targets and form elements are large enough to manipulate on touch screens. If you’re going as high as TVs, text often needs to be enlarged quite a bit at that size, so changes don’t always follow a predictable upwards or downwards path.

Then you move on to final pragmatic tweaks to ensure nothing is wonky on key devices. (Some people would say you should do this first but I think this just encourages teams to think of it as a ‘device-x site’.) Most sites fall into an 80/20 pattern where you can easily identify the top devices (often a cluster of 10-15 devices which almost always include the iPhone and iPad.) Be mindful however of the remaining 20% which can include 20-30 (+) devices and may easily amount to tens of thousands of users a month.

So while content should always guide the design (which also helps prioritize useful stuff like document flow, markup structure, and information design), the whole process works best as a balancing act between the opportunities and constraints provided by the medium.

When all is said and done, the reason we’re even doing this is because of device diversity, which will likely not go away. We are well on the way to standardizing around WebKit but even if screen sizes also standardize (…big if…more on this in a later post), a device will always remain way more than just a screen size combined with a rendering layer. The problem with the (exclusive use of a) content-out approach is that it may be seen as an excuse for many not to think about the devices at all. As it stands, very few people currently test on actual devices (on actual 2G, 3G, etc networks). There are many reasons for this (cost being only one of them) but as an industry, we’re going to have to move past this somehow.

Testing on devices reveals all sorts of stuff that simply adjusting content never will, and that you won’t see by simply testing by resizing a desktop browser.

1. Without device tests you know nothing of a design’s performance. Most modern CSS effects and techniques still work quite poorly on devices. Web fonts, CSS drop shadows, CSS gradients, CSS animations regularly grind sites to a halt (quite literally…that’s if they don’t crash the browser altogether). Testing on devices provides a reality check of just how far you can push the design and what range of devices it will work on. Sure some of these issues will improve due to better hardware but PCs are pretty advanced and we’re still building poorly performing desktop sites…i’d love to see those go away as well).

2. Device capabilities (e.g. actual capabilities vs the boolean ‘pass’ the browser returns in a JavaScript test) can also only be tested on an actual device. Whether you choose breakpoints based on ‘popular’ screen sizes or not, you will probably end up compelled to use a 320px breakpoint simply because of the iPhone. At this size also sit older (often landscape orientation) BlackBerry devices, many Nokia feature phones and many brand new small, cheap Androids. This throws all sorts of varying capabilities into the mix at what appears to be a very safe, common breakpoint. Eventually some of these devices will go away but if you believe screen sizes will standardize, then it follows that within those common screen sizes there will always be some bleeding edge AND some older or ‘good-enough’ devices.

3. Then comes form factor. It often feels as if new devices only support touch, but at least 30% of smartphones (and closer to 90% of feature phones) still have a keyboard (while others are both touch and type). There is no sign of this changing soon as a touchscreen greatly impacts a device’s bill of materials and a segment of users still prefer physical keys. The presence of any indirect manipulation control (be it keyboard, trackball, arrow keys etc) impacts how interactive elements behave and should be designed.

4. Pixel density now ranges from about 150 to about 300 ppi. That’s a massive crazy difference. Testing on a desktop reveals nothing of this. Many OEMs have reset the browser viewport to preserve legibility but you still end up with all sorts of differences that should be considered in the design process.

5. And finally comes the impact of the network. Latency is obviously a problem, often due to poor connectivity – but factors such as large numbers of concurrent requests from 3rd party services (Facebook widgets, hosted fonts etc) will also impact performance. Of course content itself may also be modified on many networks by server-side ‘tweaks’ and adaptations due to proxies, transcoders and related ‘optimisers’ which are all beyond your control.

Just to be clear, content-out design makes a lot of sense, but we’re going to need a mixture of content, device, and capability-based breakpoints going forward. The only way to develop a good understanding of these factors is to truly begin experimenting with devices, just as we experiment with design.

These devices (and ones we haven’t thought of yet) aren’t just a temporary diversion, they are the new ingredients of the web just as much as HTML5 or jQuery.