Most telling, however, is how the post concludes:

I don’t know what the answer is, but I’m very curious to see what we decide.

I hope that if any of my followers and readers are experiencing RIC (Responsive Image Consternation), you don’t spend a ton of time fretting about it today. I don’t. Because clearly, no amount of analysis or fretting can definitively solve the responsive image issue today.

Most importantly, don’t let the lack of a perfect responsive image solution keep you from experimenting with approaches to adaptive, responsive design for mobile. Why? Because performance is important, but access is more important. Mobile later is better than mobile never.

There’s a lot of talk about performance being key to mobile success, and I can’t deny that. But if you compare viewing a desktop-only design on a mobile device to even a partially improved mobile experience, the issue of images is a complete wash. To do nothing at all for mobile means that people are loading large images on mobile devices anyway. But to do something — anything else — to optimize content, layout, or navigation for mobile means that there is still a net gain. Even if people are still loading full size images.

It’s like taking up running if you’re 10 pounds over your ideal weight. Yes, you can still start running today, and partially optimize the experience by getting some running shoes. Even if you’re not at your ideal weight already. So carry around a few extra pounds if you have to — running will still improve your health, even if your overall performance isn’t as fast as you’d like it to be.

So don’t let RIC get the best of you. Sure, we don’t want people unnecessarily loading larger images than necessary if we can serve smaller versions. But that’s secondary to starting elsewhere with efforts to be adaptive and responsive. Start with things that you know deliver value. Focus on what you know, and deliver minimally viable improvements today instead of waiting for the dust to settle on responsive image approaches. As long as the web continues to be imperfect, our solutions will have to be equally imperfect.

And my prediction on how long that state will persist? As long as we have the web. =)

Yet I always like hunting for nuance, because in debates between “experts”, things sometimes get pretty black and white. So I thought it would be a nice challenge for me to search for nuance in this case, in particular, as someone who never enjoys reading Mr. Nielsen’s suggestions: is there still some merit therein?

Let’s take a look point by point:

JN: “I would assume that most industrial-scale sites would be generated from a single back-end product database and content management system…”

Comment: Well, nothing like starting with an assumption, Jakob. They’re invariably wrong. And I can certainly speak to appearances being nothing like reality. For example, I used to work at one of the largest public universities in the United States. It’s “web site” looks like it must be hosted by some gargantuan CMS, just as Jakob might assume. However, in reality, this industrial scale of web site is actually thousands of web sites, hosted in dozens of different ways. So it is with many large enterprises.

JN: “All of this is really a matter of budgets relative to the expected profits from serving customers better by optimising the user interface to their specific circumstances. Small organisations can’t do so.”

Comment: Well, yes and no. There is a nugget of truth in Nielsen’s observation here, that smaller organizations aren’t necessarily going to pivot quickly and redesign for mobile. But again, this can be just as true for a large organization (commented about above) that is actually a federation of many, many small organizations each doing its own thing.

Moreover, there are degrees of optimization and, in fact, probably should be degrees of optimization. I argue in my second book that some mobile optimization is better than none at all. And when I say this, I don’t mean that an interim solution should ever be accompanied by a proud planting of a flag on the summit of Mt. Mobile. “We did it! Layout and navigation are now responsive!”

Well, great: maybe you start with optimizing layout and navigation in some responsive manner. It’s a fantastic start, but it’s just a start. Though most importantly, in response to Nielsen: small organizations can indeed progressively enhance for mobile. And they don’t need to get it perfect at first (in fact, getting it “perfect” in one pass is a myth anyway). And if that’s easier and faster then starting with an entirely new mobile first approach, that might be the best way to start. It’s better than not starting at all.

JN: “…To treat users well, you should optimise their ability to do tasks with the device at hand. If somebody only has a mobile phone, they are ill served by a design that’s awkward to use on mobiles.”

Comment: Yes.

JN: “Studies show that content is harder to comprehend when viewed through a small viewport with less context than what’s visible on a bigger screen. Thus, we can enhance mobile users’ understanding of the information by writing shorter content that’s easier to understand. What matters is the amount of information in the user’s brain, not the word count on the screen. And people understand more with content that’s optimised for their device.”

Comment: Apparently Nielsen has never read a book on a smartphone. I go through one per week. I would argue that content is harder to comprehend if it’s garbage, badly written or edited, or simply not meeting my needs. Length alone is not a variable that determines whether content presentation is successful.

JN: “There are at least three different ways of implementing different user interfaces for different devices: 1.Each version lives at a different URL, 2. The same URL serves up different versions, depending on the device used to request the page, 3. The same code is transmitted to all devices, and the client side transforms this into the different designs, using responsive design. As long as each user sees the appropriate design, the choice between these implementation options should be an engineering decision and not a usability decision.”

Comment: This may be the most indicting thing that Nielsen says. Since when is an engineering decision not a usability decision?! The disconnection of engineering and usability is utterly ridiculous, and I don’t think even merits additional comment. Anyone who has used differently-engineered products of any kind (IRL or digital) knows that “back-end” engineering decisions have enormous impacts on usability. Enough said.

