Last year I posted about how to build and run B2G on the Nexus S. Much has changed since then and this post attempts to provide up to date instructions on building Firefox OS and installing the latest Gaia version.

I wrote ‘attempts’ because the support for the Nexus S bitrots frequently due to (I assume) most development effort going towards developer devices and devices that intend to be shipped. These instructions worked for me on my Nexus S and gives me a phone that can use Wifi, make calls, use 3G data, take photo’s, record video and install applications.

Getting the source

The main source repository is on github, https://github.com/mozilla-b2g/b2g. The first step is to clone this repository. I clone this into a directory called nexus-s:

$ git clone git://github.com/mozilla-b2g/B2G nexus-s $ cd nexus-s

Create a file in this directory called .userconfig containing the following:

export CC=gcc-4.6 export CXX=g++-4.6 export HIDPI=1

The first two entries are required if you are building on Ubuntu 12.10 to use gcc version 4.6, which you must install. B2G does not build using gcc version 4.7.

The last entry, HIDPI, results in applications using the correct resources for the screen size on the Nexus S. Without this many things will be scaled incorrectly.

Configuring

Once the source is obtained you need to pull down the sub-repositories required for the Nexus S. This step downloads multiple gigabytes of data and can take a long time:

nexus-s$ BRANCH=v1-train ./config.sh nexus-s

Note the use of the BRANCH environment variable. This configures our build to use the relatively stable v1-train branch. This branch gets regular updates but tends to be better tested than master which is often broken for not-quite-supported devices like the Nexus S.

Although we are using the v1-train we are going to use the master branch of Gaia so we get the latest and greatest user interface. We’ll change to this later.

Gecko changes

The branch of Gecko that v1-train uses has some bugs on the Nexus S. To fix this we need to apply some patches. The first is bug 832653, video playback broken on Nexus S. The patches relevant to Gecko from this bug that need to be applied are:

• Fix graphic buffer crash

There is also an MMS patch that should be applied. This is related to bug 860693. Without this patch any MMS message sent to your phone will result in the SMS app being unusable. The patch is a workaround for the lack of MMS support (which is an up and coming feature but not yet ready). When an MMS message is received it converts the MMS payload to an SMS message. You can’t read the actual MMS but it prevents the problem of killing the SMS app. The patch is at and was obtained from this XDA Developers post:

• mms patch

The following set of commands downloads these patches and applies them in a branch of the Gecko tree that the config.sh step previously obtained:

nexus-s $ cd gecko nexus-s/gecko $ git checkout -b nexus-s m/v1-train nexus-s/gecko $ curl -k -L https://bug832653.bugzilla.mozilla.org/attachment.cgi?id=734988 >p1.patch nexus-s/gecko $ curl -k -L http://cd.pn/mms.patch >p2.patch nexus-s/gecko $ patch -p1 <p1.patch nexus-s/gecko $ patch -p1 <p2.patch nexus-s/gecko $ git commit -a -m "Nexus S patches" nexus-s/gecko $ cd .. Gonk changes

Part of bug 832653 makes a change to the low level Gonk layer of B2G. This is in the libstagefright video decoding libraries. The change is to prevent output buffer starvation which results in video decoding stopping after a few frames. The required patch is:

• Fix output buffer starvation

To apply this patch:

nexus-s $ cd frameworks/base nexus-s/frameworks/base $ git checkout -b nexus-s nexus-s/frameworks/base $ curl -k -L https://bugzilla.mozilla.org/attachment.cgi?id=735002 >p1.patch nexus-s/frameworks/base $ patch -p1 <p1.patch nexus-s/frameworks/base $ git commit -a -m "Nexus S patches" nexus-s/frameworks/base $ cd ../.. Gaia changes

There are Gaia changes required as part of bug 832653 as well. This change prevents errors from decoding thumbnails causing duplicate thumbnail entries in the video app:

• Prevent duplicate entries in video app list

We also want to be on the Gaia master branch to get the latest and greatest code. The following comands switch to this branch and apply our patch:

nexus-s $ cd gaia nexus-s/gaia $ git checkout -b nexus-s mozillaorg/master nexus-s/gaia $ curl -k -L https://bugzilla.mozilla.org/attachment.cgi?id=735005 >p1.patch nexus-s/gaia $ patch -p1 <p1.patch nexus-s/gaia $ git commit -a -m "Nexus S video app thumbnail fix"

There is a bug related to video recording on the Nexus S. To fix this we need a patch from bug 832638:

• Set video recording profile in camera app

To apply this:

nexus-s/gaia $ curl -k -L https://bugzilla.mozilla.org/attachment.cgi?id=704241 >p2.patch nexus-s/gaia $ patch -p1 <p2.patch nexus-s/gaia $ git commit -a -m "Nexus S video recording fix" Building

Now that all the required changes have been made we can build:

nexus-s $ ./build.sh Installing

Once the build is complete you should be able to flash the Nexus S with the results. Note that this completely wipes everything on your phone:

nexus-s $ ./flash.sh

The phone should reboot after this step with Firefox OS installed and prompting for information from the “First Run” app.

New Zealand changes

Some New Zealand sites don’t detect Firefox OS and serve their mobile versions. This can be changed by adding overrides to gaia/build/ua-override-prefs.js. I add the entries in b2gnzuaoverride.txt to this file to get stuff.co.nz, mega.co.nz and trademe.co.nz serving the correct mobile site. Once added to this file, reinstall Gaia on the phone.

nexus-s $ ./flash.sh gaia Updating

To update the source to latest versions we need to ‘rebase’ our changes on top of the most recent repository changes. The following steps will do this:

nexus-s $ git pull nexus-s $ ./config.sh nexus-s nexus-s $ cd gecko nexus-s/gecko $ git rebase m/v1-train nexus-s/gecko $ cd ../gaia nexus-s/gaia $ git rebase mozillaorg/master nexus-s/gaia $ cd .. nexus-s $ ./build.sh

You may need to do some fixing up of merge conflicts if changes have occurred to the areas we’ve patched.

To flash the phone, overwriting everything on it, including all user data:

nexus-s $ ./flash.sh

To flash the phone, keeping (most of…) your existing user data:

nexus-s $ ./flash.sh system nexus-s $ ./flash.sh gecko nexus-s $ ./flash.sh gaia

Note that flashing gaia might remove some of your installed application icons. You’ll need to reinstall those apps to fix that.

I’ve long privately thought that Firefox should treat feed reading as a first-class citizen of the open web, and integrate feed subscribing and reading more deeply into the browser (rather than the lame, useless live bookmarks.) The impending demise of Reader has finally forced me to spit out my thoughts on the issue. They’re less polished than I like when I blog these days, but here you go – may they inspire someone to resuscitate this important part of the open web.

What? Why is this an open web problem?

When I mentioned this on twitter, an ex-mozillian asked me why I think this is the browser’s responsibility, and particularly Mozilla’s. In other words – why is RSS an open web problem? why is it different from, say, email? It’s a fair question, with two main parts.

First, despite what some perceive as the “failure” of RSS, there is obviously  a demand by readers to consume web content as an automatically updated stream, rather than as traditional pages.1 Google Reader users are extreme examples of this, but Facebook users are examples too: they’re no longer just following friends, but companies, celebrities, etc. In other words, once people have identified a news source they are interested in, we know many of them like doing something to “follow” that source, and get updated in some sort of stream of updates. And we know they’re doing this en masse! They’re just not doing it in RSS – they’re doing it in Twitter and Facebook. The fact that people like the reading model pioneered by RSS – of following a company/news source, rather than repeatedly visiting their web site – suggests to me that the widely perceived failure of RSS is not really a failure of RSS, but rather a failure of the user experience of discovering and subscribing to RSS.

Of course, lots of things are broadly felt desires, and aren’t integrated into browsers – take email for example. So why are feeds different? Why should browsers treat RSS as a first-class web citizen in a way they don’t treat other things? I think that the difference is that if closed platforms (not just web sites, but platforms) begins to the only (or even best) way to experience “reading streams of web content”, that is a problem for the web. If my browser doesn’t tightly integrate email, the open web doesn’t suffer. If my browser doesn’t tightly integrate feed discovery and subscription, well, we get exactly what is happening: a mass migration away from consuming (and publishing!) news through the open web, and instead it being channeled into closed, integrated publishing and subscribing stacks like FB and Twitter that give users a good subscribing and reading experience.

To put it another way: Tantek’s definition of the open web (if I may grotesquely simplify it) is a web where publishing content, implementing software that consumes that content, and accessing the content is all open/decentralized. RSS2 is the only existing way to do stream-based reading that meets these requirements. So if you believe (as I do) that reading content delivered in a stream is a central part of the modern web experience, then defending RSS is an important part of defending the open web.

So that’s, roughly, my why. Here’s a bunch of random thoughts on what the how might look like:

Discovery

When you go to CNN on Facebook, “like” – in plain english, with a nice icon – is right up there, front and center. RSS? Not so much. You have to know what the orange icon means (good luck with that!) and find it (either in the website or, back in the day, in the browser toolbar). No wonder no one uses it, when there is no good way to figure out what it means. Again, the failure is not the idea of feeds- the failure is in the way it was presented to users. A browser could do this the brute-force way (is there an RSS feed? do a notice bar to subscribe) but that would probably get irritating fast. It would be better to be smart about it. Have I visited nytimes.com five times today? Or five days in a row? Then give me a notice bar: “hey, we’ve noticed you visit this site an awful lot. Would you like to get updates from it automatically?” (As a bonus, implementing this makes your browser the browser that encourages efficiency. ;)

