Back in November my colleague Robert Nyman wrote about a word that annoys him. I like that. I think our day to day online conversations are full of little misunderstandings and knowing what ticks someone off or brings up weird connotations is a good thing. So I thought I should quickly write this bit here.

There is a pretty bullet-proof way to make me feel uncomfortable and not react to requests that you have and that is by calling me “Bro”. There are two people on this planet that can call me “Bro” and that is my sister and my brother and both call me “Christian”.

I don’t like “Bro”. I understand that for some this is a very normal way to talk to each other but I don’t get it.

First of all, it assumes a relationship that we just don’t have. I have quite a lot of friends and I have some very good friends (you know the ones that helped you when you were sick or show up without any questions when there are things to be done like moving flat). Friendship is something that grows, that gets earned. A bond that would warrant calling someone else a brother (or sister for that matter) that is not related to some religious lingo is something that so does not happen by using the same social media channel or commenting on the same pull request thread. Someone calling me “Bro” out of the blue makes me twitch and reminds me of the fake friendliness the bazaar salesperson shows when asking you to “want to look at my carpets, friend?”.

Secondly when I hear “Bro”, I have in my head the caricature of a beercan-on-forehead-crushing frat boy jock who is boisterously shouting about how awesome all his bros are and that they come “before hos”. I never went through university and the mere concept of fraternities and sororities is beyond me. It seems so fake and artificial and with its initiation and hazing rituals flat out creepy. Where I grew up we used to have (and still have) student organisations that have sword-fighting as the initiation rites and you might have seen old German men of power with scars in their faces. That is where that came from. All of these smack of nationalism and old-school class systems, all of which things I don’t get and that make me feel uncomfortable.

So in short, every time someone calls me “Bro”, I lose a bit of respect – subconsciously. Maybe that is something I should work on. But seriously, I think the whole “Bro” culture is outdated and seeing the effects of it in mainstream media scandals and “Brogrammer culture” is something we shouldn’t support but actually move away from. So, sorry, but #nobro from me.

I am spending this week explaining lots of press folk what the Geeksphone is about. I just got excited like a puppy on sugar rush about unpacking mine, after waiting for a long time to get it internally at Mozilla. See the unpacking photo set on Flickr

Posting this on Twitter and Facebook caused quite a stir and many people who bought a Geeksphone wondered about their delivery times. Here’s what I know about this: nothing. I also don’t have access to phones to give out or expedite delivery for you – nobody outside of Geeksphone or inside Mozilla can, so please don’t ask for any of this as it is impossible for us to help you.

I think it is very important to repeat what the Geeksphone Firefox OS preview device project means and stands for. So here it is, in a very clear fashion: the Geeksphone Firefox OS developer preview devices are developer tools for Firefox OS. They are not:

• Firefox OS phones for day to day use
• Swag to give out for free as prizes on conferences (so don’t ask)
• A collector’s item to buy and put on a shelf

Firefox OS is meant to fill a gap in the mobile space and bring HTML5 capable devices in a very affordable fashion to markets that can not get handsets with great web capabilities. In other words, it replaces feature phones, not your high end Android or iPhone.

That’s why we found ourselves in a pickle: how do developers test on a platform that is not sold in their locale as it would be pointless to add to a saturated market with a lower-spec phone? The answer is developer tools like the Firefox OS simulator and affordable testing devices where you can really see how responsive the hardware with the OS is. And these are the Geeksphone Firefox OS preview devices.

Having a Geeksphone Firefox OS preview device means you should be working on an app, that is what we need developers to do. We need the marketplace to have a lot of good apps on launch of the phones to the end users. All you need to do is to build an HTML5 app (that also can be converted to native code with PhoneGap) – you can develop that one to 80% in the browser. To get all the Firefox specific goodies, you’d need a phone like the current one Geeksphone provides.

So while it is very exciting to see people go nuts over the phones, I think it is very important to remember that these are tools to build and test apps and not phones to have instead of the phone that our partners will release in the target markets. These will be very different but share the same hardware specs.
Consider the Geeksphone Firefox OS preview device a Nightly build of a browser. You are helping the browser to test out future features for normal end users but you shouldn’t be surprised about quirks and errors. On the contrary – we want you to find them and tell us what is broken, that’s why there are preview and beta versions of browsers.

