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.

Web Look and Feel, Part 1 -- Why web development is at a disadvantage over native

When Rip Van Webble first woke up, I fully expected that the abstraction layers on the web design would have followed the window based world's examples by building on the rather primitive world of css, divs, etc and there would be plethora of toolkits with a few dominate ones. Sort of like, oh say, GTK or Cocoa, or QT, and all the rest. But when I asked around, the answer seemed to be "no". No such things had gained any traction that I could tell. JQuery doesn't fit the bill -- it's an abstraction to make dealing CSS easier for the most part, but takes no position in the style wars. Maybe things like Drupal do what I'm thinking of, but they come with a huge amount of other stuff -- it's a CMS first and foremost. I just expected something in between: a standardized date picker, for example. Better modal dialogs than alert(). Etc.

I guess this wasn't entirely surprising thinking back on this. All content was being created for the most part server-side instead of client-side. So that means that a toolkit would have had to either be created for each of the P languages, or people would have had to buy into client-side rendering which was pretty much heresy in the times IE6. Not impossible, but for whatever reasons it never seemed to take off. And then of course browsers were a) slow and b) well, IE6'ed. So everything was hand coded, and there wasn't much pressure to do anything different because the diversity of web life was taken for granted, even if most of it could use an aesthetic comet to snuff it out.

And that comet did come: apps. When the iPhone was released in 2007, it was fawned on as being "beautiful" and all of the other adjectives that Steve Jobs got. It's certainly true that the iPhone was a huge advance over the Windoze phones of the day which were as hideous as they were inappropriate for the form factor. The phone form factor changes everything about UI design, especially on touch screens, but even with keyboards. Nobody had been paying attention to that really. Well, I'm sure that BlackBerry's mail client was serviceable but web browsing was an exercise in torture. The initial iPhone laid down a marker: design for the form factor or be uncool, and most especially extinct. And that of course is exactly what happened to Windoze and BlackBerry. We can thank Steve Jobs for that.

As with many things though, when the herd found out that Apple would allow third party developers to create apps for the iPhone they confused the actual marker: "design for the form factor" with the reality distortion field: "the form factor can only be serviced by native widgets", and of course the only native widgets that would save you from extinction were Cocoa widgets designed by Apple. A great marketing strategy that played perfectly with the iSheep bigot's precepts.

To be fair, there was some reason in 2008 to take a look again at native vs. web. Browsers were just barely coming out of the dark ages where you could get decent cross-browser compatibility with decent feature sets, and javascript was just barely being paid attention to for speed. Doing cutesy animations wasn't impossible, but it wasn't great either compared to a native toolkit which was designed from the beginning to do those cutesy animations. But native toolkits -- especially with Apple -- really have one main purpose: vendor lock in. So Apple threw out some visual bling and everybody forgot in an instant why the web was so important 15 years before: vendor lock in sucks.

So what happened to browsers in the mean time? They've gotten hugely a) faster, b) compatible and c) featureful. And that's true of the browser apps on phones, as well as the WebView widgets you can embed in apps. But apps with WebView's are still considered by many -- especially by the iBigots -- to be poor relations to the "beauty" of native apps. My assertion is that that is mainly Apple marketing BS: a WebView is capable of replicating pixel for pixel what native apps do for the most part. Especially now that processors have gotten so much faster on phones.

What's missing to do that? Web-based toolkits. I understand that things like Sencha and maybe Phonegap try to bridge these two worlds and they claim some amount of success. It's not like laying down pixels on bitmaps is voodoo, after all. You want something that looks like Cocoa? Pay some team to replicate it. You want something  that looks like Android? Pay some team to replicate it. You want to be able to write a base app that can be themed like Android or iPhone depending on what it's running on? Pay for those two teams to be in the same room when the high level API's are designed.

And when you do that, you get back to what the original promise of the web was: no vendor lock in. Which is hugely important for developers these days. It is complete chaos whenever you have to keep two completely separate development teams to design the same app for different platforms and keep feature parity. In reality that parity rarely happens, and worse: usually one platform withers and dies in the long run.

With Phresheez, I took the approach of using WebViews and leveraging them heavily from the very beginning. It wasn't any sort of deep insight on my part, only the realization that I couldn't possibly maintain two different code bases for all of its UI stuff. And we've been dinged for that a lot. In the past, mainly. But a lot of what we got dinged for isn't the fault of the core web technology, it's because I didn't have the money (or inclination, honestly) to hire a team of people to design the look and feel to fool the bigots. But given a pile of money, I could have. More to the point: a lot of Phresheez early problems were my not understanding the form factor itself. Since we started designing it in 2008 we were hardly unique -- not many people understood how to design for the phone form factor. Using native widgets could have helped (and in the beginning we used them a lot more), but it was far more about understanding how people would come to use their phones, and what the accepted wisdom was -- when it was rapidly evolving at the time. C'est la guerre. I think we're in a better place now though.

