Arguably nobody on the planet stirs up the design community better and more frequently than Jakob Nielsen. His recent article, Mobile Site vs. Full Site, has already generated a lot of controversy. Designers and content strategist have leveled numerous criticisms (here and here for example) of Nielsen’s recommendation to provide separate mobile-optimized sites that cut features and cut content.
In Nielsen’s response to the criticism, via an interview with .net magazine, Nielsen defends his omission of Responsive Web Design (RWD) with a quote that probably caused many designers to slap their forehead in frustration. Of the RWD charge, Nielsen says he omitted it as an option “Because I was writing about user experience, not implementation.”
Designers and product manager are likely to howl about this attitude and his overall argument still does not hold up well to the tenets of RWD. But I’ll let the RWD experts take care of that argument. Brad Frost, for example, has already penned an excellent discussion on Content Parity that effectively debunks a lot of Nielsen’s argument.
Implementation Is Everything
What is perplexing about Nielsen’s comment is that it is indicative of a common criticism of usability testing in general. Nielsen wants to provide a usability recommendation without considering implementation. Designers and product managers live and breathe in a world of compromises due to the fact that they have to actually implement features and content while balancing resources, deadlines, project goals, and more.
They can’t evaluate features and designs without evaluating implementation. Implementation is everything when producing applications and websites.
Usability Metrics Don’t Stop At The Display
When confronted with the question of one responsive URL or different URLs per device, Nielsen cops out again “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.” (emphasis added)
This is a dangerously narrow definition of a usability decision. The usability of the page is not the only usability metric of concern. For example, sharing of pages and content on social networks is of paramount importance to most websites today. The ability of a user to find, read, and share the content is clearly a usability test case (and a conversion metric) for a lot of websites. Which means that the question “single URL or device dependent URL?” is a key usability factor that Nielsen ignores. When faced with this question Nielsen punts it as “an engineering decision.”
RWD Implementation Challenges
The modern web is too complex to ignore implementation when reviewing design and usability. This isn’t just a problem for Nielsen. Teams that take up the responsive web design banner must face the realities of implementation as well.
For example, we recently had a discussion with a client that was undertaking the task of converting their relatively large ecommerce site to a Responsive Web Design. The team was excited, management was on board, they had even recently been to our usability labs to test some of their work. But the reality of converting the entire existing site to a responsive design was daunting and causing conflict.
The problem? Stakeholders would not compromise on content for the new responsive site. Everything that exist today on the desktop site needed to be in the new site but some things didn’t translate well. A keen Mobile First evangelist, the product manager knew that the real problem was that some of the existing content and features probably needed to be removed from BOTH the desktop and mobile views. But down in the trenches of real live existing products, you don’t often get to start over and stakeholders don’t like to see their pet features cut in a new release.
From the stakeholders perspective, typically new releases are supposed to mean new features, not fewer features. And that’s when compromises happen in real projects.
RWD and Mobile First are easy concepts to defend but they are a lot easier to implement when starting from scratch than when converting an existing site. Often times, the right thing to do (such as cutting content on all views) is hard if not impossible to implement in real world projects due to outside constraints.
Compromised Project Goals
Compromise happens. For example, take a look at the originally referenced .net magazine interview with Nielsen from the mobile link and the desktop link. Notice what’s missing from the mobile link?
Ads, menus, widgets, social links, comments, registration, and login are all missing in the mobile site. I’m guessing .net magazine relies a lot on advertisements and paid subscriptions for most or all of its revenue and it relies on social sharing to bring in more readers (I found the article via Twitter for example). And yet all of these features are missing from the mobile URL.
It is easier to read the mobile version on my desktop, but as a revenue driving product the mobile site fails to meet (assumed) key requirements of the site. Compromise happens on every side of the argument.
Usability and Implementation
Nielsen wants to provide usability advice that is implementation agnostic. Designers and content managers want implementations that are device agnostic. In the real world of launching and maintaining business websites the truth is usually somewhere in the middle. Compromise happens so that something gets published, because shipping is a feature too.
Your usability approach must be flexible and ingrained in the project goals to achieve this. You need to consider not just the usability of the rendered page, but the usability of the rendered link, the availability of key product features (if it is not available the feature is not usable), and the ability of the team to implement the design within project constraints. Usability decisions are engineering decisions and engineering decisions are usability decisions.
– Brad Cranford, Director of Technology, Usability Sciences
twitter: @aggiebradley | personal blog
The compromises between engineering and usability decisions is a very good point. Various aspects of the RWD versus multiple dedicated sites dilemma have been discussed on Linkedin Boxes and Arrows threads, see: http://www.linkedin.com/groups/User-Experience-Implementation-Responsive-Web-22206.S.110191514
Hi – I put some detailed comments into the .net article – so please check these out.
Everything in that brad frost post doesn’t debunk Nielsen – that’s a specious and somewhat tenuous link to make. The problems he outlines are nothing to do with responsive or otherwise – he’s basically showing how crud the experience is in many ways.
Really – if people cared more about making the mobile experience better and less arguing about whether their method is best, we’d get a feck of a lot more work done.
Nielsen has pointed out the sense in taking a user centred, rather than design dogma approach.
C.
Right, what a lot of people don’t realize about Nielsen’s work is that it is empirical. He gives users a task to do and then watches them do it. I’ve done a small amount of user testing with responsive designs and what I’ve seen supports his findings too.
RWD *often* sends more information to the user than they need. This produces a measurable increase in load and render time, which is not ideal for the mobile user (though it is far better than not doing RWD). Also, it assumes that mobile users are using a website the same way desktop users are. In fact, mobile users are often motivated differently than desktop users.
If you gave a design team two tasks, one was to design an RWD theme and the other was to design a mobile optimized theme, you would likely get different results.
If you don’t have the ability to do a dedicated mobile site/app then do RWD. It is far far better than not considering the mobile user’s needs. But realize it IS a compromise. You could do even better with a site dedicated solely to the mobile user.
[...] can read the article here. http://usability.com/2012/04/24/compromise-happens/ Share this:EmailTwitterFacebookLike [...]
Craig,
Fair points. There is a good, if a bit heated, conversation in the comments to the .net article . It is worth a read.
I do think that Brad Frost’s “considerations” at the end of his article lead to an opposite conclusion than Nielsen’s recommendation. But that’s just my opinion. I don’t think RWD is a silver bullet or an absolute thing. And I think most of the RWD proponents do a good job of explaining it as an option, not a rule.
I am concerned that Nielsen’s recommendations encourage short sighted decisions. Mobile only links, in my opinion, are a hack to get around the core problems rather than a long-term solution. Of course it is then fair to ask “Is RWD and Mobile First the right answer or just another hack?”
For some projects, distinct URLs for mobile and desktop sites may be the right answer (even if it is only the right answer because of other constraints that prevent a more complete solution). But you should be aware of the other usability issues you are introducing (such as link sharing issues) by making that decision.
–Brad
Agreed on your points – it’s a complicated area that doesn’t bear being reduced in the way that some people have.
I’m happy if someone puts love and good user centred design into their site, regardless of whether it is mobile separate or one url/separate url RWD.
It’s where we strive towards (rwd) but there are stepping stones in that journey – and new people building should take the jump straight there. I’m still very concerned about image handling, which is a huge topic and not supported properly yet. This makes it hard to get good performance on devices with a less than optimal data rate or high latency issues.
Google have done some helpful stuff here with the new smartphone crawler which understands the redirects and content mapping and tries to help out. We’ve taken key functions like our sitelinks and popular content pages and remapped them seamlessly, so that a user clicking for a ‘Contact Us’ page on autoglass.co.uk gets the ‘Contact Us’ page on the mobile site in 1 click without redirection.
There are many recipes, ingredients and chefs to argue about the best recipe. Then, there is cooking itself. RWD is a set of technologies, approaches and a loose affiliation of techniques that is imperfect in places. HTML5 support really sucks and is turning into a battleground of sorts. I still can’t get access to some phone hardware on our mobile apps, so these are all real problems I’m trying to solve.
My concern is that we don’t push people towards RWD unless they have the skills and time to do it. Someone who doesn’t have ANY mobile website is losing business. With over 30% of UK visitors coming via mobile devices to the autoglass.co.uk site, we know this. For an SME, they need to get some presence, any presence, quickly – and then build on it.
That’s the bit a lot of companies I talk to are concerned about (particularly SMEs) and I want to see us working to improve everyone incrementally – not ask them to take leaps because we think it’s a nice idea (it’s actually not ready yet).
[...] [...]