Friday, April 5, 2013

Web Look and Feel, Part 2 -- Does Native look actually matter?

In my previous post, I explored how I think we got to where we are right now with App and Web look and feel. With the Web, there really isn't any standard look and feel (still), but with Apps the dominate ones are iPhone and Android. Phresheez took a lot of lumps -- especially very early on -- for not looking like a "native" app. So the question I posed last post is that if I had a pile of cash to redo Phresheez, say, to make it look like a "native" iPhone/Android app would I do so (even if I used still web technology)?

The answer may seem surprising but I think that my answer would be "no". I have two different axis that are somewhat contradictory from which I draw that conclusion: 1) I'm not convinced that for the average user there is any meaningful "native" look and feel and 2) there are potential forces at work that could unify web look and feel, or at least provide a better base level set of similar look and feel, making any platform specific look and feel largely irrelevant.

What Look and Feel are We Talking About?

When I consider what people mean when they talk about native look and feel, there are a number of different things to consider:
  • Does the app navigate like a modern phone app these days?
  • Does it take into account that fingers are gigantic?
  • Does it take into account that people hate typing?
  • Does it follow the expected for zooming and  panning?
  • Does the app fit the form factor instead of relying on all kinds of panning and zooming (ala unreconstructed web sites)?
  • Does it count on mouse-overs to function properly (oops!)
  • Etc, etc
None of these are specific to a given platform. They are all about making the app work in the given form factor and while that is still somewhat in flux, there's far more agreement about what "working within the form factor" is, than argument. Take swiping. You swipe to go forward/back in a related sequence. Be it dates, pictures, etc. Zooming is done by pinching. And so on. 

So what do the native bigots actually mean then when they say it "doesn't look like an iPhone app"? One has to assume that it's the set of native widgets that the app uses. What else could it be? 

Heretics and Heresies

My feeling is that people on phones these days use their phone mainly for a few tasks:

  1. Social networks -- Facebook, Twitter
  2. Messaging -- email/texting
  3. Games/Vids
  4. Tracking themselves skiing (<-- kidding)
Let's take Facebook and Twitter, here are their screen shots in the Android store:



In both of these cases, I've put up the iPhone and Android versions. Can you tell which is which? There are minor differences to be sure, but it's not clear they have anything to do with the much vaunted "iPhone" or "Android" look and feel. More like the different dev teams just disagreed. These are hugely popular apps and from what I can tell nobody ever says "that doesn't look like my phone's app!!!". They just get used to it.

Built in Messaging Apps

So with built in apps, you'd expect that they'd be paragons of their respective "Look and Feel", right? Well take the Texting apps on both. For the most part they're identical -- they both use the comic speech bubbles, neither of which to my knowledge are native widgets. Apple's uses Aqua-like gradients on their bubbles more, but there isn't really anything beyond that. The inboxes seem to both be standard-esque listviews, but they're both very utilitarian. I find it difficult to believe that people fawn over the inboxes. So it there much here that showcases platform specific look and feel? Not in my opinion.

Mail on iPhone looks a little more standard with their back button paging (their navigation controller iirc). But it too is pretty utilitarian: a mail program is a mail program is a mail program. Nor does Android win any beauty contests either. Maybe some people really do stress about the minutia of differences between the two, but then again there's a Stress Betty for just about everything. For the most part, I can't see what the big deal is, unless you're a bigot of some variety. Note I'm only talking about the look and feel here, not functionality. I'm very willing to believe that there are non-bigoted reasons to prefer one platform's native this to the other platform's, but I expect that's functionality/nav much more than look and feel you can attribute to being on a given native platform and using its look and feel.

Games

Is there any native look and feel across gaming whatsoever? Take for example Words with Friends:


Is there any appreciable difference that you can attribute to the particular platform's look and feel? They look pretty much the same to me. They play pretty much the same too. 

I expect that's true of just about any game out there. And the same goes with viewing videos: the look and feel is the payload itself, not anything that the native platform brings to the experience.