I am terribly excited about being able to give real hardware to people who work on exciting apps that will make a massive difference for people who now only can play snake and send SMS on their phones. You could be part of the new wave of mobile internet entertainmment and access in countries that hunger for a better experience. That’s what you’d need a Geeksphone Firefox OS preview device for. If all you want to do is to play with a phone, drop by in any Mozilla location or any of our events.

Right now Firefox OS needs you to build stuff for the web, and if you do that already, the device can give you the final testing platform you need. You won’t need one for most smaller apps though, so don’t feel left out as there are not that many available and it may take some time for yours to arrive.

That doesn’t mean that in the future there might not be devices sold by Geeksphone that are targetted at end-users. It simply means that the Geeksphone Firefox OS preview device is what it is – a preview device for developers.

The lovely people of Devs love bacon today released the video of my talk Helping or Hurting and I am blown away by the quality of it. Really TED style stuff.

Christian Heilmann – Helping or hurting? from BACON: things developers love on Vimeo.

I had given the talk slightly more focused before at the jQuery Europe conference (notes are available here) and thought it is important to bring the message out as a video. We are right now hurting the web of the very near future by building tools that seemingly make developers more effective but at the same time make them dependent on abstractions. And if we don’t make these abstractions not use the newest and most performance optimised technologies under the hood we are just adding more and more cruft to the web.

There is nothing more frustrating than things going wrong without you knowing what happened. Things breaking with a very obvious reason are not as bad. Say you drop your phone and you see the display smashed – there is no question why the touch interface doesn’t work any more. But when nothing happens and everything should be OK, we get very cross very fast.

This is why code that isn’t defensive in testing for what it needs before accessing it annoys me. Worse even, when code just assumes everything is OK and doesn’t have an error clause that gives a fallback or at least tells me what is going on.

This is where HTML5 multimedia on a plain markup level is terrible. It is not easy to play sound or video on computers, not a trivial task indeed. However, I would still expect to get a fallback when things go wrong other than a grey box that does exactly nothing.

When I add an image to a document and specify an alternative text this text gets displayed when the image can’t be loaded (at least in Firefox). I can also add an “error” event handler to the image and it will get fired when the image fails to load. You can try it in this Demo on JSBin

  <img src="meh.jpg" alt="cute kitten photo">

var img = document.querySelector('img');
img.addEventListener('error', function(ev) {
  if (this.naturalWidth === 0 && 
      this.naturalHeight === 0) {
    console.log('Image ' + this.src + ' not loaded');
  }
}, false);

Not so with multimedia.

Say you add a video into the page and the browser can not play it because it can not be loaded or the browser does not support its type. All you get is a grey box that does not do anything. You don’t even get a “save as” link or anything like it. And to add to the annoyance, no error handler gets fired on the video element – although the video or audio element very much has one to use. What’s going on?

What if you offer a fallback?

Say we do the right thing and offer a sensible fallback for the video should it fail to load or the browser being incapable of playing video:

<video controls>
  <source src="dynamicsearch.mp4" type="video/mp4"></source>
  <a href="dynamicsearch.mp4">
    <img src="dynamicsearch.jpg" 
         alt="Dynamic app search in Firefox OS">
  </a>
  <p>Click image to play a video demo of 
     dynamic app search</p>
</video>

If your browser doesn’t support the video element at all you get a screenshot of the video and an explanation what to do – you can still download and watch the movie in any mediaplayer on your computer. This is great. It is also a beneficial thing to do as for example links on Facebook would get a thumbnail of the image next to them.

When the browser supports the video element but doesn’t support MP4 you are out of luck though. You get the broken grey box and not the fallback content. Wouldn’t it be great if the browser showed the fallback when the video can not be played? Not according to the standard. It is up to the implementer to develop a fallback for this. And here’s how that is done: you need to assign an error handler to the last source element in the video element. If the browser doesn’t find any playable source, this allows you to replace the video with its fallback content.

<video controls>
  <source src="dynamicsearch.mp4" type="video/mp4"></source>
  <a href="dynamicsearch.mp4">
    <img src="dynamicsearch.jpg" 
         alt="Dynamic app search in Firefox OS">
  </a>
  <p>Click image to play a video demo of 
     dynamic app search</p>
</video>

