A simulated FirefoxOS experience

So it turns out that you want to do a lot of work in the client. Instead of being just some dumb rendering and a lot of calls to a remote server where all the smarts live, you have two copies of everything, one in the client making things appear to work for the user instantly and another in the server keeping up with the client state whenever there's a window of Internet access. They could be exactly the same, but for a variety of reasons they are more likely to be quite different, maybe not even written in the same programming language.

If you do this perfectly you get a really nice app, something every Nexus / iPad / whatever owner is happy to be using and you contribute to the (false) notion that everywhere has Internet access all the time these days.

Obviously you can't ever quite get it perfect, but as you deviate from the ideal further and further you interfere with the illusion. A spinning "wait" icon appears and the user curses. Somewhat more frustratingly, something they just did magically undoes itself before their eyes as the client state catches up with a server that has lost an update, or reports that an action which seemed possible was actually rejected. Worst of all, the app just freezes, unable to either complete the intended action or return the user to their state of bliss it waits forever for the Internet.

Now, obviously in theory you can implement the "smart client" with enough Javascript and nasty DOM mangling code. But in practice that's a lot more work than using real languages and real toolkits, and it probably always will be. Those "web applications" intended only for the desktop can continue to just do all the heavy lifting in the server and rely on Internet access to pump HTML views to a client, but on a phone or tablet it doesn't and may never work.

You missed something big here. In FirefoxOS all applications, and in fact the UI for every aspect of the device, are all implemented using Web standards --- HTML5, JS, CSS, etc --- and on a fairly low-end device too. See https://github.com/mozilla-b2g/gaia

If anything, FirefoxOS is proof that HTML5 *is* a viable platform on low-end devices --- at least, if you run it closer to the metal than is done on Android or iOS (where Web apps are forced to run above, or at least alongside, large "native" frameworks).

FirefoxOS has an app store, because stores turn out to be useful for discovery, management and monetization. But that's mostly orthogonal to the platform and APIs.

Perhaps HTTP and its "lack" of certain "features" like server-side push and "full-duplex semantics" also factor in towards the decision to make a native app that tries to remedy that by using some non-standard side channel that a regular browser would choke on.

The problem is that all end-users care about is having a snappy, responsive, and functional experience. I don't develop web applications so I can't comment on what's technically possible, but as a long time end user it seems no one can manage to achieve that.

Real world cellular data connections are flakey at best. They can go from 500 kB/s to 0.1 kB/s in a flash, or vanish for 10s of seconds at a time. And that's assuming your users *have* cellular data at all, many simply jump between wifi hotspots. I have yet to see a web app that can handle those conditions gracefully.

You could blame it on the lack of cross-platform standard for locally installing web-apps and caching required data for when connectivity isn't available, but I think Facebook's story is telling. They initially wrote their app by embedding a cross-platform web-app inside an OS-specific shell. The result was terrible. Loading took forever, and would frequently stall indefinitely. Caching never worked as expected, you'd get stale, inconsistent and sometimes erratic results. After trying to refine it for well over a year, they gave up and reimplemented it using as much native code as possible. The result? It handle the flakey connection gracefully. Loading was significantly faster and more reliable, time outs functioned as you'd expect and the caching problems went away. The app looked identical on surface, but the difference was the underlying mechanics actually worked reliably.

Again I'm not a web-app developer, but I'd speculate that the language and APIs just don't allow the low-level control required to handle challenging network conditions gracefully. If they did, you'd think Facebook of all companies could figure out how to make it work.

-----

"While Android does have a slight majority of the mobile marketshare... given the rapid refresh rate of mobile devices (a smartphone average replacement cycle is 11 months)... I don't think Android is necessarily cemented into the mobile fabric... and almost anyone with enough resources could take the Linux underpinnings and slap a graphical shell on top. They'd just have to get handset makers and wireless providers to buy in. So I think the real challenges aren't necessarily technical in nature."

That's exactly it, and that's why IMHO a free/open community mobile OS will never catch on. It's not the technical challenge, it's marketing. It's the ecosystem. It's the "I want that" factor. It's the style. It's about drawing the consumer in. These are all things that big companies excel at, its their bread and butter.

Apple has this aced, once you start to buy-in and have everything working in harmony, you don't want to ever leave. A new phone gets all your data, apps, music etc transfer seamlessly across. Download a song on your phone? It appears on your tablet, computer and wife's phone instantly. Take a picture with your phone and it appears on your computer before you even get home. Import a photo from your SLR to your computer and it appears on your tablet. If you've got all this working, how appealing is a new device that breaks it all? It better have some *very* compelling new features.

Apple's definitely riding the bubble right now that they got from having a head-start on the "modern" smartphone and tablet. I fully expect them to shrink down a little, but they have a firm grip on the high-end and that's not going anywhere anytime soon. This is their specialty. High-end = higher profit margin per device, and when balanced properly = highest total profit.

Google isn't dumb and they're doing their damnedest to try and mirror the ecosystem/lock-in with the Play store, etc. They're doing everything they can to gobble up whatever part of the high-end Apple doesn't have, and take as much of the middle as possible. Their business model is to get the largest number of users as possible, since their product isn't the phone, it's the users.

This leaves the low-end, consisting of people who basically only use the web-browser, facebook and twitter. They take photos, but only to upload to social media. They refuse to spend $ on apps, songs etc and as such are never "locked in" to a brand. This is exactly where I see Firefox OS excelling. A "web" device marketed to "web" users.

*This* is the problem facing a new free, open-community mobile OS. It doesn't matter how technically compelling the OS software is, that's only one small component to success.

My understanding is that Active so far has been targeting 9'' to 12'' tablet-like touch capable formfactors and not the smaller phone formfactors. I'm not sure I've ever seen Active UI/UX demo'd on phone formfactor. Not saying it doesn't play well there. I'm just saying I haven't seen what it looks like there. And I'm not prepared to assume that UI/UX optimizations for the 10''-ish tablet make sense for the pocketable phones.

That being said. Have 2 or 3 distinct open UIs to choose from as a user would not be the worst thing in the world. But man, from an app development standpoint, that's a nightmare right, there is always market pressure on devs to concetrate on the bang-for-the-buck instead of developing for all niche OSes.

If FirefoxOS does nothing else, but enshrine html5 as an open framework that app developers can code in, that can integrate well in multiple disparate mobile interface designs, that will be a big deal. Can we get to the point were html5 app developers can be reasonably certain that their app would work on a FirefoxOS or in Android or in Plasma Active? That would be a win for the ecosystem, regardless of the market penetration of any one UI platform relative to another.

-jef