“.net: Why have you made no mention of using Responsive Design? JN: Because I was writing about user experience, not implementation.”

Comment: Odd, Mr. Nielsen, because your article is full of suggestions for implementation (e.g. building a separate mobile site), not to mention that you sell expensive PDFs about “mobile design guidelines” that, I would surmise, are about implementation.

Conclusion: I’m not sure that this analysis adds much to what Josh Clark already wrote for .net. I generally get pretty bent out of shape reading Nielsen, and my picking it apart this time didn’t result in much of a difference in reaction. Yet I would say that even Jakob gets one thing right: mobile optimization is important. Yet rather than make it easier, Jakob’s advice is to go through the extra work of developing a separate mobile site; extra trouble for the owner, yet less value for the customer.

Mobile optimization is much more within reach when done responsively and progressively. And, in my opinion (as well as many other’s) taking a responsive and progressive approach is much more conducive to actively usability testing your incremental improvements along the way.

Caine’s Arcade from Nirvan Mullick on Vimeo.

This is a great story (I particularly love the “Fun Pass” and prize tickets!). But more importantly, what can this teach designers about being creative with delivering minimally viable versions of our ideas?

I don’t mean to suggest that we should just strive for cuteness in early releases of our design work, and we can’t deliver cardboard on the web. Still, I think there are some good lessons here. Thanks to Jason Grigsby for steering me to this video last night.

Brad Frost has shared some great advice about mobile device testing. He and other mobile design advocates rightly suggest that anyone designing for the web should test on at least a handful of devices. But the above chart shows how futile that goal really is.

These are the mobile device stats for a very large web site that I work on with hundreds of thousands of visits per month from people all over the world. Seen in aggregate, the numbers aren’t terribly surprising: iOS dominates, Android adds up to also be very dominant, BlackBerry has dropped out of the top dozen, etc.

But take a closer look at what it means to “test on Android”. The top Android device here, the HTC Evo 4G, registers at 5%. Then Android devices quickly plummet to just 2% and lower.

So when you want to “test on Android”, which 2-5% of your mobile traffic do you want to test if you’re only going to buy one Android device for testing?

And even adding up the remaining 10 of the top 12 devices after iPhone and iPad only yields 18.9%, still under iPhone and iPad on their own.

Does this make mobile testing too much to deal with? No, I certainly don’t disagree with Brad nor anyone else who advocates mobile device testing. It needs to be done, and any device testing is better than no device testing.

But we need to start acknowledging just how ridiculous this is, and how unsustainable it is. Because it keeps getting worse. Android devices are like bunnies: there are more of them every quarter, and they’re all different. The above chart looks totally different if I just change the dates by three months. Yes, it’s that insane.

It’s one thing for a design agency to try to keep up, if it’s a mobile-savvy agency whose leadership understands the value in buying boxes of test devices to be thorough in their testing. But this is an entirely different problem for a freelance or in-house designer. Because let’s face it, when you dip below 5% with a desktop browser, you typically can afford to ignore it (or at least not worry about it that much).

Now you not only have to pay attention, you have to spend money on a device to cover that tiny percentage. Guess how well that discussion is going to go with most people’s bosses, especially when it has to end with, “Oh, and by the way, this will all change in a few months and we’ll need to buy more.” Right.

Again, I don’t mean to suggest that mobile device testing is itself futile. It’s critically important. The trouble is, we need to stop acting heroic about it and keep suggesting that all good web designers have to try to keep up with the intense fragmentation that is mobile today. Sure, designers with the right budgets can try to keep up. But keeping up is a constant effort, not a periodic effort.

In the end, it’s not just inconvenient to test thoroughly on most mobile devices: given the fragmentation of Android and the rate of new devices being released, it’s actually impossible. And what this means for the majority of the web — the web that isn’t designed by agencies with mobile device budgets, and rather is designed by in-house staff and freelance designers — that’s a problem that has no convenient solution without additional standardization.

My latest article for them went up last week, and as with all of my writing, I already have things I’d add or change (gah!). In fact, I’m not even sure I like the title, as the article is less about making your first mobile design “perfect” or “successful” and more about just starting to deal with mobile at all, and then continuing to deal with it. (and I didn’t title it)

There’s other stuff I’d clarify more, too, like “not all content is equal”. I still think that’s true, but I also think that content parity is important. But this isn’t necessarily much of a paradox. My point about content not being equal, really, is that as you decide what to display in mobile versus hide or shorten, are you actually making decisions that should circle back and impact your “full size” version as well? Uh huh, that’s what I thought! =)

Oh well, plenty more to write about as these ideas all shake out and evolve, right? Thanks for reading.

As we all know, there isn’t a “mobile web” — it’s all one web. But there are ways to improve experiencing the web on smaller devices.

