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.
No comments:
Post a Comment