A Lengthy Introduction
I was casually browsing my Twitter stream the other day, and someone posted a link to a blog post on doctyper.com which when loaded, made me realize another downside to imitate native UIs in the mobile web.
I should make it clear first, that I don’t intend to pick on doctyper or its developer, it just happens to be popular enough that I stumbled upon it. Everything I say here is general enough to apply to almost all native-imitation-style mobile web apps.
Here’s what I saw when the page finished loading:
My first problem with this came up when the content started rendering and I tried to scroll. Because doctyper uses custom, Javascript-based scrolling (A topic I discuss in more detail here) and because the javascript hadn’t finished parsing and executing, my touches weren’t captured. Instead, the page scrolled as-is and the top and bottom black site bars along with the content all static and moving together. I released my finger, tried again, and it finally kicked in.
Not a problem native developers have to deal with.
The second problem came up when I started scrolling. I don’t know about you, but I don’t like small, confined spaces. And on this site, I felt very claustrophobic. To see what I mean, let’s deconstruct the screenshot into its various elements. Labels on the left represent the component that drew them, and the labels on the right show their pixel height:
Of the 960 pixels of real estate, 520 were used for content. In other words, 46% of the space was information and visual clutter that had nothing to do with the content.
Sometimes web developers seem to be more concerned with the frame than the painting. Haven’t we learned anything from Microsoft?
The Assumption
My assumption is that people who design and develop these native-imitation style mobile web apps are doing so in the void of MobileSafari, ignoring the ubiquity of the web. The whole point of building a web app is to leverage its strengths. One the main strengths is the web’s ubiquity.
The ubiquity of the web means you can’t guess where and how people will be using your web app. The best you can do is come up with a flexible design language that will adapt to screen sizes, form factors, and input mechanisms. Unless you’re building a hybrid app – combining web views within native wrappers – where you can presume the dimensions and access points, designing for a specific form-factor/use-case will indubitably lead to situations like the one discussed earlier.
The Addendum
Having said all that, some of you may be wondering why you would build an app-like experience on the mobile web at all. I did just spend 400 words telling you why it was a bad idea afterall. Well, let me tell you about another experience I recently had with the mobile web.
John Gruber, being the fan of @counternotions that he is, linked to one of his tweets recently. As I was browsing the feed, the mobile Twitter app loaded and I was pleasantly surprised. 1 I was expecting the basic HTML page to load that showed the tweet, the person’s avatar, and a couple of buttons. Instead, a rich UI was loaded which let me fave the tweet, see the conversation leading to it, and quickly switch over to my main timeline. 15 minutes later, I realized that I was still in the embedded web view of Reeder, lost in a sea of poop jokes and kittens.
The takeaway is, I was under-promised and over-delivered, and that’s what we ought to aim for. Mobile web apps should delight our users, not frustrate them.
Majd Taby 