Most importantly, we should worry less and less about trying to become “mobile experts”. Because here again, a “mobile expert” is somewhat of a false construct. Yet we all need to embrace mobile if we work on the web. My approach (covered in both this presentation and my related book) helps you define and set your own priorities for mobilizing web sites.

Download slides (PDF)

Listen at sxsw.com

* Don’t worry, I hear it’s too cold in Austin this week to actually wear a Speedo during my presentation.

Speedo® is a registered trademark of Speedo International Limited.

After a few years of battling Apple’s mobile platform and taking it on in a really serious way, it was starting to look like Google was achieving some parity with iOS. Sure, Android apps still aren’t downloaded as often and don’t return nearly as much income to mobile developers as iOS apps do (for me, Android represents only 10% of my total return when comparing the same apps that I’ve placed in the App Store and Android Market). But Android device purchases have skyrocketed, mobile app customers typically want both Android and iOS versions of their native apps, and companies doing mobile development often embrace both iOS and Android.

But unfortunately for many Android developers and customers, Google just threw their mobile platform under the bus this week by renaming Android Market to Google Play. Why?

Apps aren’t just entertainment

Look at the Google Play info screen above. “Play anywhere.” “All of your entertainment in one place.” Interesting… because as a mobile product manager in higher education — and an independent app developer for healthcare clients — exactly 0% of my mobile work is entertainment. Is Google telling me that the Android platform is not appropriate for my work?

Yes, they just did.

You don’t “play” apps

Worse yet, it seems like some marketing person who is completely unfamiliar with mobile apps has taken the reins of mobile marketing at Google. Because simply put, they didn’t get the verb right. You don’t play apps. You run apps. It’s a huge distinction.

And Google got their action verb very, very wrong.

Granted, apps that are games can be played. So, clearly, when people run an app that is a game, they probably say that they play that particular app. But apps are software running on small, pocket-sized and tablet-sized computers. You don’t play software. You run software. Particularly if it’s productivity or reference software.

In closing, I’ll end with an observation. Last week, several people at my company just spent a lot of time doing video production for a demo of our mobile app. The script noted that the app can be found in Apple’s iTunes App Store and Google’s Android Market. Now we get to redo that work.

But this is more than just sour grapes. Now the demo, for a higher education mobile application, will need to say “to keep in touch with your university courses, classroom discussions, faculty and classmates, and campus news, download our mobile app at Google Play.”

And I can’t even say that off-camera without getting a deeply disturbing feeling in my stomach.

This is all context for some thoughts this morning as they pertain to the web, because a presentation I heard at my church really jolted me out of my daily focus. It reminded me that there are still places in the world where the web, and especially the mobile web, are no more real to people than jet-packs and time-travel. Simply put, the web doesn’t exist and therefore doesn’t matter.

One of those places is North Korea. Did you know that people in North Korea need to be licensed to own a personal computer? And guess how easy it is to get licensed? That’s right, it’s really only an option for elite members of the country’s ruling communist party. Everyone else gets to wait in line and use a computer in a public computing center (and guess what: there’s not a lot of world wide web access in North Korea’s public computing facilities).

Of course, this is the least of the average North Korean’s problems. Higher on that list are other forms of political oppression, social isolation, starvation, and — for hundreds of thousands of North Korean citizens — a life assigned to Stalinist work camps that the rest of the world thinks went out of style last century. But oh no, Stalinist work camps are still very much in vogue in North Korea, in this, the 21st century.

So there’s a lot for the world to fix in North Korea. But even for people who are troubled by this and interested to help, there’s not a lot that the web can do to directly intervene. We web and mobile strategistas like to think that we’re on the leading edge of helping to solve a lot that inconveniences or ails the world, and in some cases we are. So it’s sobering to be confronted with a situation where it seems that the web can’t make much of a difference.

There’s simply not going to be a North Korean version of the web- and social media-driven Arab Spring any time soon.

Yet this is where content strategy shines much brighter than the various technologies on which it works. Because the presentation that we heard this morning, in a church basement on a snowy morning in Minneapolis, Minnesota, was organized by Amnesty International. And this is an organization that mastered content (and social) strategy well before the web and mobile even entered the world scene.

Of course, the internet — web, email, mobile apps — can certainly still play an important role in people networking about human rights issues. But when it comes to places like North Korea, the real work involves sitting down face to face, understanding the situation, and then doing more about it via letter writing or phone calls. Or just more conversations.

Because as Jack Rendler from Amnesty explained to us this morning, the human rights movement grew and has made enormous, positive impacts on human history over the past 30 years. But hardly any of those advances involved web or internet technologies. It all started with meetings in church basements, coffee shops, on college campuses, and in people’s living rooms.

“In Real Life”, as we like to call it today.

Driving this success, and what we can continue to do today and tomorrow, is a shining example of organizational effectiveness and tightly managed content strategy. Whether online or in-person, Amnesty International’s success is driven by getting their human stories and calls to action out to people all around the world, in any and all media.

With or without the web.

More information about the North Korea situation that we discussed can be found on the Amnesty International web site.

Stream   |   Download podcast from iTunes