LWN: Comments on "A simulated FirefoxOS experience"

my guess - it's RPC again

DavidBild — Tue, 08 Jan 2013 13:49:10 +0000

> Mobile devices, even including tablets, spend more time in the
> environment that shows up the flaws in "treat remote things as
> local" models of computation from RPC right up to the modern time.

This, this, this.

Native apps provide a better experience than web apps when the network connection is poor or non-existent. An in-browser app with local caching of data and code could in theory work as well, but the ecosystem just isn't there yet.

If mobile network connections were as omnipresent and reliable as desktop connections, users wouldn't have reason to flock to the native apps.

Platform specific "apps" vs. HTML-based "apps"?

markhb — Fri, 21 Dec 2012 20:14:26 +0000

I mean: once you are starting to write "webapps" in C++ with Qt what's there left from the webapps hype? Delivery channel?

For that matter, how is it functionally different from XUL, which the Mozilla team has been bending over backwards to get away from?

Platform specific "apps" vs. HTML-based "apps"?

redden0t8 — Thu, 20 Dec 2012 15:18:50 +0000

"Whatever happened in the war to make everything a web-application? Are browsers on mobile devices so sub-standard they don't fully support what we loosely call HTML5? The future was supposed to be web-applications... and that was supposed to make developers lives easier. But it seems the reality has become multiple APIs/platforms with developers having to either pick one or more and build/maintain them. Ouch?"

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.

Platform specific "apps" vs. HTML-based "apps"?

man_ls — Thu, 20 Dec 2012 09:12:13 +0000

Perhaps HTTP and its "lack" of certain "features" like server-side push and "full-duplex semantics" [...]

Now we have websockets, invented specifically to remedy those flaws. They work beautifully.

Platform specific "apps" vs. HTML-based "apps"?

Cyberax — Thu, 20 Dec 2012 07:59:40 +0000

> Perhaps HTTP and its "lack" of certain "features" like server-side push and "full-duplex semantics"
Both are easily emulated with long-polling. Which in reality is often better than simple TCP...

Platform specific "apps" vs. HTML-based "apps"?

jengelh — Thu, 20 Dec 2012 06:22:55 +0000

>Whatever happened in the war to make everything a web-application? Are browsers on mobile devices so sub-standard they don't fully support what we loosely call HTML5? The future was supposed to be web-applications...

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.

A simulated FirefoxOS experience

cas — Thu, 20 Dec 2012 00:35:34 +0000

> Why not use the 3x3 grid instead?

Because that would be a theft of valuable intellectual property. The entire world would collapse and billions would starve to death if innovative inventions like that were not protected from parasites and thieves.

BTW, you ought to watch what you're saying - inciting a crime is also a crime

A simulated FirefoxOS experience

mathstuf — Sun, 16 Dec 2012 06:14:04 +0000

Why not use the 3x3 grid instead?

A simulated FirefoxOS experience

xorbe — Sat, 15 Dec 2012 01:18:20 +0000

"That familiarity runs into a hitch at unlock time, though. As with other devices, one starts by making a swipe gesture (upward, in this case) on the screen. But then one must tap a padlock icon to actually unlock the device. There is no explanation of why things were done this way, of course."

While in my pocket, my touch-screen Android can manage to press the power button (side mounted and protrudes ugh), and slight movement is enough to activate the swipe unlock screen (swipe ANY direction lolwtfbbq). Then it starts doing random things in my pocket of course. And THAT'S why you need a 2-step unlock touch screen ...

Another observation is that everyone wants to have a cash-cow marketplace now, like the new "Windows Marketplace OS", er I mean "Windows 8".

recent firefox/iceweasel on debian

mirabilos — Thu, 13 Dec 2012 14:57:58 +0000

Besides, that’s the long-term supported version from the time of the freeze, and it’s still long-term supported by Mozilla. (Hah… just *how* well that works, we’ve seen with Canonical.)

A simulated FirefoxOS experience

sebas — Thu, 13 Dec 2012 11:31:54 +0000

Yes, Plasma can deliver different layouts depending on screensize (and dpi), and also use different widget sets depending on input methods available. (The latter is transparant to the app developer, the former needs simple modifications, such as providing alternative layouts, though it's usually just one file that differs.)

recent firefox/iceweasel on debian

zack — Thu, 13 Dec 2012 10:40:06 +0000

> The extension refused to install on the archaic iceweasel shipped with Debian Testing, but it works well enough on more recent Firefox browsers.

Right. ...but there is the amazing mozilla.debian.net repository, maintained by the same maintainers of firefox/iceweasel in Debian, that offers you the latest and greatest firefox/iceweasel for the all Debian suites :-) See http://mozilla.debian.net/ and enjoy.

Platform specific "apps" vs. HTML-based "apps"?

