Ubuntu HTML5 SDK
developer.ubuntu.com
developer.ubuntu.com
So we've got this decent platform, we build up HTML apps that end up kludgy compared to IOS or Android native, so you do a 180 and release the official SDK and everyone migrates over; or your product never reaches mass adoption and dies.
Also, ChromeOS and FirefoxOS are browser's so of course they have a vested interest in making their apps in HTML / JS.
Isn't that the point of those platforms?
People say this all the time, and it makes me wonder if I'm living on a different planet than them. I can see some places where native is better:
* A camera app, or a guitar tuner... something that requires access to special APIs. Making that in HTML would be a kludge.
* An app that's targeted at tech people, who want to feel like they're living in the future, and who need to have have fancy transitions and animations and subtle 3d effects.
But in my experience, the vast majority of apps do NOT require those things. Most apps are just buttons and pages and pictures and videos, and for that kind of stuff, I honestly don't see what the advantage of native is over HTML.
Maybe it's because I am an interaction designer. In my experience, the interaction design in most apps, native or HTML, is seriously lacking. It seems like almost no one actually tests their product with actual people. And it seems like very few developers are actually willing to build the dozens of prototypes that are required to iterate through a design in order to get something that actually works well.
And so we end up with all of these native apps that are supposedly "not kludgy" because they have native widgets and 3d animations, but actually are extremely kludgy in that everything you do in them is a pain in the ass.
But again, I hear people ring the native app bell over and over again like it's some major design issue. So maybe I'm just living in a different world.
Also, I'm really interested in what you mean by "the dozens of prototypes that are required..." If you're talking about building several prototypes of the same feature to compare and contrast, would you mind sharing the tools/workflows you use for this?
Finally, towards the very end you might do a few variations within your fully realized native app, but that kind of prototyping is extraordinarily expensive and 90% of your design questions should be answered by that point.
The output of a good design process should include dozens of vastly different looking prototypes, in totally different mediums, each of which helped answer key design questions.
A good introduction to this's stuff is Rogers, Preece and Sharp's "Interaction Design". My personal favorite for diving into the breadth of design techniques is Brenda Laurel's "Design Research".
This is true for very simple apps. But native platforms have developed UI conventions that should be followed for non-trivial apps, and modularity capabilities that should be exploited. Taking Android as the example:
Fragment is the way Android apps scale between small and large displays, and how such apps are modularized.
ActionBar is how commands for fragments are added to "global" UI elements as the Fragment objects appear.
The Share action is how data is moved in the highest-level, user-directed way; Intent and startActivityForResult is how apps borrow UI and capabilities from each other; bound service RPCs is how apps can call each other's APIs. You can't do that with Web apps.
Android arguably has a more powerful feature set for modularity and inter-app cooperation that has been held back from achieving its potential fro users because too many apps started with a Web app or an iOS implementation. Android also has UI conventions that are sophisticated and good-looking and that users will increasingly value apps for adhering to.
The issue of conventions does seem to be the crux of it. They can be powerful, although sometimes people seem to rely on conventions because they can't be bothered to figure out an actual powerful, simple, learnable, comprehensible interface for their application.
A lot of "non-trivial" apps could be made trivial through good design. In the absence of that, yes: if your users have to jump through hoops they better be the conventional hoops.
So in that sense my point remains. But I have no idea what proportion of apps fall into the "could be designed down into something more intuitive" va "is inherently very complex and must rely heavily on conventions" categories.
I should boot up my old Android with the new OS and familiarize myself with the new hotness. When I used it last the conventions like the back button and menus and such we're so randomly applied you couldn't really rely on them anyway.
If you are making a service like Cherry (On-Demand Car Wash) then you need to maximize the responsiveness of the app. HTML still can't do this although HTML->Native could. On the other hand many people want to write new functionality.
HTML is restrictive and results in a subpar product. You get easier development, but its not time saved if you need to redo all your work.
Frankly, if your requirements fit into HTML the your app probably sucks! :-)
The performance is still affected even for simple apps and even if the CPU can handle that degradation, the battery won't. If the application does something, it will take more CPU time and this is bad in ANY way. Why wasting theses CPU cycles? Only because you are "more productive"?
Second argument, security. Inject JAVA into a live app, not impossible, but hard. Inject HTML, easily done... When will we start to see XSS on our applications? HTML5 is literally an eval on every single text field...
Third argument, HTML5 is fantastic? Then use it, nothing stop you. There's multiple way to do it currently, the JS api on Android is complete, you can do anything you want. If the platform doesn't support HTML5, then you can start an open-source project or even a commercial project that will allow it. If we start from the HTML5, you won't be able to go native from that point, you directly block possibilities only because you prefer HTML5.
Facebook tried the HTML5 for their apps, the performance was awful and it wasn't a complex app at all.
Your battery argument only holds if the 'html overhead' is a major part of power usage and there is no evidence it will be (screen on time, radio usage etc., native calls will probably dwarf drawing the UI).
Your security argument also strikes me as weak. 'Wrapped' HTML apps presumably benefit much the same security infrastructure as native apps. Once your app is vulnerable to injection it's pretty much game over no matter what your choice of language.
I have plenty of games that eat more battery than anything on my phone.
Except that like I said in HTML every single text you show is literally an eval call. There's still ton of XSS on website, it's a common security threat, the same will be possible on an HTML5 application (they will even have access to your phone functionality).
I'll agree with you wrt games in HTML/CSS. They are likely to be much less efficient than in native code.
> Except that like I said in HTML every single text you show is literally an eval call.
I don't follow. How come?
This should not be mistaken for something akin to FirefoxOS. Full disclosure: I've dabbled in systems programming on both Cordova (for BB10), and Gecko. Cordova is but a crude approximation to a proper web environment. Long live Gecko!
Curiously, iOS have sort of taken the other path, beginning with only HTML apps and then drifted away somewhat.
And the Modern ObjC (with ARC, @properties, blocks, new @literals, awesome and useful clang errors, etc.) is much, much better than it was around iPhone OS 3.0! The signal/noise ratio of a typical iOS app is now maybe twice that of an app written in the bad old days.
rap, not wrap. Quite an interesting history http://www.todayifoundout.com/index.php/2012/05/its-bad-rap-...
I use Ubuntu on desktops and servers, but I've seen no reason to expect Ubuntu to gain any traction on phones.
Yeah, I think the story was posted here recently. They signed somebody but can't say who it is yet, just that they're "big". There were some hints that the appeal had to do with Android being a big deception built around the "open" concept.
It's not clear to me why they'd want to keep the manufacturer secret.
I would have expected to see something where I only write HTML/JS.