In the next part of this, I'll explore whether given a pile of money I would  spend it on making Phresheez look like native iPhone/Android apps today.

Authoring Content vs. HTML5 Canvas

One of the great promises of HTML5 is getting to play with real vector graphics again, mainly with the HTML5 canvas tag, but OpenGL too as well as it matures. The canvas tag drawing primitives seems pretty serviceable, though I've not looked at it any real depth. I have experience in a previous life writing the rendering engines for laser printers and graphics terminals so I'm not completely clueless (if a bit rusty).

What strikes me is that there's a real disconnect between the way that web production is done now versus where it eventually needs to go. Right now, Art is generated by graphic artists who give you .png and .jpgs. They hand over the images at the right resolution, and the geeks take it from there more or less. There are no knobs are anything like that with images so it's all very simple.

There really isn't an equivalent production pipeline for HTML Canvas that I've seen. Canvas is a javascript API so the natural thing that the Artist should produce for canvas vector artwork would seemingly be... javascript, right? Which moves the pen up/down/around, fills regions, etc, etc. Yet I haven't actually seen anything take that step. It may be my ignorance, but this is all pretty new and Google was being very equivocal about my search terms, so I'm guessing that I'm not alone groping around for a solution. How do artists and geeks interact in the Canvas world?

Let me give a for instance. In Phresheez, I wanted to create a cute graphic of a skier/boarder where you can click on various pieces of your gear and enter in the manufacturer, etc. That is, I want a customizable avatar. So far so good: I could do this with .png's like normal but I wanted a few features that make .png's problematic like, for example, I want my users to be able to color their parka one way, their skis another, etc, etc. I certainly don't want in the backend to have dozens of different color .png's to cover every combination -- yuck.

So I decided that canvas would a reasonable since it's vector graphics, I can just apply the fill/stroke colors on the fly as its rendering it. Great idea! Should work great!

Except for the disconnect I started out with. I'm a bad enough graphic artist to begin with, so I'm certainly not going to be creating art with naked context2d calls in javascript with lots of trial and error. I needed an authoring tool like, oh say, Google Draw, or Adobe Illustrator, or in my case Inkscape that I happen to have on my linux box. They, of course, have no clue about emitting javascript though. They do know about emitting SVG, but SVG as a native format (regardless of whether you think this is good or bad) is not well supported, especially on mobile browser technology (read: iphone/android) . And in any case, the authoring tools even if they do emit SVG don't really have a way to annotate the SVG in a way that I can manipulate in the geek realm (maybe I'm ignorant, but even then it's beside the point because I don't want SVG in the first place).

But there is some Google code (canvg) that takes SVG input and generates canvas pixels. Which is kind of like what I am looking for, but is still gross. What I did is drew my stuff up in Inkscape and labeled all of my fill colors with special colors and I just do a string replace with them to the appropriate colors. Simple, fast, and utterly grotesque and not scalable with real graphic designers, IMO. And this is a very simple example.

What it seems to me that I want is an authoring tool that both directly emits the javascript to create an object for drawing into a canvas, but also the exposes the knobs that can be played with at execution time. In my case, that would be the ability to affect the color(s) of the objects, but I might want many other knobs too, like, oh say, rotation knobs, scaling knobs, 3d effects knobs, animation features, etc, etc.

So what I really want is both the blob of code that renders the vectors into the canvas bitmap, but also an external set of public methods that I can play with in code to do what I need to do.

Oh, and my graphic designer needs to be able to produce those knobs too, and the answer better not involve my graphic designer understanding anything about programming, let alone javascript. My feeling is that this is an invented wheel in the visual effects business since you need to have discreet objects that real artists design, but obviously need to have attributes and methods for manipulation at higher levels. I know very little about this workflow though, but it seems to me that a vastly simplified Hollywood workflow (we're not creating Shrek MCM here, after all) would be a good place to look. Maybe not take their tools wholesale, but recasting their production pipeline's concepts into discreet functionality that the web can understand, and train both sides (eg Artists, Geeks) for the brave new HTML5 canvas world.

In conclusion, we need some cross pollination from the heavy-duty worlds of Hollywood (and probably the gaming world too) that allows lighter duty webbish vector art to start to grow. Until there's a well-understood set of interfaces between artists and geeks in the vector world, it's going to be slow to take off.