More please…

I feel today that I must tip my hat to a few organizations (and encourage others to consider following their lead).

Yesterday, the BBC launched a responsive (mobile-only) news site (in Beta for now) and followed up today with an awesome post explaining where and how it was tested. Earlier, on their responsive blog they had posted a short list of common devices accessing the BBC web site and gone into details about their strategy and development approach.

A few weeks ago I also discussed a recent Netflix article explaining which devices they support and how they go about managing diversity (while keeping their development process sane).

I also had a lovely comment on my blog a few days ago from Craig Sullivan at autoglass.co.uk who explained in fair detail (given it was a simple comment on a blog) the decisions they made around device support, and the ROI they had seen when supporting older BlackBerry devices.

More please!

These are the types of conversations we need WAY more of.

I’ve been frustrated for some time that most practical conversations about ‘mobile web’ are dominated by smaller agencies and freelancers who are (mostly) unable to disclose the details of client projects.

Sharing code is easy (and effective) but often handicapped by the fact that strategic discussions contain part urban legend, part chicken bones and tea leaves, and are therefore easy to dismiss with “…oh but that’s not my market” or “…that’s not what i’m seeing in my analytics”.

These are all valid objections, but may still be immaterial when there is no broader industry perpective to weight them against.

Meanwhile, Google, Facebook, Twitter, myriads of fortune 500 companies, major FMCG brands and others are stampeding into mobile, yet keeping quiet about their device traffic, implementation and overall strategy.

While I kinda get this from a business perspective, some of these details are hardly worth keeping secret and some of this ‘strategy’ is simply good common sense. It wouldn’t hurt them to make some of it public, and would go a long way in helping our industry move forward.

What would help

Here’s what I would love to see more of from companies large and small—and ideally in all industry sectors (not just tech…how about travel, automotive, the cultural sectors?).

Lists of common devices accessing well known sites. We all know iPhone users surf more than others. Let’s get over it and start discussing the long-tail of Android devices (and the dirty secret that each month these inch up further and will soon match iOS traffic…if they don’t already).
Case studies of ROI when supporting many browsers/platforms. Facebook seems to be spending lots of time with WURFL lately. That can’t be because all the traffic is coming from iOS. Who else is going out of their way to support lots of platforms…and how’s it working out for them?
Case studies comparing ROI for a responsive site vs. a standalone mobile site (which of course can also be responsive). And while we’re at it, would anyone (who has used one…rather than sells one) care to discuss the ROI of using a ‘proxy’ service? These are complex topics that are heavily linked to a site’s size, content, CMS/API and a host of other factors…but that’s what makes these conversations so valuable.
Case studies about server-side detection and adaptation. The big guys are doing it…so why is that? Are they all just wasting their time?
Strategies to combat the ‘ugly truths’ of fragmentation (new favourite term courtesy of these fine folks). Detecting a device, or browser feature can be tricky, but it’s often far easier than what comes next. I would love to see more discussion around what to do when detection doesn’t work as planned (…I don’t know about you but false positives and account for the majority of the bugs we currently face, and while these specific bugs will i’m sure go away, i’d be astounded if new ones didn’t take their place).

Anyone care to add more to this list (or suggest case studies I haven’t yet run into)?

And a final hat tip to R/GA who fairly regularly releases this kind of info via Brad Frost (…despite i’m sure the odd squeamishness for clients.)

More please…

Thoughts on technology

1 Reply

I was going to write something about user agent strings but have no time this week for the inevitably polarized discussion that will ensue.

So i’ll instead leave you with this fairly apt quote by Noam Chomsky.

“Technology is basically neutral. It’s kind of like a hammer. The hammer doesn’t care whether you use it to build a house, or whether a torturer uses it to crush somebody’s skull.”

And because nothing is ever black and white, i’ll also include the first tenet in Melvin Kranzberg’s six laws of technology.

“Technology is neither good nor bad; nor is it neutral.”

The mother of all device tests

Not in my best interest

20 Replies

The new iPad is so far less than thrilling.

I’m not saying that as a geek (or fanboy), but as a customer.

