Planet MozillaServiceWorkers in Firefox Update: July 26, 2014

(I will be on vacation July 27 to August 18 and unable to reply to any comments. Please see the end of the post for other ways to ask questions and raise issues.)
It’s been over 2 months since my last post, so here is an update. But first,
a link to a latest build (and this time it won’t expire!). For instructions on
enabling all the APIs, see the earlier post.

Download builds

Registration lifecycle

The patches related to ServiceWorker registration have landed in Nightly
builds! unregister() still doesn’t work in Nightly (but does in the build
above), since Bug 1011268 is waiting on review.
The state mechanism is not available. But the bug is easy to fix and
I encourage interested Gecko contributors (existing and new) to give it a shot.
Also, the ServiceWorker specification changed just a few days ago,
so Firefox still has the older API with everything on ServiceWorkerContainer.
This bug is another easy to fix bug.

Fetch

Ben Kelly has been hard at work implementing Headers and some of them have
landed in Nightly. Unfortunately that isn’t of much use right now since the
Request and Response objects are very primitive and do not handle Headers.
We do have a spec updated Fetch API, with
Request, Response and fetch() primitives. What works and what doesn’t?
  1. Request and Response objects are available and the fetch event will hand
    your ServiceWorker a Request, and you can return it a Response and this will
    work! Only the Response(“string body”) form is implemented. You can of
    course create an instance and set the status, but that’s about it.
  2. fetch() does not work on ServiceWorkers! In documents, only the fetch(URL)
    form works.
  3. One of our interns, Catalin Badea has taken over implementing Fetch while
    I’m on vacation, so I’m hoping to publish a more functional API once I’m
    back.

postMessage()/getServiced()

Catalin has done a great job of implementing these, and they are waiting for
review
. Unfortunately I was unable to integrate his patches into the
build above, but he can probably post an updated build himself.

Push

Another of our interns, Tyler Smith, has implemented the new Push
API
! This is available for use on navigator.pushRegistrationManager
and your ServiceWorker will receive the Push notification.

Cache/FetchStore

Nothing available yet.

Persistence

Currently neither ServiceWorker registrations, nor scripts are persisted or available offline. Andrea Marchesini is working on the former, and will be back from vacation next week to finish it off. Offline script caching is currently unassigned. It is fairly hairy, but we think we know how to do it. Progress on this should happen within the next few weeks.

Documentation

Chris Mills has started working on MDN pages about ServiceWorkers.

Contributing to ServiceWorkers

As you can see, while Firefox is not in a situation yet to implement
full-circle offline apps, we are making progress. There are several employees
and two superb interns working on this. We are always looking for more
contributors. Here are various things you can do:
The ServiceWorker specification is meant to solve your needs. Yes, it
is hard to figure out what can be improved without actually trying it out, but
I really encourage you to step in there, ask questions and file
issues
to improve the specification before it becomes immortal.
Improve Service Worker documentation on MDN. The ServiceWorker spec introduces
several new concepts and APIs, and the better documented we have them, the
faster web developers can use them. Start
here
.
There are several Gecko implementation bugs, here ordered in approximately
increasing difficulty:
  • 1040924 - Fix and re-enable the serviceworker tests on non-Windows.
  • 1043711 - Ensure ServiceWorkerManager::Register() can always
    extract a host from the URL.
  • 1041335 - Add mozilla::services Getter for
    nsIServiceWorkerManager.
  • 982728 - Implement ServiceWorkerGlobalScope update() and
    unregister().
  • 1041340 - ServiceWorkers: Implement [[HandleDocumentUnload]].
  • 1043004 - Update ServiceWorkerContainer API to spec.
  • 931243 - Sync XMLHttpRequest should be disabled on ServiceWorkers.
  • 1003991 - Disable https:// only load for ServiceWorkers when Developer Tools are open.
  • Full list
Don’t hesistate to ask for help on the #content channel on irc.mozilla.org.

Planet Mozilla[Video+Transcript]: The web is dead? – My talk at TEDx Thessaloniki

Today the good folks at TEDx Thessaloniki released the recording of my talk “The web is dead“.

Christian Heilmann at TEDx

I’ve given you the slides and notes earlier here on this blog but here’s another recap of what I talked about:

  • The excitement for the web is waning – instead apps are the cool thing
  • At first glance, the reason for this is that apps deliver much better on a mobile form factor and have a better, high fidelity interaction patterns
  • If you scratch the surface of this message though you find a few disturbing points:
    • Everything in apps is a number game – the marketplaces with the most apps win, the apps with the most users are the ones that will get more users as those are the most promoted ones
    • The form factor of an app was not really a technical necessity. Instead it makes software and services a consumable. The full control of the interface and the content of the app lies with the app provider, not the users. On the web you can change the display of content to your needs, you can even translate and have content spoken out for you. In apps, you get what the provider allows you to get
    • The web allowed anyone to be a creator. The curb to mount from reader to writer was incredibly low. In the apps world, it becomes much harder to become a creator of functionality.
    • Content creation is easy in apps. If you create the content the app makers wants you to. The question is who the owner of that content is, who is allowed to use it and if you have the right to stop app providers from analysing and re-using your content in ways you don’t want them to. Likes and upvotes/downvotes aren’t really content creation. They are easy to do, don’t mean much but make sure the app creator has traffic and interaction on their app – something that VCs like to see.
    • Apps are just another form factor to control software for the benefit of the publisher. Much like movies on DVDs are great, because when you scratch them you need to buy a new one, publishers can now make software services become outdated, broken and change, forcing you to buy a new one instead of enjoying new features cropping up automatically.
    • Apps lack the data interoperability of the web. If you want your app to succeed, you need to keep the users locked into yours and not go off and look at others. That way most apps are created to be highly addictive with constant stimulation and calls to action to do more with them. In essence, the business models of apps these days force developers to create needy, bullying tamagotchi and call them innovation

Transcript



You might have realized I’m not from here and I’m sorry for the translators because I speak fast, but it’s a good idea to know that life is cruel and you have to do a job.

Myself, I’ve been a web developer for 17 years like something like that now. I’ve dedicated my life to the web. I used to be a radio journalist. I used to be a travel agent, but that’s all boring because you saw people today who save people’s lives and change the life of children and stand there with their stick and do all kind of cool stuff.

I’m just this geek in the corner that just wants to catch this camera… how cool is that thing? They also gave me a laser pointer but it didn’t give me kitten. This is just really annoying.

I want to talk today about my wasted life because you heard it this morning already: we have a mobile revolution and you see it in press all over: the web is dead.

You don’t see excitement about it anymore. You don’t see people like, “Go to www awesome whatever .com” Nobody talks like this anymore. They shouldn’t have talked like that in the past as well but nobody does it anymore.

The web is not the cool thing. It’s not: “I did e-commerce yesterday.” Nobody does that, instead it is, “Oh, I’ll put things on my phone.”

This is what killed the web. The mobile phone factor is just not liking itself to the web. It’s not fun to type in TEDxThessaloniki.com with your two thumbs and forgetting how many S’s are there in Thessaloniki and then going to some strange website.

We text each other all the time, but typing in URL it feels icky, it feels not natural for a phone, so we needed to do something different that’s why we came up with the QR codes – robot barf as I keep calling it – because that didn’t work either. It’s beautiful isn’t it? You go there with your phone and you start scanning it and then two and a half minutes later with only 30% of your battery left, it goes to some URL.

Not a single mobile operating system came out with the QR reader out of the box. It’s worrying, so I realized there has to be a chance and the change happened. The innovation, the new beginning, the new dawn of the internet was the app.

“There’s an app for that,” was the great talk.

“There’s an app for everything. They’re beautiful. Apps are great.” I can explain it to my … well, not my mom but other people’s moms: “There’s an icon, you click on it, you open it and this is the thing and you use that now. There’s no address bar, there’s nothing to understand about domains, HTTP, cookies, all kind of things. You open it, you play with it and they’re beautiful.”

The interaction between the hardware and software with apps is gorgeous. On iOS, it’s beautiful what you can do and you cannot do any of that on the web with iOS because Apple … Well, because you can’t.

Apps are focused. That’s a really good thing about them, the problem with the web was that we’re like little rabbits. We’re running around like kittens with the laser pointer and we’re like, “Oh, that’s 20 tabs open.” Your friend is uploading something and there’s downloading something in the background and it’s multi-tasking.

With apps, you do one thing and one thing well. That is good because the web interfaces that we built over the last years were just like this much content, that much ads and blinking stuff. People don’t want that anymore. They want to do something with an app and that’s what they are focused and they make sense.

In order not to be unemployed and make my father not proud because he said, “The computer thing will never work out,” anyways, I thought it’s a good plan to start my own app idea. I’m going to pitch that to you tonight. I know there’s this few VC people in the audience. I’m completely buy-able. A few million dollars, I’m okay with that.

When I did my research, scientific research by scientists, I found out that most apps are used in leisure time. They’re not used during their work time. You will be hard pushed to find a boss that says like, “Wilkins, by lunch break you have to have a new extra level in Candy Crush or you’re fired.” It’s not going to happen. Most companies, I don’t know – some startup maybe.

We use them in our free time and being a public speaker and traveling all the time, I find that people use apps the most where you are completely focused and alone, in other words: public toilets. This goes so far that with every application that came out, the time spent in the facilities becomes longer and longer. At Snake, it was like 12 minutes and Angry Birds who are about 14, but Candy Crush and with Flappy Bird…

It happens. You sit there and you hear people inside getting a new high score and like, “Yeah, look what I did?” You’re like, “Yeah, look what I want to do.” That’s when I thought, “Why leave that to chance? Why is there no app that actually makes going to the public facilities, not a boring biological thing but makes it a social thing?”

