I didn’t go!

When I finally rolled up my sleeves and turned from a user to a contributor, my main interest was GNOME. Everybody was saying back then, in 2005, that the desktop is done with. The future is the web, the future is mobile. But I was stubborn; I loved the user-centered attitude in GNOME and the fantastic governance and community. I found myself working on accessibility for users with disabilities and loving it.
But here I am now, in my day job at Mozilla. Still doing accessibility, but focusing exclusively on the web, and on mobile. Yet I remained a GNOME enthusiast, and I always wait anxiously for the releases that come out twice a year when I need to try out every new feature.
It isn’t just an emotional thing. This has all gelled for me in a comprehensive analysis of the role of Free Software, and it goes something like this:
The web is important, it is a basic utility that everyone has a right to, and one company, or a consortium of them cannot hold any type of exclusivity. This is the internet that I and many of my peers first discovered in the 90s before the dot-com sleaze, and it is still the core of the internet today. The next billion users will discover the web through cheap mobile devices on a slow cell data network. They will never own a laptop, or have broadband access. The question is, will they have the same experience I did in the 90s, or will they be introduced to a limited walled garden that the phone manufacturers or carriers introduce them to? I see that as part of Mozilla’s core mission today, and it is what appeals to me. It is not a first world problem any more, and it is not primarily on the desktop any more.
So why is the desktop important? And why is GNOME important? Liberating users from corporate monopolies is one thing, but we need to liberate content authors as well. To produce quality content and applications for the web, we need to provide a free set of tools for doing it. The Free Desktop gives us that. It gives us GIMP, PiTiVi, and countless other tools with an appealing and comfortable environment that is designed to let us get work done. No need for Apple or Adobe, just some commodity hardware and you have a shop ready to get your message out there and make a difference. That is the empowering message of the desktop.
So to all the GUADEC regulars: I miss you guys. Maybe next year?

I just landed the final set of patches that will enable explore by touch for Ice Cream Sandwich screen reader users. If you use our nightly builds, you should probably see this feature in Tuesday morning’s build – if it all works out.
One of the things that I am most proud about is our focus on the core Android accessibility experience. Being “accessible”, is more than just providing a rich set  of accessibility features (although we are committed to that too), it is about allowing the user to get Firefox from the Play Store, and start using it immediately with no extra “self-voicing” extensions, no extra settings and checkboxes, and no new special gestures and interaction modes to learn. When a user with a disability purchases an Android phone, they will go through the painful process of learning how to use it and customizing it for their needs. When they install Firefox, they should be able to put the knowledge and muscle memory they acquired for every other task on the phone to browsing the web as well.
When accessibility is done right, it could be downplayed, and make space for the actual application you are using. In our case it is Firefox for Android. The positive feedback we are mostly getting from the blind community has not been about our accessibility features at all, but about the browser. The fact that Firefox for Android is fast and responsive, supports Flash, and syncs with your desktop tabs did not get “lost in translation”, it is the primary appeal for blind users just as it is for sighted users.
Why am I mentioning all this in regard to explore by touch? Because introducing this feature brings us one step closer to doing it right. Explore by touch works exactly the same in Firefox as it does in the rest of your Android TalkBack experience, move your finger around the screen and have the web content spoken to you, raise your finger and single tap to activate a link or control. Scroll with two fingers and hear the scrolling pitch change. There is nothing new here, just the same old experience you are used to in your Ice Cream Sandwich phone. Now go explore.

I am in to the second hour of watching Firefox for Android compile, and I thought it would be a good chance to test this blog of mine. It has been relentlessly hacked for over a year until I decided to move it to wordpress.com and be done with it. I need to follow up with progress posts about Firefox mobile accessibility, and fanboy posts about GNOME (it sucks that I am not going to GUADEC this year).

Hi again. Remember my first post to Planet Mozilla? I hope not. Sorry for the male enhancement pills spam. Please stop contacting me for orders.
I am in Toronto right now, spending a week with Mobile folks. It has been about 6 weeks since I started working on a mobile extension, and the list of dirty tricks we employing to get things done is growing. Some of these hacks are there because there is no alternative, and some are there because I just didn’t figure out the right way to do it.
Here is a short list:

Gestures

I reinvented them, poorly. Our extension relies heavily on the ability to support a rich set of multi touch gestures. We have a hack, similar to how it was done in Touching is Good (I know!), where we swap out the callbacks in MouseModule and GestureModule for our own. This doesn’t seem right, for a few reasons. The main one being that this doesn’t seem like a real public API, and it will be broken sooner or later. The second thing is the fact that we are relying on shaky JS to re-interpret the platform-interpreted events. So maybe there is a better way to do things. The nsIDOMSimpleGestureEvent only serves us to a limited degree, I  think there is room for a more low-level multi touch event API that is similar to the Android one. Or maybe a comprehensive high level API with more event types.

Speech

This should probably be implemented natively and have multi-platform support. Right now, in Android, we are doing Javascript <-> js-types <-> jni <-> Java. What could go wrong?! But seriously, it is kind of ugly right now, but I would like to make our JS solution prettier and useful to other extension writers who want to tap in to Android’s API and services.

Security

The Mozilla profile directory in Android is not world-readable, presumably for good reasons. Our extension’s media files need to be world-readable so that Android’s TextToSpeech service could pick them up and use them as earcons. This requires an install and uninstall hook that uses Android’s Context.getDir to get/create a subdirectory in Firefox’s top-level app directory where we could copy over those media files for system consumption. Maybe this is the best way to do it… But I can’t imagine anyone being happy about an extension writing to that directory. Sorry!

–enable-accessibility

Our extension depends on accessibility being enabled at build time. Since I am getting some face time with folks this week, it seems like a good thing to bring up.

I am sure there are other horrible horrible hacks in there. But the list above is really what I needed to confess to. Thanks for empathetic attention.