khim — Thu, 13 Dec 2012 09:10:31 +0000

Because as I said, a significant number of "apps" are really just front-ends to web-based services that should work fine in a browser.

True.

Having to maintain custom builds for each environment is the opposite of what is desired by developers.

I'm not so sure. Form-factors are too different. It's really hard to produce single GUI which works for smartphone, tablet and desktop. And only desktop requires an webapp (because there are no similar delivery channel for traditional applications).

Google with their Chrome browser is trying, I believe but perhaps I misunderstood, to offer a binary runtime environment so they can distribute binaries that run in the browser so browser-based applications don't necessarily have to be HTML/javascript-based.

Sure. As one of NaCl developers I know that very well indeed. But if this is not an admission of webapps failure then I don't know what is. I mean: once you are starting to write "webapps" in C++ with Qt what's there left from the webapps hype? Delivery channel?

It is probably easier to take a mature desktop OS and scale it down for small screen with touch features... than it is to scale a simple GUI shell up to a full-blown desktop environment.

Again: why do you think that? It didn't work that way on minicomputers, it didn't work that way on desktop, why will it work that way on smartphones?

The fact of the matter: it's much easier to scale something up rather then to scale something down. Especially when FOSS is involved: when you need to scale up you just grab bits and pieces from the bigger things and attach them to the existing base, but to scale down you need to somehow cut out the fat yet keep the experience usable.

All the teams (GNOME, KDE, Mozilla, Windows) did that in the same fashion: destroy everything and build new experience from the bits and pieces. But this basically puts them at the beginning of the race again and gives Android huge headstart! Exactly the wrong way to win the race.

Platform specific "apps" vs. HTML-based "apps"?

roc — Thu, 13 Dec 2012 03:24:57 +0000

> Are browsers on mobile devices so sub-standard they don't fully support
> what we loosely call HTML5?

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.

my guess - it's RPC again

tialaramex — Thu, 13 Dec 2012 01:06:48 +0000

Mobile devices, even including tablets, spend more time in the environment that shows up the flaws in "treat remote things as local" models of computation from RPC right up to the modern time. Internet access is patchy, it's available one moment and gone the next, bandwidth varies enormously, two apparently simultaneous things experience apparently different network conditions for whatever freak reason.

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.

A simulated FirefoxOS experience

Lennie — Thu, 13 Dec 2012 00:56:09 +0000

Many websites already support "Responsive Web Design" with the use of the "Media Queries" technlogy which allows completely different designs for different screensizes.

So yes, webtechnologies could fit the bill very well.

