Mozilla

Articles by Havi Hoffman [Editor]

Sort by:

View:

  1. QuaggaJS – Building a barcode-scanner for the Web

    Have your ever tried to type in a voucher code on your mobile phone or simply enter the number of your membership card into a web form?

    These are just two examples of time-consuming and error-prone tasks which can be avoided by taking advantage of printed barcodes. This is nothing new; many solutions exist for reading barcodes with a regular camera, like zxing, but they require a native platform such as Android or iOS. I wanted a solution which works on the Web, without plugins of any sort, and which even Firefox OS could leverage.

    My general interest in computer vision and web technologies fueled my curiosity whether something like this would be possible. Not just a simple scanner, but a scanner equipped with localization mechanisms to find a barcode in real-time.

    The result is a project called QuaggaJS, which is hosted on GitHub. Take a look at the demo pages to get an idea of what this project is all about.

    Reading Barcodes - teaser_500

    How does it work?

    Simply speaking, the pipeline can be divided into the following three steps:

    1. Reading the image and converting it into a binary representation
    2. Determining the location and rotation of the barcode
    3. Decoding the barcode based on the type EAN, Code128

    The first step requires the source to be either a webcam stream or an image file, which is then converted into gray-scale and stored in a 1D array. After that, the image data is passed along to the locator, which is responsible for finding a barcode-like pattern in the image. And finally, if a pattern is found, the decoder tries to read the barcode and return the result. You can read more about these steps in how barcode localization works in QuaggaJS.

    The real-time challenge

    One of the main challenges was to get the pipeline up to speed and fast enough to be considered as a real-time application. When talking about real-time in image-processing applications, I consider 25 frames per second (FPS) the lower boundary. This means that the entire pipeline has to be completed in at least 40ms.

    The core parts of QuaggaJS are made up of computer vision algorithms which tend to be quite heavy on array access. As I already mentioned, the input image is stored in a 1D array. This is not a regular JavaScript Array, but a Typed Array. Since the image has already been converted to gray-scale in the first step, the range of each pixel’s value is set between 0 and 255. This is why Uint8Arrays are used for all image-related buffers.

    Memory efficiency

    One of the key ways to achieve real-time speed for interactive applications is to create memory efficient code which avoids large GC (garbage collection) pauses. That is why I removed most of the memory allocation calls by simply reusing initially created buffers. However this is only useful for buffers when you know the size up front and when the size does not change over time, as with images.

    Profiling

    When you are curious why a certain part of your application runs too slow, a CPU profile may come in handy.

    Firefox includes some wonderful tools to create CPU profiles for the running JavaScript code. During development, this proved to be viable for pinpointing performance bottlenecks and finding functions which caused the most load on the CPU. The following profile was recorded during a session with a webcam on an Intel Core i7-4600U. (Config: video 640×480, half-sampling barcode-localization)

    alt=

    The profile is zoomed in and shows four subsequent frames. On average, one frame in the pipeline is processed in roughly 20 ms. This can be considered fast enough, even when running on machines having a less powerful CPU, like mobile phones or tablets.

    I marked each step of the pipeline in a different color; green is the first, blue the second and red the third one. The drill-down shows that the localization step consumes most of the time (55.6 %), followed by reading the input stream (28.4 %) and finally by decoding (3.7 %). It is also worth noting that skeletonize is one of the most expensive functions in terms of CPU usage. Because of that, I re-implemented the entire skeletonizing algorithm in asm.js by hand to see whether it could run even faster.

    asm.js

    Asm.js is a highly optimizable subset of JavaScript that can execute at close to native speed. It promises a lot of performance gains when used for compute-intensive tasks (take a look at MASSIVE), like most computer vision algorithms. That’s why I ported the entire skeletonizer module to asm.js. This was a very tedious task, because you are actually not supposed to write asm.js code by hand. Usually asm.js code is generated when it is cross-compiled from C/C++ or other LLVM languages using emscripten. But I did it anyway, just to prove a point.

    The first thing that needs to be sorted out is how to get the image-data into the asm.js module, alongside with parameters like the size of the image. The module is designed to fit right into the existing implementation and therefore incorporates some constraints, like a square image size. However, the skeletonizer is only applied on chunks of the original image, which are all square by definition. Not only is the input-data relevant, but also three temporary buffers are needed during processing (eroded, temp, skeleton).

    In order to cover that, an initial buffer is created, big enough to hold all four images at once. The buffer is shared between the caller and the module. Since we are working with a single buffer, we need to keep a reference to the position of each image. It’s like playing with pointers in C.

    function skeletonize() {
      var subImagePtr = 0,
        erodedImagePtr = 0,
        tempImagePtr = 0,
        skelImagePtr = 0;
     
      erodedImagePtr = imul(size, size) | 0;
      tempImagePtr = (erodedImagePtr + erodedImagePtr) | 0;
      skelImagePtr = (tempImagePtr + erodedImagePtr) | 0;
      // ...
    }

    To get a better understanding of the idea behind the structure of the buffer, compare it with the following illustration:

    Buffer in Skeletonizer

    The buffer in green represents the allocated memory, which is passed in the asm.js module upon creation. This buffer is then divided into four blue blocks, of which each contains the data for the respective image. In order to get a reference to the correct data block, the variables (ending with Ptr) are pointing to that exact position.

    Now that we have set up the buffer, it is time to take a look at the erode function, which is part of the skeletonizer written in vanilla JavaScript:

    function erode(inImageWrapper, outImageWrapper) {
      var v,
        u,
        inImageData = inImageWrapper.data,
        outImageData = outImageWrapper.data,
        height = inImageWrapper.size.y,
        width = inImageWrapper.size.x,
        sum,
        yStart1,
        yStart2,
        xStart1,
        xStart2;
     
      for ( v = 1; v < height - 1; v++) {
        for ( u = 1; u < width - 1; u++) {
          yStart1 = v - 1;
          yStart2 = v + 1;
          xStart1 = u - 1;
          xStart2 = u + 1;
          sum = inImageData[yStart1 * width + xStart1] +
            inImageData[yStart1 * width + xStart2] +
            inImageData[v * width + u] +
            inImageData[yStart2 * width + xStart1] +
            inImageData[yStart2 * width + xStart2];
     
          outImageData[v * width + u] = sum === 5 ? 1 : 0;
        }
      }
    }

    This code was then modified to conform to the asm.js specification.

    "use asm";
     
    // initially creating a view on the buffer (passed in)
    var images = new stdlib.Uint8Array(buffer),
      size = foreign.size | 0;
     
    function erode(inImagePtr, outImagePtr) {
      inImagePtr = inImagePtr | 0;
      outImagePtr = outImagePtr | 0;
     
      var v = 0,
        u = 0,
        sum = 0,
        yStart1 = 0,
        yStart2 = 0,
        xStart1 = 0,
        xStart2 = 0,
        offset = 0;
     
      for ( v = 1; (v | 0) < ((size - 1) | 0); v = (v + 1) | 0) {
        offset = (offset + size) | 0;
        for ( u = 1; (u | 0) < ((size - 1) | 0); u = (u + 1) | 0) {
          yStart1 = (offset - size) | 0;
          yStart2 = (offset + size) | 0;
          xStart1 = (u - 1) | 0;
          xStart2 = (u + 1) | 0;
          sum = ((images[(inImagePtr + yStart1 + xStart1) | 0] | 0) +
            (images[(inImagePtr + yStart1 + xStart2) | 0] | 0) +
            (images[(inImagePtr + offset + u) | 0] | 0) +
            (images[(inImagePtr + yStart2 + xStart1) | 0] | 0) +
            (images[(inImagePtr + yStart2 + xStart2) | 0] | 0)) | 0;
          if ((sum | 0) == (5 | 0)) {
            images[(outImagePtr + offset + u) | 0] = 1;
          } else {
            images[(outImagePtr + offset + u) | 0] = 0;
          }
        }
      }
      return;
    }

    Although the basic code structure did not significantly change, the devil is in the detail. Instead of passing in the references to JavaScript objects, the respective indexes of the input and output images, pointing to the buffer, are used. Another noticeable difference is the repeated casting of values to integers with the | 0 notion, which is necessary for secure array access. There is also an additional variable offset defined, which is used as a counter to keep track of the absolute position in the buffer. This approach replaces the multiplication used for determining the current position. In general, asm.js does not allow multiplications of integers except when using the imul operator.

    Finally, the use of the tenary operator ( ? : ) is forbidden in asm.js which has simply been replaced by a regular if.. else condition.

    Performance comparison

    And now it is time to answer the more important question: How much faster is the asm.js implementation compared to regular JavaScript? Let’s take a look at the performance profiles, of which the first one represents the normal JavaScript version and the second asm.js.

    Image Stream Profile

    image-stream-profile-asm

    Surprisingly, the difference between the two implementations is not as big as you might expect (~10%). Apparently, the initial JavaScript code was already written clean enough, so that the JIT compiler could already take full advantage of that. This assumption can only be proven wrong or right if someone re-implements the algorithm in C/C++ and cross-compiles it to asm.js using emscripten. I’m almost sure that the result would differ from my naïve port and produce much more optimized code.

    getUserMedia

    Besides performance, there are many other parts that must fit together in order to get the best experience. One of those parts is the portal to the user’s world, the camera. As we all know, getUserMedia provides an API to gain access to the device’s camera. Here, the difficulty lies within the differences among all major browser vendors, where the constraints, resolutions and events are handled differently.

    Front/back-facing

    If you are targeting devices other than regular laptops or computers, the chances are high that these devices offer more than one camera. Nowadays almost every tablet or smartphone has a back- and front-facing camera. When using Firefox, selecting the camera programmatically is not possible. Every time the user confirms access to the camera, he or she has to select the desired one. This is handled differently in Chrome, where MediaStreamTrack.getSources exposes the available sources which can then be filtered. You can find the defined sources in the W3C draft.

    The following snippet demonstrates how to get preferred access to the user’s back-facing camera:

    MediaStreamTrack.getSources(function(sourceInfos) {
      var envSource = sourceInfos.filter(function(sourceInfo) {
        return sourceInfo.kind == "video"
            && sourceInfo.facing == "environment";
      }).reduce(function(a, source) {
        return source;
      }, null);
      var constraints = {
        audio : false,
        video : {
          optional : [{
            sourceId : envSource ? envSource.id : null
          }]
        }
      };
    });

    In the use-case of barcode-scanning, the user is most likely going to use the device’s back-facing camera. This is where choosing a camera up front can enormously improve the user experience.

    Resolution

    Another very important topic when working with video is the actual resolution of the stream. This can be controlled with additional constraints to the video stream.

    var hdConstraint = {
      video: {
        mandatory: {
          width: { min: 1280 },
          height: { min: 720 }
        }
      }
    };

    The above snippet, when added to the video constraints, tries to get a video-stream with the specified quality. If no camera meets those requirements, an ConstraintNotSatisfiedError error is returned in the callback. However, these constraints are not fully compatible with all browsers, since some use minWidth and minHeight instead.

    Autofocus

    Barcodes are typically rather small and must be close-up to the camera in order to be correctly identified. This is where a built-in auto-focus can help to increase the robustness of the detection algorithm. However, the getUserMedia API lacks functionality for triggering the auto-focus and most devices do not even support continuous autofocus in browser-mode. If you have an up-to-date Android device, chances are high that Firefox is able to use the autofocus of your camera (e.g. Nexus 5 or HTC One). Chrome on Android does not support it yet, but there is already an issue filed.

    Performance

    And there is still the question of the performance impact caused by grabbing the frames from the video stream. The results have already been presented in the profiling section. They show that almost 30%, or 8ms of CPU time is consumed for just fetching the image and storing it in a TypedArray instance. The typical process of reading the data from a video-source looks as follows:

    1. Make sure the camera-stream is attached to a video-element
    2. Draw the image to a canvas using ctx.drawImage
    3. Read the data from the canvas using ctx.getImageData
    4. Convert the video to gray-scale and store it inside a TypedArray
    var video = document.getElementById("camera"),
        ctx = document.getElementById("canvas").getContext("2d"),
        ctxData,
        width = video.videoWidth,
        height = video.videoHeight
        data = new Uint8Array(width*height);
     
    ctx.drawImage(video, 0, 0);
    ctxData = ctx.getImageData(0, 0, width, height).data;
    computeGray(ctxData, data);

    It would be very much appreciated if there were a way to get lower-level access to the camera frames without going through the hassle of drawing and reading every single image. This is especially important when processing higher resolution content.

    Wrap up

    It has been real fun to create a project centered on computer vision, especially because it connects so many parts of the web platform. Hopefully, limitations such as the missing auto-focus on mobile devices, or reading the camera stream, will be sorted out in the near future. Still, it is pretty amazing what you can build nowadays by simply using HTML and JavaScript.

    Another lesson learned is that implementing asm.js by hand is both hard and unnecessary if you already know how to write proper JavaScript code. However, if you already have an existing C/C++ codebase which you would like to port, emscripten does a wonderful job. This is where asm.js comes to the rescue.

    Finally, I hope more and more people are jumping on the computer vision path, even if technologies like WebCL are still a long way down the road. The future for Firefox might even be for ARB_compute_shader to eventually jump on to the fast track.

  2. Videos and Firefox OS

    Before HTML5

    Those were dark times Harry, dark times – Rubeus Hagrid

    Before HTML5, displaying video on the Web required browser plugins and Flash.

    Luckily, Firefox OS supports HTML5 video so we don’t need to support these older formats.

    Video support on the Web

    Even though modern browsers support HTML5, the video formats they support vary:

    In summary, to support the most browsers with the fewest formats you need the MP4 and WebM video formats (Firefox prefers WebM).

    Multiple sizes

    Now that you have seen what formats you can use, you need to decide on video resolutions, as desktop users on high speed wifi will expect better quality videos than mobile users on 3G.

    At Rormix we decided on 720p for desktop, 360p for mobile connections, and 180p specially for Firefox OS to reduce the cost in countries with high data charges.

    There are no hard and fast rules — it depends on who your market audience is.

    Streaming?

    The best streaming solution would be to automatically serve the user different videos sizes depending on their connection status (adaptive streaming) but support for this technology is poor.

    HTTP live streaming works well on Apple devices, but has poor support on Android.

    At the time of writing, the most promising technology is MPEG DASH, which is an international standard.

    In summary, we are going to have to wait before we get an adaptive streaming technology that is widely accepted (Firefox does not support HLS or MPEG DASH).

    DIY Adaptive streaming

    In the absence of adaptive streaming we need to try to work out the best video quality to load at the outset. The following is a quick guide to help you decide:

    Wifi or 3G

    Using a certified Firefox OS app you can check to see if the user is on wifi or not.

    var lock    = navigator.mozSettings.createLock();
    var setting = lock.get('wifi.enabled');
     
    setting.onsuccess = function () {
      console.log('wifi.enabled: ' + setting.result);
    }
     
    setting.onerror = function () {
      console.warn('An error occured: ' + setting.error);
    }

    https://developer.mozilla.org/en-US/docs/Web/API/Settings_API

    There is some more information at the W3C Device API.

    Detecting screen size

    There is no point sending a 720p video to a user with a screen smaller than 720p. There are many ways to get the different bounds of a user’s screen; innerWidth and width allow you to get a good idea:

    function getVidSize()
    {
      //Get the width of the phone (rotation independent)
      var min = Math.min($(window).innerHeight(),$(window).innerWidth());
      //Return a video size we have
      if(min < 320)      return '180';
      else if(min < 550) return '360';
      else               return '720';
    }

    http://www.quirksmode.org/m/tests/widthtest.html

    Determining internet speed

    It is difficult to get an accurate read of a user’s internet speed using web technologies — usually they involve loading a large image onto the user’s device and timing it. This has the disadvantage of having to send more data to the user. Some services such as: http://speedof.me/api.html exist, but still require data downloads to the user’s device. (Stackoverflow has some more options.)

    You can be slightly more clever by using HTML5, and checking the time it takes between the user starting the video and a set amount of the video loading. This way we do not need to load any extra data on the user’s device. A quick VideoJS example follows:

    var global_speedcount = 0;
    var global_video = null;
    global_video = videojs("video", {}, function(){
    //Set up video sources
    });
     
    global_video.on('play',function(){
      //User has clicked play
      global_speedcount = new Date().getTime();
    });
     
    function timer()
    {
      var diff = new Date().getTime() - global_speedcount;
      //Remove this handler as it is run multiple times per second!
      global_video.off('timeupdate',timer);
    }
     
    global_video.on('timeupdate',timer);

    This code starts timing when the user clicks play, and when the browser starts to play the video it sends timing information to timeupdate. You can also use this function to detect if lots of buffering is happening.

    Detect high resolution devices

    One final thing to determine is whether or not a user has a high pixel density screen. In this case even if they have a small screen it can still have a large number of pixels (and therefore require a higher resolution video).

    Modernizr has a plugin for detecting hi-res screens.

    if (Modernizr.highresdisplay)
    {
      alert('Your device has a high resolution screen');
    }

    WebP Thumbnails

    Not to get embroiled in an argument, but at Rormix we have seen an average decrease of 30% in file size (WebP vs JPEG) with no loss of quality (in some cases up to 50% less). And in countries with expensive data plans, the less data the better.

    We encode all of our thumbnails in multiple resolutions of WebP and send them to every device that supports them to reduce the amount of data being sent to the user.

    Mobile considerations

    If you are playing HTML5 videos on mobile devices, their behavior differs. On iOS it automatically goes to full screen on iPhones/iPods, but not on tablets.

    Some libraries such as VideoJS have removed the controls from mobile devices until their stability increases.

    Useful libraries

    There are a few useful HTML5 video libraries:

    Mozilla links

    Mozilla has some great articles on web video:

    Other useful Links

  3. Build Your Next App With a Flame

    Update:This program is now closed. We are no longer accepting new “phones for apps” proposals for Apps on a Flame. The form to submit is no longer available. Thanks for all the great apps built or ported for Firefox OS. If you’re still working on an app, we can’t wait to see it live in Firefox Marketplace.

    Earlier this week, we introduced Flame, the Firefox OS reference device for developers, testers and reviewers from T2Mobile, and announced the opening of the everbuying.com pre-order page. The Flame retails at $170 (USD), global shipping included.

    Wanted: Engaging apps for Firefox OS

    Flame2If you are an experienced HTML5 app developer with a published, well-rated app that you’d like to port to Firefox OS, we’d love to hear from you! It’s always exciting to discover topnotch apps (such as PhoneGap app Find the Movie, pictured to the right running on a Flame) and see them ported from native platforms to Firefox OS. We currently have a small inventory of Flame phones for qualified HTML5 app developers with published, well-rated apps.

    How to qualify

    Through our ongoing Phones for Apps program, there’s an opportunity now for a limited number of invited app developers to receive Flame devices in exchange for a commitment to port their qualifying HTML5 apps within a month of receiving the device. Please apply here.

    There are only three ways to qualify:

    1. You’ve built a successful, well-rated HTML5 app on another platform (such as Amazon Web Apps, Blackberry WebWorks, Chrome Web Store, WebOS, Windows Phone or the PhoneGap store) and are ready to port it now to Firefox OS.
    2. You’ve built a successful, well-rated native app for iOS or Android using a cross-platform wrapper like Cordova or PhoneGap and are ready to port it to Firefox OS. Be sure to indicate the cross-platform tool you used.
    3. You’ve already published a well-rated app in Firefox Marketplace, and you have a second app in progress or already built, and are ready to port it now to Firefox OS.

    Resources

    • Learn more about the Flame (Mozilla Developer Network)
    • Get started with Open Web Apps (Mozilla Developer Network)
    • Mark your calendars for Marketplace Day, June 26 – it’s all about Apps and how you can contribute – as app developers, testers, reviewers and localizers. Hope you can join us!
  4. Firefox OS App Workshop Prague

    Update:This event will be rescheduled for Autumn 2014. We are designing the workshop with a new regional focus and aim to re-open the invitation request form with a confirmed date and venue before the summer starts. Please stay tuned here on the Hacks blog.

    Back in March, Mozilla tech evangelist Frédéric Harper visited Prague in the Czech Republic and gave a talk at the local Prague JavaScript meetup. His presentation, Empower Mobile Web Developers With JavaScript and WebAPI introduced a roomful of Czech JavaScripters to Firefox OS, Open Web Apps, and our recent integration with Apache Cordova and Adobe PhoneGap. PhoneGap/Cordova developers who’ve built native apps for other platforms and stores can now port PhoneGap-built apps to Firefox OS.

    Just as sure as the coming of summer, Firefox OS is coming to the Czech Republic in 2014, and Fred and friends are heading back to Prague to host a full-day, invitation-only Firefox OS App Workshop on Saturday, June 28. There will be phones! All participants will receive a developer device to test and demo their apps, and to keep for future app development. For free.

    Requirements: Show us your app

    REQUIRED: To qualify for this free hands-on, technical workshop, you must be able to show us a published HTML5 app that you’re porting to Firefox OS or a working Firefox OS app in progress. Show us a link to your existing app or to working code for the app you’re building.

    Apply now for the Prague App Workshop, June 28, 2014.

    FoxSay500


    NOTE: If you do not provide relevant links to working app code we will not be able to consider your application. Firefox Marketplace currently offers plenty of tic-tac-toe games, sliding puzzles, calculators, and to-do list apps. We love to be impressed by new, original, and locally relevant apps, for work and play.

    In the Czech Republic, we need apps that are in Czech. And if you want to extend the reach of your app by translating it to other languages, we have a pilot localization program to help you.

    What to expect

    This workshop is open to individual developers and teams of up to 4 people. The workshop begins with a technical introduction in English in the morning; the rest of the time is for coding and testing your app using the App Manager that’s built in Firefox Developer Tools. Bring laptops and devices.

    At the close of the day, there will be demos of all the apps in progress. After demos, we’ll all go to dinner. Mozilla will provide food and drink throughout the day of the workshop, but travel and lodging arrangements are up to you. And after the workshop, we will stay in touch while you complete your apps and submit them to Firefox Marketplace.

    Resources

    If you don’t have a Firefox OS app in progress, here are some resources to help you get started. There’s never been a better time:

  5. The Translation of the Firetext App

    The History

    Firetext is an open-source word processor. The project was started in early 2013 by @HRanDEV, @logan-r, and me (@Joshua-S). The goal of the project was to provide a user-friendly editing experience, and to fill a major gap in functionality on Firefox OS.

    Firetext 0.3Firetext 0.3

    In the year since its initiation, Firetext became one of the top ten most popular productivity apps in the Firefox Marketplace. We made a myriad of new additions, and Firetext gained Dropbox integration, enabling users to store documents in the cloud. We also added Night Mode, a feature that automatically adjusts the interface to the surrounding light levels. There was a new interface design, better performance, and web activity support.

    Even with all of these features, Firetext’s audience was rather small. We had only supported the English language, and according to Exploredia, only 17.65% of the world’s population speak English fluently. So, we decided to localize Firetext.

    The Approach

    After reading a Hacks post about Localizing Firefox Apps, we determined to use a combination of webL10n and Google Translate as our localization tools. We decided to localize in the languages known by our contributors (Spanish and German), and then use Google Translate to do the others. Eventually, we planned to grow a community that could contribute translations, instead of just relying on the often erratic machine translations.

    The Discovery

    A few months passed, and still no progress. The task was extremely daunting, and we did not know how to proceed. This stagnation continued until I stumbled upon a second Hacks post, Localizing the Firefox OS Boilerplate App.

    It was like a dream come true. Mozilla had started a program to help smaller app developers with the localization process. We could benefit from their larger contributor pool, while helping them provide a greater number of apps to foreign communities.

    I immediately contacted Mozilla about the program, and was invited to set up a project on Transifex. The game was on!

    The Code

    I started by creating a locales directory that would contain our translation files. I created a locales.ini file in that directory to show webL10n where to find the translations. Finally, I added a folder for each locale.

    locales.ini - Firetext

    I then tagged each translatable element in the html files with a data-l10n-id attribute, and localized alert()s and our other scripted notifications by using webL10n’s document.webL10n.get() or _() function.

    It was time to add the translations. I created a app.properties file in the locales/en_US directory, and referenced it from locales.ini. After doing that, I added all of the strings that were supposed to be translated.

    app.properties - Firetext

    webL10n automatically detects the user’s default locale, but we also needed to be able to change locales manually. To allow this, I added a select in the Firetext settings panel that contained all of the prospective languages.Settings - Firetext

    Even after all of this, Firetext was not really localized; we only had an English translation. This is where Transifex comes into the picture.

    The Translation

    I created a project for Firetext on Transifex, and then added a team for each language on our GitHub issue. I then uploaded the app.properties file as a resource.

    I also uploaded the app description from our manifest.webapp for translation as a separate resource.

    Firetext on Transifex

    Within hours, translations came pouring in. Within the first week, Hebrew, French, and Spanish were completely translated! I added them to our GitHub repository by downloading the translation properties file, and placing it in the appropriate locale directory. I then enabled that language in the settings panel. The entire process was extremely simple and speedy.

    The Submission

    Now that Firetext had been localized, I needed to submit it back to the Mozilla Marketplace.  This was a fairly straight forward process; just download the zip, extract git files, and add in the API key for our error reporting system.

    In less than one day, Firetext was approved, and made available for our global user base.  Firetext is now available in eight different languages, and I can’t wait to see the feedback going forward!

    The Final Thoughts

    In retrospect, probably the most difficult part of localizing Firetext was supporting RTL (Right To Left) languages.  This was a bit of a daunting task, but the results have totally been worth the effort!  All in all, localization was one of the easiest features that we have implemented.

    As Swiss app developer Gerard Tyedmers, creator of grrd’s 4 in a Row and grrd’s Puzzle, said:

    “…I can say that localizing apps is definitely worth the work. It really helps finding new users.

    The l10n.js solution was a very useful tool that was easy to implement. And I am very happy about the fact that I can add more languages with a very small impact on my code…”

    I couldn’t agree more!

    Firetext Editor - Spanish

    Editor’s Note: The Invitation

    Have a great app like Firetext?  You’re invited too!  We encourage you to join Mozilla’s app localization project on Transifex. With a localized app, you can extend your reach to include users from all over the world, and by so doing, help to support a global base of open web app users.

    For translators, mobile app localization presents some interesting translation and interface design challenges. You’ll need to think of the strings you’re working with in mobile scale, as interaction elements on a small screen. The localizer plays an important role in creating an interface that people in different countries can easily use and understand.  Please, get involved with Firetext or one of our other projects.

    This project is just getting started, and we’re learning as we go. If you have questions or issues not addressed by existing resources such the Hacks blog series on app localization, Transifex help pages, and other articles and repos referenced above, you can contact us. We’ll do our best to point you in the right direction. Thanks!

  6. Wanted: Awesome HTML5 app ports for Firefox OS & the Open Web

    A bit of background

    In 2013, Mozilla and our partners launched Firefox OS in fourteen markets. We released three Firefox OS smartphone models and a Geeksphone developer preview device. Our Developer Relations team hosted eight invite-only workshops for app developers around the world: Mountain View, London, Madrid, Bogota, Warsaw, Porto Alegre, Guadalajara, and Budapest. This year, Firefox OS will launch on more devices in more countries around the world. We continue to grow Firefox Marketplace with new and engaging HTML5 apps that run on Firefox OS devices.

    Through our Phones for Apps program, we’ve shipped hundreds of Geeksphones to app developers around the world. Developers like you ported existing HTML5 apps to Firefox OS, and got to keep the developer preview devices we sent. Huge thanks to hundreds of these pioneers in scores of countries who delivered apps to Firefox Marketplace!

    What’s new: Phones for Cordova/PhoneGap ports

    This year we’re focused on finding the very best apps — apps that deliver great experiences and local relevance to Firefox OS users. For HTML5 app developers, powerful cross-platform tools make it easier to build apps for native platforms and to access native device APIs. This week we introduced the Firefox OS Cordova 3.4 integration, which makes it possible to release Cordova apps on the Firefox OS platform. While this is an ongoing project, significant functionality is available now with the 3.4 release of Apache Cordova. Yesterday’s post describes how to use these new capabilities to port your existing app or apps.

    If you’ve already built apps with Cordova/PhoneGap this is a unique opportunity to port your apps quickly and easily. We’ve heard from developers who successfully migrated PhoneGap apps to Firefox OS over a weekend — taking hours, not weeks or months. And we know there are great PhoneGap apps out there. For this reason, the third phase of our popular and successful Phones for Apps program will focus exclusively on app “porters” with currently popular and well-rated Cordova/PhoneGap apps. (NOTE: HTML5 applications can be packaged as native apps via the framework and made available for installation. Cordova is the underlying software in the Adobe product PhoneGap.)

    Who should apply

    Works_w_PhoneGap

    If you’re a Cordova/PhoneGap developer with published HTML5 apps on any platform, we invite you to participate in the Phones for Cordova/PhoneGap Apps program. Show us your well-rated listed app and if it’s a fit for Firefox Marketplace, we’ll ship you a developer device and help you through the process of getting your app into the Firefox Marketplace. Here’s how it works:

    • Apply here: Phones for Cordova/PhoneGap Ports application.
    • All submissions will be reviewed as they are received. We’ll let you know if your application is accepted.
    • Once you commit to porting your app, we’ll send you a device.

    Upcoming Firefox OS workshops & hack events

    In addition to our online Phones for Cordova/PhoneGap Ports program, we plan to host a limited number of invitation-only Firefox OS App Workshops in new locales. We’re excited to announce a workshop in the beautiful city of Prague in the Czech Republic, date to be set next quarter. The enrollment form is open and we are accepting applications from qualified HTML5 developers.

    REQUIRED: You must have a Firefox OS app in progress or a published HTML5 app that you’re porting to Firefox OS. Show us a link to your existing app or to working code for the app you’re building. If you don’t provide relevant links to working app code we will not consider your application.

    Apply now for the Prague App Workshop.

    What if you don’t live near Prague in the Czech Republic? Don’t worry! We plan to offer several other app workshops this year and we’ll announce them here.

    hackday_devices

    Whether you’re just getting started or you’ve already built apps for Firefox OS, there are many hackathons, App Days, and other events hosted or sponsored by Mozillians and happening around the world where you can participate and learn. Find out about community-driven Firefox events hosted by Mozilla Reps as well as talks and events that include Mozilla participants across the planet.

  7. Write Elsewhere, Run on Firefox OS

    Over the last year we’ve been recruiting developers who’ve already built apps for various Open Web and HTML5 platforms: apps for native platforms built with PhoneGap, Appcelerator Titanium or hand-coded wrappers; HTML5 apps built for Amazon Appstore, Blackberry Webworks, Chrome Dev Store, Windows Phone, and WebOS; and C++ apps translated to JavaScript with Emscripten. We’ve supported hundreds of developers and shipped devices all over the world to test and demo Firefox Apps. If you have a well-rated, successful HTML5 app on any platform we urge you to port it to Firefox OS: We’re betting it will be worth your while.

    In November, Firefox OS launched in Hungary, Serbia, Montenegro and Greece. Earlier this month we launched in Italy. In 2014, we launch in new locales with new operators, with new devices in new form factors. We anticipate more powerful cross-platform tools in 2014, and closer integration with PhoneGap and Firefox Developer Tools. It is the best of times for first-mover advantage.

    Here’s a look at just a few of the successful ports we’re aware of. We spoke with skilled HTML5 app developers who’ve participated in “app port” programs and workshops and asked them to describe their Firefox app porting experience.

    RunOnFirefoxOSCaptain Rogers, by Andrzej Mazur; Reditr by Dimitry Vinogradov & David Zorycht; Aquarium Plants by Diego Lopez

    Aquarium Plants (Android w/ hand-coded native wrapper)

    App: Aquarium Plants Developer:Diego Lopez Original platform: Google Play Store

    Time:

    Aquarium Plants is written with our own JavaScript code and simple HTML5 code: we just used two common JavaScript frameworks (Zepto.js and TaffyDB.js). It took me about 3 hours or less. Most of the time was reading forums and documentation.

    Recommendations:

    It is extremely easy to build/port apps for Firefox OS. It is great that we can use web tools and frameworks to create native apps for Firefox OS. I recommend that other developers start developing Firefox Apps; it is almost effortless and a great experience.

    Challenges:

    The only challenge I had was finding out how to build the package. It was amazing when I realized that building for Firefox OS was as easy as creating a zip with the app files and manifest.

    Calc (iOS w/ hand-coded native wrapper)

    App: Calc Developer: Markus Greve Original platform: iOS w/ hand-coded native wrapper

    Time:

    It was really easy. That’s why I would sign the claim “Write Elsewhere, Run on Firefox OS.” I think it took about two evenings with night #1 getting the app to run and night #2 doing some fine-tuning for display size of the simulator and Keon. Afterwards another evening for app icon and deployment to the Marketplace ;-) .

    Recommendations:

    I would recommend that developers give it a try to see how easy it really is. I think Mozilla.org is doing a great job and your support for developers is excellent. I already made a short presentation about how to create FirefoxOS Apps as a documentation of my experiences. You can see it here: A Firefox OS app in five minutes (in English). There’s also a blog post called App Entwicklung fur den Feuerfuchs that documents my experience in German.

    Challenges:

    1. I use OSX 10.9 Mavericks and the Simulator crashed with the old plugin and ran more stably with Firefox 1.26b and app-manager. 2. The need to have a subdomain per app — it seems there’s an open issue with this. 3. Data types in JSON Manifest (I tried “fullscreen”: true instead of “fullscreen”: “true”). My fault: Solved by sticking to the documentation. 4. I have the feeling that the icon sizes are different in the documentation to the sizes really needed for the Marketplace. Also, it’s not sensible to offer a Photoshop-Template for a 60×60 pixel Icon when you need much bigger files elsewhere (256×256 for the store I think). It would be better if you provided a template for 1024 and the user then shrank the images afterwards. 5. Suggestion: The correlation between navigator.mozApp.checkInstalled() and .install() could be explained more comprehensively.

    Calcula Hipoteca – Amazon Appstore

    App: Calcula Hipoteca Developer: Emilio Baena Original platform: Amazon Appstore

    Time:

    It was easy. I took a few hours.

    Recommendations:

    You are doing good work with this platform.

    Challenges:

    I had problems with manifest.webapp, I think that I missed having more documentation about this type of file.

    Captain Rogers (HTML5 Desktop)

    App: Captain Rogers Developer: Andrzej Mazur Original platform: HTML5 Desktop

    Time:

    The whole process of porting Captain Rogers for the Firefox OS platform took me only two weeks of development with an additional two weeks of testing and bug-fixing. In the core concept the game was supposed to be simple so I could focus on the process of polishing it for Firefox OS devices and publishing it in the Firefox Marketplace.

    Challenges:

    There weren’t any big problems, because basically building for Firefox OS is just building for the Web itself. Firefox OS devices are the long-awaited hardware for the mobile web — it is built using JavaScript and HTML5 after all. My main focus on making the game playable on the Firefox OS device was put on the manifest file. I had some problems with getting the orientation to work properly, but during the Firefox OS App Workshop in Warsaw I received great help from Jason Weathersby and at the end of the day the first version of the game was working very smoothly and a few days later it was accepted into the Firefox Marketplace. For optimizing the code I recommend this handy article by Louis Stowasser and Harald Kirschner — it was very helpful for me. Also, the Web Audio API is still a big problem on mobile, but it works perfectly in Captain Rogers, launched on the Firefox OS phone.

    Recommendations:

    The main message is simple: if you’re building HTML5 games for Firefox OS, you’re building them for the Open Web. Firefox OS is the hardware platform that the Web needs and in the long run everybody will benefit from it as the standards and APIs are battle-tested directly on the actual devices by millions of people. If you want to know more about HTML5 game development I can recommend my two creations: my Preparing for Firefox OS article and HTML5 Gamedev Starter list. You should also read this great introduction by Austin Hallock. The community is very helpful, so if you have any problems or issues, check out the HTML5GameDevs forums for help and you will definitely receive it. It’s a great time for HTML5 game development, so jump in and have fun!.

    Cartelera Panama (Appcelerator Titanium)

    App: Cartelera Panama Developer: Demostenes Garcia Original platform/wrapper: Appcelerator Titanium

    Time:

    It was pretty easy to get up to speed on the development flow for Cartelera. The development for Firefox OS is easy, since it’s well documented and HTML5 + JavaScript makes it *really* easy to make apps.

    Challenges:

    Our UX/UI team at Pixmat Studios is very centered on usability, and that’s why we choose Titanium over PhoneGap (better user experience) so our main challenge was to make it look as a real Firefox OS application. In the end, we decided to go with real Firefox OS Building Blocks, instead of using Titanium for the UI. We decided to:

    • Extract all the business logic for the App (which handles the schedules, movies, listings, etc.) to its own Git repository/module. Then we reuse everything on Titanium and Firefox OS, using native user experience for all the three platforms we now accept.
    • Another issue we had was to actually implement an OAuth client on our phone in a good way. However Jason Weathersby pointed out good resources on that matter for us.

    Recommendations:

    Firefox OS and the environment (debug, etc) is easy for a regular web developer, so we didn’t need extra knowledge for making real mobile apps.

    • Use Firefox OS Building Blocks for UI. It’s easy to get a native UI experience with no fuzz.
    • Firefox OS at the Mozilla MDN will be your best friend :-).
    • GitHub has some good projects to learn from, so create an account (if you still don’t have one) and look for demo projects.

    Fresh Food Finder (PhoneGap)

    App: Fresh Food Finder Developer: Andrew Trice Original platform/wrapper: PhoneGap

    Time:

    PhoneGap support is coming for Firefox OS, and in preparation I wanted to become familiar with the Firefox OS development environment and platform ecosystem. So… I ported the Fresh Food Finder, minus the specific PhoneGap API calls. The best part (and this really shows the power of web-standards based development) is that I was able to take the existing PhoneGap codebase, turn it into a Firefox OS app AND submit it to the Firefox Marketplace in under 24 hours!

    Recommendations:

    Basically, I commented out the PhoneGap-specific API calls, added a few minor bug fixes, and added a few Firefox-OS specific layout/styling changes (just a few minor things so that my app looked right on the device). Then you put in a mainfest.webapp configuration file, package it up, then submit it to the Marketplace. If you’re interested, you can check out progress on Firefox OS support in the Cordova project, and it will be available on PhoneGap.com once it’s actually released. (Editor’s note: Look for release news in early 2014.)

    Picross (WebOS)

    Picross: Picross Developer: Owen Swerkstrom Original platform: WebOS

    Time:

    Picross was installed and running on FxOS within minutes of getting my hands on a device.

    Challenges:

    I did have to make some touch API tweaks, but that just meant some quick reading.

    Recommendations:

    My favorite quote was “You’re not porting to FirefoxOS, you’re porting to the Web!” Also, Firefox OS (and Firefox browser) Canvas support is sensational. My next game will use Canvas, for sure. In my case, the “porting” path was really simple. My game already ran in a browser, and it had originally been designed to run on the Palm Pre, a device with the exact same resolution as the lowest-end FirefoxOS phone. But the concept of installing an app involves nothing more than visiting a website: that’s what really made it painless, and that is what’s really unique about FirefoxOS. It has an “official” app marketplace, but unlike every other smartphone ever made, it doesn’t _need_ one! As a user, this is liberating. I can install any web app, from any site I want. As a developer, the story’s even better. I don’t even need Mozilla’s permission to publish an app on this platform. I don’t need to put my device into a special developer mode, or buy any toolkit, or build on any specific platform. If I can put up a website, I’m good to go. Even though I just called it “unnecessary”, the Firefox Marketplace has given me nothing but good experiences. I don’t need to bundle up, sign, and upload any package — I just enter a URL and type up some descriptive blurbs. Review times have always been short, and are even quicker now than when I started. When I submitted Halloween Artist, it was approved almost immediately, and the reviewer suggested that I write up a blog entry for Mozilla Hacks about how I’d put it together. This is both a traditional “marketplace” with the featured apps etc, and a community of geeks celebrating interesting code and novel ideas. That is absolutely the world I want my apps to live in. Before I went to the Mozilla workshop, I was considering what approach to take for an action/adventure game that I’m still working on. I was torn between writing some C OpenGL code, waiting for the not-yet-released-at-the-time SDL 2.0, or, as a longshot, doing at least some prototyping in HTML5 canvas. After learning that Canvas operations on a FirefoxOS phone basically go right to the framebuffer, and after trying some experiments and seeing for myself the insane performance I could get out of these cheap little ARM devices, I knew I’d be ditching C for the project and writing the game as a web app. I’d highly recommend investigating Canvas for your next game, even if you’ve mostly done Flash or SDL etc. before.

    Reditr (Chrome Dev Store)

    App: Reditr Developer: Dimitry Vinogradov & David Zorycht Original platform: Chrome Dev Store

    Time:

    It took us about a week to port everything over from Chrome to Firefox OS.

    Challenges:

    One challenge we faced when creating Reditr for Firefox OS was the content security policy (CSP). One of the great things about web applications for users is that they can see an entire overview of the permissions that a given app requires. For developers though, it can take some time to learn how to create a content security policy. For Reditr, it took us several days of trial and error to learn how the security policy effected our app.

    Recommendations:

    Make sure you understand how your app deals with the content security policy. Check to see if the APIs you use have oAuth support since this can help remedy CSP issues.

    Speed Cube Timer – Blackberry Webworks

    App: Speed Cuber Timer Developer:Konstantinos Mavrodis Original platform: Blackberry Webworks

    Time:

    It took about half an hour to make the exported web app compatible with Firefox OS. (Insanely fast, don’t you think? :) )

    Challenges:

    No real challenges here that I can recall of. Everything was almost a piece of cake!

    Recommendations:

    My recommendation to fellow devs would be them to port their HTML5 apps to Firefox OS as soon as possible! Porting a Web app has never been easier. Firefox OS is a promising OS that shows the great power of Web Development!

    Squarez (C++)

    App: Squarez Developer: Patrick Nicolas Original platform: C++ with Emscripten

    Emscripten and C++ usage:

    I have always preferred statically typed and compiled languages as they fit better with my way of organizing software. There are several options with Emscripten, and I have decided to write the game logic in C++ and the user interface in HTML/CSS/JavaScript. All the logic code is in C++, and for multiplayer mode, server can reuse everything and only has roughly 500 additional lines of code.

    Time:

    The game has always been a web project: the initial development, from scratch, took nearly 1 month. Porting it to be a Firefox application only took a couple of days, in order to make the manifests and icons. Performance tweaking has been a complex task and took nearly as much time as the rest of development.

    Challenges:

    Squarez is the first game I have ever written and it is the first time I have used Emscripten, that was the first challenge. Writing a web application is not really a challenge any more, because good quality documentation is available everywhere. Second challenge was tweaking performance, once I had received the Geeksphone Keon, I saw that the game was so slow that it was almost unplayable. I have used performance tools from native compiled code and both desktop Firefox and Chromium to find the bottlenecks. Because of Emscripten JavaScript generation, it was not very easy to track the faulty functions, I had to deal with partially mangled names in profile view. The following step was to optimize CSS, and I have only found tools to check time spent in selector processing. It is impossible to know which specific animation is taking time, I had to use very manual methods and try disabling individual ones, guess what is taking time and change it blindly.

    Recommendations:

    My recommendation for other developers is to choose technologies they like; I wanted structured and statically typed code, so Emscripten/C++ was a great solution. I would also discourage creating an application that only works in Firefox OS, but take advantage of standards to make it available to any browser and have Web APIs used to enhance the application. If you want to also include a link to the code repository, it is available at squarez.git. Everything is GPLv3+, fork it if you want.

    Touch 12i (Windows Phone)

    App: Touch 12i Developer: Elvis Pfutzenreuter Original platform: HTML5 for Windows Phone (and other platforms)

    Time:

    It took one day to do the bulk of the work, and another day for final details, including registration in Marketplace. Later, I added payment receipt checking which took me the best part of a day since it needs to be well tested. But this effort could be reused readily for another app (Touch 11i).

    Challenges:

    In general, porting was very easy. I put it to work in one day. The biggest problem was the viewport: that works differently in other platforms (all Webkit-based). For Firefox, I had to use a CSS transform-based approach to fit the calculator in screen. Touch 12i is an HTML5 app that runs on Windows Phones and it works in the same way for Android and iOS too: a “shell” of native code with a Web component that cradles the main program. Currently the Firefox version is the only one that is “purely” HTML5. (I used to have a pure Web-based version for iOS as well, but this model has been toned down for iOS.) I’ve written a detailed blog post called Playing With Firefox OS, about my experience participating in the Phones for App Ports program. And that’s a wrap. Thanks for reading this far. If you’re a Firefox OS App porter, a web developer or simply a curious reader, we’d love to hear from you. Leave a comment or send us a note at appsdev@mozilla.com.

  8. New Firefox OS App Workshops & Other Updates

    Here in the virtual headquarters of Mozilla’s geo-distributed tech evangelism team, we always have bags packed and traveling shoes on. Today we’re happy to announce a couple of new Firefox OS App Workshops for web developers: we’ll be in Guadalajara, Mexico, on Saturday, October 26, and we’ll be in Budapest, Hungary, on Saturday, November 23.

    Who should apply

    Remember, these are full-day hands-on technical workshops for developers who are already working on building or porting mobile apps for Firefox Marketplace. You must apply to participate and we will give a preference to developers who can show us a Firefox OS app in progress or a listed HTML5 web app that’s ready to port. Try to arrive at the Workshop with app code already running in the Firefox Simulator.

    bogota_workshop

    At the workshop, you’ll spend the day working on your app with help from our team, with breaks for meals and snacks. Our first activity will show you how to send your app from the Simulator to the Geeksphone Keon Firefox OS Developer Preview device. At the end of the day, there’s a chance to demo the app you’re working on. After the workshop, the Geeksphone is yours to keep, to complete your Firefox OS app and continue to use. Our goal is to help you finish your first app and see it listed in Firefox Marketplace. We’re especially interested in apps built in your language, for people in your location.

    Firefox OS App Workshop, October 26, Guadalajara, MX: Apply here.

    Firefox OS App Workshop, November 23, Budapest, HU: Apply here.

    How to prepare

    Getting started with Open Web Apps – why and how will help you get started. Once you’ve installed the Firefox OS Simulator, and spent a little time reading the documentation, there are many other useful articles about Firefox OS on the Hacks blog. On the Mozilla Developer Network, you’ll find abundant documentation for app developers.

    captrogers

    Update: Phones for app ports

    Thanks to everyone who applied for our Phones for app ports program. Submissions to this program are now closed. We share your enthusiasm and look forward to seeing all your apps listed in Marketplace. We hope to finish reviewing all submissions this week, so please be patient just a little bit longer if you haven’t heard from us. Please note: If your proposal is not accepted, you will not receive a notification.

    If your proposal is selected, you will receive an acceptance email from Mozilla, followed by a notification from the shipper with more information. Once your phone is shipped and your app is in progress, someone on our team will contact you and be available if you need help to get your app done and listed. We are probably a week or two behind on shipping phones, so again, please bear with us. In some countries, we are working through some specific shipping issues. Thanks everyone for your patience. We regret that we can’t respond to every email inquiry.

    Special kudos to those app developers who’ve already received phones and gotten their apps ported and listed in Marketplace. We are super-proud of you and we know there are more of you every day. Together we can build the open mobile web. Thank you!

  9. Calling All Porters: Phones for App Ports to Firefox OS

    Back in May we launched a program for app developers called Phones for Apps for Firefox OS. We heard from thousands of developers in all corners of the world– thank you for your overwhelming interest.

    Developers at BrazilJS by holmes.josh
    Since then we’ve shipped out heaps of Geeksphone Keon Firefox OS Developer Preview phones and we’ve listed many new apps in Firefox Marketplace, including games like Rooftops and Yatzy, and L’Arrosoir, a lovely French language garden app. If you’ve built and submitted your app, thank you! Hope the rest of you are making good progress.

    Phase 2 now open

    Today we’re opening up the second phase of Phones for Apps for Firefox OS. This phase is about sending you a device (for keeps!) to make it easier for you to PORT and test your existing HTML5 app. We’re hyper-focused on getting Firefox OS phones into the hands of porters – developers who’ve already built and shipped an HTML5 web app and have the time now to port that app to the new Firefox OS platform.

    Help Mozilla bring the open web to the world of mobile — and gain yourself a first-mover advantage in the Firefox Marketplace.

    First step: Apply.

    Guidelines

    Here’s what you need to know when you apply.

    • We expect to see a URL for a web site, a code repository, or an app platform such as Amazon Web Apps, Blackberry WebWorks, Chrome Web Store, webOS, or the PhoneGap store. If you wrapped an HTML5 app with a native skin to distribute it to iTunes, Google Play or another app market, please indicate the tool you used (e.g., Appcelerator, PhoneGap, Sencha).
    • You must be able to get to work quickly. We are looking for completed apps in September and October.
    • Don’t wait to hear from us. Get started now by downloading the Firefox OS Simulator.
    • REMINDER: If you can’t point us to a live HTML5 app, you will not be eligible for this program.

    Introducing Firefox OS

    Apply

    We look forward to reviewing your application. We’ll send an email confirmation when you complete the form. Then we will be in touch only if you are selected to receive a phone. Otherwise you will not hear from us. Thanks for your understanding. (We’re a really small team.)

    Can’t wait to see your awesome ported apps. Apply now!

    Photo credits: Thanks to Josh Holmes for the great shot from BrazilJS and to MozillaEU for the image from the Firefox OS Debut Poland.

  10. Phones for Apps for Firefox OS

    Update: Today, Wednesday, June 19, we began inviting app developers with winning Firefox OS app proposals to join the Phones for Apps program. We will begin shipping Geeksphones to app developers who’ve committed to building and porting apps for Firefox OS. Congratulations.

    Thanks to everyone who participated by sending a proposal. The open mobile web needs your interest and enthusiasm. And your apps!

    Whether or not you receive an invitation now, the Marketplace is open and there’s never been a better time to submit your apps. We regret we can’t respond to the thousands of you with great ideas for apps for Firefox OS. There will be other opportunities to get access to the the Developer Preview device. We can’t wait to see what you build.

    Hello HTML5 app developers, the open mobile web is calling.

    We know you’re out there, chomping at the bit, coding, testing, reading documentation, downloading and running the Firefox Simulator. And you’re ready to ‘Send to Device.’ You just need to get your hands on a device.

    Today we’re announcing a new program with you in mind. We call it: Phones for Apps for Firefox OS.

    Firefox Marketplace on the Geeksphone

    Firefox Marketplace on the Geeksphone Keon

    Maybe you’ve built apps in the past for Chrome, webOS, Blackberry WebWorks, or the PhoneGap store. Maybe you’ve created beautiful web apps for a desktop environment and now you want to port them to mobile. Maybe you’re a student about to start a summer break. We know you may not live anywhere near Bogota, Colombia or Warsaw, Poland, locations of upcoming App Workshops.

    Wherever you are

    Wherever you are, if you can show you’ve got a great app idea and the skill to build it, we’d love to see your apps in the Marketplace when the Firefox OS launch begins later this summer. And to sweeten the deal, we’ll send a Firefox OS Developer Preview device for you to work with now.

    When Firefox OS phones become available to consumers in select locales this summer, you’ll have an opportunity that only comes around once—a first-mover advantage in Firefox Marketplace. End users in Latin America, Eastern Europe and other launch locations will be on the lookout for playful and practical apps to install: games, tools, and utilities as well as locally relevant news, sports, travel, entertainment, review apps, and social sharing experiences. And you can build and submit them now!

    Apply now

    Tell us about the Firefox App you’d like to build or port. If your proposal is accepted, we’ll send you a Geeksphone Keon. Our device inventory is limited and our launch dates are approaching fast, so act now. This program will close at the end of May or when our limited supply of Geeksphones runs out. There’s a limit of one phone per app proposal. We can’t wait to see what you’re working on. There’s never been a better time to get started.

    Note: We are not accepting applications for the Phones for Apps program at this time.