Keynote on Firefox OS at Campus Party Recife!

NOTE:  I put this up on my blog almost 6 months ago - and never realized it didn't get published at the time!

Chris Heilmann and I just finished our keynote at Campus Party Recife in this lovely Brazillian coastal town.  It's amazing to see the enthusiasm and momentum around Firefox OS in the community.

The boy in the picture is hearing for the first time.

Led by Chris (with some added points on the APIs themselves from me), the presentation started with a short bit about Mozilla's history and (open) values and traced the (very fast) evolution of our Web APIs toward a hardware-accessible web.
 
In the same spirit as we did with the Browser Wars before, we (Mozilla) are taking on the Mobile OS lockout being faced currently in developing countries like Brazil.

Simply put, if you can't afford it, you can't have it!  And an Android phone is alot more expensive (relatively speaking) for a consumer in a developing country like Brazil than it is for us North Americans or Europeans.

By enabling mobile application and content development in longtime-proven technologies like HTML5, CSS and JavaScript, Mozilla aims for critical mass in developer space (meaning there are much lower barriers to entry where any webpage can be an app!)  It's "write once run anywhere" for real, and it's already been around a while.

Already, with Telefonica on board (with their open web device initiative) and talks happening with several more phone and service providers, it's no wonder our audience more than doubled expected capacity!

Typical questions centered around"How will this shake up the existing hegemony?" and "Will this run on my device?"  While we're currently limited by the practical and proprietary limitations of porting hardware abstraction layers, we hope that, for starters, by driving a critical mass of developers toward Open Web Apps and Firefox OS, that we can affect the current of change in this space.

As with all things Mozilla, this followed up with an appeal for community.  Yes, we need YOU, to help us test, to help us develop, to help us translate, and to evangelize in your language.

To this end, there was an appeal to the Evangelism Reps program (which yours truly is test driving at the moment!)

Slides for our presentation are available here with notes  and without notes.  More information and links can be found in the presentations themselves.

Part 2: Setting up Marionette for automating WebAPI testing on B2G

NOTE:  This article is now available as a series of articles on MDN: https://developer.mozilla.org/en/Mozilla/Boot_to_Gecko/  and will be maintained and updated there.

A plug for the Fullscreen, Gamepad, and Mouse Lock gaming APIs

Sometimes, when things are moving as quickly as they generally do here at the Moz (as in the open web generally), the best that one can do is channel the work of others to try and stay on track with everything.   It certainly beats trying to do everything oneself, at the breakneck speed at which envisioning the new technology - and technology itself - unfolds.


On that note, kudos to Dave Humphries,  Rob Hawkes and Chris Pearce for their recent blog posts on these brand new APIs.  And so, by way of a rehash...


Fullscreen, Gamepad and Mouse Lock APIs are available in a single experimental desktop build of Firefox.  There are also builds that support these features here.

These APIs are estimated to land soon in the nightly builds.


The Fullscreen API:


Scheduled to ship in firefox 10 by the end of January, you can still try out some of the examples in the latest nightly builds.


Based on the  W3C's draft spec, this API enables any HTML element to be made "fullscreen", which hides the browsers UI and stretches the element to cover the entire screen area.


To use it, the developer calls void mozRequestFullScreen(), which, if the request is granted (there are security implications here) gets a mozfullscreenchange event back to the specifying element; otherwise a mozfullscreenerror is dispatched.

The user can ESC or F11 to exit full screen mode.   As with YouTube or other fullscreen videos, navigating (ALT+TAB) will cause fullscreen mode to exit.

There is a cross-browser full-screen API example here. 

The Gamepad API:

As directed by the W3C spec, Javascript and Firefox now gives developers the possibility to connect a gamepad directly to the computer (using USB or Bluetooth) - a domain previously only available to gaming consoles and native computer games.  

You can try it out here; note that you''ll need that custom build.   This wiki page contains more implementation specifics.

Rob Hawkes made a great demo video:

The Mouse Lock API:

This API hides the cursor and locks it to the center of the screen, thus enabling developers to make games and visualizations of a 3D world (otherwise the cursor would go off the side of the screen or hit the edge). With the cursor locked, the user can roam X, Y, Z axes without restrictions.

David Humphrey and his students at Seneca College are currently implementing this API based on the W3C spec.

There are demo files available.

We're tracking Mouse Lock API on Bugzilla. You can also check out David Humphrey’s series of posts on the development of the Mouse Lock API.

I'm just now trying these out myself; of course, if you find any issues, please feel free to file a bug.

Mozilla's Web API - on testing a framework.

So, hello again to you all.  It's been ages since I last posted at this space - but for good reason:  I've taken my performance show on the road again, and, at the same time, begun my work at Mozilla.  I find myself, once again, in the happy place of doing, on a daily basis, two different things that I love.

Primarily, my work has been around our Web API, and how we will write -and eventually automate - tests against it.  But how will we do this?

Our API is intended to "expand what the web can do".   One of the most important implications is the ability to access - in a secure fashion - our device hardware from the web.  To that end, there are such things as Vibrator API, Battery API, Settings API, Accelerometer and Sensor API, a new and improved Geolocation API, Sound API....from which we can work our device directly from the web!

So, how does one test a bunch of APIs as a user would use them?    Well, one thing (and I've been involved with such an effort before) is to build an Application Framework - essentially a series of mock-up and atomic apps that each demonstrate a single API.  

Over time, these atomic apps will be folded into more feature rich ones - to demonstrate the capabilities and (hopefully - we're QA after all) reveal any bugs that mixing and matching these APIs will uncover.

Another aspect that is important - particularly where automation is concerned - is a way of getting "golden values".   We will build a series of simple native applications for each OS that will help us to obtain these values for comparison.

Watch this space -  in the (very near) future we will demonstrate how many of the web apis work; how we will build HTML/JS test pages around them and test many of the features as a user would use them; build our golden apps in java and/or python (depending on our target platform), and, eventually, work the lot into an automation framework.   All of the code will be freely available on github.

I'm hoping for many outcomes; one of them being that you will learn (if you don't know already) how any of the technologies depicted here actually work, but also that you might jump in and help out - when the time is ready - by expanding what we've started here and our web api testpages, enriching our automation core apps, and really putting those apis through the paces, at their intended purpose.

Stay tuned!