Wow, what a thing to wake up to! At the heart of the Open Web Device is Mozilla's Boot2Gecko project. I just joined up with Mozilla on B2G a couple weeks ago and it's been an honor to work alongside so many amazing people, with a great goal: building a truly open mobile ecosystem. If you guys have any questions about B2G itself, feel free to ask and I'll do my best to answer.
I had a couple of questions on how you'd implement things like Spotify or Dropbox (i.e. apps that download a bunch of files, or upload existing ones).
And also about how apps would interact with each other (so that I can change out one SMS app for another, but have everything else continue to work).
Oh, and will it support things like different keyboards? I love that on Android I'm not using the home screen, keyboard, email, SMS, or calendar apps, and it all just works fine.
There are probably millions of soon to be unsupported devices, N900 (already left behind), N9 and N950 that could conceivably run this. After all, N900 can run open office and it is the oldest of these devices.
It would be much easier to test and contribute if one had a device already to properly experiment with. My N900 is gathering dust and there is no good replacements for its OS.
web standards is greate but what if I want to port my multiplayer game that uses bluetooth for the communication between devices. How will B2G handle bluetooth and can my B2G app use it?
I'm curious about b2g's security model but I haven't been able to find much of substance about it. Currently I'm pretty sure if you beat gecko you own any firefox tab that's open. Does that mean if you beat it on the phone you own the whole thing?
Until I use this, I'm going to hold off on the excitement everyone seems to have for it.
The tagline is "The Device the developer community is waiting for." That's great for the developer community. Unfortunately, the developer community is a small minority of people and honestly, people don't really care if their device is easy to develop for. People care how good their device is. If a device is easy to develop for, but it's slow, or clunky or crashes all the time or doesn't have features that people expect out of a mobile device, what's the point?
> That's great for the developer community. Unfortunately, the developer community is a small minority of people
I think you underestimate the amount of influence developers have on the rest of the population. If you get developers to love you by making their jobs that much easier, they will go out of their way to promote your product and get other people to start using it. It's in their profit-minded interests to see to it that your product succeeds, because if it doesn't, then they have to bear the costs of doing things the old way.
The quality of the product matters, too, and we'll have to see if this will be a high-quality product. But there's something to be said about getting developers on your side.
Personally, I have not been waiting for another Html driven platform. I don't like Html/Css as a UI framework, I just think it's highly overrated.
Things I like better: Qt/Qml, Wpf because they are much more precise (meaning, I don't have to use an opaque type like "DIV" as a placeholder for a list-view or something else that I really wanted).
I'm amazed how quickly they seem to be moving this. It wasn't that long ago that I first heard about Boot2Gecko (the wiki page is from last July), and now they already have some hardware partners and operators lined up. Quite a difference to the momentum behind MeeGo and Tizen...
I guess a big difference is that the driver here is Mozilla, a foundation that most players in the field don't see as a direct competitor, and which already has a very good name in the web space.
This is actually a big deal. It is a step in the right direction to take care of the missing pieces of mobile app development. I really believe that in 5 years time, "application development" will be just assumed to be web app development and not desktop application development.
Yep, it may not be in 5 years but it's only a matter of time, no matter what native app developers would like you to believe. If we learned one thing from desktops, it was don't underestimate the web. Good to see things start coming back full circle with the mobile web.
I disagree. The thought of maintaining an app with a large code base written in JavaScript doesn't seem like a "step forward" to me. I'd much rather stick with my Android apps object oriented code base and associated tools.
I for one am very excited to see B2G finally ship. I'm anxious to see how well this OS performs and how well thought out is user experience is. I trust Mozilla, they build quality products. The competition is fierce though and the carriers ultimately have too much power here in the US. I really hope B2G is committed to competing in the mobile arena.
"Qualcomm currently delivers the chipset for a large volume of Android based smartphones, which is the DNA of the device. By tightly integrating the Open Web Device with the chipset we will guarantee that any OEM will be able to manufacture a device with very little effort: it will be almost a plug & play procedure."
I think this is a bad idea. Why would you want to lock down the hardware at such an early stage?
Maybe it's prejudice, but I feel uneasy with their connection with Telefonica, after seeing so many Spanish users (including some family members) complain about them
Same can be said about AT&T, Verizon, O2, DTAG/T-Mobile, Rogers, etc. There's no universally good telecom, and someone is always going to be complaining about them.
WebOS also has its own framework. As far as I understand this is about standard web applications (i.e. framework agnostic). F.e. you could build your app in jquery-mobile and make your app communicate with the device through a JavaScript API.
This seems a lot like a webOS with Gecko instead of webkit. This seems interessting as I hope the projects open webOS are building are going to be on which both plattforms can build on.
Doesn't support + signs in email addresses. Awesome. Does not inspire confidence in a platform that is based on internet standards, where email is an important part of communication.
You're right, if they left out the + sign on the beta keyboard UI they probably forgot all the calls to free(), WebSockets, and maybe CSS. Outlook is bleak.
I've always seen mobile web apps winning over native mobile apps in the long term. Jacob Nielsen described as much last week as well but was careful not to put a timeline on it.[1]
Hopefully this project helps make it happen sooner than later.
I hope that some sort of support for inter-app linking is supported.
One of the biggest problems with native apps on iOS and Android is support for moving from one app to another, but still allowing the user to easily return to the originating app.
At the moment, the only native support for this kind of feature that I can think of is maps support. For example, if you click on a Google Maps directions link on OS X, the Google Maps application is opened automatically instead of maps.google.com in the web browser.
Dunno if this would require a dedicated link button that remembers the app you came from to take you back there or not. Perhaps there is a more elegant solution. It's possible that Hypermedia JSON APIs could play a role in helping people move between apps.
Whatever solution is adopted, making it easy for the user to return to the originating app with ease is of utmost important, because this will create an environment where app developers will fill comfortable partnering with other app developers by including inter-app links.
This is about creating an open standard for APIs a phone OS would need to implement so that pretty much any app people have on phones right now can be implemented with web technologies (HTML, CSS, JavaScript). Essentially, any web page can be an app; apps that need access to some sort of hardware capabilities that web pages don't normally have access to would need to have a permissions system of some sort, of course.
It's also about then shipping actual phones with an OS implementing these APIs installed, creating an "app store" to aid in app discovery and whatnot and whatever other pieces of infrastructure are needed to actually get this open standard used.
One long-term goal, of course, is being able to switch phones (or carriers, or phone OSes; whatever choice the consumer wants to make) without losing all your apps; hence the need for an open standard.
Isn't this exactly the same as Google Chromium[1]? Boot a minimal OS and load a web browser to do all the heavy lifting. Don't get me wrong, I think doing it in the open is much better than behind closed doors, I just want to make sure that I'm not missing something.
It looks like all "apps" are web pages. I'm looking forward to seeing how well they can make it run things like Angry Birds.
And how well they deal with background tasks. On Android I can upload my photos in the background, or play music through Spotify (or my MP3 app) while I'm doing other things. Will I be able to do similar things here?
How is this going to handle updates? Obviously the UI/html5 portion will be trivial to update, but Firefox gets updated every six weeks. Is the system core going to lag behind the rest of the Firefox ecosystem, or ami I going to have to rely on my carrier or manufacturer to push out system updates every six weeks?
I see updates as being crucially important as all the system functionality is exposed as html/css/javascript.
I'm also curious how/if they sandbox the device's browser and still keep within their proposed paradigms. Is a malicious website going to be able to exploit my system using XSS?
I'm curious about this too. The FAQ mentions they will update the core browser like Firefox normally does, but I wonder if that means they also need to update the web browser frontend (written in HTML/JS) at those times as well.
I would also like to find out how this is planned. Ideally a Chrome-style auto-update would be great. The bane of mobile web application development is dealing with the lowest common denominator - developing for multiple Android versions is especially painful. Anything to prevent fragmentation will be a good thing, as we all know carriers won't bother updating very often, unless they have a good reason to do so!
Last time I checked, Gecko and all the other browsers still had a long way to go before being fully HTML5 compliant. Chunks of the File API, postMessage, and a variety of other specs are incomplete and underdocumented.
Sites like caniuse.com vastly overestimate what has been sufficiently implemented.
Chrome Apps can use non-standard technologies (WebSQL, for example; and soon Dart), so they won't work in other browsers. In fact, some of those nonstandard technologies won't even work on Chrome when running on another type of device (NaCl apps will not run on ARM).
[+] [-] daeken|14 years ago|reply
[+] [-] AndrewDucker|14 years ago|reply
And also about how apps would interact with each other (so that I can change out one SMS app for another, but have everything else continue to work).
Oh, and will it support things like different keyboards? I love that on Android I'm not using the home screen, keyboard, email, SMS, or calendar apps, and it all just works fine.
[+] [-] kenrikm|14 years ago|reply
[+] [-] left_behind|14 years ago|reply
There are probably millions of soon to be unsupported devices, N900 (already left behind), N9 and N950 that could conceivably run this. After all, N900 can run open office and it is the oldest of these devices.
It would be much easier to test and contribute if one had a device already to properly experiment with. My N900 is gathering dust and there is no good replacements for its OS.
[+] [-] lumba|14 years ago|reply
[+] [-] trotsky|14 years ago|reply
[+] [-] benihana|14 years ago|reply
The tagline is "The Device the developer community is waiting for." That's great for the developer community. Unfortunately, the developer community is a small minority of people and honestly, people don't really care if their device is easy to develop for. People care how good their device is. If a device is easy to develop for, but it's slow, or clunky or crashes all the time or doesn't have features that people expect out of a mobile device, what's the point?
[+] [-] fragsworth|14 years ago|reply
I think you underestimate the amount of influence developers have on the rest of the population. If you get developers to love you by making their jobs that much easier, they will go out of their way to promote your product and get other people to start using it. It's in their profit-minded interests to see to it that your product succeeds, because if it doesn't, then they have to bear the costs of doing things the old way.
The quality of the product matters, too, and we'll have to see if this will be a high-quality product. But there's something to be said about getting developers on your side.
[+] [-] WayneDB|14 years ago|reply
Things I like better: Qt/Qml, Wpf because they are much more precise (meaning, I don't have to use an opaque type like "DIV" as a placeholder for a list-view or something else that I really wanted).
[+] [-] bergie|14 years ago|reply
I guess a big difference is that the driver here is Mozilla, a foundation that most players in the field don't see as a direct competitor, and which already has a very good name in the web space.
[+] [-] mikehuffman|14 years ago|reply
[+] [-] rooshdi|14 years ago|reply
[+] [-] miloco|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] goatslacker|14 years ago|reply
[+] [-] eaurouge|14 years ago|reply
I think this is a bad idea. Why would you want to lock down the hardware at such an early stage?
[+] [-] icebraining|14 years ago|reply
[+] [-] freehunter|14 years ago|reply
[+] [-] TazeTSchnitzel|14 years ago|reply
[+] [-] xlevus|14 years ago|reply
[+] [-] eterps|14 years ago|reply
[+] [-] bergie|14 years ago|reply
Still no core webOS src on http://github.com. We haven't had time or cause for Enyo. Having fun building non-O-O JS/HTML/CSS apps
https://twitter.com/#!/BrendanEich/status/174117089047621632
[+] [-] MatthewPhillips|14 years ago|reply
[+] [-] Thomaschaaf|14 years ago|reply
[+] [-] josegonzalez|14 years ago|reply
[+] [-] fabrice_d|14 years ago|reply
[+] [-] andhow|14 years ago|reply
[+] [-] bradt|14 years ago|reply
[1] http://www.useit.com/alertbox/mobile-sites-apps.html
[+] [-] malandrew|14 years ago|reply
One of the biggest problems with native apps on iOS and Android is support for moving from one app to another, but still allowing the user to easily return to the originating app.
At the moment, the only native support for this kind of feature that I can think of is maps support. For example, if you click on a Google Maps directions link on OS X, the Google Maps application is opened automatically instead of maps.google.com in the web browser.
Dunno if this would require a dedicated link button that remembers the app you came from to take you back there or not. Perhaps there is a more elegant solution. It's possible that Hypermedia JSON APIs could play a role in helping people move between apps.
Whatever solution is adopted, making it easy for the user to return to the originating app with ease is of utmost important, because this will create an environment where app developers will fill comfortable partnering with other app developers by including inter-app links.
[+] [-] drivebyacct2|14 years ago|reply
Which is why Web Intents were modeled after it. They're surely coming to Gecko, if they're not already in place.
[+] [-] tucson|14 years ago|reply
[+] [-] bzbarsky|14 years ago|reply
It's also about then shipping actual phones with an OS implementing these APIs installed, creating an "app store" to aid in app discovery and whatnot and whatever other pieces of infrastructure are needed to actually get this open standard used.
One long-term goal, of course, is being able to switch phones (or carriers, or phone OSes; whatever choice the consumer wants to make) without losing all your apps; hence the need for an open standard.
[+] [-] Corrado|14 years ago|reply
1: http://www.chromium.org/chromium-os
[+] [-] AndrewDucker|14 years ago|reply
And how well they deal with background tasks. On Android I can upload my photos in the background, or play music through Spotify (or my MP3 app) while I'm doing other things. Will I be able to do similar things here?
[+] [-] notatoad|14 years ago|reply
[+] [-] runjake|14 years ago|reply
I'm also curious how/if they sandbox the device's browser and still keep within their proposed paradigms. Is a malicious website going to be able to exploit my system using XSS?
[+] [-] azakai|14 years ago|reply
[+] [-] fiznool|14 years ago|reply
[+] [-] samarudge|14 years ago|reply
[+] [-] akoumjian|14 years ago|reply
Sites like caniuse.com vastly overestimate what has been sufficiently implemented.
[+] [-] dannyr|14 years ago|reply
I hope an app built for Chrome will work for OpenWebDevice & vice-versa.
[+] [-] azakai|14 years ago|reply
[+] [-] zobzu|14 years ago|reply
[+] [-] mrsebastian|14 years ago|reply
[+] [-] TazeTSchnitzel|14 years ago|reply