Mobile Site vs. Full Site — commentary on Jakob Nielsen’s lightning rod post

Samsung Galaxy Gio (GT-S5660) Svenska: Samsung...
Samsung Galaxy Gio (GT-S5660) Svenska: Samsung Galaxy Gio (GT-S5660) (Photo credit: Wikipedia)

 

Recently, Jakob Nielsen posted an AlertBox called Mobile Site vs. Full Site — www.useit.com — Readability. In it, he argues that when designing for mobile, it is best to keep the mobile version separate from the desktop version—in essence two (or even three!) unique websites. “Two designs, two sites, and cross-linking to make it all work.”

Two designs, two sites, and cross-linking to make it all work.
–Jakob Nielsen

The backlash on Twitter is fierce with Karen McGrane calling it an “April Fools Day piece” and another imagining it coming out five years ago. Is it really worth the ire? Yes. And it isn’t particularly close.

Nielsen posits that it is best to have a separate website for each class of device (desktop, mobile and, in a class by itself, the Kindle Fire). This is a solution that Netflix has adopted—each device should have it’s own user interface. But every website? The upkeep alone automatically doubles. Just picture combing through file after file to find an esoteric text snippet that may or may not be there. Apparently, Nielsen tested “hundreds of mobile sites and full sites on all the currently popular platforms” and the results are how people best interact with the content.

There is a little sense here. One of the separatist method’s strengths is that it is optimized for each device’s capabilities. From that standpoint, its no surprise this method was better than a responsive design, the users were using something that felt much more at home.

If this really is better for the end-user, wouldn’t the extra resources be worth it? It depends, is it that much better considering the cost? Furthermore, and perhaps more importantly, is it really looking to the future?

The future

Today’s findings are not necessarily representative of how mobile will work in the future. Given the wide variety of devices in the past, it is sensible that this will continue on into the future. With the rise of tablet computing blurring the line between mobile and desktop, Jakob Nielsen’s ideal requires an ever increasing number of versions of your website. Where do you draw the lines for “good enough?” Because with this approach, you can never have it all, you are always one step behind.

New devices with new dimensions and resolutions are coming on the market all the time. At present, the largest mobile screens weigh in at over 5 inches with a resolution greater than some old desktop computer screens. The smallest are less than half that size with a resolution even tinier. Although touch interfaces seem to be becoming the norm, there are still plenty of keypads out there. With great diversity in mobile devices alone, how can just one mobile solution be enough—in addition to the others required for a tablet and desktop? And of course, these all would need to be built and maintained separately with the appropriate resources behind them.

Maintaining separate content for the mobile, tablet and desktop is a gigantic chore and certainly cannot be worth it for just about everyone. A responsive design works, but apparently not well enough for Jakob Nielsen to give it his approval.

The third way

Luke Wroblewski offers a third suggestion, RESS. Basically, this mashes up responsive design with server side magicianry to output an optimized experience for everyone, while retaining advantages such as one codebase, no separate URL structures and a flexible interface to future-proof against changing screen sizes. If you are interested in this approach, check out Luke’s walkthrough.

Concluding thoughts

While I applaud Mr. Nielsen’s contributions to the usability community in general, I can’t help thinking he missed on this article. While his extensive research shows an usability increase in a mobile-only site, the findings are myopic when considering the variety of currently available and future devices as well as the cost of supporting the burdensome architecture required for his recommended solution.

Enhanced by Zemanta
Posted in Uncategorized