var v = document.querySelector('video'),
    sources = v.querySelectorAll('source'),
    lastsource = sources[sources.length-1];
lastsource.addEventListener('error', function(ev) {
  var d = document.createElement('div');
  d.innerHTML = v.innerHTML;
  v.parentNode.replaceChild(d, v);
}, false);

Not the most intuitive, but it works. Wouldn’t it be easier if the video element showed the fallback content when it can’t play a video or at least fire an error handler saying “no valid codec found”?

• Video element standard document

Today I gave a talk at the State of the browser 3 event in London, England. The Slides are here, a screencast (with bad audio) is on YouTube and here are the notes.

Abstract:
When the web was defined as an idea it was based on the principle of independence of hardware, global location, prosperity or ability. This changed drastically when the mobile web came around and we got sucked into a world of software dependent on certain hardware and global location. HTML5 and the mobile web based on open technologies became something that needed conversion to native code to access the new hardware people use. This is against the main principle of the web and means we duplicate efforts all over the place. In this talk Chris Heilmann shows how Mozilla is battling this trend and how brushing up your HTML5 solutions allows you to reach millions of new users forgotten by native technology but nevertheless eager to be online.

When I was a kid, I had an uncle in America and he sent us comic books. One of the things advertised in these comic books were sea monkeys – awesome pets that are a whole society and play with another and anyone can look after. Turns out these things are just Brine Shrimp and don’t look at all like that. Actually they are really ugly and boring.

This is what I feel a bit like when we look at what happened to HTML5 on mobile devices. When the iPhone came out Steve Jobs announced that there is no need for an SDK and that Safari with web technologies is more than enough to deliver great experiences. When I tried though what worked I quickly found myself hindered in a lot of respects and the attitude of Apple towards web technologies on the phone vs. native apps changed drastically and very quickly.

And somehow this lead to a terrible experience of the web on mobile devices. This is especially annoying when the sites have been “optimised for mobile viewing” and still fail to deliver anything useful. Another big thing that is happening right now is web sites redirecting you to download a native app instead. This is not what I want when I am on the go on a limited connection and simply look something up. Brad Frost collects a lot of terrible user experiences on mobile at wtfmobileweb.com.

What happened? When did we give up on the idea of nice and responsive web products that use what is available to them? It can not be about the tools we have. Browsers have amazing developer tools built into them these days – all of them, really. Using these tools we have very fine-grained control over what happens in a browser.

For example in this shot you can see the difference using requestAnimationFrame instead of setTimeout makes.

Let’s not forget how far browsers have come in the recent years.
Browsers these days are nothing more but awesome. Whatever you can complain about you can file as a bug and if it is a real issue it can be fixed within weeks. Every few weeks there are browser updates and security fixed happen over night. All of them render HTML the same way.

And yet the web is full of sites that are plain broken on different devices. Simple things like forgetting to define a viewport size can make an interface unusable or really annoying to get around. Why?

I think as a community we get far too excited about products. The whole mobile space thrives on hardware sales. So instead of building stable and good solutions we continuously want the newest and coolest and support it exclusively. I remember when Retina displays came out and many voices in the web design community called out that we need to fundamentally change what we are doing now. This is fleeting, and in many cases we aren’t even allowed as web developers to access the new technology that makes a product what it is. You can look very silly, very quickly when chasing the shiny.

One big part of this was people getting too excited about the iPhone and Android as the only platforms to support prematurely calling WebKit the only browser engine worthy of our efforts (effectively repeating the same mistakes we did in the end 90ies which gave us all the fun “IE only” web products). With the announcement of the Blink rendering engine powering Opera and Chrome from here on forward the “webkit only” argument went down the drain. Good riddance.

How about we give web technologies a new platform on mobile devices? And how about not trying to compete with iOS and Android on high end devices while doing so? This is what Firefox OS is about – it brings the web to people who have mobiles as their main interaction with the web – based on web technologies and without the lock-out.

Here are the main differences that FirefoxOS bring in comparison to Android or iOS:

• Targeted at new, emerging markets
• Very affordable hardware
• No credit card needed – client billing
• Web technologies through and through
• 18 mobile partners, 4 hardware partners