The new iPad certainly isn’t cheap. The screen is of course gorgeous, but good designers know that perfection isn’t always what a customer is after. (Or as Peter Drucker famously put it… “The customer rarely buys what the company thinks it sells him.”).

Apple has just released a device that makes them look good (or at the very least clever), but at the expense of everyone else (including the customer). Sure, the fonts are so crisp they could cut glass, but absolutely everything else on screen is fuzzy.

(Everything except Apple’s own site where for possibly the first time ever, they’ve acknowledged that the web is now multi-context, and have taken the time to swap some images. Pigs may however fly before Apple honours us with a small-screen and bandwidth optimised experience).

The past week has been full of frantic tweets, articles and GitHub commits aiming to “solve the retina image problem” that the new iPad has thrust upon us. (And matters are not much rosier on the native app side of the world.)

The optimist in me thinks this episode may finally compel the standards bodies to properly discuss a multi-context image tag. The pessimist in me sees the second coming of the Y2K bug, as we all scurry around to solve a problem that could have been avoided through pragmatism and good design.

In this case, the pragmatism would have been needed on Apple’s part.

Everyone already loves the iPad. They’ve already sold more tablets than anyone else, and competitors are still struggling to catch up.

Releasing a retina-display version hasn’t really improved the device (which is now also noticeably heavier and feels awkwardly out of balance). What it’s merely done is create hype that no one (including Apple) actually needed.

What I would have loved to see from them is an admission that releasing a retina display iPad was not in anyone’s best interest at the moment. They could have even (as they do so well…) spun a story around that fact; explaining that in matters of user experience the whole is greater than the sum of its parts.

This quote by Maya Angelou sums it up very well for me (the customer…not the web designer):

“I’ve learned that people will forget what you said, people will forget what you did, but people will never forget how you made them feel.”

The iPad used to make me feel happy. The new iPad no longer does.

—————————————-

Update: This post is certainly generating some vibrant conversations on Twitter

What i’m first finding interesting is that it’s really quite hard to be a user, designer and developer at the same time. There is a clear value in innovating, but no technology operates in a vacuum, and once the technology is there, it’s often the social change we struggle with the most.

Many people have responded that Apple is simply innovating, and that in the end, we will all be better for it. And on the one hand, I don’t disagree. I just find it sad that with fast release cycles and the need to compete, this innovation often occurs at the expense of users (and of course other times it doesn’t…hopefully it all balances out).

Bryan also mentioned something interesting after chatting with a few folks on Twitter. If Apple really wanted to use this as an opportunity to innovate, they would have also included their version (or vision?) of how to gracefully solve the multi-context image problem (and maybe even the bandwidth detection problem) in the latest version of Safari and iOS. There’s nothing like a new bit of implemented ‘spec’ to jumpstart progress.

The value of 1000 Androids

1 Reply

I chuckled a bit today when I read about the 1000 Android devices that Netflix needs to support. I suspect a good third of those are trivial combinations of model and operator variants (my blog for example shows 7 variants of the HTC Incredible). But still—that’s a pretty big list of Androids!

Numbers such as these tend to horrify people, when in fact they’re not as bad as they first appear. The process Netflix uses to group (and identify) test devices is not that different from the one I described a few weeks back.

And buried within their article, there is this very important point…

With this information, we have taken stock of all the devices we have in house and classified them based on their specs. We figured out the optimal combination of devices to give us maximum coverage. We are able to reduce our daily smoke automation devices to around 10 phones and 4 tablets and keep the rest for the longer release wide test cycles.

The dirty little secret is that the more you test—the more accurately you will determine when it’s ok not to.

Sure these devices are all different, but those differences should inform your design and development strategy far more than your choice of workarounds or poly-fills.

Brad put it very well recently, while comparing the strategy of two mobile web sites:

…one is working with the constraints of the medium and using those constraints to it’s advantage, while the other is introducing unnecessary dependencies on what’s essentially a list of links…

The ultimate goal is to work with the medium, and tweak, workaround and poly-fill as little as possible.

