Archive for October, 2012

Time to start building apps for FirefoxOS

WARNING: This post reflects my PERSONAL opinions and not those of Mozilla !

Doing something new requires tenacity. There can be a lot of challenges (emotional, intellectual, financial, etc.)

FirefoxOS is one of those things.

The OS itself is a real community driven, free Open Source project. This, in and of itself, is challenging. Search the web for “Is Android really Open Source” and you will read about some of the issues and challenges.

Then there is the competition. There are 6 billion mobile phone subscriptions in the world, and in the smart-phone segment, Android has 52.2% or the market and Apple has 33.4%. Even Microsoft hasn’t been successful in cracking the smart-phone market, no matter how much marketing they invest in the effort.

And what about the technology? HTML5 is not done yet, is it? It’s not hard to find an “expert” that will tell you HTML5 is not ready for prime time!

So why would you, as a developer, bother starting to build an application for a platform that hasn’t been released yet, on a technology that’s not ready yet, developed by a relatively tiny organization in the industry?

I spend a lot of time at work playing devil’s advocate and having this conversation with the engineering, marketing, and business development teams I work with at Mozilla.

But, after all, Mozilla is the poster child for success against the challenging conditions I just described. The community-driven, open source projects of Firefox and Thunderbird were launched to shake up a market that was already dominated by strong commerical competitors.

Mozilla’s mission has always resonated well with people, especially software developers who care about the free and open web.

And, in my humble opinion, the developer audience who will ultimately buy into Firefox OS is larger and somewhat differentiated from the traditional supporters of the Open Web.

While not all application developers define success in terms of monetary return, the success of all applications is defined by:

  1. The ability to REACH the largest possible percentage of intended users.
  2. The usefulness of the FUNCTION it provides to those users

The function can take many forms.

  1. Monetary gain
  2. Decreased customer service costs
  3. Increased customer satisfaction
  4. Decreased operational costs
  5. Increased or Improved Brand Identity and Affinity
  6. Public Service

There are other considerations like personal preference, choice of technology, hardware, “cool factor” etc., but it’s my contention that all other factors are not “decision pivots” like reach and function are.

So, if the question is “why would developers start building apps today for Firefox OS,” the question can’t be answered without discussing Firefox OS in the context of reach and function.

So, can you really meet your technical needs with HTML5 ?

First, I’m not even going to refer to the development technology as HTML5 because it’s much more than markup language.

Let’s instead call it the Web-Runtime!

  • HTML
  • CSS
  • JavaScript
  • JavaScript callable runtime implemented APIs
  • Related tools, libraries and frameworks

If your goal is to find some application feature that you just can’t make work using the above technology, you probably can find a corner case of some sort, though in the last year I’ve yet to have a developer describe a consumer application use case scenario to me that truly could not be done with Web-Runtime technology.

Yes, the technology is evolving so there are pieces that are not fully “here” yet – but I never suggested you wouldn’t have to get a bit creative if you are starting early in the Firefox OS / Apps ecosystem life cycle.

Apart from feature specific API concerns the other argument I hear is “the performance isn’t there!”

My teammate Rob Hawkes has been doing a lot of performance profiling of HTML5 games since games tend to really expose performances issues. He’s found a number of good games that work just fine written in HTML running on low end devices.

Like all performance considerations when you move platforms. Some optimization may be required.

Ok, so if you buy my argument that technically you could build your app for FirefoxOS, then why WOULD you?

Well, I think this is the interesting part.

First there is the expected reach opportunity .

FirefoxOS devices will start being available in 2013, initially in Brazil.

Eventually I think you’ll see lots of telcom carriers selling them in a variety of emerging and established markets. You see, carriers don’t make money on phones; they make money on services including bandwidth consumption. This means that they are happiest when everyone can afford the phones that will be used the most often and that will promote lots of interaction.

The original code name for Firefox OS was “Boot to Gecko,” referring to fact that the design imperative for the operating system was booting directly to the Gecko rendering engine without the heavily layered stack that you see in other mobile operating systems. This means that it will run well on lower end (less expensive) hardware.

It also suggests that Firefox OS devices will enjoy great success (penetration) in emerging markets. Why is THAT important to developers? (See the Firefox OS Marketplace HERE)