Firefox OS was created to bring users of feature phones into the web-enabled mobile world. It is meant to cater to the markets not covered by iOS and Android. Yes, you can buy cheap Androids world-wide but the version of Android they support doesn’t have an out-of-the-box browser that allows you to do interesting things on the web. Much like Firefox and Opera for Android allow more users world-wide to have a great web experience without having the latest hardware, Firefox OS goes further. Its main goal is to bring millions of new users to the web on their mobile devices without getting a second-grade experience.

One huge differentiator of Firefox OS is that instead of solely relying on a market place to list apps, apps can be found by entering what you are looking for. This means that if you enter for example a band name like “u2”, you get music apps offered to you. For a movie title it is apps that have to do with films. These are both apps listed in the market place and web-optimised sites. Say you looked for a band, you could click on the songkick icon and get the mobile interface of songkick. You can try the app before you download it and see if you like it. If you want to install it you just tap it for longer and Firefox OS will install the app – including offline functionality, full-screen interface and the extra hardware access Firefox OS offers. This means your mobile interfaces become the ad for your application and users don’t need to download and install a huge app just to try it out. Everybody wins. We made App discovery as easy as surfing the web.

What makes your HTML5 site and app for Firefox OS is the manifest file:

{
  "name": "My App",
  "description": "My elevator pitch goes here",
  "launch_path": "/",
  "icons": { "128": "/img/icon-128.png" },
  "developer": {
    "name": "Your name or organization",
    "url": "http://your-homepage-here.org"
  }
}

In it you define the name, describe the app, give us info about yourself and which icons to display. You also define the localisations that are available and what access you need to the hardware. Depending on how many things you want to access, you can host the app yourself or you have to get it hosted through our infrastructure. This is a crucial part of keeping the platform secure. We can not just allow any app to make phone calls for example without the user initiating them.

These are the three levels of apps available in Firefox OS. For third party app developers, the first two are the most interesting.

• Hosted apps – stored on your server, easy to upgrade, limited access.
• Privileged apps – reviewed by the App store, uses a Content Security Policy, hosted on trusted server
• Certified apps – part of the OS, only by Mozilla and partners

Apps that run on your own server have all the access HTML5 gives them (local storage via IndexedDB, offline storage via AppCache) and the new WebAPIs defined by Mozilla and proposed as a standard. A few of these APIs are also available across other browsers, for example the Mouselock API or the Battery API.

• Vibration API
• Screen Orientation
• Geolocation API
• Mouse Lock API
• Open WebApps
• Network Information API
• Battery Status API
• Alarm API
• Push Notifications API
• WebFM API / FMRadio
• WebPayment
• IndexedDB
• Ambient light sensor
• Proximity sensor
• Notification

One very important API in this stack is the Open Web Apps API. With these few lines of code you can turn any HTML5 web app into a Firefox OS app by offering a link or button to install it. No need to go through the marketplace at all – you can be in full control of your app.

var installapp = navigator.mozApps.install(manifestURL);
installapp.onsuccess = function(data) {
  // App is installed
};
installapp.onerror = function() {
 // App wasn't installed, info is in 
 // installapp.error.name
};

All the APIs are kept simple, they have a few properties you can reda out and fire events when there are changes in their values. If you used jQuery, you should be very familiar with this approach. This code, showing the Battery API should not be black magic.

var b = navigator.battery;
if (b) {
  var level = Math.round(b.level * 100) + "%",
      charging = (b.charging) ? "" : "not ",
      chargeTime = parseInt(b.chargingTime / 60, 10),
      dischargeTime = parseInt(b.dischargingTime/60,10);
  b.addEventListener("levelchange", show);
  b.addEventListener("chargingchange", show);
  b.addEventListener("chargingtimechange", show);
  b.addEventListener("dischargingtimechange", show);
}

If you host your app in the Mozilla Marketplace your app can do more than just the APIs listed earlier. You can for example access the address book, store data on the device’s SD card, connect via TCP Sockets or call third party APIs with XHR.

• Device Storage API
• Browser API
• TCP Socket API
• Contacts API
• systemXHR

For a hosted, privileged app it is simple to create a new contact. That enables you for example to sync address books across services. As with all the other APIs, you get an event handler that gets fired on success or failure.

var contact = new mozContact();
contact.init({name: "Christian"});
var request = navigator.mozContacts.save(contact);
request.onsuccess = function() {
// contact generated
};
request.onerror = function() {
// contact generation failed
};