I’m proposing the app called, “What’s Out.” What’s Out is a local application much like FourSquare and others that you can use to good use while you’re actually sitting down where you do things that you know how to do anyways without having to think about them.

You can check in, you can become the mayor, you can send reviews, you can actually check in with your friends and earn badges like three stalls in a row.All these things that make social apps social apps – and why not? You can actually link the photo that you took of the food in Instagram to your check in on What’s Out and that gets shared on the internet.

You can also pay for the full version and it doesn’t get shared on your Facebook account.

You might think I’m a genius, you might think that I have this great idea that nobody had before, but the business model is already in use and has been tested for years successfully in the canine market. The thing is dogs don’t have a thumb so they didn’t tweet about it. They also can’t write so they didn’t put a patent on it so I can do that.

Seriously now though, this is what I hate about apps. They are a hype, they’re no innovation, they’re nothing new. We had software that was doing one thing and one thing well before, we call it Word and Outlook. We called it things that we had to install and then do something with it.

The problem with apps is that the business model is all about hype. WhatsApp was not bought because it’s great software. WhatsApp was bought because millions of people use it. It’s because it actually allowed people to send text messages without paying for it.

Everybody now sees this as the new thing. “We got to have an app, you got to have an app.” For an app to be successful, it has to play a massive numbers game. An app needs millions of users continuously. Twitter has to change their business model every few months just to show more and more and more and more numbers.

It doesn’t really matter what the thing does. What the app does is irrelevant as long as it gets enough people addicted to using it continuously. It’s all about the eyeballs and you put content in these apps that advertisers can use that people can sell to other people. You are becoming the product inside a product.

That even goes into marketplaces. I work on Firefox OS and we have a marketplace for the emerging markets where people can build their first app without having to spend money or have a good computer or download a massive SDK, but people every time when I go to them like, “How many apps do you have in the marketplace?” “I don’t know. The HTML5 apps, they could be anything.”

“If it’s not a few million, the marketplace isn’t good.”

I go to a baker if they have three good things. I don’t need them to have 500 different rolls, but the marketplaces have to full. We just go for big numbers. That’s to me is the problem that we have with apps. I’m not questioning that the mobile web is the coming thing and is the current thing.

The desktop web is dying, it’s on decline, but apps to me are just a marketing model at the moment. They’re bringing the scratchability of CDs, the breaking of clothes, the outdated looking things of shoes into software. It’s becoming a consumer product that can be outdated and can look boring after a while.
That to me is not innovation. This is not bringing us further in the evolution of technology because I’ve seen the evolution. I came from radio to the internet. Out of a sudden, my voice was heard worldwide and not just in my hometown without me having to do anything extra.

Will you download a Christian Heilmann app? Probably not. Might you put my name in Google and find millions of things that I put in there over the last 17 years and some of them you like, probably and you can do that as well.
For apps to be successful, they have to lock you in.

The interoperability of the internet that made it so exciting, the things that Tim showed like I can use this thing and then I can do that, and then I use that. Then I click from Wikipedia to YouTube and from YouTube to this and I translate it if I need to because it’s my language. Nothing of that works in apps unless the app offers that functionality for a certain upgrade of $12.59 or something like that.

To be successful, apps have to be greedy. They have to keep you in themselves and they cannot talk to other apps unless they’re massively other successful apps. That to me doesn’t allow me as a publisher to come up with something new. It just means that the big players are getting bigger all the time and the few winners are out there and the other just go away and a lot of money has been wasted in the whole process.

In essence, apps are like Tamagotchi. Anybody old enough to remember Tamagotchi? These were these little toys for kids that were like a pet that couldn’t afford pets like in Japan, impossible. These little things were like, “Feed me, play with me, get me a playmate, do me these kind of things, do me this kind of thing.” After a few years, people were like, “Whatever.” Then rusting somewhere in the corner and collect dust and nobody cares about them any longer.

Imagine the annoyance that people have with Tamagotchi with over a hundred apps on your phone. It happens when your Android apps, for example, you leave your Android phone with like 600 updates like, “Oh please, I need a new update because I want to show you more ads.” I don’t even have insight of what updates do to the functionality of the app, it’s just I have to download another 12 MB.

If I’m on a contract where I have to pay per megabyte, that’s not fun. How is that innovative? How is that helping me? It’s helping the publisher. We’re making the problem of selling software our problem and we do it just by saying it’s a nicer interface.

Apps are great. Focus on one thing, one thing well, great. The web that we know right now is too complex. We can learn a lot from that one focus thing, but we shouldn’t let ourselves be locked into one environment. You upload pictures to Instagram now, have you read the terms and conditions?

Do you know who owns these pictures? Do you know if this picture could show up next to something that you don’t agree with like a political party because they have the right to show it? Nobody cares about them. Nobody reads that up.
What Tim showed, the image with the globe with the pictures, that was all from Flickr. Flickr, I was part of that group, licensed everything with Creative Commons. You knew that data is yours. There’s a button for downloading all your pictures. If you don’t want it anymore, here’s your pictures, thank you, we’re gone.

With other services, you get everything for free with ads next to it and your pictures might end up on like free singles in your area without you having to do anything with it. You don’t have insight. You don’t own the interface. You don’t own the software.

All in all, apps to me are a step back to the time that I replaced with the internet. A time when software came in a consumable format without me knowing what’s going on. In a browser, I can highlight part of the text, I can copy it into your email and send it to you. I can translate it. I can be blind and listen to a website. I can change things around. I can delete parts of it if it’s too much content there. I can use an ad blocker if I don’t like ads.
On apps, I don’t have any of that. I’m just the slave to the machine and I do it because everybody else does it. I’ve got 36,000 followers on Twitter, I don’t know why. I’m just putting things out there, but you see for example, Beyonce has 13.3 million followers on Twitter and she did six updates.

Twitter and other apps give you the idea that you have a social life that you don’t have. We stop having experiences and we talk about experiences instead. You go to concerts and you got a guy with an iPad in front of you filming the band like, “That’s going to be great sound and thank you for being in my face. I wanted to see the band, that’s what I came here for.” Your virtual life is doing well right? Everybody loves you are there. You don’t have to talk to real people. That would be boring”. Let’s not go back in time. Let’s not go back where software was there for us to just consume and take in.

I would have loved Word to have more functionality in 1995. I couldn’t get it because there wasn’t even add-ons. I couldn’t write any add-on. With the web, I can teach any of you in 20 minutes how to write your first website. HTML page, HTML5 app give me an hour and you learn it.

The technologies are decentralized. They’re open. They’re easy to learn and they’re worldwide. With apps, we go back to just one world that has it. What’s even worse is that we mix software with hardware again. “Oh you want that cool new game. You’re on Android? No, you got to wait seven months. You got to have an iPhone. Wait, do you have the old iPhone? No you got to buy the new one.”
How is that innovation? How is that taking it further? Software and technology is there to enrich our lives, to make it more magical, to be entertaining, to be beautiful. Right now, the model how we build apps right now, the economic model means that you put your life into apps and they make money with it. Something has gone very, very wrong there. I don’t think it’s innovation, I think it’s just dirty business and making money.

I challenge you all to go out and not upload another picture into an app or not type something into another closed environment. Find a way to put something on the web. This could be a blog software. This could be a comment on a newspaper.

Everything you put on that decentralized, beautiful, linked worldwide network of computers, and television sets, and mobile phones, and wearables, and Commodore 64s that people put their own things in, anything you put there is a little sign and a little sign can become a ripple and if more people like it, it become a wave. I’m looking forward to surfing the waves that you all generate. Thanks very much.

Bruce LawsonReview: JavaScript & JQuery by Jon Duckett

Disclosure stuff: I was sent a free copy of this by the publishers. From 2000-2002 I worked with its author. I currently work with Mathias Bynens, the book’s technical reviewer (but didn’t know this until after reading it).

Don’t tell anyone, but I’m not very confident with my JavaScript – I learned to program in COBOL, FORTRAN, BASIC, 6502, Z80 and DCL which are all procedural, so I was looking forwards to a book that starts at the very beginning and treats me kindly, before clubbing me over the head because I polluted the global namespace and laughing at me for extending my prototypical object literal constructors into my callbacks.

The book’s blurb says “We’ll not only show you how to read and write JavaScript, but we’ll also teach you the basics of computer programming in a simple, visual way” and is the follow-up to Duckett’s hugely successful HTML and CSS Book which sold over 150,000 copies. (In tech book terms, that’s practically Harry Potter; in this industry, 5,000 is a successful book.)

The book looks beautiful. High quality paper, colour images, with real care and attention lavished on the layout and the words. I’m no quivering aethete designer, but I found it pleasurable to read even though it’s a weighty 600 page tome. Each page (or spread) is its own discrete infolump so it’s easy to out down and come back to.

It starts light – defining events, objects, methods and properties, showing the relationship between HTML, CSS and JS, and with a section on Progressive Enhancement (hoorah). However, I was slightly peturbed that the first worked example uses document.write. I can see why you’d do this – it allows you to show something, but without having to muck about appending to the DOM or using getElementById and innerHTML but it didn’t feel particularly good practice (especially as getElementById and innerHTML are introduced soon after, anyway.) In the author’s defence, he does note that this is Considered Naughty.

Elsewhere, we see lots of workarounds and IE-specific aspects of the DOM. I’m comfortable with these being there; we have to live in the real world, and I think that a book that ignores this does a disservice to its readers – it’s right to equip someone to make pages work on IE.wtf or understand what’s happening in older/ inherited scripts.