I’m not talking about cutting corners here. I’m talking about knowledge and craft. That very tacit knowledge that comes from experience and enables you to identify constraints, design for them, and use them to your advantage. This is one of the great gifts (if you can excuse the sappy term here…) that device testing bestows.

Mobile web workshop with Nielsen Norman Group, 23 March in Edinburgh

Responsiveness is a characteristic

4 Replies

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…)

Diversity is not a bug

A post-pc chat over coffee

2 Replies

“This thing is so, so, so useful” he said “Since I got this thing I never turn on the computer anymore.”

The man in question was 30-something and speaking to a much older gentleman who appeared skeptical, but genuinely interested (and went on to ask lots of questions). They were accompanied by a small child who spent most of the conversation transfixed by a game on the iPhone.

“I just use this for everything now…” the younger man continued.

“You see it’s always on, always there. It’s always next to me, or in my pocket. I don’t need to fuss with it or wait for it to turn on. It just works…so it’s kinda completely replaced my PC.”

“So much so…” he said with a chuckle, “…that the last time I turned the computer on, I forget for what…the antivirus was so out of date I had to do this great big update!”

[Eavesdropping session made possible by the iPad on my lap...these things are indeed so incredibly useful.]

Mobile users don’t do that

18 Replies

The conversation often starts like this…

“Mobile users won’t want to do that, they’re ‘on the go’ and will be in a hurry or want a quick distraction.”

This is true, except when it’s not.

Study after study reveals people use their mobile at home, while watching TV. People also use mobile devices for hours while waiting on trains and at airports. For each user who is in a hurry there will be another who stares intently at their device for 20-30 minute stints. If that devices happens to be a tablet, they may use it for even longer periods. And while many users will simply be consuming content, others will be shopping, banking, or performing other very specific tasks.

“Ok, but some mobile users will still be in a hurry. Shouldn’t we cater to them? Make things extra simple for them?”

Agreed. Mobile users will curse up and down if they can’t do that really useful, common, important thing really quickly. Any chance you have to focus and trim copy, streamline interactions, or minimise data input should be considered.

But why exactly are we only fixing things for mobile users?

Desktop users may have a bit more time on their hands, but does it mean we should waste it with happy talk, redundant data entry, or poorly optimised interactions? If I had a penny for the number of times I’ve had to input Edinburgh, choose United Kingdom or specify today’s date in a menu I’d be rich by now. Modern browsers make it much simpler to implement intelligent defaults. Why should it only be a mobile thing?

“Ok. But we still can’t implement all features for small screens. Some things are just too complicated.”

Agreed. Completing a life insurance form on a mobile (or BTW on the desktop and on paper) is really complicated. That doesn’t mean people won’t try it, and even that is besides the point.

Let’s look at it a bit differently…

First off, what is the traffic for this feature on the desktop?

If traffic (and completion rates) are high, shouldn’t you seriously consider including it in the mobile roadmap, even if it will be hard to implement (or may involve additional testing and come in a later phase)?

And if the traffic is low, why is that? Maybe the feature isn’t actually needed, or maybe it’s too hard to use (or find) on the desktop as well.

Kayak recently tweaked their desktop site to bring it in line with the simplicity of their mobile offering. One of the steps they took was to remove rarely used features, to better focus on optimising higher traffic ones.

Also worth considering that people who suffer through impossibly complex (or broken) features on a tiny screen are either really desperate, or are power users who simply want to get stuff done…wherever they happen to be at the time. As acquisition typically costs much more than retention, are these really the people you want to disappoint?

And don’t forget, some of these devices are also phones

Sometimes a well placed voice call or SMS can save the day. Yell.com (and several travel sites) recently implemented a “Call Us” feature for those times when despite their best efforts, what a user wants to do is just too complicated (or maybe not yet supported). If a user is about to bail, the ‘best UX’ is one that provides them with a handy one-click life raft.

PS – You will lose points however for displaying a “Call Us” button on a device that can’t actually place a call. If you provide a life raft, be sure it actually floats.

Stephanie Rieger

Beyond the mobile web