Re: UX gap, was Re: How can HTML5 compete with Native?

On Wednesday, October 23, 2013 at 5:36 PM, Tobie Langel wrote:

> That's precisely the problem, imho. You have to pick a UI library/framework. Then you're kind of stuck with it.  

You don’t *have to*… but it would save you some time and pain if you did.    
> Components from this library most probably don't match default ones, so design consistency is hard to achieve.

Yes, this is a downside to truly cross-platform design and the generic user agent style-sheet - but platform-specific design can be pulled from under a developer on a native platform too, as happens on Android on just about every major release (not to mention that some OEMs use their own UX wrapper, like Samsung) and recently on iOS with version 7 (I have a bunch of apps in iOS that either now look weird or are simply unusable, so anecdotally, I see this happen).   

Having said that, successful apps generally have their own look and feel - integration with some OS-level component behavior (e.g., <select>, various input types, like “email” “url”, etc.) can ease some of that platform consistency pain.  
> These different library/frameworks also don't work together at all.

I don’t think that’s necessarily true (though it may be true in general). For instance, Topcoat is built specifically to just provide the UI components and to be model and controller agnostic. I don’t know how well it achieves this, but at least that’s the sell.  

I know that the guys from PhoneGap encourage people to use handlebars together with Topcoat + require + jQuery. For example:
https://github.com/ccoenraets/phonegap-day-eu/tree/master/part08-final/
  
> So if you've picked library A and need a component x of library B, you're either bound to re-implement it, or will end up bloating your app by adding both libs to it (plus you might bump into weird compat issues).

Yeah, can see that happening. But, at the same time, it’s should be seen as a good thing that developers have a great deal of choice in what frameworks they use to build their apps. This is at least what we want with regards to the extensible web manifesto.   
> Finally, high level components in native platforms can be wired-up really easily to data models (using MVC-like patterns) which means that changes to the data will propagate immediately to the UI.

Yes, some of that is nice. Better data binding options is something that is totally missing today. I imagine Object.observe is going to be a killer feature once it lands too.   
> While such solutions also exist as JS frameworks (Angular, Ember, ReactJS, etc.), you're just adding another level of buying into a framework on top of the UI one you might have picked.


Ok, so my spidey senses are feeling like the data binding aspects might be a significant part of the problem. Mozilla has been toying around with a generic “data source” API that might be useful here [1]. It could provide a generic interface for data (which can come from anywhere, including memory, the device, or remotely)… be nice if there was a way of hooking up HTML elements to those data sources to watch for changes.   
  

[1] Note, they call it “data store”, but I think that’s confusing - https://wiki.mozilla.org/WebAPI/DataStore  
--  
Marcos Caceres

Received on Wednesday, 23 October 2013 17:13:16 UTC