Responsive Layouts, Mobile Templates, Native Apps And Universal UI.

Andrew Boon posted 8th of April 2013 in Dolphin.pro News. 49 comments.

Dolphin is getting more attention from the perspective of multi-device compatibility. We have been looking for the best way to make Dolphin more "adaptable" for quite a while, but it seems that there is still no definite consensus on what has to be done. Moreover, the new solutions designed to tackle the problem seem to only bring more confusion. After a lot of research, comparison, talks and reflection we'd like to share our opinion and perhaps spur a constructive discussion on the topic. Let's try...

The Need

Internet browsing is changing rapidly. Smartphones and tablets accelerated mobile browsing to such pace that social networks started reporting more mobile traffic than desktop traffic. Some services are getting designed for "mobile first" or even "mobile only". So, it's not the 2005 anymore, when developers could shake off mobile as a "thing of distant future" and come up with half-baked options. We have, effectively, entered the age of mobile web.

History

Interestingly, Internet used to be very mobile-friendly. The very first versions of web markup - HTML assumed flexible page layout, web fonts controlled by browsers and content structured as article-like pages. It would work wonderfully on modern mobile browsers and desktop browsers without any change.

Unfortunately, we had some odd 20 years of various display sizes, resolutions, browsers and OSs with developers trying to make things look beautiful, adapt and utilize space effectively. Tables, CSS, Ajax, DHTML, blah blah blah - these things complicated web markup to such extent that we now have to "retrofit" our page elements to look more like what they would look like 20 years ago - because we have small screens, "white-space" is in fashion and pixels become too small to worry about.

Option 1 - Mobile Version / Mobile Template

This one is really interesting - in effect it's the same old "solution" that was tried and constantly failed for more than a decade. Remember "WAP versions"? Remember ".mobi" for mobile-sites? This is a classic example of "assumed demand" when developers got so disconnected from real-world use-cases that they (ok, we) started to believe that the world needs a stripped down version of the site to be able to use it on mobile devices. At first, it was justified by slow and costly mobile Internet connection, and later by smaller screens and shorter attention-span. Either way, mobile versions never proved to be effective. I keep asking friends and relatives - they all hate them! First thing users tend to do is look for the "full version" link. There is a good reason why...

Mobile version of a website always brakes some of the most fundamental rules of UI design usability.

To wit - Jakob Nielsen: 10 Usability Heuristics for User Interface Design:

Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

See, it's hard enough for most people to learn how to use one version of your site, and if they come from mobile device and see a dramatically different layout - you've lost them. They can't "muddle through" their tried'n'true use-paths and have to re-learn. Menus are repositioned, blocks are in different places, some parts are gone, some features are seemingly (or actually) absent. It's a mess.

Remember the first iPhone presentation by Steve Jobs? The whole point of new generation of smartphones was about displaying FULL web on a small screen. Pinch-to-zoom, double-tap to zoom and orientation change were designed for FULL web pages.

Bottom line is that mobile and desktop versions should be same, or very similar to preserve consistent user experience. Otherwise, it's just not worth it - let people zoom and enjoy the feeling of actually understanding what they're doing.

Option 2 - Responsive Layout

The most recent twist on the same old idea - responsive layout frameworks like Bootstrap and Foundation look rather sexy. In theory they're supposed to intelligently reposition page elements to suit any screen size - phone, tablet or desktop. Unlike the ancient one-page HTML markup, however, they work with complex layouts that contain menus, multiple columns, adaptable images, etc.

And again, all of that wizardly only creates the same trap - webmasters get all worked up thinking that we've got a saviour, while users get frustrated every time they can't find a familiar "red button in the top right corner" or something like that. Even when you look at the websites of the responsive frameworks developers you can get lost, unless you're savvy enough to assume that.. top menu converts into a button, blocks jump lower down, side menu is now top or bottom menu, etc. It's a whole new science for science's sake.

Responsive is good, but only if doesn't create too much dissimilarity. Check out the resposiveness of Boonex.com or NNGroup - browser resizing triggers display of small or large versions, but they're almost identical. They also look the same on tablets and mobiles. And that's a good thing, alright!

Option 3 - Native Mobile Apps

A new kid in town. Everyone knows that Apps are not sites and they have their own usability conventions. Just that premise already created a foundation for native apps success - people accept that apps are not websites, they know it and they go back to a website when app fails to deliver. This is why most of the Facebook's "mobile users" are in fact mobile apps users.

Native apps can be designed to make good use of the hardware-specific features, they're normally faster and more efficient at what they can do. On the other hand, development of rich functionality for different OSs in native app form is costly and time-consuming. Developers just can't commit enough resources to every app to make it do everything a website does. Luckily this only reinforces the first point - people know that apps are for quick access to features that need to be accessed quickly. For everything else - there's a full website.

Ok, this is pretty much what we're do doing with Dolphin - we have a full-blown web platform and native mobile apps for iPhone and Android. Our apps don't do everything, but they are extensible, Prime clients can access and modify the source code, and updates come our regularly with great improvements. With current state of affairs this seems to be the best way to tackle mobile. Oh, and there's one more thing...

Option 4 - Universal UI

The idea of Universal UI is to make just one layout that is consistent across all devices, but is still very usable both on small and large screens. This is not about some sort of CSS wizardry or fancy repositioning - it's just a methodology of building web-pages for "grandmoms". Think large page elements, bigger fonts, single-column-pages, short menus, scalable icons, etc. iPad is a good reference device for Universal UI for non-tech-savvy end users. Things that look good on iPad would work great on desktop (less clutter = better usability), and would still be usable on on smartphones with a bit of zooming, when needed.

Universal UI is what we're working towards when developing Dolphin.

----------------------