Certified apps – apps built by Mozilla and partners have full access to the hardware and can do everything on it, including calls and text messaging and reading and writing permissions as well as accessing the camera.

• WebTelephony
• WebSMS
• Idle API
• Settings API
• Power Management API
• Mobile Connection API
• WiFi Information API
• WebBluetooth
• Permissions API
• Network Stats API
• Camera API
• Time/Clock API
• Attention screen
• Voicemail

One question we get a lot is why hosted apps on your own server couldn’t get full access to the camera and the phone – something that always is an annoyance on iOS which is why we need to use something like phonegap to create native code from our HTML5 solutions. The reason is security. We can not just allow random code not in our control to access these devices without the user knowingly allowing it every time you want to access this functionality.

If however, you are fine for the user to initiate the access, then there is a way using web activities. This for example is the result of asking for a picture:

The user gets an interface that allows access to the gallery, the wallpaper or to the camera. Once a photo is picked from any of those, the data goes back to your app. In other words, web activities allow you to interact with the native apps built into the OS for the purpose of storing, creating and manipulating a certain type of data. Instead of just sending the user to the other app you have a full feedback loop once the activity was successfully done, or cancelled. This is similar to intents on Android or pseudo URL protocols on iOS, with the difference that the user gets back to your app automatically.

There are many predefined Web Actitivies allowing you to talk to native apps. All of these are also proposals for standardisation.

• configure
• costcontrol
• dial
• open
• pick
• record
• save-bookmark
• share
• view
• new, f.e type: “websms/sms” or “webcontacts/contact”

For example this is all the code needed to send a phone number to the hardware. For the user it would switch to the dialer app and they have to initiate the call. Once the call is hung up (or could not be connected) the user gets back to your app with information on the call (duration, and the like).

var call = new MozActivity({
  name: "dial",
  data: {
    number: "+1804100100"
  }
});

To get a picture from the phone you initiate the pick activity and specify an image MIME type. This offers the user all the apps that store and manipulate images – including the camera – to choose.

var getphoto = new MozActivity({
  name: "pick",
  data: {
    type: ["image/png", "image/jpg", "image/jpeg"]
  }
});

Again, a simple event handler gets you the image as a data blob and you can play with it in your app.

getphoto.onsuccess = function () {
  var img = document.createElement("img");
  if (this.result.blob.type.indexOf("image") != -1) {
    img.src = window.URL.createObjectURL(this.result.blob);
  }
};
getphoto.onerror = function () { // error
};

The great news is that if you have Firefox on Android, this functionality is also available outside of Firefox OS for you – any Android device will do.

I hope you are as excited as we are and you are ready to have a go at playing with these APIs and Activities. But where to start?

The Firefox OS Developer Hub is the one-stop-shop for everything Firefox OS. There you can find information on what makes a good HTML5 app, play and download example apps to change into yours and find information how to submit your app to the marketplace or how to publish it yourself. You also get information about monetisation and how to set up a development environment (basically installing the simulator).

The simplest way to test out Firefox OS is to install the Simulator, which is just an add-on for Firefox. Once installed you can test your apps on your server or on your local hard-drive in a Firefox OS instance running in an own thread and an own window. You can get all kind of feedback about your app working in Firefox OS with the developer console and the error logs.

alt=”Boilerplate App” height=”400” class=”middle shadow”>

Firefox OS Boilerplate is a demo app that has stub code for all the different Web Activities. You can try them out that way and just delete the ones you don’t need. It is a great demo app to get started with and base your efforts on.

Sooner or later you’d want to test your app on a real device though. The easiest way to do that is to get a developer phone from Geeksphone.com. These have the same specifications as the Firefox OS phones sold in the markets our partners are targeting. These are now ready for pre-order and the shop should be live soon.

Even if you don’t care for Firefox OS or don’t want to build something for it, rest assured that it will have an impact on the current mobile web. A whole new group of users will emerge and the mobile version of your site will become a calling card for them to get interested in your offers. And if anything, HTML5 is supported by every player in the market, so now is a good time to brush up what is out there. This is what Firefox OS brings you – and soon:

• A whole new audience
• HTML5 without the lock-out
• Your web site is your ad!
• Minimal extra work, it works across platforms