The book moves briskly after the traditional introduction to loops, variables and other syntax. By page 270 we’re looking at event listeners, including IE5-8, event delegation, mutation events (with a note that mutation observers are coming, but no more than that.)

Chapter 7 begins with jQuery. Again, there are times when jQuery is entirely appropriate. What’s good is that this book teaches JS concepts first, and always keeps the two separate. (I get tired of “JS” tutorials that are actually about jQuery.)

The rest of the book romps through “HTML5″ APIs, JSON, common UI widgets and – usefully – debugging. Attention is paid to pointing out what’s standard and what isn’t, what’s vanilla JS and what isn’t. Progressive enhancement, accessibility and separation of concerns is are kept in mind throughout. This is good. You can see the table of contents.

When I’m reading, I often don’t care if I’m reading a paper book or a Kindle. But in this case, I was glad I was reading the full-colour, attractive book. I’ve railed about the shoddy quality and general unattractiveness of most computer books before. When so much information is available on the web, publishers must provide some sort of extra value. This book has it – the information is thought-through, beautifully presented and clearly explained. While I guess that the majority of my regular readers won’t need an explanation of what a loop or variable is, I believe this would be an excellent book for someone wanting to start with JavaScript, and learn it well. It doesn’t cover Promises, Mutation Observers, but I don’t really think they’re right for a beginners’ book, anyway.

Oh – and it made me realise that I’m not nearly as crap at JavaScript as I thought I was. Which is nice.

Planet MozillaWebVTT Released in Firefox 31

If you haven't seen the release notes WebVTT has finally been released in Firefox 31. I'm super excited about this as it's the culmination of a lot of my own and countless others' work over the last two years. Especially since it has been delayed for releases 29 and 30.

That being said, there are still a few known major bugs with WebVTT in Firefox 31:

  • TextTrackCue enter, exit, and change events do not work yet. I'm working on getting them done now.
  • WebVTT subtitles do not show on audio only elements yet. This will probably be what is tackled after the TextTrackCue events (EDIT: To clarify, I meant audio only video elements).
  • There is no support for any in-band TextTrack WebVTT data yet. If your a video or audio codec developer that wants in-band WebVTT to work in Firefox, please help out :-).
  • Oh, and there is no UI on the HTML5 Video element to control subtitles... not the most convenient, but it's currently being worked on as well.
I do expect the bugs to start rolling in as well and I'm actually kind of looking forward to that as it will help improve WebVTT in Firefox.

Bruce Lawson“Native experience” vs styling select boxes

I mused about this on stage at Fronteers 2013, and was reminded of it when reading Stephanie Reiger’s excellent slidedeck The future of media queries?, specifically slide 42 which I reproduce with Stephanie’s permission.

Stephanie suggests a mechanism of telling a user agent to render a navigation list as a native component, so it looks native across a range of devices, because it is native. (We could bikeshed about the markup and whether it should be in the CSS, but that doesn’t matter.)

I get that developers want their sites to appear native on the host device. Presumably users like native feel, too; there’s a reason why users show a huge preference for native apps over web apps, and one of those reasons is that native apps

allow the user to use device-specific hand gestures. Android and iOS are gradually developing different conventions for interaction, and a native app responds the way its user expects. User Experience Stack Exchange

So Stephanie’s idea makes perfect sense to me.

But what puzzles me is the fact that for ages designers and developers have also desperately tried to style away native controls. For example, recently Nicholas Zakas said

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

and was retweeted hundreds of times. Nicholas isn’t wrong to want this, and this wish isn’t new; when Safari first came out, designers were close to burning their moleskines because they couldn’t make buttons in corporate orange and heliotrope. When I first started showing HTML5 form controls at conferences, without fail I’d be asked how they can be styled. There are endless articles and scripts that painstakingly take real selects, hide them more or less accessibly, then recreate them so they don’t look native on any device.

But why this urge to re-style page elements that end-users are familiar with? You’ll be shocked to learn that I’m not actually trained as a designer – so what am I failing to understand? Or is it that we love native look and feel, except when we don’t?

UPDATE 21 July 2014: Aaron Gustafson wrote an interesting response to my post: The “Native” vs. “Stylable” Tug of War.

Steve Faulkner et alHTML5 accessibility implementation support in browsers

HTML5 I have been testing and tracking browser accessibility implementation support for a range of new HTML features since 2010. Data can be found on HTML5accessibility.com. Over the last week I also undertook a more formal, targeted testing of the normative implementation requirements in the WAI-ARIA section of the HTML5.0 specification which is currently on its way to becoming a W3C Recommendation.

<script async="async" charset="utf-8" src="http://platform.twitter.com/widgets.js"></script>

Understanding the testing results

HTML5 contains normative requirements (things a browser MUST implement) to be considered to support HTML5. In order for HTML5.0 to become a W3C Recommendation the normative requirements must be implemented interoperably (i.e. in at least 2 independent browsers). One of the methods used to decide whether a given HTML feature is implemented interoperably is to create tests and test the assertions in the specification in browsers. Details of the requirements are in the Model CR Exit Criteria (Public Permissive version 3).

In the case of accessibility semantics implementation the assertions are framed in terms of ARIA roles, states and properties as implicit ARIA semantics. For example:

HTML feature Implicit ARIA semantics
button element button role

Another step is required

ARIA semantics in this case are used as an abstract indicator of the platform specific requirements. To find out and test what browsers are actually required to implement to conform to the above requirement we have to refer to the ARIA implementation guide, which describes the implementation requirements for ARIA semantics in terms of the platform accessibility API mappings

MSAA + UIA Express role (IE on windows) MSAA + IAccessible2 role andother IAccessible2 features (Firefox chrome on windows) ATK/AT-SPI role (firefox on linux) Mac OS XAXRole
AXSubrole
AXRoleDescription
(Safari, Chrome, Firefox on OSX)
PUSHBUTTON PUSHBUTTON PUSH_BUTTON AXButton
<nil>
‘button’

So from this information it can be assessed whether a browser passes or fails the assertion that the button element has a button role by looking at what role the browser exposes via the platform accessibility API(s) it has implemented (noted browser/platform in table headers) . We can look at the accessibility information (roles and properties) by using an object inspection tool, such as aViewer inspect.exe or a11y-probe.

For example, using aViewer it can be confirmed that Firefox 29 on Windows exposes the correct role for the button element:

button element information exposed in MSAA and Iaccessible2 by Firefox 29 is role of button.

The results of testing all the assertions within the WAI-ARIA section of the HTML5.0 Last Call Working Draft specification are available: Implementation status for HTML5 element/attribute accessibility mappings

Notes

The accessibility requirements specified in the HTML5.0/5.1 specifications are only a subset of browser accessibility implementation requirements. Much of what is needed is simply not specified in any HTML specification. Work is continuing on a HTML accessibility mapping and related specifications to fully define the requirements on browsers to support HTML and SVG accessibility.

The testing conducted is for the purposes of checking HTML5 Last Call Working Draft specification support, these are a subset of the requirements contained in the (still in development) HTML 5.1 specification,  features that do not have at least 2  implementations  are absent from HTML5.0 (e.g. dialog element).

W3C Team blogThis week: #i18n Personal names around the world, #HTML elements, #Web2024, etc.

This is the 4-11 July 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

Open Web & net neutrality

W3C in the Press (or blogs)

5 articles since the 4-Jul Digest; a selection follows. You may read all articles in our Press Clippings page.

Planet MozillaMy 2009 yearly report


I am not great at blogging in English and communicating about my work so I thought that publishing my yearly report would compensate that ;)

All in all, it has been a busy year, nobody in the localization drivers team and among our localization teams had time to get bored, lots of product releases, lots of pages, lots of travel and events too. I am listing below what I have been directly leading and/or participating in, not some other projects where I was just giving a minor help (usually to my colleagues Stas and Delphine).

Products:

  • 2 major releases: Firefox 3.5 and Thunderbird 3 (with a new multilingual Mozilla Messaging website)
  • 26 other releases (maintenance, beta and RC releases)

Mozilla Europe website(s):

  • 3 new locales: Serbian, Bulgarian, Swedish, our geographic coverage of Europe is now almost complete
  • New content for 3.5 release, minor releases and many side projects
  • major cleanups of content and code for easier maintenance (especially maintenance releases) and more features (html5 support, per locale menu navigation, visits now with referrer hints for better locale detection...)
  • Site now sharing same metrics application as other mozilla sites
  • More per country news items than previous years (events, new community sites, community meetings...)
  • 46 blog posts written by our European community on blogs.mozilla-europe.org
  • Our events management web application was used for 10 European events (I created it back in summer 2008)

Mozilla.com website

  • We now have a localized landing page for our 74 locales on top of up to date in-product pages
  • Geolocation page for all locales
  • 3.0 and 3.5 major updates offered for all locales
  • Localized beta download pages to incitate beta-testing of non-English versions of Firefox
  • Better code for our localized pages (better right-to-left, language switching, simpler templates...)
  • Whatsnew/Firstun pages now warn the user in his language if his Flash plugin is outdated  (for better security and stability)
  • Lots of content, css, graphics updates all along the year, everywhere
  • Firefox 3.6 in-product pages (firstrun, whatsnew, major update) localization underway, pluginscheck page localization almost technically ready for localization
  • Fennec pages being localized for 1.0 final

Marketing Sites made multilingual

Mozilla Education:

  • Gave a lecture at the Madrid university about opensource, the mozilla project and community management.
  • MMTC Madrid one week sprint in July, gave Mozilla classes with Paul Rouget and Vivien Nicolas to 30 students (evaluation TBD)
  • Organized CoMeTe project at Evry university, France,  in October with Fabien Cazenave and Laurent Jouanneau as teachers