Nearly every mobile industry analyst will tell you that the biggest opportunities in the software industry are in emerging markets. Many (perhaps most) emerging markets have better cellular infrastructure than conventional Internet infrastructure, and many have better cell service (with data) then we have in the U.S.A.or Europe.

There is an entire generation of users who skipped the traditional connected personal computer and went straight to mobile.

On top of that, the apps that you write for Firefox OS phones will also install as native apps on Android phones and tablets with the Mozilla Web-Runtime installed. That’s an additional 300 million devices with hundreds of thousands of new users every day.

And like they say in the ShamWow infomercials, “But wait, there’s more!…..”

Because the entire stack is open, in the near future you’ll be able to run your well designed app on Windows, Mac and Linux Computers. And if Microsoft and Apple permit it, probably iPhone/iPad and Windows Phone / Surface devices too.

That’s one app – everywhere.

Then we will have achieved the idea that “The Web IS the Platform”—t he idea that the whole can be greater than the sum of the parts.

As I side note, I think people continue to be confused about what is an app versus what is a web page. Maybe there is no real answer but if you think outside the box a little, the fact that you can write apps (or web pages) that work even when no or limited connectivity is available create the opportunity to build some really interesting experiences for end users.

Yes, there are some “ifs” in all that logic, but you don’t get to AMAZING by waiting to see what everyone else does.

Before I wrap up, I wanted to hightlight one additional inducement for app development, and that’s the last item on my app functions list above. Enhancing Public Service.

Every day I Mozilla I participate in conversation where people are asking about and talking about “how can we make things better for people?”

For example, at my last organizational team off site, a representative from Medic Mobile came to speak to us about the amazing things they are doing in developing regions of the world to help get desperately needed health care to patients in remote areas.. It was one of the most inspirational talks on the use of technology I’ve heard and it made me think about what could be done with rich Firefox OS smart phones to make people’s lives better around the world.

As an advisor, consultant, industry analyst, throughout my career, I’ve always looked at new and interesting technology and markets and continued to ask the question, “when is the right time to “get in?”

After a year of being involved with HTML5 and mobile technology, I think the time for starting to build apps for Firefox OS is now! At least for many, many kinds of apps and targets.


  1. If you have an HTML5 app or page that you’re considering bringing to FirefoxOS and the Firefox Marketplace, or
  2. You have an Android of iOS app that you’re considering bringing to FirefoxOS and the Firefox Marketplace, or
  3. You have an idea for an app in Brazil, or
  4. You have a Firefox Add-in that you could bring to FirefoxOS and the Firefox Marketplace, or
  5. You just have some other cool idea for an HTML5 app

Then I want to hear from you!!!!

Tell me about your app!

J Stagner AT Mozilla DOT com

User Initiated Resizing

The Firefox Marketplace Aurora Android was released last week so developers can start submitting their HTML5 based apps.

I’ve been working on the interval timer app on and off for some time now and have been using it for experimentation and proof points around HTML5.

In playing with user interface options I wanted a mechanism that would let athletes set the size of the main display element to whatever they wanted. The trick for my app is that they need to be able to do it with little dexterity (like with gloves or hand wraps on) and I wanted it to work on a PC with, or without a mouse, and on an Android Tablet.

So my idea was to allow each important element of the app to be re-sized in one of three ways.

  1. The app is running on a PC with a mouse wheel and when the user places the mouse inside the element and scrolls the wheel, the element will grow or shrink depending on the direction of the scroll action (larger for Up-Scroll and smaller for Down-Scroll).
  2. The app is running on a PC whose mouse does not have a scroll wheel, in which case the user can click and drag to change the element size.
  3. The app is running on a tablet of phone and they should be able to swipe an element to re-size it. (Note: I don’t want to use pinch in this case because my users may be wearing gloves.)

So, I put together a demo.

The demo starts with this……

And after using any of the three methods above the element is re-sized as ….

Note that the resizing actions only work when the mouse or touch events are on the specific element that is to be re-sized.

As is so often the case, there are jQuery plugins handle all of these UI desires.

The code is below. Simple stuff, but another example of a feature that I started out with saying “you can’t do that in HTML.

You can run the dmo HERE

