February Updates – Mobile and Responsive Design

We thought it would be helpful to review the fundamentals of web design for aspiring web professionals in this article.

Responsive Web design is a Web design approach aimed at crafting sites to provide an optimal viewing experience. This is also aimed for easy reading and navigation with a minimum of resizing, panning, and scrolling across a wide range of devices.

What Is Mobile Responsive Design?

When a website is responsive, the layout and/or content responds or adapts based on the size of screen they are presented on. A responsive website automatically changes to fit the device you’re reading it on. Typically there have been four general screen sizes that responsive design has been aimed at: the widescreen desktop monitor, the smaller desktop or laptop, the tablet and the mobile phone.



Josh Byers 2012 article – A Beginner’s Guide to Mobile Responsive Design – StudioPress has examples given as the screen gets smaller, the content shifts and changes to the best display for each screen. This article also has more detailed information about

  • Why Should I Care About Mobile Responsive Design? These days we need to think of mobile first.
  • We first need to optimize the layout of the content.
  • Next, we need to adapt the content that is shown (and only show content that is really needed).
  • It has been amazingly easy to create a mobile responsive website for some time.

Why Responsive Images?

In article Responsive images by MDN Web Docs we can learn about the concept of responsive images — images that work well on devices with widely differing screen sizes, resolutions, and other such features — and look at what tools HTML provides to help implement them.

It also has a detail overview of

  • How do you create responsive images?
  • Resolution switching: Different sizes
  • Useful developer tools
  • Resolution switching: Same size, different resolutions
  • Art direction
  • Active learning: Implementing your own responsive images

Why Responsive Design?

Use of responsive web design is highly recommended because it

  • Makes it easier for users to share and link to your content with a single URL.
  • Helps Google’s algorithms accurately assign indexing properties to the page rather than needing to signal the existence of corresponding desktop/mobile pages.
  • Requires less engineering time to maintain multiple pages for the same content.
  • Reduces the possibility of the common mistakes that affect mobile sites.
  • Requires no redirection for users to have a device-optimized view, which reduces load time. Also, user agent-based redirection is error-prone and can degrade your site’s user experience (see Pitfalls when detecting user agents” section for details).
  • Saves resources when Googlebot crawls your site. For responsive web design pages, a single Googlebot user agent only needs to crawl your page once, rather than crawling multiple times with different Googlebot user agents to retrieve all versions of the content. This improvement in crawling efficiency can indirectly help Google index more of your site’s content and keep it appropriately fresh.

Google provides many more details in this article.

Other Resources which may be helpful

We always try to deliver something new in our Web professional’s world. Also we hope you find these overviews useful and always look forward to your comments and feedback (whether you are a member or not).

If you aspire to be a web professional and don’t know where to start, we offer a number of beginning classes to our members via our School Of Web. As a member, your first class is free.


The post February Updates – Mobile and Responsive Design appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

From game jam to mobile and Firefox OS

I love participating in game jams, where game developers get together to craft games in a very short amount of time. I thought it would be cool to take one of my past Game Jam games, Metal vs Hipsters, and port it to the mobile web and Firefox OS.

Metal vs Hipsters (original)

Adapting to mobile

My starting point was an HTML5 game built for desktop. It had a fixed resolution, was controlled by the keyboard, etc. Some minor (and major!) tweaks would be required to make it a mobile game.

The game uses the open source game engine Phaser, so some of the code shown here will make use of Phaser’s API.

You can check out and play the final mobile version here.

Visualising the game

The first tool I used was Firefox’s Responsive Design View. It allows you to crop the screen and simulate different screen sizes. You can access it from the Firefox browser Tools drop-down menu under Tools>Web Developer>Responsive Design View.

The other tool was an actual mobile phone! I have an Android device with several browsers installed. By running the game in localhost and then connecting my phone to my local Wi-Fi network, I could access the game at my computer’s IP.

And this would yield the first problems…


This is how bad the game looked in the responsive design view with no scaling at 320×480 size (landscape):

Scaling issues

The solution was to use Phaser’s ScaleManager to scale the game so it would fit well on the screen (with letter-boxing if needed):