Subscription

Once you’ve figured out you can subscribe, then what? As it currently stands, someone tells you to click on the orange icon, and you do, and you’re presented with the NASCAR problem, made worse because once you click, you have to create an account. Again, more fail; again, not a problem inherent in RSS, but a problem caused by the browser’s failure to provide an opinionated, useful default.

This is not an easy problem to solve, obviously. My hunch is that the right thing to do is provide a minimum viable product for light web users – possibly by supplementing the current “here are your favorite sites” links with a clean, light reader focused on only the current top headlines. Even without a syncing service behind it, that would still be helpful for those users, and would also encourage publishers to continue treating their feeds as first-class publishing formats (an important goal!).

Obviously solving the NASCAR problem is still hard (as is building a more serious built-in app), but perhaps the rise of browser “app stores” and web intents/web activities might ease it this time around.

Other aspects

There are other aspects to this – reading, social, and provision of reading as a service. I’m not going to get into them here, because, well, I’ve got a day job, and this post is a month late as-is ;) And because the point is primarily (1) improving the RSS experience in the browser needs to be done and (2) some minimum-viable products would go a long way towards making that happen. Less-than-MVPs can be for another day :)

1. By “RSS” and “feeds” in this post, I really mean the subscribing+reading experience; whether the underlying tech is RSS, Atom, Activity Streams, or whatever is really an implementation detail, as long as anyone can publish to, and read from them, in distributed fashion.
2. again, in the very broad sense of the word, including more modern open specifications that do basically the same thing

My daughter turned 4 a few months ago. We were musing over how to ask family not to give too much: we’re uncomfortable when she receives a lot of gifts. We don’t want to be ungrateful, so we experimented with asking people to give her $4. We’d then talk with her about saving a 1/3 of the money, spending 1/3, and donating a 1/3 to a charity.

Tonight we discussed what she’d like to do with the 1/3 she’d give to charity. We’d discussed inequality before - and she said she’d like to give the money to kids who needed it. We talked about places in the world at war, and how the kids in those countries suffered. We talked about Syria. And I thought of Bassel.

Bassel Khartabil is a contributor to open source projects. He is a developer. He’s a tinkerer. He’s help build two projects that have had a profound impact on my life: Creative Commons and Mozilla. And for over a year, he has been detained in a Syrian prison - arrested by the government in a mass roundup in Damascus.

Bassel had arranged a screening of my documentary, Rip, in a Damascus hackerspace. We’d exchanged a few emails. I had a chance to meet him in 2011 in Seoul at a Creative Commons gathering, and was very impressed by him. Humble, generous, intelligent. We discussed a potential collaboration - we chatted and explored Seoul. I snapped this picture of him. I had forgotten about this picture and found it on my computer in a backup of cell phone pics.

Bassel’s curiosity is the same as mine and my colleagues at Mozilla. He has a family. I am grateful to him, and upset that he remains in prison for being a hacker and an independent thinker. I feel for his friends and family, and hope that the web he helped build can help in its way to dismantle regimes such as Assad’s.

Layla donated a third of her birthday money to children in Syria with savethechildren.com. Bassel, we hope you are ok.

…And you can, too!

We did it with one simple rule:

Only items that have already been raised on the mailing list are allowed on the agenda.

Using this rule, Reps Council cut their average meeting time from 2 hours (yes! you read that right!) to the target 1 hour. It’s really that simple.  Here’s why it works:

The Problems Topic 101

We realized that most of the meeting was taken up with the “stupid” questions that inevitably come up with a new topic, asking for clarification on what was meant, asking for background on the topic. Getting everybody on the same page on a new topic can take 15 – 30 minutes depending on how complicated or contentious the subject is.

Language Barrier

By the way, this is why Reps meet on IRC. I like to say that “you guys don’t type with an accent!” when I mention my preference to IRC meetings over voice calls. Depending on the English skills of the people attending, they may need more time to understand what was said, or have it explained a different way.  At least on IRC non-native speakers can form their thoughts while others are typing.

Using speech, the accent issue can cause delays both ways. Not all English speakers’ accents are created equal. When the Reps mentors met in Berlin, it was often requested that I speak because my Canadian accent was easily understood, while some people whose written English was very good, couldn’t be understood by many when speaking.

The language barrier does cause delays even on IRC. It can add 15 minutes or more while people try to understand what was said, then formulate their response, and have to speak slowly. More worrying is the time that isn’t taken up by those that don’t understand the topic well enough to discuss it in the moment.

Forming an Opinion

Before you make a decision on a topic, you need to know how you feel about it. In well functioning teams this also means taking time to consider how the rest of the team feels, and why. An opinion can’t be formed in a moment. It takes consideration, some mulling, maybe even research. We could easily take a whole hour discussing one new topic, but here is another 15 minutes at least of discussion.

The 80% Rule

In Athens, Gunner introduced a very good rule for group discussion. He said (paraphrasing), “For a feature to be included in Firefox, it has to be relevant to 80% of the users. Only ask questions that you think apply to 80% of the group.” If a meeting is the primary discussion mechanism for a group, or team, it becomes the place where people ask questions that only apply to a small portion of the team, or even just themselves. Everyone else has to wait for these discussions before moving on to the next 80% topic. Even the time it takes for someone to ask the question and be told to ask it privately later can add up. It can sometimes take 5 minutes or more for the person to explain their question and for the other participants to understand that it’s not really applicable to the group.

The Solution

Using a mailing list, newsgroup, forum or other asynchronous discussion tool prevents many of these topics from running down the clock in your meeting.

Going Async

This is a time trade-off. Obviously the 101 discussions and opinion arguments need to happen. Having them asynchronously allows people to choose the time that best suits them for contributing to the discussion. It allows people to participate that can’t make the meeting time. People can skim over the topics they’re not interested in, or don’t have anything to add to. In a synchronous meeting, they must sit and wait while these discussions happen, unable to completely context shift away from the meeting as they need to follow along to know when the discussion reaches a topic of interest.

Background and 101

You can give a much more complete background of a topic asynchronously. Asking people to read a blog post or proposal before a meeting means people can come to the discussion well informed, which a chance to point out missing pieces of the background. Again people can choose when to do this on their own time and will be able to give it more time and consideration than if you give them 5 minutes in a meeting to get familiar. People who are familiar with the topic can skim the discussion without having to wait through that portion of the meeting.

Forming an Informed Opinion

How many of us have epiphanies on subjects while in the shower, or taking a walk? We all need time to consider someone else’s point of view. I think we all tend to be more aggressive about our own opinions when discussing them real-time. Our brains don’t have time to explain ourselves while trying to understand someone else in the moment. When we have time to think about what we’re saying, and what others are saying we have time to form better responses, better consider what the other is saying, and even time to walk away, calm down, and come back with a fresh perspective.

Discussing opinions on a topic before a meeting also allows those in the meeting to recap and consider the opinions of those who can’t make the meeting. Someone else can raise a good point that was made in the async discussion, even if it wasn’t their own.

Making Decisions and Moving Forward

When topics are presented and discussed on the mailing list (or your tool of choice) it leaves you prepared to recap and make a decision in the meeting, identify the next steps, assign action items and move on. All of a sudden a topic that used to take up 15 – 30 minutes of your meeting can be reviewed and acted upon in under 5. People can call out where they need still need help or have completed past action items, and use “discuss on list” as an action item liberally!

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

Here is lecture two from my class “The Company is the Content.” The case for this lecture was Hubspot, which provides inbound marketing tools for business, mainly SMBs.

Hubspot is pretty a pretty fascinating company to me and I was happy to find a case study on them. They are really one of the innovators in helping companies create and distribute content for marketing purposes. Not only is the content of the case really great, it is particularly well written so it was fun to teach and discuss.

The rest of the lecture looks at examples of what companies are doing to create and distribute their own content. It must be noted that the content here isn’t just marketing content, but also original content created and distributed to educate the market (not necessarily to sell to it.)

The best example in the world is Cisco. Their online newsroom “The Network” runs like and actual newsroom and draws on the expertise of professional industry journalists to research and write stories. The journalists are given considerable leeway to cover the stories they want, and in the manner they want.

Here’s the lecture

Lecture 2 talking from ronpiovesan

Here’s an amusing video from Hubspot explaining “inbound marketing”:

I’m working across a lot of different repos these days, and while fixing a whitespace issue in one of my patches, I wondered if it would be possible to eliminate this altogether.

Working with git, we already have a version of what I want in terms of core.autocrlf.  You wrote this patch on Windows, I’m on OS X, and our server is Linux?  No problem, we’ll just use Unix EOLs and have git automatically manage the line endings whenever we checkout or commit.  In other words, when I checkout the code locally, I get a version of it customized to my environment.  There’s a canonical version that git will store, but every developer can have something different in their editor.

Now let’s go one step further.  Imagine you need to add the following code, as I did today:

module.exports = function( req, res ) { res.json({ http: "okay" }); };

How many arguments can you have about how to style that code?  Come on, what would you r- in this?  “Dave, no space between `(` and `req` please;” “Dave, you need to indent with 4-spaces not 2;” “Dave, you should just put that `res.json` all on one line.”

The truth is, there’s no right answer here.  Of course there are famous examples of automatic semi-colon insertion causing havoc (`return\n{` vs. `return {`), but let’s stick with my example code for a minute.  Could we let git manage the whitespace here?  Could we, in other words, take that code above, and when I commit, actually store this:

module.exports=function(req,res){res.json({http:"okay"});};