<!doctype html>
      <title>Mousewheel font resizer</title>
      <link rel="stylesheet" type="text/css" href="css/style.css" />
      <script src="js/jquery.js"></script>
      <script src="js/jquery.mousewheel.js"></script>
      <script src="js/jquery.event.move.js"></script>
      <script src="js/jquery.event.swipe.js"></script>
      <script type="text/javascript">

         var TextSize = 1;

         $(function() {
             var currentTime = new Date()
             var month = currentTime.getMonth() + 1;
             var day = currentTime.getDate();
             var year = currentTime.getFullYear();
             $('#TimeDisplay').html(day + "/" + month + "/" + year);

               .mousewheel(function(event, delta, deltaX, deltaY) {
                  var o = '';
                  if (delta > 0) {               
                     o = delta;
                 else if (delta < 0)
                     o = delta;
                  if( o != '' )
                     size( o );
                  return false; // prevent default
               $('#TimeDisplay').on('swipeleft', function(e) {
               $('#TimeDisplay').on('swiperight', function(e) {
               $('#TimeDisplay').on('swipeup', function(e) {
               $('#TimeDisplay').on('swipedown', function(e) {
            function size(msg) {
               TextSize += msg;
               if (TextSize < 1) {
                   TextSize = 1;
            $('#TimeDisplay').css('font-size', TextSize + 'em');
      <br /><br />
      <div id="TimeDisplay">s</div>
      <br />

HTML5 Off Line: Storing and retrieving Videos with IndexedDB

HTML5 Off Line: Storing and retrieving Videos with IndexedDB

There’s some disagreement among developers as to the importance of an offline experience for HTML5 apps. Some people say it’s not that important  because everything is always connected. That may be true if you live in the heart of Silicone Valley but if you live in the hills of New England, like I do, or in Central or South America (where the first Firefox OS devices will ship), then that may not be true.

Personally, I think a great app needs to include an offline strategy. “Adaptive” design shouldn’t be only about the user interface.

You’ve probably heard about HTML AppCache, but AppCache is only designed for certain limited use cases.

Think of media files for example. AppCache is declarative, meaning that you specify the resources that should be downloaded and cached in the cache manifest. AppCache is also non deterministic so it downloads the referenced resources on a best efforts basis, primarily for use “next time”.

In the case of a content driven app, this doesn’t solve all the problems. Take, for example an app for a video podcast. There may be hundreds, or even thousands of video files. The user wouldn’t want the run-time to just start downloading thousands of videos, many of which they may never even watch. The user wants to watch only certain videos and only those certain videos should be downloaded..

Since I pay for band width (both as an application hoster and as an Internet user) I don’t want a preferred video to be download each time a user wants to view it.

HTML5 local storage is not designed for lots of data or for large objects.

Gecko, the engine behind Mozilla Apps and Firefox OS Apps supports an embedded database – IndexedDB.

IndexedDB has been available in Firefox for some time and is mostly implemented in Google Chrome. It will also be implemented in Microsoft’s IE 10.  Safari, Opera, etc have implemented WebSQL which the the W3C has stopped working on.

(The demo that follows did not work in Chroime at the time of this writing, probably related to this issue. Since the focus if this article revolves around Firefox OS and Mozilla Apps I’m not going to try to debug the issue on Chrome at this time. Please email me if you get it to work in Chrome.)

I have to admit that I found IndexedDB a bit daunting when I first started with it. It’s different than the SQL databases that I have worked with because it does not involve user created SQL syntax in order to interact with the database. Instead, it leverages what feels to me more like an  ORM (Object Relation Mapping) approach. If you’re not used to ORM syntax there is a bit of a learning curve but once you adjust to it I think you’ll find that your code reads and gets written in a more fluid manner.

So given the use case described above for a video viewing app, here is the English pseudo code for the app’s function.

  1. Fetch a video from the Internet and download it into the browser DOM.
  2. Store that video in an IndexedDB object store
  3. In response to some user generated event …
  4. Retrieve the previously stored video from the IndexedDB object store.
  5. Play the retrieved Video

The demo starts with an index.html page

Note the  link to the put.html page.

Put.html will automatically start downloading a video file.

See the “WORKING” message ?

When the file has been downloaded and saved that message will change to indicate that you can click the link to move on to the display page.

Here is the put.html markup.

<!DOCTYPE html>
<html lang="en">
      <meta charset="UTF-8">
      <title>HTML5 - Storing a video file IN IndexedDB</title>
      <link rel="stylesheet" href="css/base.css" type="text/css" 
      <div class="container">
         <header class="header" role="banner">
            <h1>Storing a video file IN IndexedDB</h1>
         <div class="main">
            <article class="main-content" role="main">
               <span id="fetchstatus">
                  WORKING : Video File is Downloading
               <br /><br />
               <a href="show.html">
                     Click to DISPLAY a video retrieved FROM IndexedDB
      <script src="js/put.js"></script>

And the included JavaScript file – put.js

I think the code’s functionality is pretty straight forward.

(function () {

   window.indexedDB = window.indexedDB || window.webkitIndexedDB ||
                      window.mozIndexedDB || window.OIndexedDB || 
   var IDBTransaction = window.IDBTransaction || 
                        window.webkitIDBTransaction || 
                        window.OIDBTransaction || 
   var dbVersion = 1.0; 
   var indexedDB = window.indexedDB;
   var dlStatusText = document.getElementById("fetchstatus");

   // Create/open database
   var request ="VideoFiles", dbVersion),
      createObjectStore = function (dataBase) {

      getVideoFile = function () {
         var xhr = new XMLHttpRequest(),
         // Get the Video file from the server."GET", "Heilman-Betts.webm", true);     
         xhr.responseType = "blob";
         xhr.addEventListener("load", function () {
            if (xhr.status === 200) {
                blob = xhr.response;
                dlStatusText.innerHTML = "SUCCESS: Video file downloaded.";
            else {
                dlStatusText.innerHTML = "ERROR: Unable to download video.";
          }, false);

      putVideoInDb = function (blob) {
         var transaction = db.transaction(["Videos"], "readwrite");
         var put = transaction.objectStore("Videos").put(blob, "savedvideo");

    request.onerror = function (event) {
        console.log("Error creating/accessing IndexedDB database");

    request.onsuccess = function (event) {
        console.log("Success creating/accessing IndexedDB database");
        db = request.result;

        db.onerror = function (event) {
            console.log("Error creating/accessing IndexedDB database");
    // For future use. Currently only in latest Firefox versions
    request.onupgradeneeded = function (event) {

Note both the xhr event listener and the onsuccess / onerror methods for IndexedDB funtions which indicate that both APIs are asynchronous.

Now that the video file is stored in the IndexedDB store, we can click on the lick to navigate to the show.html page which will automatically retrieve the video from the IndexedDB store and ready it for playing on the page.

Here is the show.html markup.

<!DOCTYPE html>
<html lang="en">
      <meta charset="UTF-8">
      <title>HTML5 - Storing and Playing Videos with  IndexedDB</title>
      <link rel="stylesheet" href="css/base.css" type="text/css" 
      <div class="container">
         <header class="header" role="banner">
           <h1>Display a video stored in IndexedDB</h1>
         <div class="main">
            <video  id="Video" type="video/webm" controls>
               If you are reading this,
               it is because your browser does not support the 
               HTML5 video element.
                Video MIME type is : <span id="vidMimeDisplay"></span>
      <script src="js/show.js"></script>

And the show.js code…..

(function () {
    // IndexedDB
    window.indexedDB = window.indexedDB || window.webkitIndexedDB || 
                       window.mozIndexedDB || window.OIndexedDB || 
    IDBTransaction = window.IDBTransaction || 
                     window.webkitIDBTransaction ||
                     window.OIDBTransaction || window.msIDBTransaction,
    dbVersion = 1.0;

    var indexedDB = window.indexedDB;

    // Create/open database
    var request ="VideoFiles");
    request.onerror = function (event) {
        // Failed to Open the indexedDB database

    request.onsuccess = function (event) {
		db = request.result;
		// Open a transaction to the database
        var transaction = db.transaction(["Videos"], "readwrite");

        // Retrieve the video file
        transaction.objectStore("Videos").get("savedvideo").onsuccess = 
        function (event) {
        var videoFile =;
        var URL = window.URL || window.webkitURL;
        var videoURL = URL.createObjectURL(videoFile);

        // Set video src to ObjectURL
        var videoElement = document.getElementById("Video");
            videoElement.setAttribute("src", videoURL);

       var mimeDisplayElement = document.getElementById("vidMimeDisplay");
           mimeDisplayElement.innerHTML = videoFile.type;

Which results in…..

Now the video can be watched and re-watched without having to re-download the video for each viewing.

If we configured the player for app caching the videos could even be played with no internet connection. (I’ll do an example of that if a future post.)

[ CLICK HERE ] To download the code.