Community work

  • Found new localizers for a dozain locales, helped some creating blogs, community sites and local events
  • Many community meetings, IRC or IRL
  • Participated in Firefox 3.5 party in Madrid
  • I am since May on twitter, communicating about my work and Mozilla in Europe
  • Organized a theming contest in collaboration with the Dotclear project for our community blog, won by Marie Alhomme
  • Created with Julia a Mozilla Planet for French Speakers
  • Lots of Web l10n QA with Delphine plus some personal QA work on 3.6 looking for Linux specific Firefox bugs
  • Went to 21 events (7 of them internal Mozilla events) like Fosdem, MozCamps Chile + Prague, Ubuntu parties, Solutions Linux, W3C event, Firefox 5 year anniversary, Firefox 3.5 party Madrid, JDLL, Geneva Community meetup... Lots of time abroad and travelling.
  • Blogging in French about the Mozilla project and its place in the FLOSS ecosystem, current focus on Mozilla QA and how to get involved in the project.

Other

  • Some documentation work (mostly on QA of localized pages)
  • Many updates to the webdashboard
  • Helped Delphine setting up Womoz website and general advices on community building
  • Several press interviews for Spain as well as conferences given about the Mozilla project
  • Started this week with Stas and Patrick the localization work needed for the Browser Choice Screen in Windows for Europe
  • Lots of technical self teaching while building projects, I even did my first Jetpack extension this week, Yay!
  • A new expresso machine :)

Happy new year 2010 to all mozillians and FOSS lovers in the world :)

Planet Mozilla[video+slides] FirefoxOS – HTML5 for a truly world-wide-web (Sapo Codebits 2014)

Chris Heilmann at SAPO codebits
Today the good people at Sapo released the video of my Codebits 2014 keynote.

In this keynote, I talk about FirefoxOS and what it means in terms of bringing mobile web connectivity to the world. I explain how mobile technology is unfairly distributed and how closed environments prevent budding creators from releasing their first app. The slides are available on Slideshare as the video doesn’t show them.

There’s also a screencast on YouTube.

Since this event, Google announced their Android One project, and I am very much looking forward how this world-wide initiative will play out and get more people connected.

Photo by José P. Airosa ‏@joseairosa

Steve Faulkner et alWhat’s Happenning at The Paciello Group?

In addition to client work we do at The Paciello Group we like to keep our clients and colleagues abreast of our contributions to the international accessibility and web standards work. I’m personally very proud of our team and their individual contributions as we continue to drive accessibility and raise the bar in quality of user experience for people with disabilities!

Summary of some of our recent activity:

Tips for Creating Accessible SVG by Léonie Watson

Scalable Vector Graphics (SVG) exists in a quantum state of accessibility. Which is to say that SVG is both accessible and inaccessible at the same time…

Measuring the harm of flawed academic papers by Karl Groves

For several years I’ve been interested in finding and reading academic work in the field of web accessibility. I have a very strong belief that the things we say regarding web accessibility must be based on a significant amount of rigor…

Thoughts on professional accreditation in digital accessibility by David Sloan

I’ve been working (more or less) full time in digital accessibility for quite some time now, so naturally I’ve watched with great interest the unfolding developments in recent years… towards establishing the International Association of Accessibility Professionals (IAAP)

Building an Accessible Disclosure Button – using Web Components by Cédric Trévisan

Web components are the next step in building modern web applications and a great way to prototype accessible widgets. Today we are going to build a disclosure widget, by extending the native HTML button element…

HTML5 accessibility implementation support in browsers by Steve Faulkner

Over the last week I also undertook a more formal, targeted testing of the normative implementation requirements in the WAI-ARIA section of the HTML5.0 specification which is currently on its way to becoming a W3C Recommendation.

Accessibility Research Methods with Jonathan Lazar by Sarah Horton

Accessibility research can help us better understand how people with disabilities use the web and what we in product design and development can do to make that experience more successful and enjoyable…

<html5-h> heading custom element by Matthew Atkinson, Cedric Trevisan and Steve Faulkner

Custom heading element intended to replace <h1> to <h6> with a single heading element (yup just like XHTML promised land) and the promise of the HTML5 outline…

Using ARIA in HTML by Steve Faulkner

ARIA (WAI-ARIA if you want to be formal) is a set of attributes that you can add to HTML elements. These attributes communicate role, state and property semantics to assistive technologies via the accessibility APIs implemented in browsers…

#ID24 A GAAD Hit! Thanks to All Speakers by Mike Paciello