Now imagine that I’ve got a .gitstyle file in my tree, or I’ve somehow specified config options globally, and I can tell git how to style this code again when I check it out.  Imagine you like 8-space indents and I like 2-spaces; imagine you’re allergic to spaces around arguments, and I love them; imagine your OCD demands that all variable declarations line up on the equal sign, and I’m happy to let them wind their way down my editor like a raindrop on a window.  And, imagine we can both do what we like with the same code in the same tree!  Imagine there’s no style guide, it’s easy if you try…

BUT DAVE, THIS CAN’T WORK BECAUSE <strong-reason />!!!  Sure, there’s all sorts of things to work out.  This is a thought experiment.  I’m supposed to be grading final assignments right now, and I needed to procrastinate.  But if this could work, it would be so, so useful!

Patches accepted (please use 2-space indents).

The last weeks a lot of volunteers showed up to develop on (GNOME) Music.

Now we can browse the albums and their content making it our most complete view. Playback to the albums view and songs view is in development (works but is buggy).

 

Also we are heavy working on the artist view trying to match the mockups, currently the code delivers the following screenie:

There is still a lot to be done, and we created a semi roadmap of our development plan. Phase 1 should be completed within the next 2 – 3 weeks. We also moved our UI development to be glade.

I am very happy with the contributor turnout (no special order):

• Vadim Rutkovsky
• Eslam Mostafa
• Paolo Borelli
• Guillaume Quintard
• Allan Day
• Jakub Steiner
• Shivani Poddar
• Sriram Ramkrishna
• Hylke Bons

Nice to have this mix of old and new contributors working together. If interested join us on #gnome-music on gimpnet. This is where the communication happens.

Also I would like to thank Next Tuesday for sponsoring part of my time on working on GNOME Music

.

 

Sometimes you have to build something, to find out if it already exist…

Last Friday I created Taxiderm.

Watch the demo…

Taxiderm Freaky Friday from on Vimeo.

The elevator pitch? Taxiderm takes the skins from your frontend and pumps them full of sawdust. Creates life-like webapps which can easily be:

• worked on for CSS tweaks in hard to reach places
• share links with localization community to preview their translations

Of course this idea could be generalized to any templating language, jinja2 using nunjucks, mustache templates, etc.

Does a tool like this already exist for Designers to preview their CSS without setting up a full application stack? That creates a catalog of links for all the various application states?

On Februrary 20, 2004, the day before FOSDEM 2004, I apparently made slides of my talks public for the first time, putting the L10n status update for that weekend up on kairo.mozdev.org for everyone to refer to.

It was nice to have them up on the web both for people to look them up and for myself in case there would be a problem with my laptop and I'd not have my "master copy" available there. Also, having the contents managed in a version control system (cvs) meant that recovering from accidental changes would be easier and that I could easily sync copies between my desktop, laptop and the web.

Over the years, I added all slides from any presentations I made to that site, and even those from the years before - even that "outliner" for the 2002 talk about what "chrome" was all about (which I wrote up during the presentation right before it, and which was my only slide for that talk - things were a bit different on our first FOSDEM appearance then nowadays for sure).

Fast forward to today: mozdev.org isn't all that well-maintained any more, I never did put up much more than the slides there as I ended up putting all my content on my own server (and domain) anyhow, and cvs also probably isn't the state of the art any more for version control. In addition, I recently discovered how I could do decent auto-deploy of changes on my websites with git hooks on the repos that I host on my own server anyhow.

So, I did a simple "git cvsimport" on a cvs checkout of my slides, and now am using the resulting git repository to host all this right on my server at slides.kairo.at.

I also improved the index page from a pure list into a tabular format, of course using the common KaiRo.at color scheme and my logo, and exchanged the URLs on the slides themselves to point to the new domain. Note that I didn't do any other changes to the slides, so some of them might not be optimal in usability or design in current Firefox versions (I relied on SeaMonkey's site navigation bar a lot in the earlier slide sets, and I didn't add unprefixed versions of some CSS rules I used), but the newer ones should be as good as they can.

Now all I'm missing is to find a way to do a smart redirect (or URL rewrite) from mozdev to the new domain. Oh, and I need to get to creating slide sets for my Linuxwochen 2013 presentations...

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

Another collection of amazing things on the web, as compiled by the Webmaker community in our weekly community call. Make something amazing on the web now at Mozilla Webmaker — or help us brainstorm next week’s hotlist. What’s the coolest thing you saw on the web this week? Let us know…

• on our “memes” newsgroup. memes [at] mozillafoundation [dot] org
• at the start of each weekly Mozilla Webmaker call.
• as comments to this post.

• Hyper-lapse. Wow. Turn Google Street view images into something that feels like racing through streets at high speed.

• Blast from the GUI past. Check out this video of the very first CAD program from 50 years ago. Really.

• This video from a Learning Party Pop-Up at Hive NYC member NYSCI is a great explanation and demo of what we hope Maker Party 2013 will be like. Webmaker Tools get a shout-out about five minutes in.

• Harry Potter Quidditch meme. AKA, “Pottering.”
• Mozilla’s Mark Surman as Indiana Jones.

No Shia Labeouf or nuking fridges in this one, we promise.

• Listen to BitCoin. Hear and visualize BitCoin transactions in real time. The sweet sound of internet commerce.
• How Animals Eat Their Food. 41 million views!
• Candid interview with Han Solo Harrison Ford on Jimmy Kimmel that are in no way related to the new Star Wars movie.
• The social media cautionary tale of Adam Orth. Guy loses his job over tweets.

I always wanted to see all the little things that happen when loading a web page in Firefox.  I know how it works well as a Gecko developer, but to actually see the interaction and chaining is not at all always obvious, unless you study crazy NSPR logs.  Hence, I started a development of a tool, called event tracer, to get a timeline showing the hidden guts.

Example screenshot will tell the story the best way, a trial run of www.mozilla.org load:

Planning improvements

At this time the work is not complete.  There is a lot more to make this an actually useful development tool and my next steps are to hunt those requirements down.

I am using about:timeline to verify patches I review do what they intend to do.  It can also help find hidden bugs.

However, using about:timeline for discovery of perfomance suboptimal code paths showed up being not that simple.  Events are just spread all over around and connection between them is not easily, if at all, discoverable.

Hence, this needs more thinking and work.

First thoughts to improve are to more focus on “the resource” and a single object dealing with it.  It might be better to show what all events are happening on e.g. a single instance of an http channel or http transactions then to tortuously hunt them somewhere in the graph.  There is some simple way to highlight and filter, but that is not enough for an analytical view.

Then, I’m missing a general way to easily recognize how things are chained together.  So, I’d like to link events that are coming one from another (like http channel creates an http transaction, then a connection etc.) and present the timeline more like a gantt chart plus show a critical path or flow for any selected pass through.

From inspecting the timeline it should be visible where bottlenecks and long wait times worth fixing are.  At this time I don’t have a complete clear plan on this, though.

 

Still here?  Cool   If you have any though or ideas for how to use the data we collect and visualize as a valuable source for the performance optimization surgery please feel free to share them here.  More on how the timeline data are produced check bellow.

 

How it works

This event track on the image is produced with a special code instrumentation.  To get for instance “net::http::transaction” traces, following 3 places of the code have been instrumented (in blue):

 

1. WAIT – record time when an http transaction is scheduled:

nsresult nsHttpTransaction::Init(uint32_t caps,                         nsHttpConnectionInfo *cinfo,                         nsHttpRequestHead *requestHead,                         nsIInputStream *requestBody,                         bool requestBodyHasHeaders,                         nsIEventTarget *target,                         nsIInterfaceRequestor *callbacks,                         nsITransportEventSink *eventsink,                         nsIAsyncInputStream **responseBody) {     MOZ_EVENT_TRACER_COMPOUND_NAME(static_cast<nsAHttpTransaction*>(this),                                    requestHead->PeekHeader(nsHttp::Host),                                    requestHead->RequestURI().BeginReading());     MOZ_EVENT_TRACER_WAIT(static_cast<nsAHttpTransaction*>(this),                           "net::http::transaction");

 

2. EXEC – record time when the transaction first comes to an action, it is the time it gets a connection assigned and starts it’s communication with the server:

void nsHttpTransaction::SetConnection(nsAHttpConnection *conn) {     NS_IF_RELEASE(mConnection);     NS_IF_ADDREF(mConnection = conn);     if (conn) {         MOZ_EVENT_TRACER_EXEC(static_cast<nsAHttpTransaction*>(this),                               "net::http::transaction");     }

 

3. DONE – record time when the transaction has finished it’s job by completing the response fetch:

nsHttpTransaction::Close(nsresult reason) {     LOG(("nsHttpTransaction::Close [this=%x reason=%x]\n", this, reason)); ...     MOZ_EVENT_TRACER_DONE(static_cast<nsAHttpTransaction*>(this),                           "net::http::transaction"); }

The thread timeline where an event is finally displayed is the thread where EXEC code has been called on.

What is the exact definition of the WAIT and EXEC phase is up to the developer now.  For me the WAIT phase is any time an operation is significantly blocked before it can be carried out, it’s the time having the main performance affect we may be in particular interested in shortening.  Few examples:

• time spent in a thread’s event queue – duration from the dispatch to the run
• time spent waiting for an asynchronous callback such as reading from disk or network
• time waiting for necessary resources, such as an established TCP connection before an object can proceed with its job
• time spent waiting for acquirement of a lock or a monitor

How to bind a URL or any identifying info to an event

The following instrumentation is used (in red):

nsresult nsHttpTransaction::Init(uint32_t caps,                         nsHttpConnectionInfo *cinfo,                         nsHttpRequestHead *requestHead,                         nsIInputStream *requestBody,                         bool requestBodyHasHeaders,                         nsIEventTarget *target,                         nsIInterfaceRequestor *callbacks,                         nsITransportEventSink *eventsink,                         nsIAsyncInputStream **responseBody) {     MOZ_EVENT_TRACER_COMPOUND_NAME(static_cast<nsAHttpTransaction*>(this),                                    requestHead->PeekHeader(nsHttp::Host),                                    requestHead->RequestURI().BeginReading());     MOZ_EVENT_TRACER_WAIT(static_cast<nsAHttpTransaction*>(this),                           "net::http::transaction");

 

Here the http transaction event is set a host + path of the resource it loads.

The object’s this pointer, that needs to be properly cast by the developer, is what sticks all together.  This is the main difference from how usual profiling tools work.  Event timeline is providing a view of event chaining crossing thread and method boundaries, and not just a pure stack trace.

View details of a tracked event

Each event track is bound with e.g. a URL it deals with, where applicable.  You can inspect the URL (the associated resource) and more details when an event is clicked on:

Wait between is track of the time the event spent waiting, i.e. the time the event has been scheduled and time of the execution start, both since the time tracking has been turned on.  The number in parentheses is simply the wait phase duration.

Execution is track of time spent by execution, i.e. when the intended job it self has started and when it has actually finished.  The parenthesized number is how long the job execution took.

Posted from is name of the thread the event has been scheduled at.

The Filter button is used to quickly filter this particular event plus it’s sister events out.  How it work is described bellow.

The Zero time button is used to shift the “time 0.000? of the timeline to the start time of the inspected event, so that you can inspect recorded timing of other events relative to this one particular.

mxr link will open results of search for the event name in the code.  This way you can quickly inspect how this event timing is actually instrumented and collected right in the code.

Filtering timeline events

You can filter events using two filtering functions:

• By type of an event (e.g. “net::nttp::transaction”, “docshell::pageload” etc.)
• By name of a resource an event has been associated with (e.g. “www.mozilla.org”, “/favicon.ico” etc…)

Filter by type – currently there are following event types so far implemented (instrumented).  Yyou get this check box list after the tracer run when you click filter events at the top bar:

Each event has a namespace, e.g. for “net::http::transaction” the namespaces are “net::” and “net::http::”.  You can turn on or off the whole set of events in a namespace easily.  Currently there are only “net::” and “docshell::” top level namespaces worth mentioning.

 

 

 

 

 

 

 

 

Filtering by resource, i.e. usually the URL a particular event or set of events have been bound to, is also possible when you click filter resource:

You can enter the filter string manually or use the provided autocomplete.  The by-the-resource filtering works as follows:

1. we inspect whether the string set as the filter is a substring of the event resource string
2. we inspect whether the event resource string is a substring of the string set as the filter

If one of these conditions passes, we display the event, otherwise, we hide it.

This way when you enter “http://www.mozilla.org/favicon.ico” as a filter, you see the http channel and transaction for this resource load, as well as any DNS and TCP connection setups related to “www.mozilla.org”.

 

How to use about:timeline your self

• Create an optimized build of Firefox with --enable-visual-event-tracer configure option
• Install about:timeline extension
• Run Firefox
• Go to about:timeline
• Press the orange [ Start ] button, you get the message the trace is running
• Proceed with your intended actions, e.g. a page load, and let it finish
• Return to about:timeline tab and press the [ Stop ] button
• Wait a little to get your events timeline details

 

So, here it is.  It’s a work in progress tho.  I’ll keep updates.

Just one year ago, the French Mozilla community was living times of major changes: several key historical contributors were leaving the project, our various community portals were no longer updates or broken, our tools were no longer maintained. At the same time a few new contributors were also popping in our IRC channel asking for ways to get involved in the French Mozilla community.

As a result, Kaze decided to organize the first ever community meetup for the French-speaking community in the Paris office (and we will repeat this meetup in June in the brand new Paris office!) .

This resulted in a major and successful community reboot. Leaving contributors passed on the torch to other members of the community, newer contributors were meeting in real life for the first time. This is how Clarista officially became our events organizer, this is how Théo replaced Cédric as the main Firefox localizer and this is how I became the new developer for Transvision!

What is Transvision? Transvision is a web application created by Philippe Dessantes which was helping the French team finding localized/localizable strings in Mozilla repositories.

Summarized like that, it doesn't sound that great, but believe me, it is! Mozilla applications have big gigantic repos, there are tens of thousands of strings in our mercurial repositories, some of them we have translated like a decade ago, when you decide to change a verb for a better one for example, it is important to be able to find all occurrences of this verb you have used in the past to see if they need update too. When somebody spots a typo or a clumsy wording, it's good to be able to check if you didn't make the same translation mistakes in other parts of the Mozilla applications several years ago and of course, it's good to be able to check that in just a few seconds. Basically, Phillippe had built the QA/assistive technology for our localization process that best fitted our team needs and we just couldn't let it die.

During the MozFR meetup, Philippe showed to me how the application worked and we created a github repository where we put the currently running version of the code. I tagged that code as version 1.0.

Over the summer, I familiarized myself with the code which was mostly procedural PHP, several Bash scripts to maintain copies of our mercurial repos and a Python script used to extract the strings. Quickly, I decided that I would follow the old Open Source strategy of Release early, release often. Since I was doing that on the sidelines of my job at Mozilla,  I needed the changes to be small but frequent incremental steps as I didn't know how much time I could devote to this project. Basically, having frequent releases means that I always have the codebase in mind which is good since I can implement an idea quickly, without having to dive into the code to remember it.

One year and 15 releases later, we are now at version 2.5, so here are the features and achievements I am most proud of:

1. Transvision is alive and kicking
2. We are now a team! Jesús Perez has been contributing code since last December, a couple more people have shown interest in contributing and Philippe is interested in helping again too. We have also a dynamic community of localizers giving feedback, reporting bugs are asking for immrovements
3. The project is now organized and if some day I need to step down and pass the torch to another maintainer, he should not have difficulties setting the project up and maintaining it. We have a github repo, release notes, bugs, tagged releases, a beta server, unit testing, basic stats to understand what is used in the app and a mostly cleaned up codebase using much more modern PHP and tools (Atoum, Composer). It's not perfect, but I think that for amateur developers, it's not bad at all and the most important thing is that the code keeps on improving!
4. There are now more than 3000 searches per week done by localizers on Transvision. That was more like 30 per week a year ago. There are searches in more than 70 languages, although 30 locales are doing the bulk of searches and French is still the biggest consumer with 40% of requests.
5. Some people are using Transvision in ways I hadn't anticipated, for example our documentation localizers use it to find the translation of UI mentioned in help articles they translate for support.mozilla.org, people in QA use it to point to localized strings in Bugzilla

A quick recap of what we have done, feature-wise, in the last 12 months:

• Completely redesigned the application to look and feel good
• Locale to Locale searches, English is not necessarily the locale you want to use as the source (very useful to check differences from languages of the same family, for example Occitan/French/Catalan/Spanish...).
• Hints and warnings for strings that look too long or too short compare to English, potentially bad typography, access keys that don't match your translation...
• Possibility for anybody to file a bug in Bugzilla with a pointer to the badly translated string (yes we will use it for QA test days within the French community!)
• Firefox OS strings are now there
• Search results are a lot more complete and accurate
• We now have a stable Json/JsonP API, I know that Pontoon uses it to provide translation suggestions, I heard that the Moses project uses it too. (if you use the Transvision API, ping me, I'd like to know!)
• We can point any string to the right revision controled file in the source and target repos
• We have a companion add-on called MozTran for heavy users of the tool provided by Goofy, from our Babelzilla friends.

The above list is of course just a highlight of the main features, you can get more details on the changelog.

If you use Transvision, I hope you enjoy it and that it is useful oo you. If you don't use Transvision (yet), give it a try, it may help you in your translation process, especially if your localization process is similar to the French one (targets Firefox Nighty builds first, work directly on the mercurial repo, focus on QA).

This was the first year of the rebirth of Transvision, I hope that the year to come will be just as good as this one. I learnt a lot with this project and I am happy to see it grow both in terms of usage and community, I am also happy that one tool that was created by a specific localization team is now used by so many other teams in the world

Today’s graph charts the percentage of Firefox users who have known-insecure versions of Flash. It also allows us to visually see the impact of various plugin blocks that have been staged over the past few months.

We are gradually rolling out blocks for more and more versions of Flash. In order to make sure that the blocklist was not causing significant user pain, we started out with the oldest versions of Flash that have the fewest users. We have since been expanding the block to include more recent versions of Flash that are still insecure. We hope to extend these blocks to all insecure versions of Flash in the next few months.

From the data, we see that users on very old versions of Flash (Flash 10.2 and earlier) are not changing their behavior because of the blocklist. This either means that the users never see Flash content, or that they always click through the warning. It is also possible that they attempted to upgrade but for some reason are unable.

Users with slightly newer versions seem more likely to upgrade. Over about a month, almost half of the users who had insecure versions of Flash 10.3-11.2 have upgraded.

Finally, it is interesting that these percentages drop down on the weekends. This indicates that work or school computers are more likely to have insecure versions of Flash than home computers. Because there are well-known exploits for all of these Flash versions, this represents a significant risk to organizations who are not keeping up with security updates!

View the chart in HTML version and the raw data. This data was brought to you by Telemetry, and so the standard cautions apply: telemetry is an opt-in sample on the beta/release channels, and may under-represent certain populations, especially enterprise deployments which may lock telemetry off by default. This data represents Windows users only, because we just recently started collecting Flash version information on Mac, and the Linux Flash player doesn’t expose its version at all.

Raw aggregates for Flash usage can be found in my dated directories on crash-analysis.mozilla.com, for example yesterday’s aggregate counts. You are welcome to scrape this data if you want to play with it; I am also willing to provide interested researchers with additional data dumps on request.

In any project that’s making active use of its bug tracker, there is always a danger of the tracker turning into a discussion forum itself, even though the mailing lists would really be better. Usually it starts off innocently enough: someone annotates an issue with, say, a proposed solution, or a partial patch. Someone else sees this, realizes there are problems with the solution, and attaches another annotation pointing out the problems. The first person responds, again by appending to the issue…and so it goes.

The problem with this is, first, that the bug tracker is a pretty cumbersome place to have a discussion, and second, that other people may not be paying attention – after all, they expect development discussion to happen on the development mailing list, so that’s where they look for it. They may not be subscribed to the issue changes list at all, and even if they are, they may not follow it very closely.

…

There isn’t one right answer, but there is a general principle: if you’re just adding data to an issue, then do it in the tracker, but if you’re starting a conversation, then do it on the mailing list. … To use a mathematical analogy, if the information looks like it will be quickly convergent, then put it directly in the bug tracker; if it looks like it will be divergent, then a mailing list or IRC channel would be a better place.

– Karl Fogel, Producing Open Source Software

“Setting disruptors to stun” was the keynote at HTML5 Devcon in San Francisco in April 2013. In it, I am explaining why we can not directly compare native and web apps and that the technical differences are not really the main issue. The main problem is that native apps follow a very old principle of “built-in obsolescence” which means that they are built to break and be replaced with a newer version so you can sell more. The talk then shows how Firefox OS disrupts that idea with the dynamic app discovery and by going to where new audiences are.

• Video on YouTube
  
• Slides
  
• Screencast
  

Transcript

Thanks for coming again. Thanks for being in the grand ballroom. With this chandelier I would’ve expected people to dress up a bit more nicely, but we’re geeks so I guess that didn’t work out. Today I was asked to give an inspiring speech about things and stuff, and I think that’s a very good start for a day. I wanted to do something very, very technical, but then it’s a keynote so you don’t do that, so don’t expect that from me. We can talk technical in any way you want to later.

I want to talk about how the web used to be this massive disruptor to a terrible market and how it changed over the years, and how in the last few years, especially last year here, a lot of people started scaring us into thinking the web was not there any more and it’s a new thing that we have to do right now and we are all going to lose our job and be homeless in two months because we don’t support the newest coolest iPad. It’s like this children’s book that you can buy now, which is called, “You can’t be an astronaut, it’s just not realistic.” This is really cool to give to your kids, like, “Here you go.”

Back in the days when I started on the web it was like this. We had wired connections and we all had keyboards to surf on. We all had to keep the mouse up, otherwise it would fall off the keyboard. This is what the web was about. It was just beautiful and in nice colors, and every kid had the hat sideways. It was just this wonderfully cool thing.

In reality, it was a really cool thing. I worked as a radio journalist back then, and I saw the Internet as there for everybody to start publishing and for everybody to be found worldwide and to communicate with people worldwide. To me this was a totally new thing. Before that we had these BBS’s where you had to know the telephone number to call to connect and get data from another server worldwide.

Then with the Internet, we connected with modems that sounded a bit like Skrillex but really wasn’t. It was just connectivity. You stood there and like, “This almost looks like an image, just give it another five minutes and it’ll be fine.” You had connections where you loaded something and then you disconnected it because you paid per minute, and then you went through the cache to find all the images you’ve been downloading because while you where loading it was too slow.

All these were really cool things, but it was a geek thing. The main market basically saw us like that. They saw it like the Ubuntu launch party there. Basically these are the geek guys that just do that and it’s never going to catch on and nobody cares. Old-school programmers like mainframe programmers or people that use Java and things like that, people who have beards and suspenders and are real men, told us that the web will never be anything. “That’s just a toy. You use that angle bracket stuff that’s never coding.”

Nowadays it’s a bit different. The web is mainstream and we’re all these cool hipsters. Everybody uses the web for something. Most of the time horrible things, like following Justin Bieber on Twitter and things like that, but everybody uses it and we’re seen as these magical creatures that can build websites and nobody knows what we are doing.

The reason why that blossomed so much in those few years is that it’s built on a principle that anybody can be on the web just with an HTTP connection and something that shows HTML. It doesn’t matter where you are, it doesn’t matter what your ability is, what your language is, what your connectivity is. Everybody is invited. That was the Olympic Games, the opening, and that’s when Tim Berners-Lee typed this in and said the web that he invented, or with other people, is for everyone.

We keep forgetting that, just how powerful the web is for people who don’t have a voice in mainstream media, who cannot get a school education but they can go to an internet café and look at a Udacity course or look at a Khan Academy course if they wanted too. They can look at Wikipedia. I went to the library to do my homework. I didn’t have Wikipedia. I know teachers have actually put wrong things in Wikipedia articles to see how many students will actually bring that in their essays, which is a really cool way of using the web as well.

Everybody on the web is a consumer and a creator. We keep forgetting that because we are getting into that consumption thing. People get excited, “I can watch Game of Thrones streaming on my Internet.” You’re like, “How is that better than TV? You can start and stop it, that’s just like a VCR.” A streaming video, a streaming TV channel would allow the audience to remix it and to do things with it and to vote on different endings and make it different.

This is what we do in Mozilla with the Webmaker project where we invite kids and journalists and people who are just afraid of computers and not use to the web for anything to start playing with them and start creating. Seeing how empowered they feel when they start creating is just gorgeous, because for a lot of people it’s a totally new job that they couldn’t have had before. So good times we’ll have.

We have these browsers that get better and better and better. We had a few browsers that finally died and then we had a few browsers that actually agreed on everything. HTML 5 means first and foremost that all browsers run the HTML the same way. That was a big, big thing. We see this as a given now, but actually that white space in Internet Explorer between LI items means you couldn’t style them. That was just a very annoying thing. You had to delete all kinds of things in there.

The browsers got better and better and we’re like, “Yes, we got it made, we got these cool HTML 5 APIs, we can do something.” Then change happened. What’s the main difference between Bill Clinton’s inauguration and Obama’s inauguration, except for the size of the flag and the color of the president, is everybody has this phone and takes pictures. Really blurry ones, really bad ones but everybody wants to take a picture and put it up online and be the first one to put it online because the 600 other people in that room don’t do the same thing, they don’t have the same idea.

I love it when you are at concerts and people hold their iPads up and film the band. You’re like, “Yeah, that sound quality is going to be amazing.” I had it the other day at Dropkick Murphys. I’m like, “Dude, last time you wouldn’t have survived and your iPod wouldn’t have,” but fair enough.

The web came around and the mobile phones came around, the smartphone came around. All hail the hypnophone; everybody has one, everybody needs one. It’s a great thing. You can talk to your friends who are on the other side of the planet, so you don’t have to talk to people next to you because they’re smelly and they spit and stuff. You have your virtual friends, so you don’t need to have real connections with other people, but you can complain online that you don’t have any friends. It’s a very on-the-go market and sometimes you even have connectivity and video with AT&T.

It started well. This is Steve Jobs, the visionary, the really, really good man, a really, really interesting guy. He released the iPhone … well, he had a few people helping him. He released the smartphone and iPhone and the first thing he said, “To be really disruptive and re-invent the phone, we have to actually have no SDK. It’s the web, it’s a web-based phone. You have Safari, you have the power of Safari and HTML 5 in your hand. You can build everything on the web with the phone, you can build great applications that can talk to the telephone, can talk to the map application.” That’s what he said.

Then the big backlash came from the developers and internally. Why did that happen? Well first of all, the mobile web was this mixed thing that nobody knew what’s going on there. We had this thing in the middle, and we had web developers on one side and native developers on the other, and both of them wanted to do it.

The native app developer is different to a web developer in many, many ways. They are actually used to a different environment. As a web developer I’ve got not SDK. I use VI, I use sublime text, I use that and we argue for a month who’s got the better text editor. We don’t wait for actually downloading an SDK for it as well.

The mobile space is a competitive and very closed market. The success of companies is very much based off how many patents they have and what they can actually protect from another. Like, “Oh, you can’t touch the screen of my phone because that’s my right.” Developers coming from that environment, for them the web seems scary. Like, “Everything is free and you can look at my code?” “How can I protect my java script code?” is a question I get every single time. Put it on a memory stick; leave it in your desk.

Fragmentation is the next big horror. “Oh my God, people have different phones and basically different sizes, and I have to support all of them. If only we had one government issued phone for everybody that has a fixed static thing.” For web developers it was, “Yeah, so? This is cool, I can write things for different platforms.” So fragmentation is being this horror word for everybody.

Shouldn’t we cherish flexibility much more? Shouldn’t we say, “Hey, if everybody cannot afford the newest iPhone, they have an old one, why not give them something for an iPhone 4? I mean these are just people with so much hardship in their lives, they only have an iPhone 4, so we should give them something.”

If you think about it, these tablets and smartphones are actually very flexible. Because you see as soon as you tilt them, they get longer. Because nothing at an angle could be as high as the other one, as long as it’s longer. Every display of those … I guess if you have the phone and hold it, it just automatically happens slowly so you don’t realize it. So tilting the phone makes it longer, and this is something you care about in your designs as well.

I wondered what the whole backlash was about. Why do developers get so riled up about not having an SDK and actually bringing the web on the phone? I did some research and I found this wonderful website called, “The Story of Stuff,” which explains about consumption and how America with 1% of the world population creates 20% of the waste and all these kind of interesting things. It’s a great thing to learn on the web. It’s in Flash but it’s not evil, so it’s really nice.

I learned about an old, old idea from Victor Lebow in The Journal of Retailing 1955. Actually what they said, and he was one of the advisors of President Eisenhower back then as well, “To make American companies be successful and make sure that we have money and jobs for the next few years our enormously productive economy demands that we make consumption our way of life, that we convert the buying and use of goods into rituals, that we seek our spiritual satisfaction, our ego satisfaction in consumption. We need things consumed, burned up, replaced and discarded at an ever-accelerating rate.” That was in 1955, it’s called, “The Principle of Obsolescence” and I’m happy I managed to pronounce that word.

Now as evil minds thing alike, there was this person that a year before even took that further. The build in obsolescence means that products are built to break after a year or two so you buy a new one. You realize that with every brand out there. I remember when I could kick a car door and there wasn’t a dent except my foot. Nowadays you have to replace everything and there are fifteen sensors in there to actually realize, “Hey…” parking sensors and all kinds of things.

Clifford Brooke Stevens actually took that further – and you can see that he is a very content and happy person – because he came up with the idea of the planned and built-in obsolescence. You don’t even need to make things break, you just have to make them look old and look outdated. You have to instill in the buyer the desire to own something a little newer, a little better, a little sooner than is necessary.

Every advertising is about this. Everything we see on telly is like, “This now has rounded corners.” Okay. How many people really feel like “Oh now I need this”. I was at Mobile World Congress and they showed all these hardware providers who went there and I went to every stand and asked, “What do you have?” “We got a new phone.” “What does it do?” “It’s bigger.” “Okay, is it faster too?” “Oh yeah, it’s faster too.” “What else does it do?” “It’s bigger and nicer and…” It’s no change. It’s just like a constant change in there that has to happen.

Perceived obsolescence is the next. Planned style obsolescence occurs when marketers change the styling of products so consumers will purchase products more frequently. The style changes are designed to make the owners of the old model feel out of date. You feel embarrassed pulling your first generation iPhone out in the coffee shop in San Francisco. This is because of this. We’ve been trained to think that things have to be outdated quickly and they’ve got to get new, new, new, new.

These shoes are 12 years old. Doc Martens in England. Now that Doc Martens has been sold to a company somewhere in the East, Doc Martens break within a year now as well. These ones don’t yet. So I will be very unhappy when they break.

It’s just amazing how we got into that. Other people thought it already as well. This was the ‘50s and everybody’s, “Oh my God, we’ve got to do this.” Then in the ‘60s some cynical mind basically said the systemic attempt of business to make us wasteful, debt ridden and permanently discontented individuals. To a degree, that’s right. People really, really rack up their credit card bills to get a new smartphone that they don’t need because they actually have a good smartphone already, but they want to be the new cool ones to have to swag and be awesome about it.

In essence, this is not our struggle. This is Apple’s and Google’s struggle and Samsung’s struggle and hardware makers’ struggle. We cannot compete with that. We cannot go and say, “Look, websites, you can edit it, you can change it, you can change the interface of a website. It will be maintainable for five years in the future.” No, no, no this thing has to break tomorrow. What can you give me that makes people buy a new phone because they want to have the next version of that game? This happens.

Web development and native development cannot be compared one to one. We always do these HTML 5 showcases where we show that HTML 5 could be like native apps. Then we make it work across all the browsers and across all the platforms like we should in HTML 5, and it turns out not to be as performing and as good as the native app. If you really want to prove that it does the same, do it on one platform, one browser and one configuration. This is not HTML 5, this is just making a native app in some environment that should not be native.

Fragmentation to us is a given. I never knew what browser you use. Hopefully Firefox, otherwise you have a bad time. I didn’t know what connection you have. I don’t know what resolution you have. I don’t know if you’re drunk. I don’t know if you can read English. I don’t know if you’re sober but you can’t read English. I don’t know anything about you and I love that. I love to write defensive code that actually says, “Can you do this?” “Yes.” “Okay, do this.”

@supports was put in Firefox Nightly yesterday, so basically you can have modernizer in CSS itself and in JavaScript. That’s kind of the stuff we need. All of these things [different hardware on screen] should get something. They should not get the same. They should get something that people can stomach.

To me it’s this golden playground. It’s a bit like Temple Run. You’ve got this street full of gold and there’s all kinds stumbling blocks and stuff, and we actually have to fix these stumbling blocks. It’s a bit like the 101. You go down to the Silicon Valley, you see how many millions of dollars are spent on different companies and you’ve got all these potholes at the same time.

The mobile web is there for us to make a good living with, but we just try to go for that big gold gem in the sky all the time. We want to be that $30 million seventeen-year-old kid that got bought by some company because this is the future. This is the same … I don’t want to say a strong word. This is the same lie that we have with this built-in obsolescence.

Yes, there will be one guy who’s actually starting to Facebook, there will be one guy who gets $1 billion for his company, but this is not maintainable. Not all of you can be that guy, and not all of you probably want to be that guy because they don’t have free time in their life anymore and a lot of pressure on them.

Who here plays an instrument or sings in a band? Why? You can never be as good and as successful and fast and rich as Justin Bieber. You don’t need to play your instrument, you need a producer. You need a nice dance move, you need some swag, and that’s about it. Why do you bother with this? You cannot be Justin Bieber. He’s much younger than you, he’s much faster than you, he’s much better than you.

Why do you do it? Because you like it. It’s fun to do. A musician is a person that takes thousand of dollars of gear 100 miles away to play $100 gig, because we love it. Because we want to do things and we don’t want that mainstream mediocrity that means that if you do the Justin Bieber thing and you’re successful for half a year you’re going to be in rehab two years later. So let’s play the long game a bit and think about what you’re going to do in 10 years with that, rather than, “Oh, money, money, money, more, more, bigger, bigger, bigger.”

We need lateral thinking. Which line of this one is longer? The upper, downer? Are they the same? No, they’re not. So why did all of you think that this is the same length? Because you’ve seen that thing before, it’s an old trick. It’s an old trap. It’s a clever trap. It’s obvious that they should different lengths, but it actually isn’t. You’re like, “I’ve seen that, you’re not going to get me again with this.”

This is how we build things right now. We learn hacks in browsers and then we internalize them and say, “The web will always be shit at that so I cannot do that in the future. I will do it like this for the next 15 years and, ‘The web just can’t do it, I’m sorry.’” Let’s think about it. Let’s measure things. Don’t get too excited about measuring like this. Lots of people get JS perf and these kinds of things, but it’s just like you can measure things but you have to measure them in context. Don’t fall into the too-clever trap. Don’t see the thing for the first time and you remember it didn’t work last time and say, “It’s not going to work again.”

What do we do now, instead of thinking about why we come and use the web? We build many, many, many, many awesome solutions. We build so many awesome solutions it’s incredible. We’ve got this Bootstrap. You don’t need to learn any HTML, just use Bootstrap and start from that if you’re not a professional. Grunt, Ember, Backbone, jQuery, Sencha, Hammer.js, Emmett, Compass, SASS, LESS, Zepto, blah blah blah, all these cool things that are coming out.

All of these things are great. They really are good. They are tools for power users that need to actually make their day-to-day job easier. They’re great. We just make new ones every month, that’s the problem with it, but we actually want to be more professional about it so we tell people, “These are the things you have to use, otherwise you are not really a web developer.” When I hear people say you need to know command line to be a web developer I’m like, “No, sorry, this is not the same. The command line is not on the web. You build things that are visual, you build interfaces, you build things that people need.”

We’ve got many, many awesome demos. This was going around a few months ago, a few weeks ago, a very, very remembrable URL fff.cmicmcn.com which showed all kinds of playful things and HTML 5 canvas demos and stuff. All of the things we’ve done in Flash four years ago and we now use in HTML 5 and we say, “This is awesome.” I think what we are having right now is an overflow of awesome.

I’m getting tired of seeing awesome, awesome, awesome, awesome. What I want to see is, “We’ve got this really terrible content management system. We have a room booking system, here’s how we fix it with HTML. Here’s how we made people happy across five different platforms.”

We don’t have to impress each other. We have to impress the mainstream. So stop building tools for each other and making the other tool do one thing less than the other one does. They’re all open source. Fork them, do things with them. Don’t build your own again.

I get excited about people building things. I’ve just been at POSCON in South Carolina, and all the developers you meet there are actually in small companies or freelancers. You show them something, I did a CCS 3 talk and two weeks later you get an email, “Oh, thanks for your talk, here is how I implemented it into my product.” I’m like, “Yes, this is exactly what I want to do.” Please build these things. Give it out to the main market. Don’t be excited that everybody is clever on stage and then be depressed that you’re not on stage and you build your own system so you get on stage. That’s a bit of loop we do at the moment.

The other day I had a guy in my gym in London ask me, “Hey you’ve got a computer, so you know about the Internet?” I’m like, “That’s obviously an interesting fallacy.” He’s like, “Oh, I want to get a new job. I want to learn about the Internet stuff. People say it’s really good to be a web developer and it’s a really good job to know that.” So I found this old laptop in my house that I cleaned up and I just put Ubuntu on it and a text editor and an HTML 5 book, and that’s what I gave him. I didn’t tell him, “Use Grunt, use Ember, start with Bootstrap.” That’s how I learned it, that’s how I got incredibly excited realizing that if I put a different color in there it looks different. Wow.

We can do that nowadays. The web needs no massive tools for production, for power users. Tools are great. For starters, don’t overload them with things that they can’t rely on in the future. All of these things are not built in the browser, so they might get outdated. They might get replaced. Don’t teach people things that are for just for the next two months.

How do we disrupt? How do we change that whole market? How do we get back to that idea that from the very beginning we said software is on the web and content is on the web, and it’s distributed worldwide without having to send floppy discs and CDs to each other? How do we go back to that?

The first thing is to stop being scared. Last year we had a few interesting things on stage here where people said, “Maybe the web is over. Maybe the web is going away.” We’ve got to keep the lights going. We’ve got to keep the lights going! I mean who of you as a web developer has problems paying their electricity bill? I didn’t know it was that high in San Francisco. My brother’s a fire man, he can’t find a job at the moment or a better job. He hates his job. But when he doesn’t do his job, people burn. When we don’t do our job things are five pixels off.

Don’t be worried about the future of the web. The web survived Flash. The web survived Java. The web survived Java Server Faces. The web survived any kinds of things out there because it’s a distribution model. It’s not technology. It’s not a certain stack of technology.

Will the web be the same in seven years? Hell, no. It will not be the same next month. That’s the power of the web. It keeps mutating. It keeps getting better. You cannot compare it with systems that are actually, “This is version one of the web, this is version two of the web.” No. This is worldwide changing constantly every second, and that’s the cool thing about it.

Chill out. Breathe. You’re going to have a job in five years, ten year’s time easily if you bet on the web right now. It may not be the same job, you have to be up on your feet and learn new things, but that’s what makes it interesting. I always hated a job that I got a pamphlet and like, “This is what you are going to be doing the next twelve years. No change, don’t worry about it.”

On the web, different story. New challenges every single day. I think we should stop copying. A lot of people, “Oh, there’s a native app that everybody uses right now, so let’s copy that in HTML 5. Let’s copy that in our technologies.” No, it’s a different idea. First of all you’ve got your obsolescence thing. Not every native app has everything in there in the beginning because they want to roll it out. If your app has all the features at the beginning you’re not going to have good time. You want to roll it out month by month by month. Trying to keep up with that is not possible.

Try to actually see the power of the web and the benefits of the web, of web technologies over native technologies. The biggest one is flexibility. If your app is not flexible you are doing it wrong. The thing should actually tell the user, “Okay, this works, this works, this works. I have a problem with that so I don’t give you that functionality.” Or just don’t show the functionality. Don’t promise things that you can’t fulfill. It’s an if statement, it’s not that hard to do.

If you copy, then kick ass. Sencha did this Fastbook and showed that the whole HTML 5 and stuff from Facebook was actually a misnomer and actually based on wrong assumptions. They did a good thing there and they showed basically that you can do a fast app on an iPhone in HTML 5, who should have known, like the ex-CEO of the company wanted it to be. That’s great. If you do these kinds of things then we should stop saying, “Yeah, but it only works in IOS and it only works in that.” Yeah, that’s what we cared about it in this moment.

We are fixing it together with them right now, and Flexbox is now in Firefox partly because Sencha Fastbook wanted to have it. We actually had a real, real good reason and demo to actually see what the problem was.

The other way to disrupt is to go where others don’t go. The problem is they’ll be like, “if you want to make money now only go for the iPhone market in America. That’s where people spend money.” This earth is this round blue thing and there’s these people, people everywhere and they want to do things on the web as well. Why not tap into a market that is not there for others? Why not tap into a market where the people that are actually driven by obsolescence cannot go, because the market can’t afford it, because the market can’t do it?

That is what we are doing with Firefox OS. I’m not here to make a pitch. I’ll just say what it is right now, because it is 90% of my life at the moment and I get incredibly excited about. We went to the Mobile World Congress, which is the most evil sales show on this planet. I spent two days just reporting incidents of booth babes to blogs in America that talk about inequality at conferences.

We rocked that thing. We were in every headline. Everybody released new phones, everybody released new things, and Firefox as an open source company, as a non-for profit organization giving out a free operating system was the main headline. Why? Because we got 18 mobile partners to partner with us and four hardware partners to bring out phones that are internet connected, that are web connected with smartphone functionality to markets that cannot get iPhones and that cannot get Android phones and can’t afford them.

Emerging markets like South America, like Eastern Europe, we have a lot of partners that go out to them. These aren’t partners that sell the thing with us, these are partners that actually code the thing with us. Instead of just having salespeople around them, we’re just like, “Okay you want to be part of this? Show us your engineers.” This is what where doing with that.

What Firefox OS does is replace old feature phones. We don’t replace the Androids, we don’t replace the IOS’s because we can’t compete on that market. We don’t have the marketing budget, we don’t have actually the hardware, we don’t have the people that want to actually partner with us because they’re like, “We’re just stinky free open hippies, that’s not right to work with.”

One of the main differentiators for us here in Firefox OS is first of all that everything is HTML 5 on that phone. Nothing in here is Java or Cocoa or Objective C. This is all HTML 5 and it’s on Github. You can go play with it. Of course for the mainstream market this means, “Oh, who cares?” What people care about is actually making it easier for them to find apps and to play with apps.

What is easy? Finding things on the internet. Maybe a search functionality, maybe something like playing with it. If you go on Firefox OS and hopefully my connector is working here, and I have a mouse somewhere, there you go. This is the emulator that was just put into Firefox as an add-on. Once you put it in there and it starts … Why does it do that to me when I go on stage? There you go. You can start the emulator. This is what it looks like. You got the error console, you can play with it, and this is the operating system itself.

If I go to a market right now and I want to have an app about my favorite band, I want to know something about a band, what do I do? I click through music apps, then I got 6000 of them, all of them reviewed by probably paid reviewers. I don’t know the name of those things. I don’t know what to do. That’s why we have to pay posters. That’s why we have to pay advertising, to get our name of our app into people’s heads. This is software, this is indexable software, why do we need this?

In Firefox OS, if you go here, you search for example Nine Inch Nails. Let’s do a good band. You get the background already changed into Nine Inch Nails and you get … oh we have nine here, wonderful. There’s a space in there, that was the problem. Let’s use U2 as another demo.

U2. I’ve got my background here. It changed into U2. I’ve got YouTube for videos, I’ve got Grooveshark for music, I’ve got SoundCloud for music, Wikipedia for written information. I can buy tickets on Songkick. It realized that I was entering a band and gave me your applications, anybody’s applications that are submitted in the market or are on the web. These are not the apps that are in my phone, these are apps on the web.

I can now click on this one for example, Grooveshark, and start listening to a U2 song if I really don’t like my life. Once I had a good experience with that app, I can go back and do a long click on the app and install it. A long click will then install it on the operating system. It will operate it like a bookmark like it does in IOS. It actually will install it with app cache, with everything going offline and giving you access to the hardware in ways that IOS doesn’t give you.

We made app discovery and app try before you buy as simple as actually surfing the web. If you have a mobile website and you want to sell an app, your mobile website is your advertisement for the app because we can index that for you and you can actually show up and do search results. This is bringing search technology to the app world, which is very interesting to me. I think it’s just, for you, a good idea to spruce up your mobile HTML versions that you have right now of your pages. You can play with that yourself.

Somewhere I’ve got my presentation again. There you go. I found that hard to explain to people at times. Once they started playing with it they entered a movie title and then they realized, “There’s movie apps, there’s Flixster, I can watch these movies.” You go from the use case to the app and from the app to the use case, which is what we do with closed markets right now.

The other thing we do is we enable hardware access. You’ve got all these API’s to access the hardware directly from JavaScript. The vibration API, which was called Vibrator API, I made too many stupid jokes, geo-location was one of the first things that we did years and years ago and then it went out to all the browsers. All of these APIs are not inside a SDK, these are standardized API proposals that other browsers can implement as well. Geo-location is across all browsers, the battery API is across all browsers. Network information, speed connectivity APIs have been used for others as well, indexedDB has been used by others.

You get full access to the hardware. That was always the problem in the iPhone, basically you got promise to access the hardware but you couldn’t get to it. You just had to build a native app going through PhoneGap or something like that. The other thing we did, of course we cannot allow any app to access every piece of the hardware, because you could make a puzzle game that calls 1-900 numbers in the background and racks up lots and lots of money. We actually have to review some apps in terms of security, how much access to the hardware you want.

We also came up with a system called Web Activities, which was much like Web Intents in Chrome, but it’s actually active. What it does, it allows you to use other apps to do something on your behalf. If you want to do a telephone call you have to have an app that is listed in the marketplace and reviewed by Firefox or by Mozilla. If you want to just do a telephone call from a web app that you host on your own server, you can use the telephony pick API here, so you’ve got the pick action. Nope. Okay, again.

You need a photo. If you want to have a photo you just call a pick action. You don’t care where the photo comes from. You don’t want to know if it’s from the gallery, from the wallpaper or if it’s from the camera. That’s what you do. You do a pick action, the user then chooses which ones he wants to actually use. Give you a photo; you get the photo back.

Same with the telephone call, you give the telephone action a call … telephone number. It switches to the dialer app. The user has to initiate the call. You don’t do it on their behalf. It’s up to them to actually make that call. Once they hang up you go back to your app automatically and you get the duration of the call and the telephone number that was called.

The difference to the pseudo-protocols and things that we had on IOS is that you get a feedback loop. You bring something to a native app and then you get the data back. That is cool because I don’t want to use your phone app all the time. I have a phone app that works fine on my phone. Why can’t I just use that? The Web Activities allow you actually to … any websites and any web app, to actually tie into other native apps of the operating system.

That works across Android and that works across Firefox OS as well. I love that because I don’t want to be in control for that. I don’t want to have your Flickr or Twitter or whatever credentials. These are yours, don’t give me them. It’s your way to share it on Twitter. It’s yours to actually take away. I don’t want my app to be responsible for things happening on your Twitter stream.

That is right now happening because we identify on behalf of the user the whole time. Web Activities allow any HTML 5 app to go into native apps and do their thing and get the data back. It’s much more important to me then actually accessing it myself and getting their information.

It works well with others. If you put Firefox on your Android all of these things, well not all of the APIs but the Web Activities, for example, work as well. So you can do that. Firefox for Android supports down to Froyo, so you don’t need the newest coolest Android to actually get HTML 5 support, sensible HTML 5 support.

Opera does the same thing now. Opera is also a browser you can install on Android to go back to an old version of android, rather than having Chrome only on the newest one.

Another big thing that we just released is that you shouldn’t make people think about the web but just come halfway. At the game conference that was just here in San Francisco we’ve announced ASM.js, which is also … there’s a meetup at 6:00 in our office today on the Eventbrite I think. What that one is, it actually allows you to convert C++ games or C++ code into JavaScript code.

If you’re a C++ company and you want to do something on the web but you really don’t want to re-educate all of your developers onto JavaScript because C++ guys looking at JavaScript makes them covered in hives and stuff, you can use that. One thing that we announce is the Unreal 3D engine, now running in JavaScript and Canvas and web GL in the browsers. You don’t need Flash to run 3D games.

Electronic Arts was one of our partners to actually bring out the 3D gaming onto the web and just convert their apps, convert their games, not write them from scratch because that’s not going to happen. We want to have the fidelity of 3D gaming on the web but we don’t want people to have to write from scratch, so we wrote a converter.

Same as the PDF displayer in the browser – it is also done through the same engine. Instead of having a plug-in that gets hacked every two months we just ran the PDF in JavaScript and the original thing was a C++ library. If you’ve got cool C++ stuff right now you can convert it to JavaScript rather than learning JavaScript, which to me is a handshake back to the 1980s where we can work together. The web will not replace you. We want your stuff. That’s what we do.

What can you do? How can you be part of that? The first thing that I have not seen yet and I want to see much more is context aware applications. Everybody has … okay this is a responsive design, it’s smaller on the phone and shows five buttons and it’s bigger on the other one. It doesn’t change the context. It doesn’t give you a way to actually work with it.

Imagine a company that actually has a guy walking around going to meetings. The interface on the phone could be start it there, find my location, stop the meeting there. When he goes back into his office and starts the desktop, he opens the same app, the same HTML app, and it actually shows him, “Okay, here’s what you did today. Please put the notes in there. Please put the photos in there. Upload the other stuff.” We do different things that we do on a phone than we do on a desktop.

We shouldn’t just make everything dumber because the mobile phone is the clever thing. We should give you a context aware app. What do you want to do on a desktop? What do you want to do on a mobile? What do you want to do on a tablet? Give you the best experience on all of these. HTML 5 is the only technology that allows you to do that because a native app cannot do this. You have to install three different apps on three different platforms.

That’s just not clever to me. That just doesn’t make any sense, that I have Temple Run on my tablet and my mobile phone, they’re out of sync and I have to do the same challenges on both of them? That’s just terrible for a small problem but it’s just not nice.

Go small. Go offline. If you can cut out a few k’s cut out a few k’s. If you can make the thing work offline that people can enter things while they’re actually waiting for it to load, great, that’s what we want. We want this experience to be as smooth as possible because we are impatient when we are on the phone.

We don’t really care about reloading a page three times on our desktop but on the phone it’s like, “This is broken, this is broken.” I love it in maps when people like, “We can’t find the map.” “Well it’s going to space for you, be a bit more grateful.” When I’m here, one pound, fifty per megabyte Internet roaming. If you have this 20 MB animated gif landing page, I hate you.

Fix the first generation mobile web. This was the login system at the airport in Barcelona, how it looked on my Android. Well that’s fun. Especially when you go through a second step it asked you for your passport number to get fifteen minutes of Internet access. Sure, I found somebody else’s passport so it’s all good.

That shouldn’t happen anymore. This is just silly. This is just … a viewport meta tag should be enough to fix that kind of crap. Make sure you realize … we’ve got wonderful things like VW and VH now in CSS as well, it can make typography resize according to the size of the screen. We can make the flexibility that Flash had years ago in web technologies easily nowadays.

Trust and help the platforms. You’re complaining that something doesn’t work in Firefox. Go to Bugzilla, complain, be annoying, put screenshots there. Put test cases there. Tell people what is wrong. Don’t go on Twitter and say, “Oh, Firefox does this wrong; I hope somebody from Firefox reads this and does my work for me.”

Same with Chrome, same with Opera, same with Internet Explorer, all of these things are available to you to complain where people are working on them. Not where we get applause from other people when we complain about them. Help us make the web better by using what browsers put in. I told you about @supports. Look at that tonight. Don’t animate anything in JavaScript. We cannot hardware accelerate your JavaScript animations. We can hardware accelerate anything in CSS because that’s our engine, but when you simulate what the browsers do natively we cannot help you make the web faster. Then it’s no help complaining that browsers are slow. You made that. You took over the browser’s job, so you make it fast.

Let us do what we need to do. Use translate instead of top and left. Use CSS animation. Use CSS transitions instead of JavaScript animate. We can make the thing better. Every six weeks there’s a new browser out. These things change constantly, please use that stuff. Give us feedback, what is necessary, what is unnecessary, what you like, what you don’t like. Jump right in, it’s fun. Yes it’s messy, but hey, this is fun.

Nothing stops you from actually helping the web of the future by helping the people who build the platform of the web. You can be massively successful tomorrow with a great native app. Good luck. Have fun with it. In half a year’s time it is going to be obsolete because the next one has to come. If you want to do that, if you want to play on the web, play by its wonderful, open rules and be successful by sharing and actually playing with things that come in there.

Every week I find something new in browsers and it gets me terribly excited. It’s a sad life. If I had some of the things that I had in the past … that I didn’t in the past, I would be on a beach now or something because I wouldn’t have to work anymore. Every browser is a developer platform. Every browser is a conversion tool. Reader Mode in browsers allows you to actually fix a lot of sites and actually read them nicely rather than have to click through two thousand ads. With that, I am out of time. I thank you very much.

If the weather forecast isn't too horrible I'll be away the coming Sunday afternoon to Tuesday morning tramping in the Hunua hills southeast of Auckland.

Thursday is Anzac Day, a public holiday, and I'll be taking Friday off to go on a holiday with my family. So I'll probably be in the office/online only on Wednesday next week (that's Tuesday for those of you on the wrong side of the date line).

About a week later, Sunday May 5, I have a flight to San Francisco. I'll be in the Bay Area on Monday and Tuesday, and at LEAD training on Wednesday and Thursday.

About week after that, Friday May 17, I'm flying to Taiwan for a Mozilla layout/graphics/media work week.

Fun times!

All around the world, millions of developers trudge to their jobs. They sit in bland cubicles, dealing with pointy-haired bosses who don’t get them, and working on projects, some of which never see the light of day. It’s a meager existence, and they long to do something else. They’re working for the weekend. I used [...]

On Monday it’s the last Web Literacy standard community call before the soft launch of the draft Web Literacy standard on April 26th. If that sounds tentative, it is! We want as much feedback from as wide a range of people and organisations as possible on the road towards v1.0 at the Mozilla Festival in late October 2013.

Below you’ll find the overview grid, the descriptors for each competency, and a diagram of the ‘stack’ of where this competency grid fits into the whole picture. We’ll have new, much better versions of these diagrams in due course – these are just my mockups!

The descriptors still need some work so that’s what we’ll be focusing in on at Monday’s call.

Exploring

• Web Fundamentals – Understanding and using the Web ecosystem
• Search – Locating information, people and resources
• Security – Keeping your identity, system and network safe
• Credibility – Assessing the trustworthiness of online sources of information or activities.

Building

• Composing for the Web – Composing ‘texts’ using hyperlinks and other affordances of the Web
• Remixing – Using existing openly-licensed content to create something new or modified.
• HTML- Understanding HyperText Markup Language, how to read and write the building blocks of the Web, and use it to create digital artifacts
• CSS – Understanding Cascading Style Sheets, how to read and write them and use them in different ways to style the building blocks of the Web
• Coding/scripting – Animating and providing services for the Web
• Design & accessibility – Developing competencies required to build web pages that promote efficient use of content and ease the acquisition of content provided
• Infrastructure – Understanding the Internet stack and hosting your own data

Connecting

• Sharing & Collaborating – Working and playing with others to create value through curating and creating content
• Community participation – Taking part in online communities taking into account netiquette
• Privacy – Taking steps to understand and decide how much data to share online
• Open practices – Championing, creating, and protecting the Open Web

To clarify, in the above diagram:

• We’re referring to the categories as strands
• Competencies are groups of skills from the same area
• The meta-level elements (which we’ll perhaps call literacies) are made up of competencies from different strands

Feedback is very welcome, either here or on the community calls.