var BootScene = {
  init: function () {
    // make the game occuppy all available space, but respecting
    // aspect ratio – with letterboxing if needed = Phaser.ScaleManager.SHOW_ALL; = true; = true;
  // ...

Furthermore, in the original game I used a wrapping div element to center the game on the page and also add some padding, text, etc. Now, all these page elements would have to be removed for the game to access all the available screen space.

Proper scale

Much better now!


The next issue was controls. My desktop game used the arrow keys to move and jump the main character. I opted to include a virtual gamepad, so I created a new image for it:

Virtual gamepad

I needed three buttons: two for moving left and right and another one for jumping. I created three Phaser.Button instances. This was done in a helper function:

var upBtn = new Phaser.Button(, ...);

Since Phaser.Button doesn’t have a flag that tells us whether a button is pressed or not, I needed to add it myself. This is easily done by listening to inputDown and inputUp events.

[leftBtn, rightBtn, upBtn].forEach(function (btn) {
  // register callbacks
  btn.isDown = false; () { btn.isDown = true; }); () { btn.isDown = false; });

We also need to listen to the Up button’s inputDown, to enable the character to jump, since jumping in the desktop game was triggered by a keyDown event:, this);

For moving, it was just a matter of checking the isDown flag I’d already set, in addition to the previous check against the this.keys.left keyboard key.

if (this.keys.left.isDown || this.keys.btnLeft.isDown) {

Added virtual gamepad

The game was then playable on my device in the Firefox and Chrome for Android mobile browsers. However, play testing revealed even more issues…

Reposition elements

While I was playing the game I noticed that my own fingers would hide the game characters. This was a huge deal, since it made the game very difficult and annoying to play.

The solution was to make the group bigger (100 pixels) and then shift all the game elements up.

Reposition ground and characters

Allow tapping on additional areas

I also found out that tapping on the click to restart text was a bit hard. So I made the Game Over text, which was bigger, clickable too.

// create game over text
var banner =;
banner.inputEnabled = true;, this);

In addition to that, I substituted click to restart for tap to restart, which makes more sense in mobile environments.

Revamping the splash screen

The splash screen needed some love too, since it was originally hardcoded to a fixed resolution.

The first step was to resize the background to take up the whole screen space, while maintaining its aspect ratio:

.overlay {
  background-size: cover;

Then I resized some of the existing text and buttons, and deleted the controls help diagram, since it referred to desktop arrow keys.

Splash screen


Finally, the game was fully playable… but now it was too short! The original game had five predefined waves of enemies. It was fine for the game jam, since most people only try the games for a very short amount of time (there are literally thousands of games to try out).

For a mobile game, one quick minute of gameplay is not good enough. So I tweaked the gameplay code to get rid of the predefined waves and make them random and infinite. Unlimited playtime!

Transform into a Firefox OS app

Once the game worked decently and was fun to play, it was time to turn it into a Firefox OS app.

Run in the simulator as a hosted app

The first step was to run it as a hosted app in a Firefox OS Simulator.

You can get the Simulator from the WebIDE (Tools > Web Developer > WebIDE) by clicking Install Simulator in the right sidebar. I installed Firefox OS version 2.6.

Install simulator

To create a hosted web app, we need an icon referenced in a JSON file with some metadata. This file is called the web app manifest.

While you can provide different sized icons, the minimum requirement is to have a 128x128 one:

Icon 128x128

The manifest file is just a JSON file in our app’s root. It contains some metadata about our app: the name of the app, the author, locales, etc. This is what the initial version of my manifest.webapp looked like.

  "name": "Metal vs Hipsters",
  "description": "Arcade game",
  "launch_path": "/index.html",
  "icons": {
    "128": "/images/icon-128.png"
  "developer": {
    "name": "Belén 'Benko' Albeza",
    "url": ""
  "default_locale": "en",
  "version": "1.0.0"

To run Metal vs Hipsters in the Simulator from the WebIDE, click on Open Hosted App and then point to the location of the manifest in the running local server:

Open Hosted App

Manifest URL

Now my project has been added…

Hosted web app

…and we can finally run it in the simulator.

Game running on simulator

Run in the phone as a packaged app

Running a game in the simulator is cool, but nothing beats playing your game on a real device. I wanted to create a packaged app in addition to a hosted app for Firefox Marketplace.

I had an Xperia Z3 Compact with Firefox OS on it ready for action. Once plugged in via USB and with developer mode enabled, it was listed in the WebIDE on the USB devices list.

Devices list

The workflow for creating a packaged app is very similar to the one I described for a hosted app. In the WebIDE click on Open Packaged App and then point to the game’s folder:

Packaged app

With my phone selected as a device, I clicked on the “play” button in the top bar and… boom!

Game running on Firefox OS phone

Now that I had the game running on a phone I could take advantage of some settings available only for apps and not just mobile websites. I wanted the game to run in fullscreen (without any prompting!) and I wanted to force a landscape orientation. I was able to do this by adding some more settings to the manifest.

  "fullscreen": "true",
  "orientation": ["landscape"]

Game running in fullscreen

Local assets

Now that I’d built the game as a packaged app, I needed to include all the assets needed to run it. The game uses one font from Google Fonts, Bangers. For the game jam, I included the font using one of Google’s suggested methods: linking to CSS on their servers that contains the font definition.

<link href=''
 rel='stylesheet' type='text/css'>

As you can see, this won’t work for a packaged app, since it’s possible for a player to launch the game for the first time while offline, and they would not be able to access the font. Luckily, these fonts are also available for download and distribution with your projects (yay for open source!), so I did just that.

I copied the content of Google’s CSS file to my own CSS, changed the src URL to point to my local copy, and everything was set!

@font-face {
  font-family: 'Bangers';
  font-style: normal;
  font-weight: 400;
  src: url(../fonts/Bangers.woff2) format('woff2');

Into the Firefox Marketplace

Packaging for Firefox OS

A packaged app is distributed via a single zip file with our application on it. I was using a task runner, Gulp, to automate some parts of the development; so I added a new task to generate this zip file automatically. I made use of the gulp-zip module.

npm install gulp-zip --save
gulp.task('release', ['dist'], function () {
  var data = JSON.parse(fs.readFileSync('./package.json'));
  var filename = + '-' + data.version + '.zip';

  return gulp.src('./dist/**/*')

Tip: once generated, always unzip your file to make sure everything is there!

Submitting your app to Firefox Marketplace

You can submit your app to the Marketplace, but you will need to create an account first.

Once logged in, I selected Free App, then Packaged and uploaded the zip file. Then the manifest and app files were validated.

App validation

There were some warnings related to the CSP, but since the game doesn’t ask for special permissions (like access to the contacts), it’ll be OK. These CSP warnings were due to Phaser using document.createElement('script') when using bitmap fonts. Since my game wasn’t using these fonts, I could just monkey patch Phaser and remove that code bit if I really needed special permissions for my game.

In order to submit the game, I had to provide a privacy policy. The game wasn’t collecting or storing any sort of data, so I settled by writing just that:

This application does not store or collect personal information or any kind of user data.

If your game does collect data, check out the privacy policy guidelines in the MDN to help you draft one.

I also needed some 320x480 screenshots:

Marketplace screenshot

As the last step, I was asked to setup content rating. The submission form takes you to the IARC tool, which is a wizard to help you rate your game depending on some criteria. Since my game features a form of fantasy violence –I guess a guitar of flames that destroys hipsters and cupcakes counts as so–, this ended up rated as PEGI-12.

PEGI rating

All done! Now time to wait a bit until it gets reviewed and approved.

More tweaks and potential improvements

Not all browsers have the same support of features or file formats. While testing the game in different devices, I found out some issues with Safari on iOS: the webfont wasn’t loaded properly and the background music tracks was not being played. The issue was that Safari for iOS doesn’t support neither Woff nor OGG as formats for fonts and audio (tip: you can check these things in Can I use?). All I had to add to be able to play the game in my iPad was to add those assets in TTF and MP4 as well.

The game should be playable in major major mobile browsers (Firefox, Chrome and Safari). I expect trouble with IE/Edge, but I don’t have a Windows device at hand to test this.

Although the current version is fun to play in browsers, there are other improvements that could make this a better game: use of the vibration API when the main character gets killed, store the high-score with localStorage, allow installation of the app directly from the game’s website, support for offline mode in the web version, etc.


The game is already available in the Firefox Marketplace for downloading. You can also play the game from your mobile browser here, and grab the full source code at Github as well.

I hope this article can help to port your HTML 5 games to mobile and Firefox OS. Most of the times they don’t need much tweaking and you could expand your player base. Plus playing your own game while commuting is priceless 🙂

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Creating a mobile app from a simple HTML site: Part 4

How to polish your app and prepare it for market

In previous sections of this step-by-step series (Part 1, Part 2, and Part 3) we’ve created an app that loads multiple school plans from the server.

What we have so far is functional, but still has a number of issues, including two which are major: no offline mode and a hard-coded configuration. In this closing post, we’ll work on all of these issues.

If you haven’t built up the examples from the previous parts, use stage7 app and stage7 server as a starting point. To get started, follow the instructions on how to load any stage in this tutorial.


First, let’s do some refactoring. We’ll add a User object type to make it easier to choose which user’s plan to display. This will allow us to remove some more code from the app’s main logic flow, making the code cleaner and more modular. This object will load data from the server to create the plan UI. At the moment, rendering is done in app.onDeviceReady and app.renderData methods. Our new onDeviceReady method creates an app.user object and runs the methods needed to get and render plans. Replace the existing onDeviceReady method with the following:

onDeviceReady: function() {
    app.user = new User('johndoe');


Next, delete the app.renderData method completely. We will store this functionality inside our new User object instead, as you’ll see below.

Next, at the beginning of the index.js file (before the definition of Plan), add the following code to define the User object:

function User(userid) { = userid;
    this.plans = [];

User.prototype.getPlans = function() {
    var self = this;
    var request = new XMLHttpRequest({
        mozAnon: true,
        mozSystem: true});
    request.onload = function() {
        var plans = JSON.parse(this.responseText);
        for (var i = 0; i < plans.length; i++) {
            self.plans.push(new Plan(plans[i]));
    };"get", app.getPlansURL +, true);

User.prototype.displayPlans = function() {
    var self = this;
        var deck = document.getElementById('plan-group');
        var tabbar = document.getElementById('plan-group-menu');
        for (var i = 0; i < self.plans.length; i++) {
            self.plans[i].createUI(deck, tabbar, dayOfWeek);
    }, function() {}, {type: 'narrow', item: 'days'});

This contains functionality previously found in renderData and onDeviceReady. After the plan’s JSON is loaded from the server we iterate over the list and create a list of Plan objects in user.plans. We then call user.displayPlans, which creates the required DOM environment and invokes plan.createUI for each element of user.plans.

You may notice that the above code uses app.getPlansURL to allow the XHR call to find the JSON. Previously the URL was hardcoded into"get", "", true);. Since it’s better to keep settings in one place we’ll add this as a parameter of the app object instead.

Add the following into your code:

var app = {
    getPlansURL: "",
    // ....

Now try preparing your app again with the cordova prepare terminal command, starting your server, and reloading the app in WebIDE (as we’ve done in previous articles). The app should work as before.

Offline mode

Let’s turn our attention to making the app work offline.

There are several technologies available to store data on the device. I’ve decided to use the localStorage API, as the data we need to store is basically just simple strings and doesn’t need any complex structuring. As this is a key/value store, objects need to be stringified (represented as a string). I will use only two functions — setItem() and getItem(). For example, storing a user id would require you to call localStorage.setItem('user_id',;.

There are two values we definitely need to store in the phone memory — the ids of the current user and the plans. To make the app fully open and allow users to use servers not provided by the app creators we also need to store the server address. We’ll start by storing the plans. The user id and server will be still hardcoded. Let’s add a new method — User.loadPlans — and call that from app.onDeviceReady, instead of calling both user.getPlans() and app.user.displayPlans. We will decide if the plans need to be loaded from the server and then display the plans by calling User.displayPlans() from User.loadPlans.

First update onDeviceReady again, to this:

onDeviceReady: function() {
    app.user = new User('johndoe');

Now add in the following definition for the loadPlans method, up near your other User object-defining code:

User.prototype.loadPlans = function() {
    var plans = localStorage.getItem('plans');
    if (plans === null) {
        return this.getPlans();
    console.log('DEBUG: plans loaded from device');

The above method calls another new method — initiatePlans. This parses the JSON representation of the plans and initiates Plan objects inside the User.plans array. In the future we would like to be able to reload the plans from the server, but the existing code always adds new plans instead of replacing them.

Add the following definition just below where you added the loadPlans code:

User.prototype.initiatePlans = function(plansString) {
    var plans = JSON.parse(plansString);
    for (var i = 0; i < plans.length; i++) {
        this.plans.push(new Plan(plans[i]));

We also need to store the plans on the client. The best point to do this is right after the plans have been loaded from the server. We will call localStorage.setItem('plans', this.responseText) inside the success response function of getPlans. We must also remember to call the initiatePlans method.

Update your getPlans definition to the following:

User.prototype.getPlans = function() {
    var self = this;
    var request = new XMLHttpRequest({
        mozAnon: true,
        mozSystem: true});
    request.onload = function() {
        console.log('DEBUG: plans loaded from server');
        localStorage.setItem('plans', this.responseText);
    request.onerror = function(error) {
        console.log('DEBUG: Failed to get plans from ``' + app.getPlansURL + '``', error);
    };"get", app.getPlansURL +, true);

At this moment, successful loading of the user’s plans happens only once. Since school plans change occasionally (usually twice a year) you should be able to reload the plans from the server any time you want. We can use User.getPlans to return updated plans, but first we need to remove existing plans from the UI, otherwise multiple copies will be displayed.

Let’s create User.reloadPlans — add the code below your existing User object-defining code:

User.prototype.reloadPlans = function() {
    // remove UI from plans
    for (var i = 0; i < this.plans.length; i++) {
    // clean this.plans
    this.plans = [];
    // clean device storage
    localStorage.setItem('plans', '[]');
    // load plans from server

There is a new method to add to the Plan object too — Plan.removeUI — which simply calls Element.remove() on a plan’s card and tab. Add this below your previous Plan object-defining code:

Plan.prototype.removeUI = function() {

This is a good time to test if the code has really reloaded. Run cordova prepare again on your code, and reload it in WebIDE.

We’ve got two console.log statements inside loadPlans and getPlans to let us know if the plans are loaded from device’s storage or the server. To initiate a reload run this code in Console:


Note: Brick reports an error at this point, as the link between each tab and card has been lost inside the internal system. Please ignore this error. Once again, our app still works.

reloadPlans from Console

Let’s make the reload functional by adding a UI element to reload the plans. In index.html, wrap a div#topbar around the brick-tabbar. First, add a reload button:

<div id="reload-button"></div>
<div id="topbar">
    <brick-tabbar id="plan-group-menu">

Now we’ll make the button float to the left and use calc to set the size of the div#topbar. This makes Brick’s tabbar calculate the size when layout is changed (portrait or horizontal). In css/index.css, add the following at the bottom of the file:

#topbar {
	width: calc(100% - 45px);

#reload-button {
	float: left;
	/* height of the tabbar */
	width: 45px;
	height: 45px;
	background-image: url('../img/reload.svg');
	background-size: 25px 25px;
	background-repeat: no-repeat;
	background-position: center center;

We will download some Gaia icons to use within the application. At this stage, you should save the reload.svg file inside your img folder.

Last detail: Listen to the touchstart event on the #reload-button and call app.user.reloadPlans. Let’s add an app.assignButtons method:

assignButtons: function(){
    var reloadButton = document.getElementById('reload-button');
    reloadButton.addEventListener('touchstart', function() {
    }, false);

We need to call it from app.deviceReady before or after app.activateFingerSwipe().

onDeviceReady: function() {
    // ...

At this point, save your code, prepare your cordova app, and reload it in WebIDE. You should see something like this:

reload button

Here you can find current code for app and server.

Settings page

Currently all of the identity information (the address of the server and user id) is hardcoded in the app. If the app is to be used with others, we provide functionality for users to set this data without editing the code. We will implement a settings page, using Brick’s flipbox component to change from content to settings and vice versa.

First we must tell the app to load the component. Let’s change index.html to load the flipbox widget by adding the following line into the HTML <head> section:

<link rel="import" href="app/bower_components/brick-flipbox/dist/brick-flipbox.html">

Some changes must happen inside the HTML <body> as well. brick-topbar and brick-deck need to be placed inside switchable sections of the same flipbox, and the reload button also moves to inside the settings. Replace everything you’ve got in your <body> so far with the following (although you need to leave the <script> elements in place at the bottom):

    <section id="plans">
        <div id="settings-button"></div>
        <div id="topbar">
            <brick-tabbar id="plan-group-menu">
        <brick-deck id="plan-group">
    <section id="settings">
        <div id="settings-off-button"></div>

The idea is to switch to the “settings” view on pressing a settings-button, and then back to the “plans” view with the settings-off-button.

Here’s how to wire up this new functionality. First up, inside your app definition code add a toggleSettings() function, just before the definition of assignButtons():

toggleSettings: function() {

Update assignButtons() itself to the following (we are leaving the reloadButton code here, as we’ll need it again soon enough):

assignButtons: function() {
    app.flipbox = document.querySelector('brick-flipbox');
    var settingsButton = document.getElementById('settings-button');
    var settingsOffButton = document.getElementById('settings-off-button');
    settingsButton.addEventListener('click', app.toggleSettings);
    settingsOffButton.addEventListener('click', app.toggleSettings);
    var reloadButton = document.getElementById('reload-button');
    reloadButton.addEventListener('touchstart', function() {
    }, false);

Next: we need to retrieve some more icons for the app. Save the settings.svg and back.svg files inside your img folder.

Let’s update our css/index.css file too, to add the additional icons in and style our new features. Add the following at the bottom of that file:

#form-settings {
    font-size: 1.4rem;
    padding: 1rem;
#settings-button, #settings-off-button {
    float: left;
    width: 45px;
    height: 45px;
    background-size: 25px 25px;
    background-repeat: no-repeat;
    background-position: center center;
#settings-button {
    background-image: url('../img/settings.svg');
#settings-off-button {
    background-image: url('../img/back.svg');
    border-right: 1px solid #ccc;
    margin-right: 15px;
brick-flipbox {
    width: 100%;
    height: 100%;

If you now prepare your cordova app again with cordova prepare, and reload the app inside WebIDE, you should see something like this:

flipbox working

Adding a settings form

To add a form and some data, replace your current <section id="settings"></section> element with the following:

<section id="settings">
    <div id="settings-off-button"></div>
    <form id="form-settings">
        <p><label for="input-server">Server</label></p>
        <p><input type="text" id="input-server" placeholder=""/></p>
        <p><label for="input-user" id="label-user">User ID</label></p>
        <p><input type="text" id="input-user" placeholder="johndoe"/></p>
        <p><button id="reload-button">RELOAD ALL</button></p>

Making it look good is easy! We’ll use some ready-made CSS available in Firefox OS Building Blocks. Download input_areas.css and buttons.css and save them in your www/css directory.

Then add the following to your HTML <head>, to apply the new CSS to your markup.

<link rel="stylesheet" type="text/css" href="css/input_areas.css">
<link rel="stylesheet" type="text/css" href="css/buttons.css">

Go into the css/index.css file and delete the #reload-button { ... } rule to make the “RELOAD ALL” button display correctly.

Run cordova prepare again and reload the app in WebIDE, and you should see something like this:


We’ve got the view — now to support it. When the app first installs there will be no setting, so the app will have no idea how to load the data. Instead of showing empty plans we immediately toggle the view to the settings. Update your onDeviceReady function as shown:

onDeviceReady: function() {
    app.plansServer = localStorage.getItem('plansServer');
    app.userID = localStorage.getItem('userID');

    if (app.plansServer && app.userID) {
        app.user = new User(app.userID);
    } else {

The app needs to read the data from our form inputs, so save them into the phone’s storage, and reload after the change. Let’s add this functionality at the end of the app.assignButtons function. First we will stop the form from submitting (otherwise our app would just reload the index.html instead of redrawing the content). Add the following code to the end of the assignButtons function, just before the closing },:

document.getElementById('form-settings').addEventListener('submit', function(e) {
}, false)

We will read and set the input value for the server. I’ve decided to read the input value on the blur event. It is dispatched when the user touches any other DOM Element on the page. When this happens, the server value is stored in the device’s storage. If app.plansServer exists on app launch, we set the default input value. The same has to happen for the userID, but there is a special step. Either we change the app.user or create a new one if none exists. Add the following just above the previous block of code you added:

var serverInput = document.getElementById('input-server');
serverInput.addEventListener('blur', function() {
    app.plansServer = serverInput.value || null;
    localStorage.setItem('plansServer', app.plansServer);
if (app.plansServer) {
    serverInput.value = app.plansServer;    

var userInput = document.getElementById('input-user');
userInput.addEventListener('blur', function() {
    app.userID = userInput.value || null;
    if (app.userID) {
        if (app.user) {
   = app.userID;
        } else {
            app.user = new User('app.userID');
        localStorage.setItem('userID', app.userID);
if (app.userID) {
    userInput.value = app.userID;    

After preparing your app and reloading it in WebIDE, you should now see the settings working as expected. The settings screen appears automatically if no plans are found in the localstorage, allowing you to enter your server and userID details.

Test it with the following settings:

  • Server:
  • User ID: johndoe

The only inconvenience is that you need to switch back to the plans view manually once Settings are loaded. In addition, you might get an error if you don’t blur out of both form fields.

settings are working

Improving the settings UX

In fact, switching back to the plans view should be done automatically after plans are successfully loaded. We can implement this by adding a callback to the User.getPlans function, and including it in the call made from User.reloadPlans:

First, update your getPlans() function definition to the following:

User.prototype.getPlans = function(callback) {
    var self = this;
    var url = app.plansServer + '/plans/' +;
    var request = new XMLHttpRequest({
        mozAnon: true,
        mozSystem: true});
    request.onload = function() {
        console.log('DEBUG: plans loaded from server');
        localStorage.setItem('plans', this.responseText);
        if (callback) {
    };"get", url, true);

Next, in User.reloadPlans add the callback function as an argument of the this.getPlans call:


Again, try saving, preparing, and reloading your new code. You should now see that the app displays the plans view automatically when correct server and user information is entered and available. (It switches to the Settings view only if there is no error in self.initiatePlans(this.responseText).).


Where do we go from here

Congratulations! You’ve reached the end of this 4-part tutorial, and you should now have your own working prototype of a fun school plan application.

There is still plenty to do to improve the app. Here are some ideas to explore:

  • Writing JSON files is not a comfortable task. It would be better to add new functionality that lets you edit plans on the server. Assigning them to the user on the server opens new possibilities, and this would just require an action to sync the user account on both server and client.
  • Displaying hours would also be nice.
  • It would be cool to implement a reminder alarm for some school activities.

Try implementing these yourself, or build out other improvements for your own school scheduling app. Let us know how it goes.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Turn your Facebook page into a Firefox OS mobile app

Whether you are a business or community page owner, what would be better than increasing your page reachability by offering your standalone mobile app?

Apptuter is an open source framework to help you achieve that, with minimum coding knowledge and easy to follow steps you would be able to produce your own app. The framework currently supports Facebook pages as a content source and is capable of producing apps for Firefox OS and Android platforms.

How it works

Let us take a test drive on how this is supposed to work. In our example we will generate a standalone app using Mozilla’s Facebook page as a content source.

Clone the repository

First step would be to download or clone the Apptuter-Firefox directory from the Apptuter repository:

git clone

Directory structure should look like this:

Get the Facebook numerical id

Then we will need to get the Facebook numerical page id. If you have assigned a friendly page name, the page ID will not be visible from the page URL, in this case we will need to visit the following URL to retrieve it:

In our example this would be:

Page ID will be visible on the first line of data returned.

Create a Facebook app

Next step would be creating a Facebook app: You will able to get App ACCESS TOKEN by combining APP ID & APP SECRET so that the requested URL should be in the following form:|app_secret

Requesting Page Info (Info.js) is where we are going to define those parameters, replace PageID with the numerical that can be found at /Apptuter-Firefox/js

var Main = function () {
    this.pageName = ‘pageID’; = null;
    this.category = null;
    this.description = null;
    this.photoArray = null;
    this.postArray = null;
    this.infoArray = [];
    this.accessToken = 'AppID|AppSecret';
    this.pictureUrl = null;
    this.paging = '' + this.pageName + '/posts?limit=20&amp;access_token='+this.accessToken;
    this.pagingNext = '' + this.pageName + '/posts?limit=20&amp;access_token='+this.accessToken;

Let us define our new app properties in the manifest.webapp file found at the directory root:

  "name": "Mozilla App",
  "description": "This is an example app of apptuter framework",
  "launch_path": "/Shared/index.html",
  "icons": {
    "32": "/images/app_icon_32.png",
    "60": "/images/app_icon_60.png",
    "90": "/images/app_icon_90.png",
    "120": "/images/app_icon_120.png",
    "128": "/images/app_icon_128.png",
    "256": "/images/app_icon_256.png"
  "chrome": {
    "navigation": true
  "version": "1.0.1",
  "developer": {
    "name": "Egirna Technologies Limited",
    "url": ""
  "orientation": [
  "default_locale": "en"


Only thing left is the artwork. From the repository, go to /Apptuter-Firefox/images and replace the default images with those of our example logo with matching dimensions and file name.


And we are done! Let us test what the app would look like using Firefox OS Simulator:

You ultimately are responsible to use this software in compliance with Facebook, Google and Mozilla terms of service and end user license agreement. This applies to any service this software may integrate with.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Quick Note: Mozilla looking to survey Mobile App Developers in the Bay Area – tell us what you need

The Mozilla User Experience Research team is looking for developer who have experience writing mobile Web apps in the Bay Area to participate in a paid research study that will have a significant impact on making our developer-focused efforts even better.

To qualify for the study, please take this 10-minute survey.
If you’re eligible, a member of our team will contact you to tell you a little more about the research and schedule time with you. Developers who qualify for and fully participate will receive an honorarium of $250.

We’re looking for developers who are:

  • willing to participate in a 2-hour in-person interview at their workplace or home
  • available for the interview the week of March 10 to 14 (the weekend before / after may also be possible)

The interview will be recorded, but all materials will be used for internal research purposes only.

You DON’T have to use Mozilla products or be part of our community to participate (in fact, we’d like to hear your voice even more!).

Your feedback has the potential to improve the experience of other Web app developers and influence the direction of our products and services, so we would love to get a chance to talk with you! Please feel free to share this opportunity widely with your own network as well.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional Trends for 2014 – Mobile Web and Desktop with David Balmer

In this 7 minute interview with David Balmer, Mobile HTML5 DeveloperAdvocate we talk about Web Professional Trends for 2014 including the merging of mobile web and the desktop including:

* Benefits of HTML5
* Resources such as
* Browser vendors
* Mobile equipment vendors
* Web GL and accelerated 3D inside the browser

More about WebGL

According to Wikipedia, WebGL (Web Graphics Library) is a JavaScript API for rendering interactive 3D graphics and 2D graphics within any compatible web browser without the use of plug-ins.[2] WebGL is integrated completely into all the web standards of the browser allowing GPU accelerated usage of physics and image processing and effects as part of the web page canvas. WebGL elements can be mixed with other HTML elements and composited with other parts of the page or page background.[3] WebGL programs consist of control code written in JavaScript and shader code that is executed on a computer’s Graphics Processing Unit (GPU). WebGL is designed and maintained by the non-profit Khronos Group.


WebGL is based on OpenGL ES 2.0 and provides an API for 3D graphics.[5] It uses the HTML5 canvas element and is accessed using Document Object Model interfaces. Automatic memory management is provided as part of the JavaScript language.[4]

Like OpenGL ES 2.0, WebGL does not have the fixed-function APIs introduced in OpenGL 1.0 and deprecated in OpenGL 3.0. This functionality can instead be provided by the user in the JavaScript code space..

WebGL grew out of the Canvas 3D experiments started by Vladimir Vuki?evi? at Mozilla. Vuki?evi? first demonstrated a Canvas 3D prototype in 2006. By the end of 2007, both Mozilla[6] and Opera[7] had made their own separate implementations.

In early 2009, the non-profit technology consortium Khronos Group started the WebGL Working Group, with initial participation from Apple, Google, Mozilla, Opera, and others.[4][8] Version 1.0 of the WebGL specification was released March 2011.[1] As of March 2012, the chair of the working group is Ken Russell.

Early applications of WebGL include Google Maps and Zygote Body.[9][10] More recently, Autodesk ported most of their applications to the cloud running on local WebGL clients. These applications included Fusion 360 and AutoCAD 360.[11]

Development of the WebGL 2 specification started in 2013.[12] This specification is based on OpenGL ES 3.0.

The post Web Professional Trends for 2014 – Mobile Web and Desktop with David Balmer appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Web Professional Trends for 2014 – Mobile with Chris Wilson

In this 10 minute interview with Chris Wilson, Open Web Platform Developer Advocate at Google we talk about Web Professional Trends for 2014 including Mobile Web and Application Trends:

* Although not a new trend this year, Mobile is a growing in significance and is dominating Web browsing activity
* Mobile doesn’t just mean applications but Web page access from Mobile is outpacing desktop
* How existing Web skills including HTML, CSS and JavaScript still rule and apply
* How those Web skills are portable and how designing or developing for Mobile is unique
* How usability will play an even a larger role
* Great opportunity for designers and developers
* How Google Chrome has invested a lot for the Mobile browser experience
* How the technology and Web professionals like Chis are is introducing new features and benefits into the Mobile web experience

The post Web Professional Trends for 2014 – Mobile with Chris Wilson appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Mobile Application Development Technologies and Opportunities

Mobile Application Development Technologies and Opportunities – Interview with Jonathan Rende

In this 13 minute interview with Jonathan Rende, Vice President Products @Appcelerator we talk about:

* Native vs Mobile Application Development with HTML5
* Skills required for both
* The pros and cons of both
* Tools that can leverage existing HTML, CSS and JavaScript skills to develop robust Native apps
* Job opportunities Mobile Application Development.

The post Mobile Application Development Technologies and Opportunities appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)