in celebration of Global Accessibility Awareness Day (GAAD), TPG with support from YOU and our co-sponsors, Adobe Systems Inc., pulled off one of the greatest online accessibility events ever – Inclusive Design 24 (#ID24). Twenty-four hours of non-stop, international accessibility webinars FREE to the entire world. WOW!! Many thanks to all our friends who made #ID24 a huge success. The final, fully captioned versions of those sessions are nearly complete and will be posted for all to enjoy!

JavaScript touch/pointer events research notes: screenreaders, faked mouse events, touchscreens by Patrick Lauke

Over the last two years I’ve been dabbling with various aspects related to the handling of touch events and pointer events – specifically trying to determine which events are being dispatched by browsers as a result of touchscreen interactions, and what the repercussions of this are considering the increasing number of multi-input devices

 

Planet MozillaBringing SIMD to JavaScript

In an exciting collaboration with Mozilla and Google, Intel is bringing SIMD to JavaScript. This makes it possible to develop new classes of compute-intensive applications such as games and media processing—all in JavaScript—without the need to rely on any native plugins or non-portable native code. SIMD.JS can run anywhere JavaScript runs. It will, however, run a lot faster and more power efficiently on the platforms that support SIMD. This includes both the client platforms (browsers and hybrid mobile HTML5 apps) as well as servers that run JavaScript, for example through the Node.js V8 engine.

https://01.org/blogs/tlcounts/2014/bringing-simd-javascript

Bruce LawsonApps For All: Coding Accessible Web Applications – book review

(I was sent a free ebook of this title. That hasn’t influenced my review. This ebook is published by Smashing Magazine and costs €10.95. There’s a sample chapter available. I have no financial connection with the publisher or author.)

When I read about this book I was excited to read it. I don’t need Yet Another Accessibility Book (I co-wrote one a long time ago) but wanted something that delves deeply into WAI-ARIA and how it interacts with HTML5 and assistive technologies. As this book’s blurb says “the underlying theme of this book is about making the interactivity of web applications include keyboard and screen reader users”, it seemed like the book for me. It’s also tech-reviewed by Steve Faulkner who’s my go-to Bogan for practical accessibility information, so I was pretty sure I could trust it.

WAI-ARIA is one of the vital specifications for making the web accessible. There are three problems with using it, though: firstly, the spec is hard to read and understand, even in the context of specs’ inherent indigestibility; secondly, it’s hard to understand how its concepts intertwine with other specs like HTML and, thirdly, most developers don’t use assistive technologies so are unable to understand or test the output of their ARIA pages.

Therefore, I greatly appreciated that author Heydon Pickering is a developer, so keeps the book practical. ARIA is used, in conjunction with markup and script in situations that you’d really encounter. The problem to be solved is elucidated, and the output is clearly explained. It goes deep, too; I learned a great deal and plan to re-read it soon.

It’s a short book (but quite dense) and Heydon’s prose style is clear and occasionally humorous. But don’t let that fool you; this is an important book because it’s the only one that thoroughly explains the technical merits and use of ARIA (and doesn’t browbeat the reader about accessibility).

Without hyperbole: every developer should read this book, and put its techniques into practice. Now.

Planet MozillaHave we lost our connection with the web? Let’s #webexcite

I love the web. I love building stuff in it using web standards. I learned the value of standards the hard way: building things when browser choices were IE4 or Netscape 3. The days when connections were slow enough that omitting quotes around attributes made a real difference to end users instead of being just an opportunity to have another controversial discussion thread. The days when you did everything possible – no matter how dirty – to make things look and work right. The days when the basic functionality of a product was the most important part of it – not if it looks shiny on retina or not.

Let's get excited

I am not alone. Many out there are card-carrying web developers who love doing what I do. And many have done it for a long, long time. Many of us don a blue beanie hat once a year to show our undying love for the standard work that made our lives much, much easier and predictable and testable in the past and now.

Enough with the backpatting

However, it seems we live in a terrible bubble of self-affirmation about just how awesome and ever-winning the web is. We’re lacking proof. We build things to impress one another and seem to forget that what we do sooner than later should improve the experience of people surfing the web out there.

In places of perceived affluence (let’s not analyse how much of that is really covered-up recession and living on borrowed money) the web is very much losing mind-share.

Apps excite people

People don’t talk about “having been to a web site”; instead they talk about apps and are totally OK if the app is only available on one platform. Even worse, people consider themselves a better class than others when they have iOS over Android which dares to also offer cheaper hardware.

The web has become mainstream and boring; it is the thing you use, and not where you get your Oooohhhs and Aaaahhhhs.

Why is that? We live in amazing times:

  • New input types allow for much richer forms
  • Video and Audio in HTML5 has matured to a stage where you can embed a video without worrying about showing a broken grey box
  • Canvas allows us to create and manipulate graphics on the fly
  • WebRTC allows for Skype-like functionality straight in the browser.
  • With Web Audio we can create and manipulate music in the browser
  • SVG is now an embed in HTML and doesn’t need to be an own document which allows us scalable vector graphics (something Flash was damn good in)
  • IndexedDB allows us to store data on the device
  • AppCache, despite all its flaws allows for basic offline functionality
  • WebGL brings 3D environments to the web (again, let’s not forget VRML)
  • WebComponents hint at finally having a full-fledged Widget interface on the web.

Shown, but never told

The worry I have is that most of these technologies never really get applied in commercial, customer-facing products. Instead we build a lot of “technology demos” and “showcases” to inspire ourselves and prove that there is a “soon to come” future where all of this is mainstream.

This becomes even more frustrating when the showcases vanish or never get upgraded. Many of the stuff I showed people just two years ago only worked in WebKit and could be easily upgraded to work across all browsers, but we’re already bored with it and move on to the next demo that shows the amazing soon to be real future.

I’m done with impressing other developers; I want the tech we put in browsers to be used for people out there. If we can’t do that, I think we failed as passionate web developers. I think we lost the connection to those we should serve. We don’t even experience the same web they do. We have fast macs with lots of RAM and Adblock enabled. We get excited about parallax web sites that suck the battery of a phone empty in 5 seconds. We happily look at a loading bar for a minute to get an amazing WebGL demo. Real people don’t do any of that. Let’s not kid ourselves.

Exciting, real products

I remember at the beginning of the standards movement we had showcase web sites that showed real, commercial, user-facing web sites and praised them for using standards. The first CSS layout driven sites, sites using clever roll-over techniques for zooming into product images, sites with very clean and semantic markup – that sort of thing. #HTML on ircnet had a “site of the day”, there was a “sightings” site explaining a weekly amazing web site, “snyggt” in Sweden showcased sites with tricky scripts and layout solutions.

I think it may be time to re-visit this idea. Instead of impressing one another with codepens, dribbles and other in-crowd demos, let’s tell one another about great commmercial products aimed not at web developers using up-to-date technology in a very useful and beautiful way.

That way we have an arsenal of beautiful and real things to show to people when they are confused why we like the web so much. The plan is simple:

  • If you find a beautiful example of modern tech used in the wild, tweet or post about it using the #webexcite hash tag
  • We can also set up a repository somewhere on GitHub once we have a collection going

W3C Team blogThis week: input APIs collaborations, W3C TAG by-election, etc.

This is the 27 June – 4 July 2014 edition of a “weekly digest of W3C news and trends” that I prepare for the W3C Membership and public-w3c-digest mailing list (publicly archived). This digest aggregates information about W3C and W3C technology from online media —a snapshot of how W3C and its work is perceived in online media.

W3C and HTML5 related Twitter trends

[What was tweeted frequently, or caught my attention. Most recent first (popularity is flagged with a figure —number of times the same URIs or tweet was quoted/RTed.)]

And, on the lighter side

  • Markup pun galore in Twitter thread (via @tenderlove)
  • “In W3C, browser devs consult the reference copy of the CSS spec that’s kept in a humidity-controlled glass case” [image (via @brucel)]

Open Web & net neutrality

W3C in the Press (or blogs)

6 articles since the 27-Jun Digest; a selection follows. You may read all articles in our Press Clippings page.

Bruce LawsonReading List

Planet MozillaImplementing Scroll Animations Using Web Animations

It's fashionable for apps to perform fancy animations during scrolling. Some examples:

  • Parallax scrolling
  • Sticky headers that scroll normally until they would scroll out of view and then stop moving
  • Panels that slide laterally as you scroll vertically
  • Elements that shrink as their available space decreases instead of scrolling out of view
  • Scrollable panels that resist scrolling as you get near the end

Obviously we need to support these behaviors well on the Web. Also obviously, we don't want to create a CSS property for each of them. Normally we'd handle this diversity by exposing a DOM API which lets developers implement their desired behavior in arbitrary Javascript. That's tricky in this case because script normally runs on the HTML5 event loop which is shared with a lot of other page activities, but for smooth touch tracking these scrolling animation calculations need to be performed reliably at the screen refresh rate, typically 60Hz. Even for skilled developers, it's easy to have a bug where once in a while some page activity (e.g. an event handler working through some unexpected large data set) blows the 16ms budget to make touch dragging less than perfect, especially on low-end mobile devices.

There are a few possible approaches to fixing this. One is to not provide any new API, hope that skilled developers can avoid blowing the latency budget, and carefully engineer the browser to minimize its overhead. We took this approach to implementing homescreen panning in FirefoxOS. This approach sounds fragile to me. We could make it less fragile by changing event dispatch policy during a touch-drag, e.g. to suppress the firing of "non-essential" event handlers such as setTimeouts, but that would add platform complexity and possibly create compatibility issues.

Another approach would be to move scroll animation calculations to a Worker script, per an old high-level proposal from Google (which AFAIK they are not currently pursuing). This would be more robust than main-thread calculations. It would probably be a bit clumsy.

Another suggestion is to leverage the Web's existing and proposed animation support. Basically we would allow an animation on an element to be use another element's scroll position instead of time as the input to the animation function. Tab Atkins proposed this with declarative CSS syntax a while ago, though it now seems to make more sense as part of Web Animations. This approach is appealing because this animation data can be processed off the main thread, so these animations can happen at 60Hz regardless of what the main thread is doing. It's also very flexible; versions of all of the above examples can be implemented using it.

One important question is how much of the problem space is covered by the Web Animations approach. There are two sub-issues:

  • What scrolling effects depend on more than just the scroll position, e.g. scroll velocity? (There certainly are some, such as headers that appear when you scroll down but disappear when you scroll up.)
  • For effects that depend on just the scroll position, which ones can't be expressed just by animating CSS transforms and/or opacity as a function of the scroll position?
If people are aware of scrolling effects in either of those two categories, it would be very useful to hear about them.

Planet MozillaMicrosoft nominated me as a Most Valuable Professional

mvp

You read well; Microsoft nominated me, and I’m now a MVP, a Most Valuable Professional about Internet Explorer. For those of you that don’t know, it’s an important recognition in the Microsoft ecosystem: it’s given to professionals with a certain area of expertise, around Microsoft technology or technology Microsoft use, for their work in the community.

So why Microsoft gave me recognition for Internet Explorer? In the end, I’m working at Mozilla. Well, I see this as a good news for everything I was doing while I was there (like Make Web Not War), and everything I’m doing right now: it’s another proof that Microsoft is more, and more open. As I’ve always said, it’s not perfect, but it’s going in the right direction (MS Open Tech is a great example). In my case, this award is less about Internet Explorer itself, than about the Web, and it’s lovely technology that is HTML5. They recognize the work I’m doing in that sense, either with Open Source, with communities in Montreal or with talks I’m doing about the Web. At first, it may seem weird for you, but I think it makes a lot of sense that Microsoft recognize someone like me, even if I’m working in a company making a competing product. Microsoft is doing a better job since Internet Explorer 9, and the browser is getting better, and better. No matter if you don’t use it, but other people do, and by making a better browser, which respect more the standards, they are helping the web to move forward. It’s also a good thing for us, developers, as we can more easily build great experiences for any users, no matter the browser they use. On that note, I was happy to see a bit more transparency about IE with the platform status website.

So, I salute the openness of Microsoft to nominate someone like me (they even hired me in the past). By being part of that MVP program, I’m looking forward to seeing how I can continue to work on the Mozilla mission while helping Microsoft to be more open with web technologies.


--
Microsoft nominated me as a Most Valuable Professional is a post on Out of Comfort Zone from Frédéric Harper

Jeremy KeithA new website for dConstruct 2014

dConstruct 2014 has a new website. Huzzah!

When I announced the original website two months ago, I was very, very excited about the line-up, but I was less excited about the design of the site itself. To be honest, it was a somewhat rushed affair. It did the job but it didn’t have much pizzazz. I had some design direction—colour, typography, texture—courtesty of Mikey, but I didn’t push it to do anything very interesting.

dConstruct original 320 dConstruct original 600 dConstruct original 768

So Mikey took some time to iterate and revise, and he came up with a gorgeous new design. I think this does a much better job of capturing the spirit of dConstruct.

As well as a revised colour palette and lusher textures, there was also opportunity to do something quite playful in the masthead. Making sites for our own projects always presents a nice opportunity to try out some whacky stuff that we might not get a chance to do on client work.

In this case, the plan was to play with the theme of this year’s dConstruct—Living With The Network—and use it as part of the visual design, literally networking up parts of the interface.

It was a nice chance for me to play around with canvas. But I didn’t dive into code straight away. I had a think about how I could add this an enhancement to the responsive layout.

My plan was to generate a canvas element under the existing elements in the header using z-index to keep them separated while maintaining the appearance of having everything connected up.

Sketching before coding

It worked out pretty well. But I wanted to push it further. How about making it an interactive element that responds to the user?

I know, I know. It’s very silly and frankly a bit wanky, but y’know, it felt like it would be nice and playful.

I had no idea how to do it though. At an internal code review here at Clearleft, I demoed what I had so far and asked for advice. The general consensus was that I should probably be using SVG rather than canvas for making interactive graphical elements. They’re probably right, but I distinctly remember learning about hit detection and mouse events in canvas during Seb’s excellent Creative JS workshop.

So I stuck with canvas and fiddled around with numbers until I got to something that felt lke it reacted nicely to hover events (or touch/clicks if hover isn’t available …or even if it is). requestAnimationFrame was a godsend when it came to getting smooth animations.

Have a play with it. It’s hard to miss. It’s not exactly a subtle easter egg.

The content of the site remains much the same. While I was disatisfied with the original visual design of the site, I’m still pretty chuffed with the copy.

One small change I made was to give the code of conduct its own page (and expand on it a bit). Previously it was included with terms and conditions but there was a good chance that it could’ve been overlooked there.

Anyway, I hope you like the new site. I think Mikey did a terrific job with the design and it was a lot of fun to put together …especially the silly wanky bit. The only slight disadvantage is that the page weight comes in slightly larger than the previous design. But I’ll keep optimising to see if I can shave off some bytes here and there.

Device testing dConstruct Device testing dConstruct

Oh, and you might notice one significant change on the home page. In addition to the speakers that are currently listed, there’s an addendum that reads “…and more”. That’s because the line-up for this year’s dConstruct, awesome as it is, is not yet complete. It’s going to get even better.

If you don’t have your ticket to this year’s dConstruct yet, what are you waiting for?

See you on September 5th.

Planet MozillaInvest in the future: build for the web!

I spoke at GOTO Amsterdam a few weeks ago. I was really thrilled to be back in the Netherlands after so many years! So thanks to Sergi Mansilla, who curated the HTML5 track, and the organisation in general for bringing me there!

The talk wasn’t recorded, but I made a screencast just in case you really want to listen to me. I am also posting the outline/notes I wrote, and they differ in places because I don’t read them during the talk (I don’t even have them handy) and I sometimes went a bit off topic, but that’s the beauty of improvisation!

Here are the slides, and the slides source code just in case you wanted it too.

On to the notes-expect some MASSIVE GIFs and amazingly clever photomanipulation! tee hee hee!

Invest in the future: build for the web!

Hey all and thanks for coming! My name is Soledad Penadés (@supersole in Twitter) and I am an Apps Engineer at Mozilla. But some time before that… I worked on Android apps.

They sold us this “dream” that you could earn a living with Android apps. And of course, who wouldn’t want to earn enough money building things they loved? So I did this sort of market research and tried to figure out what I wanted to do. The first thing I tried to build was an audio tool, but it was too slow and too glitchy. I kept wanting to do something which had to do with graphics or audio but I didn’t want to build games; they need things such as a story, audio, artwork, etc, and I didn’t think I could do all of them, but I still didn’t know what to build.

One day I was walking around in London and I saw something really cool. I wanted to take a picture but I realised I had forgotten my camera. I thought: well maybe I could take the picture with the phone instead! But it was really freezing, so I was wearing gloves. And although you can buy gloves with conductive tips nowadays, I didn’t know that back then, so I had to take out the glove in order to touch the screen and take the picture. Also, the interface for selecting different options was really slow to use, and it was specially painful when standing there in the cold!

Photography apps

So I had this idea: what if I built a camera app that was better than the stock camera app?

It would…

  • be less clunky than stock – it would be faster to navigate the options
  • use the hardware buttons – so you wouldn’t need to touch the screen to take pictures
  • silent – I was so tired of the shutter sound because it would scare my sister’s cats away each time I tried to take a picture of them

And that was the first photography app I built. Shortly afterwards I decided I wanted to play a little bit more with the Camera API and thought that I could maybe build an app that would apply filters to images. At that time Instagram didn’t exist for Android yet, and the existing filter apps were about taking a picture and applying postprocessing afterwards, so the process wasn’t as fluid and playful as I would have liked it to be.

I then built this realtime effects app that would take the live stream off the camera and process the image in real time.

Good feedback, but…

The apps were generally well welcomed and the feedback was mostly positive, but still there were lots of hardware issues that I couldn’t test because I either didn’t have the phones or couldn’t buy them either. Some people were using weird Chinese built rebranded phones and it was really difficult to find out where the error actually was-was it the OS version, was it the extra rebranded stuff, was it the actual phone? And even if I wanted to buy the phones, sometimes it was impossible because they were exclusive to a certain geography, so my only solution would have been buying them from eBay.

On the other hand, people liked the filters from my app and they started to ask for ports to their favourite operating system. iOS? Blackberry? (yes, Blackberry was still a thing back then). Even desktop platforms: Windows? Mac OS? That was driving me crazy because I really liked being liked and appreciated the positive feedback, but there was just no way I could please them. I was running Linux, for whatever it’s worth!

Interactive picture books start-up

At some point I decided to start working for others again, so I ended up joining a start-up that wanted to enable authors make great interactive picture books. There was work going on in two fronts: first the Mac OS authoring environment, which was the tool for the authors and where they could assemble their text, images, and possibly sounds and animations. This would then be saved into an XML based format that could in turn be read and ‘executed’ by the second ‘front’, which was the engine. There were two versions of the engine: iOS and Android.

Layout was DIFFICULT

I was just working on the Android side, and there we probably spent like 70% of our time fighting the operating system to make things look and behave the way we wanted them to work. The worst part was that there was no preview (specially when using Custom Views) or that the preview differed from the actual results. You then had to push the app to the device, and because it was really rich in graphics it would took so long that when it finished, one minute or so later, you had totally forgotten what you wanted to look at. You’d ask yourself: what was that thing I was working on? I can’t remember. Oh well, I guess I’ll just have another coffee, or something. Ironically, for complex layouts -specially layouts with lots of text- we actually had to use an embedded WebView because it was just faster to layout using HTML and CSS than styling “the Android way”.

Another big issue was that native animations were quite limited. The books had transitions between pages, and often within each page too, and we wanted those to be smooth. But the native animations didn’t offer many parameters, and felt really mechanical. Plus the elements we tried to animate often ended up being really janky! We weren’t sure of where the problem was. Was it our code? Was it the way we were animating? If we were using Android’s native animations, should we have garbage collection issues? And since we weren’t sure at all, we had to spend inordinate amounts of time in the profiler, trying to trace where did those slowdowns come from. Still, jank continued to be there! Plus weird graphical glitches, and we kept finding cargo cult tricks in Stack Overflow and applying them out of desperation, but of course, the jank was still there!

And what about testing… LOL about testing to be quite honest. I would just say that at some point we just half joked about creating a kickstarter to try and get some Google engineer to make it possible to test asynchronous code for reals, because no matter how many testing frameworks and solutions we tried, none would work.

Bad habits, deeply ingrained

There were other issues which were less about the tech and more about the process and the mindset. The biggest issue was that “different output sizes” was treated as an exception and not as the norm. So when a project was initially released for the iPad 1, the designs only considered those dimensions and aspect ratios, which made it really hard to port to variable sized environments such as Android.

For example, the graphic design would call for an overlap on top of the menu that would be sized exactly for the iPad 1, so using that same overlay in an Android tablet, which had a wider screen aspect ratio size, ended up stretching the image in a bad way.

Imagine when the retina iPads were introduced. It was fun fun fun.

One day I woke up and wondered…

why is this not HTML+JS+CSS?

So I asked my boss, which politely replied that he had been experimenting a lot with it, but…

… the web is not ready yet…

… you can’t have smooth animations and audio in the browser…

I hadn’t actually tried to build the engine in HTML5, so what could I argue against that? So I just said “OK” and continued work.

Contracting for local newspaper

We built this app for a local newspaper which was, pretty much, a glorified RSS reader.

With the exception that the layout kept getting more and more complex, and even then we had lots of embedded WebViews for more complicated things and for rendering the articles (which were, basically, the HTML pulled raw from the RSS feeds) and embedded JavaScript for things such as adding favourites and bookmarks.

This app kept getting new features and more complex layout until we reached this point in which we reached the maximum limit of nested views. But–and here’s the funny thing– NOT ALL the devices exhibited that error.

We ended up reaching that point in which the only solution we could suggest was:

hey, so… what about a total rewrite of this less than two years app?

One day I woke up and wondered again…

Why is this not HTML+JS+CSS?

And again I asked my boss. And again I got a similar answer:

… because the web is not ready yet…
… you can’t store offline data…
… you can’t have push notifications…

which only mildly convinced me, so I muttered a meh “A-ha” and kept working on the thing.

One day I was updating the company website

And opened DevTools to live edit it. And I had an epiphany.

We were recreating browsers again and again because “the web is not ready”, but I had had enough.

I said to myself:

I’m out of this madness, and back to the web.

Back with a vengeance!

Two sides of the fence

But I’d be back after having been to the two sides of the fence. I knew about the upsides and the downsides, and I decided that I wanted to teach people about the upsides and help them take the maximum advantage of them, and work in fixing the downsides.

So…

I joined Mozilla

hey panda

We want YOU to build for the web

we want you to build for the web

Why build for the web?

Of course you will be asking me why should I bother writing for the Web?

Well, the first reason is that it is the only non proprietary platform. No one owns it, and no one controls it. Compare that to the Windows or Apple platforms, and where sometimes you’re not even allowed to discuss the issues you’re having when developing because you’re under an NDA.

And it’s also the closest to Write Once Run Everywhere you’ll ever get. As a sort of secondary bonus, writing for the web, using standards, gives you a high chance that whatever you build will still work in the future. Compare that to trying to get some old binaries to work in newer platforms–specially when you don’t have access to the source code or to the toolchain that generated those binaries in the past.

Also, fragmentation is not an issue: it’s business as usual. And encouraged. The web is about enabling people to access and work on their data, and if they prefer to use a cheaper phone with dithered screens because they can’t afford to get a super high end device, then we shouldn’t be adding artificial barriers. Working this way, taking into account that your apps might be running on a variety of devices widens your base of customers, and at the same time cuts down on development costs–because you don’t need to rewrite the same app for each of the native platforms that customers might use.

And finally, because it is everywhere–e-books, TV set top boxes, GPS trackers, mobile native via WebKit views, native via PhoneGap, Ludei, AppCelerator, desktop environments (GNOME 3), even Mac OS scripting… so maybe all these people cannot be wrong.

We helped unlock desktop browsers from monopoly

Firefox

Just as Mozilla helped unlock desktop browsers from monopoly with Firefox OS…

We’re doing the same in mobile with Firefox OS

Firefox OS

And doing “the same” means giving power back to developers and enabling them to build awesome cool stuff, which means definining and implementing new JavaScript APIs for accessing features that so far have only been accessible to native code.

New APIs

These are some of the new APIs that are accessible for code running in Firefox OS:

Most of these APIs are prefixed for now, but that’s because Firefox OS is the testing ground–the place where APIs are not only designed but also put in practice and battle tested with real users, apps and needs. And these APIs are also submitted to the appropriate standards tracks, so that in the future not only Firefox OS, but all browsers can use this specification to implement those features, which in turn gives more power to developers to do more amazing stuff that works everywhere.

Or in other words: our guiding goal is to help shaping standards, not to build a proprietary OS in JS.

Existing APIs

Existing Web APIs which are implemented in most of the browsers do need some love for mobile implementations too. They have to be efficient.

That might mean that the C/C++ code that does something in Firefox Desktop has to be rewritten to take advantage of the ARM processor or the hardware decoders that come with the phone and can do that way faster than a software decoder would. Or maybe read and writes to storage need to be optimised for battery usage.

These are some of those APIs:

The conclusion to this is that spending developer efforts in making APIs available and code runnable anywhere has a multiplier effect where way more people benefit than if those developers simply focused their efforts on building native apps.

But there’s still more work to be done…

Over two billion people still don’t have access to the Internet

That’s right, 2,000,000,000+ people still can’t “browse” just like you and me can.

At Mozilla we believe the Internet must be open and accessible, so we are working on fixing this too. We partnered with some manufacturers to make a phone that would run Firefox OS and also be affordable.

$25 phone

Tarako

This phone is in the same price bracket that the feature phones that are sold in many countries yet runs entirely on Firefox OS and has access to 2.5 EDGE networks. It might look underpowered and “crappy” compared to whatever you have in your pocket right now, but compared to those featurephones this is a massive step forward: updatable and a wider range of apps and services can be accessed because it is, basically, a portable browser, rather than a J2ME device.

Better tooling

We are also aware that the web is so much more than just documents today, and we need to have better tools.
These are some examples of the tools that have been added to Firefox:

Responsive design mode

This allows you to quickly see how your app looks and behaves in differently sized viewports, and you can also store presets to go back to those specific values.

responsive design

Network + cache inspector

Not only lets you inspect the requests that happen when you load a page in your app, but it also allows you to see the difference in requests when you load the page for the first time compared to when it’s loaded a second time. So you can make sure that static content is correctly cached, and your app is as fast as it can be.

network inspector

Scratchpad

This is a sort of a notepad where you can both write code with autocompletion and suggestions and also execute it on the context of the page you’re on. This will help you debug and experiment without having to go to an external editor to write your code and then reloading the page.

scratchpad

Canvas inspector

This lets you capture all the drawing requests that go to a canvas context between two requestAnimationFrame calls, and then also lets you replay them so you can see what is being done and can both understand how the drawing is made and if there are any extra or redundant calls that could be optimised.

canvas inspector

Shader editor

Just as the JavaScript debugger lets you inspect the code in the current page, the shader editor lets you inspect the code in the current WebGL context. And also allows you to pick any program and edit it with instant results. This is really a great tool for developers using WebGL since being able to test your shaders in the right context makes a huge difference compared to editing them and seeing the results being applied to a cube rotating over a white background.

shader editor

Web Audio Editor

This is the last addition to the tools, so it’s still a bit early times for this inspector! It will let you inspect the Web Audio context node graph, and if you click on a node it will let you change its parameters on the fly, so again you can get instant feedback.

The graph is also very helpful when trying to debug complex hierarchies that might have been built programmatically and thus aren’t easily understandable just by looking at the code-the graph provides a much better visual insight.

web audio inspector

Polyfills and libraries

Despite all the work in implementing APIs and pushing them to be standards, this process moves slowly and sometimes the needs of developers are way ahead of the needs of implementors. Luckily JavaScript is flexible enough that it’s often possible to write polyfills and libraries that will either fill the gap or provide some proof of concept API that could maybe become a native API later on if enough people adopt it.

So there is also a number of libraries that we develop to make writing apps more enjoyable.

Brick

Brick is a carefully curated selection of web components to build the UI of a modern web app. You can write your own elements using web components, and this in turn generates a sort of lightweight DSL where you have things such as the header of the app, the main content with a deck element and several cards on it, and a footer with a tabbar in it. The tabbar is linked to the deck, and so when you click on a given tab, the corresponding card in the deck will become active and be brought to the foreground.

Phonegap + Firefox OS

Despite our efforts to make the web the best platform, some features are still only available to native code unless you use something like PhoneGap-then you can keep writing your app in HTML+JS+CSS.

We want to make it easy for PhoneGap developers and we are working on plugins for Firefox OS, so the apps can be exported to Firefox OS too.

I know this all sounds ironic–building native apps using HTML? But I’d like to quote Brian Leroux, one of the stewards of PhoneGap, who gave a talk here past year:

our ultimate goal is to cease to exist

and I really liked the spirit in that sentence. For some things to change, we sometimes need transition solutions, and PhoneGap is one of those.

localForage

While new APIs such as ServiceWorkers get implemented, developers still need to store content for offline access, and the existing set of APIs was very inconsistent and unpleasant to use, so we built this library-mega-polyfill that provides a unified simple interface while trying to use the most efficient solution under the hood without bothering the developer with decisions. So for example if IndexedDB is available it will try to use that but exposing an API that is way less hostile than IndexedDB, and if IndexedDB is not available, as was the case in most iOS platforms until recently, it will try and use WebSQL if available, and if that doesn’t work either it will try to defer back to good old localStorage, which is the slowest of them all because it’s synchronous, so the whole script blocks until localStorage operations have finished.

// In localStorage, we would do:
localStorage.setItem('key', JSON.stringify('value'));
doSomethingElse();

// With localForage, we use callbacks:
localforage.setItem('key', 'value', doSomethingElse);

// Or we can use Promises:
localforage.setItem('key', 'value').then(doSomethingElse);

Animated_GIF

This is another example of API that maybe should be available in the browser but until it is, JavaScript nowadays is powerful enough that this can work decently fast even if performing lots of arithmetic operations.

var imgs = document.querySelectorAll('img');
var ag = new Animated_GIF();
var animatedImage = document.createElement('img');
ag.setSize(320, 240);

for(var i = 0; i < imgs.length; i++) {
    ag.addFrame(imgs[i]);
}

ag.getBase64GIF(function(image) {
    animatedImage.src = image;
    document.body.appendChild(animatedImage);
});

This is an example of the output you can generate: a GIF adding several frames, using dithering and an specific color palette.

Maybe in the future some spec writer will look at this and say oh, this is disgusting, what a poor API design! I will design something so much better and submit it to a standards track!

And I’ll be super happy to hear that.

Yeah, but…

Of course not everything is perfect. Of course there’s still lots of work to do.

Are you missing a feature? Don’t just complain, get involved!

This is not the 90s anymore

You can do so much more than complain because your browser vendor hasn’t updated the browser in years and bugs still plague you left, right and center.

The Web is YOURS, so shape it! Get involved!

Getting involved means you make informed decisions. What works? What doesn’t? Why? And… is there a work around?

Getting involved means your needs are taken into account. You can say We need this feature for our use case…, or also This feature can’t work for this reason… and it will be listened to.

Ultimately it boils down to this:

A W3C editor sitting on their chair on a lonely room will never know about your needs unless you tell them.

Ways to get involved

  • Always assume good intent, and be respectful. You might have had a bad day trying to build your app, and it isn’t working and you can’t figure out why, but it’s not the job of other people to listen to a parade of hateful swearing. Also if your plea for help apparently goes unnoticed, maybe wait a bit more until someone has the time to pick it and answer you. It’s not that people are unresposive–it’s just they might just be busy!
  • Find your channel: mailing lists, GitHub repos, IRC, meet ups, the Extensible web summit…. Find the channel that makes you feel more comfortable, and study it for a while-you don’t need to get active from day 1. It’s OK to lurk for a while until you get familiarised with the dynamics of the place. Then…
  • Ask questions. Questions are incredibly valuable for everyone. Phrasing your question in a way that is clear is an skill that requires development, but will help you actually understand what is it that you do not understand. And being asked a question will provide useful feedback to an implementor: it is a way of letting them know that something in the API is not as clear as they think it is, and that needs improvement.
  • Try your code in different browsers. Often developers try their code in a more permissive browser and when they release their app to the world they start getting reports that it doesn’t work as well as they expected in other, more restrictive browsers. It’s not that the other browsers are wrong but maybe you didn’t test enough. Or maybe they are-so this is a fantastic opportunity to read the spec and ensure you got it right. Maybe this will highlight other errors in your code?
  • Try nightlies for preview features. This will allow you to make sure your code keeps working even when new versions of an API are introduced. Maybe the API breaks in some edge cases that only your code uses. Is this in the spec? If it is and it shouldn’t behave this way, you should bring that up. If it’s not, maybe that should be in the spec to make things clearer. You can help here!
  • For the braver souls, maybe you could even learn to compile your favourite browser! And maybe you can even help fix issues that bother you.
  • File bugs. If you don’t think you can fix anything yet, but keep seeing things that don’t work as they should, you should file bugs. Often some issues only arise when certain factors fall in place at the same time. There are so many configurations and there’s no way to reproduce them all.
  • Build things. It’s the only way to put APIs to a test, and because each developer is unique, it’s the only way to try APIs in unique ways.
  • Break things! It’s OK if things break! It either highlights that you didn’t understand something correctly, because it’s unclear or because you need to give another go to reading the specs, or maybe it’s that you found something that truly didn’t work correctly. Congratulations!
  • File more bugs! You should not keep those extra bugs to yourself. Share them with implementors and browser vendors and help make the web even better!

For the Web to be ours, it needs everyone’s input.

Let’s build this together.

mozfest groooar

flattr this!

Planet MozillaGoogle IOU – where was the web?

I’ve always been a fan of Google IO. It is a huge event, full of great announcements. Google goes all in organising a great show and it is tricky to get tickets. You always walked home with the newest gadgets and were the first to learn about new products coming out. The first years I got invites as an expert. This year I got a VIP ticket which meant I paid for it but didn’t have to wait or be part of a lottery or find an easter egg or whatever else people had to do. I was off to the races and excited to go.

IOU in a piggy bank

IO, a kick-ass mobile and web show

I liked the two day keynote format of the last years: on the first day you learned all about Android and new phones and tablets and on the second it was all about Chrome and Google Web Services like Google+. This wasn’t the case this year; the second day keynote didn’t happen. Sadly enough the content format seems to have stayed the same.

I liked Google IO as it meant lots of great announcements for the web. As someone working for a browser maker I had a sense of dread each year to see what amazing things Chrome would get and what web based product would draw more people to using Chrome as their main browser. Google did well getting the hearts and minds of the web (and web developer) community.

This is good: competition keeps us strong and the Chrome team has always been fair announcing standards support in their browser as a shared effort between browser makers instead of pretending to have invented it all. The Chrome Summit last year was a great example how that can work. This hasn’t changed. I have quite a few friends in the Chrome team and can rely on them moving the web forward for all instead of building bespoke APIs.

Google IO sign

Google, a web company

Google is a company that grew on the web. Google is a company that innovated with simplicity where others overwhelmed their users. We used their search engine because it was a simple search box, not a search box in a huge web site full of news, weather, chat systems, sports news and all kind of other media provided by partners. We used GMail because it made us independent of the computer we read our mails on and it had amazingly simple keyboard shortcuts. Google understood the web and its needs – where others only allowed you to make money by plastering huge banners all over your blog, Google was OK with simple text links.

With this in mind I was super happy to go and get my fix of Google IO for this year.

Where is the web?

Suffice to say, in this respect I was disappointed by this year’s Google IO. Not the whole event, but the keynote. My main worry is that there was hardly any mention of the web. It was all about the redesign of Android. It was about wearables Google doesn’t create or have much of a say in. It was about “introducing” Android TV (which has been done before and then scrapped it seems). It was about Android Auto. It was about Android’s new design and the ideas behind it. Mentions of Chrome were scarce and misguided.

What do I mean by that? I was sure that Google will announce HTML5 Chrome Apps to run on Android and be available in the Play store. This would’ve been a huge win for the web and HTML5 developers. Instead we got an announcement that Android Apps will now run on Chromebooks. There was no detailed technical explanation how that would happen but I learned later that this means the Android Apps run in Native Client. This is as backwards as it can get from a web perspective. Chromebooks were meant to make the web the platform to work on and HTML5 as the technology. Heck, Firefox on Android creates dynamic APKs from Open Web Apps. I’d have expected Google to pull the same trick.

There was no annoucement about Chromebooks either (other than them being the best-seller on Amazon for laptops) and when you followed Google+ in the last months, there were some massive advancements in their APIs and standards support.

The other mention was that the new look and feel of Android will also be implemented for the web using Polymer.

Android’s new face looks beautiful and I love the concept of drop shadows and lighting effects being handled by the OS for you. It felt like Google finally made a stand about their design guidelines. It also felt very much like Google tries to beat Apple in their own game. The copious use of “delightful experiences” in every mention of the new “material design” refresh became tiring really fast.

Chrome and the web didn’t get any love in the IO keynote. The promise that the new design is implemented “running at 60FPS” using Polymer in Chrome was an aside and can’t have been a simple feat. It also must have meant a lot of great work of the Android team together with the Polymer and the Chrome team. Lots of good stories and learning could have been shown and explained. Other work by the Chrome and Polymer team that must have been a lot of effort like the search result page integration of app links or the Chromebook demos were just side notes; easy to miss. Most of the focus was on what messages you could get on your watch or that there might be an amazing feature like in-car navigation coming soon later this year if you can afford a brand new car.

Chromecast was mentioned to get a few updates including working without sharing a wireless network. This could be huge, but again this was mostly about sending streaming content from Google Play to a TV, not about the web.

Google+ apparently doesn’t exist and the fact that Hangouts now don’t need any plugin any longer and instead use WebRTC wasn’t noteworthy. Google Glass was also suspiciously missing from the keynote.

Props to the Chrome Devrel team

I got my web fix from the Google Devrel team and their talks. That is, when I arrived early enough and didn’t get stuck in a queue outside the room as the speaker beforehand went 10 minutes over.

long queues everywhere

I got lots of respect for the team and a few of the talks are really worth watching:

Others I have yet to see but look very promising:

Another very good idea was the catered Chrome lunch allowing invited folk to chat with Chrome engineers and developers. These could become a thing they can run in offices, too.

Other things that made me happy

It wasn’t all doom and gloom though. I enjoyed quite a few things about Google IO this year:

  • It was great to see all the attendees from different GDG chapters. Very excited developers from all over the globe, waving their respective flags and taking pictures of one another in front of the stage was fun to see. Communities rock and people who give their free time to educate others on technologies of certain companies deserve a lot of respect and mentioning. It is a refreshing thing to see this connected with a large Silicon Valley company and is a very enjoyable contrast to the entitlement, arrogance and mansplaining you got at the parties around IO.
  • Android One – a very affordable Android phone aimed at emerging markets like India and Africa. It seems Google did a great job partnering with the right people and companies to create a roll-out that means a lot. FirefoxOS does exactly the same and all I personally want is people to be able to access the web from wherever. In many countries this means they need a mobile device that is affordable and stays up-to-date. Getting your first mobile is a massive investment. I am looking forward to seeing more about this and hope that the Android One will have a great web experience and not lock you into Play Store services.
  • The partner booths were interesting. Lots of good info on what working with Android TV was like. I loved the mention of the app students created for their blind friend to find classes.
  • The internet of things section was very exciting – especially a prototype of a $6 beacon that is a URL and not just an identifier. This was hidden behind the cars, in case you wondered what I am talking about.
  • Lots of mentions of diversity issues and that Google is working hard to solve them was encouraging to see.
  • Google Cardboard was a superb little project. Funny and a nice poke towards Occulus Rift. Well done marketing, that one.
  • Project Tango is pretty nuts. I am looking forward to see more about this.
  • Accessibility had an own booth on the main floor and it seems that people like Alice Boxhall get good support in their efforts to make Web Components available to all
  • The food and catering was good but must have cost Google and arm and a leg. I saw some of the bills that Moscone catering charges and it makes me dizzy.
  • The party was not inside the building with a band nobody really appreciated (the pilot of Silicon Valley comes to mind and the memory of the Janes Addiction “performance”) but outside in Yerba Buena gardens. It had a lovely vibe and felt less stilted than the parties at the other IOs.

IO left me worried about Google

Overall, as a web enthusiast I am not convinced the experience was worth getting a flight, hotel in the valley (or SF) and the $900 for the ticket.

The crowd logistics at Google IO were abysmal. Queues twice around the building before the keynote meant a lot of people missed it. Getting into sessions and workshops was very hard and in many cases it made more sense to watch it on your laptop – if you were outside as the wireless of the conference wasn’t up to the task either. One amazingly cool feature was that the name tags of the event were NFC enabled. All you had to do was touch your phone to it and the people you met were added to your Google+ as “people I met”. The quite startling thing was that I had to explain that to a lot of people. If you do something this useful promoting one of your products and making it very worth while for your audience, wouldn’t it make sense to mention that in the beginning?

The great thing is that with YouTube, IO has the means to bring out all the talks for me to watch later. I am very grateful for that and do take advantage of it. All the Google IO 2014 videos are now available and you can see what you missed.

I always saw Google as one of the companies that get it and drive the web forward. The Chrome team sure does it. The Web Starter Kit (kind of Google’s Bootstrap) shows this and so does all the other outreach work.

This keynote, however, made Google appear like a hardware or service vendor who likes to get developers excited about their products. This wasn’t about technology, it was about features of products and hardware ideas and plans. At times I felt like I was at a Samsung or HTC conference. The cloud part of the keynote claimed to be superior to all competitors without proving this with numbers. It also told the audience that all the technical info heralded at previous Google IOs was wrong. As someone who speaks a lot on stage and coaches people on presenting I was at times shocked by the transparency of the intention of the script of some of the parts of the keynote. Do sentences like “I use this all the time to chat with my friends” when announcing a new product that isn’t out yet work? The pace was all wrong. Most of the meat of the announcements for developers were delivered in a rather packed 8 minutes by Ellie Powers at 2:16:00 to 2:24:00.

To me, this was an IOU by Google to the Web and Developer community. Give us a better message to see that you are still the “don’t be evil” company that makes the web more reachable and understandable, faster and more secure. Times may change, but Google became what it is by not playing by the rules. Google isn’t Apple and shouldn’t try to be. Google is also not Facebook. It is Google. Can we feel lucky?

Comment on Google+

Footnotes

Updated: .  Michael(tm) Smith <mike@w3.org>