But I assume Plasma Active can do that too (I've never looked) ?

Platform specific "apps" vs. HTML-based "apps"?

dowdle — Thu, 13 Dec 2012 00:28:20 +0000

so why would you tolerate awful restrictions of webapps if there are no upside?

Because as I said, a significant number of "apps" are really just front-ends to web-based services that should work fine in a browser. Having to maintain custom builds for each environment is the opposite of what is desired by developers.

And this is different from what happens on desktop, console and other places… exactly how?

Because Apple (and Android to a much lesser degree) is/are constantly referring to the large number of apps they have... and that there is "an app for that". We just don't hear "there's a webapp for that" when it is really also the case.

There is also a mis-perception that making mobile apps is a potential gold mine... but I think the gold rush is mostly over.

Google with their Chrome browser is trying, I believe but perhaps I misunderstood, to offer a binary runtime environment so they can distribute binaries that run in the browser so browser-based applications don't necessarily have to be HTML/javascript-based.

Why do you think Android or iOS can not be extended to become usable on desktop, too?

It is probably easier to take a mature desktop OS and scale it down for small screen with touch features... than it is to scale a simple GUI shell up to a full-blown desktop environment. That is obviously just conjector on my part. Of course we know that Android has a (modified) Linux kernel underneath. The main features for developers are the APIs and various libraries for things. I haven't really seen any serious productivity apps for Android (Softmaker Office and the stylus apps from the Samsung Galaxy Note perhaps?) but I'm sure they do exist. From what I understand the vast majority of games for Android are written in C++ and completely avoid the Java bits. So I have no hard evidence other than Colberting.

Puny platform

man_ls — Thu, 13 Dec 2012 00:16:17 +0000

Eventually smartphones are going to be powerful enough where we can plug them in to a docking station for complete PC usability when we have arrived at our destination... and still use them somewhat productively when they aren't docked.

In fact the OpenWebDevice (the hardware that goes with Firefox OS) is supposed to ship precisely with very limited hardware capabilities -- apparently running HTML5 apps directly is faster than going through an OS. So it will take a long time before Firefox OS is competing with desktops.

Versions

corbet — Thu, 13 Dec 2012 00:04:22 +0000

I ran it fine with the v17 browser shipped with F17.

A simulated FirefoxOS experience

lkundrak — Thu, 13 Dec 2012 00:02:45 +0000

With what browser does it work?
Running latest Firefox ESR it says "Not available," not providing an alternative,

Platform specific "apps" vs. HTML-based "apps"?

khim — Wed, 12 Dec 2012 20:45:38 +0000

Whatever happened in the war to make everything a web-application?

In short? AppStores happened.

In it's heart the fabled "web applications" is a mixture of mediocre-yet-mandatory programming language, mediocre-yet-mandatory presentation layer and crippled API.

You can ask: Why all this mediocrity ever gained any traction?

Well, web-application have one but important property which was unprecedented for a long time: the deliverability.

It's easy to deliver web application to the end user - and s/he can easy to remove it if she does not like it (just close the web browser window).

Every time web application were tried where they had no such intrinsic head start… they failed. All these active desktops and things like Adobe Flex were failures. Well, some people managed to use them to repackage popular web applications and offer them as kinda-native applications, but in most such cases everything started with success on the web and only later it was converted to native application.

And of course with AppStore deliverability is no longer the problem… so why would you tolerate awful restrictions of webapps if there are no upside? If you just want to show HTML you can easily embed appropriate control in your app, after all.

Some analysis of various apps in apps stores shows that the vast majority of them (75% or more) are almost never downloaded/purchased and just gather digital dust... and that the vast majority of mobile app purchases go to a mob of 25 development houses.

And this is different from what happens on desktop, console and other places… exactly how? Most application were failures in the previous decades, too. Well, there is one difference: now, when a lot of applications are in one place you can easily do such measure while previously it was much harder, but is it such a big difference?

That will mean the OS has to offer both a good desktop and mobile experience. I guess a few people are working on that... but I don't really see iOS and Android morphing into a good desktop anytime soon.

Why not? As you've said yourself all contemporary OSes deep down are just Xerox Alto on steroids. Why do you think Android or iOS can not be extended to become usable on desktop, too? It's kind of chicken-end-egg problem (there are few Android devices which can be used in desktop mode), but I don't see anything fundamentally limiting.

A simulated FirefoxOS experience

jspaleta — Wed, 12 Dec 2012 20:41:34 +0000

Is there a similar "simulator" appliance to demo how Active would behave on a phone formfactor while sitting at a desktop/laptop/workstation device, without having to install it on phone hardware?

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

A simulated FirefoxOS experience

ingwa — Wed, 12 Dec 2012 19:23:36 +0000

Your editor has frequently written that, while Android is a great system that has been highly beneficial to the cause of open mobile devices, it would be awfully nice to have a viable, free-software alternative.

I would say that the combination of Mer and Plasma Active is exactly that.

Platform specific "apps" vs. HTML-based "apps"?

juliank — Wed, 12 Dec 2012 17:55:48 +0000

FirefoxOS applications are HTML5, and based on open web standards developed by Mozilla.

Platform specific "apps" vs. HTML-based "apps"?

dowdle — Wed, 12 Dec 2012 17:42:02 +0000

Whatever happened in the war to make everything a web-application? Are browsers on mobile devices so sub-standard they don't fully support what we loosely call HTML5? The future was supposed to be web-applications... and that was supposed to make developers lives easier. But it seems the reality has become multiple APIs/platforms with developers having to either pick one or more and build/maintain them. Ouch?

Some analysis of various apps in apps stores shows that the vast majority of them (75% or more) are almost never downloaded/purchased and just gather digital dust... and that the vast majority of mobile app purchases go to a mob of 25 development houses. I also have to wonder if the bulk of apps that are available are just front-end for web-based services that could easily be accessed from a competent web browsers... and that the app icon is mostly for marketing. Thoughts?

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.

I just don't see the "innovation" that supposedly exists in the crop of mobile OSes we have today. They all remind me of Microsoft Windows 3.1's Program Manager with touch. What does an OS have to do? Provide a display that is touchable and forgiving of sloppy fingers... provide a program launcher... and a way to shop for applications. Yeah, I'm oversimplifying it but really... is how notifications are done offer that much room for innovation?

I'd prefer to see most everything a web-app... with application icons really just browser bookmarks... and of course it would be nice if the web-based applications were locally cacheable and usable without a connection... and offer the ability to sync back when a data connection is available. You know... it should operate like Chrome OS. :) While Chrome OS doesn't seem to have made any inroads in replacing traditional desktops and laptops... perhaps if they put it on tablets and smartphones they could get more traction.

Eventually smartphones are going to be powerful enough where we can plug them in to a docking station for complete PC usability when we have arrived at our destination... and still use them somewhat productively when they aren't docked. That will mean the OS has to offer both a good desktop and mobile experience. I guess a few people are working on that... but I don't really see iOS and Android morphing into a good desktop anytime soon. I'm guessing people disagree with me, eh?