[note: I'm most emphatically not implying a web platform is a viable candidate for gaming, just saying that  native look and feel for a major use case for phones is a no-op]

Back to Web Look and Feel

Now let's be clear, Facebook, Twitter, and Words with Friends are huge and create their own wind. But their existence pretty much makes a lie of the notion that it's some platform specific look and feel that is giving them a boost in the minds of their users. I doubt it even enters their users minds at all. To be sure, all of these guys have big budgets to throw at their look, feel, and interaction, but it's clear that a credibly designed app will be accepted by users regardless of whether it conforms to a particular native platform toolkit's look or not.

So what are the implications for using WebViews in apps and/or mobile sites? The high level bit from my standpoint is that it matters far more that the app is designed well for the form factor than any particular look and feel which is typically a secondary aspect of what a user sees with most apps (ie, date pickers, say). 
The nav has to work properly, the buttons have to be big enough, etc, etc. In the early days, that was far more important as people were groping around in the dark trying to figure out what constituted "well designed" for the phone form factor. The Native toolkits definitely gave devs a leg up on that account. But I'd say that was far more of getting both developers and users to come to gradual agreement on what constituted "obvious" and "intuitive" (neither of which happen in the real world, IMO). When they did that, it ceased being particularly important what the bling looks like so long as the bling is pretty.

That said, there still is the bootstrap problem for new apps. Eventually successful apps have their own look and feel and move away from the boring native widgets, but it's useful to have them at your disposal in the beginning. With no budget. Boring is better than outright ugly, after all. And that's the big drawback of the web approach: there isn't a base level widget library to fall back onto that looks familiar and comforting, if a bit stodgy. So you have to suffer through designing all of that crap yourself, and for non-UI kind of people it's probably going to look not so great.

Enter Firefox OS

Think what you will of the concept of booting Gecko on a phone, but there is a potential high level bit that people might be missing if they dismissively predict its uselessness: FFOS too has to provide a "native" widget toolkit to be viable. That is, they need to have high level constructs like date pickers, selector boxes, listviews, modal dialogs, tabs, etc, etc. in order to compete with iPhone and Android. At this time, it doesn't look (from the outside) like they've got much fleshed out, but they do seem to understand that this a necessary baseline that must be provided. It's a little early to tell whether it will be "beautiful", but the high level bit here is that it will exist. And it will exist using regular old -- and standards based -- web technology. (it's really too bad that Palm/WebOS croaked, it too could have provided the same). 

This is potentially very important if they pull it off. Since it's just a bag of js, html and css it can trivially be ported to non-Gecko OS things like, oh say, iPhone and Android webviews. Or to mobile websites. Or even to regular old websites for that matter. Here finally we potentially get back to a solution for Rip Van Webble's expectation that there be widget libraries for the web. And since the widget toolkit effort is its own ends (rather than the usual means to an end for website developers), Moz devs can actually take the same pride and ownership that Apple and Android widget developers take with their respective toolkits. That's important, because then there is incentive to get to parity with what native libraries can do, but using web technology which has huge code reuse advantages for app developers.

Conclusion

I'm really kind of hopeful about this. I think that web technology has been given a bad rap that isn't really its fault per se. It's a victim of the atmospherics and reality distortion fields for the most part, and was abandoned for app/mobile development just as it became a credible player. But so goes fads, and the rush to Native is mainly another fad, in my opinion. Don't get me wrong: I'm glad that Native shook things up, and we'd be much poorer for the experience if we had to wait for W3C to provide everything that Native app api's provide today, but look and feel is something that ought not be one of the reasons that you decide to develop a native app. 

This is why I'd still not use a native app look/feel and their associated native toolkits, even if I had a pile of money to do so. Maintaining two different code bases suck regardless of how much money you have to throw at the problem. Minimizing the differences and reusing code to the degree possible is still a very worthwhile goal. The biggest problem with the Web UI approach is the bootstrap problem given the lack of widget toolkits for your average schmuck web developer. But given FFOS -- and eventually a lot of toolkit imitators if successful -- there is hope that that advantage of Native will be going away. Given that most people don't notice or care that major apps they use day-to-day have little resemblance to a platform specific native app, it shows that native look and feel isn't a disqualifer, per se. The app working well for the form factor is far, far more important. Which, hopefully, emerging web based widget toolkits will give web-centric developers a leg up on.

No comments:

Post a Comment