What I came up with is a small app using a combination of Python and JavaScript that you can find here. A cron job uses a Python script to query Bugzilla for the data in order to make loading the page faster, with the downside – of course – of the bug query being up to 5 minutes old (in this case). The actual front-end consists of a few JavaScript functions, flot, jQuery and some markup.

The app itself consists of two parts:

1. a grid based data overview, where you can drill into the details of every element and
   
2. a graph based overview, with various presentations of the data
   

For now, I have chosen a variety of presentations of data for both the grid and graph overviews but I am very interested in hearing about other ways of looking at the data, other cross-sections, different graphs, better ways of interacting with the data, etc.

So please try it out and write a comment about what could be changed to make it better.

PS. The last two graphs “Graph Opened/Changed” and “Graph Bug Age” are both zoomable ie. you can mark a section of the graphs and the graph will display only that part.

Update: The source code is now available here. It still needs to be cleaned up, but is functional.

This has also had the – some may say positive – effect that I haven’t posted anything new for a while. I do have a backlog of posts though, that will appear either this week or next as I get this mess cleaned up.

We have more than 20% marketshare on the desktop and it is growing. The desktop also provides a bunch of alternative browsers. In the smartphone market we will soon make our entrance with Fennec, to compete with the browsers in that space: Mobile IE, S60 Browser, Opera and others.

But if you look at the total market for mobile phones and what countries are using mobile phones and entirely skipping PCs we are missing a large group of people. These are people who aren’t using smartphones but featurephones. For many, the distinction between those two groups of phones is a blurry one, but the main difference is that a featurephone does not run an open operating system and usually has less memory and processing power than a smartphone does. But a featurephone still has the capability to use data on the network.

Looking at the total number of mobile phone sales in the world, you can see that there are about half a billion featurephones in the world today that we are not reaching. And if you look at a geographical breakdown of these sales you can see that the majority of mobile phones sold in emerging markets (Asia, Africa and Latin America) are in the featurephone category. Some even think the growth in these markets will be higher than others, making the disparities even larger.

So, if the majority of people using mobile phones are on featurephones, this raises the question: How do we bring the web to these people?

Current Options

So currently the options for people using featurephones are pretty much limited to:

1. using a limited browser (not full support for HTML, CSS and Javascript) from companies like Openwave (my former employer), Access, Teleca (Obigo)
2. a proxy based solution, currently only Opera Mini AFAIK. I haven’t included Skyfire as an option, since it is currently only available for Windows Mobile and some Symbian phones, all phones I consider smartphones.

The way Opera Mini works (well, a simplification of it) is that it delegates the processing of rendering webpages to a server (proxy) that then sends a rendered page to the phone. The benefit of doing this is it eliminates the need for large amounts of memory and processing power plus the client on the phone can be very thin, since it only has to implement some basic functionality (input fields and hyperlinks). It also means that all the data you have goes through that server raising issues about privacy and security. E.g. if you have to do a banking session, the server will know your username and password because it will have to use it itself to establish the connection from the server to the bank.

One More Consideration

Besides us not being able to reach people on featurephones, we also can’t reach people on a variety of smartphones for one reason or another e.g. Android (no support for native apps – yet), RIM (Java-based OS and no support for native apps), iPhone (license restrictions), Palm (big effort to port for small effect) and others. I am interested in hearing on how we can bring the web to there these people are as well.

So What Do We Do?

So should we care about this? If we think about the Mozilla manifesto and our mission, I believe the answer is yes. If you agree, how do you think we can accomplish this: how can we bring the web to where people are?
So, why does this matter?

So should we care about this? If you believe that the Internet is a global public resource that must remain open and accessible, I believe the answer is yes: clearly we can do more to make the Internet accessible for people. If you believe that the Internet should enrich the lives of individual human beings, I believe that the answer is yes.

If all that needed to be done was to render the original Yahoo! start page from 1994, we would not have a problem. But Moore’s law is working on both sides of the equation, and just as featurephones will gain capabilities, so will the web take advantage of the power in high-end devices. Unless someone focuses on the problem of the low-end, it will always be a problem.

To illustrate what I am talking about: there are websites like The Faces of the Fallen project, commemorating American service personnel killed in the line of duty, but we do not have even the roughest idea of how many Iraqis or Afghans were killed in those same wars. Thanks to Google, we can study the New York, Sydney and San Francisco, and yet we know almost nothing of sub-Saharan Africa. This is the digital divide. The Web is a wonderful thing, but it tends to focus more and more of our attention on the rich world.

So, shouldn’t Mozilla be thinking about how it can contribute to solving this?

We have now kicked off a project in an incubator repository to get the development kick-started and are inviting everybody who is interested in seeing Fennec (Mobile Firefox) on Symbian to get involved. Harry Li already started some of this work, where he has ported NSPR to Symbian.

The current high-level plan (that we will revise as we move forward) is split into 5 phases:

1. Fennec compiling and linking
   Planned completion date: end of January
2. Basic/limited browsing possible
   Planned completion date: end of February
3. Full browsing
   Planned completion date: end of April
4. Fennec ready for initial testing
   Planned completion date: TBD
5. Bug fixing and productisation of Fennec
   Planned completion date: TBD

Want to get involved? Take a look at the wiki or join us on irc on #mobile for general mobile discussions or #symbian for Symbian specific discussions.

In my next post I will write more details about how the actual work will be done and a more detailed breakdown of the schedule. Drop a comment if there is something else you would like to see me cover in the next post.

Update: The dates in the high-level plan are for 2009 (here’s’ looking at you Doug)

It has been about a month since I started at Mozilla and worked on Mobile. We have now reached the point where we have specific goals for Mobile (they are also on the Mobile wiki). The overall goals for Mobile are:

1. provide Mozilla’s standards-based open-source browser engine, optimized for mobile, that can be embedded by device manufacturers and others;
2. a full-featured mobile browser including support for XUL-based add-ons, delivering on Firefox’s key principles of ease-of-use, security and accessibility;
3. grow the Mozilla community in the mobile space;
4. provide tools and documentation to help developers develop, debug and deploy web applications;
5. do all of this work in the shared Mozilla source repositories so all platforms, desktop and mobile benefit each other

Next Steps

• get automated builds up for the Linux/ARM platform (check out “1.9-browser-chinook-armel” on tinderbox)
• integrate the awesome work Nokia has done on the N810 in the main 1.9 CVS tree
• create build targets and instructions, so that anyone can pull from CVS and target Linux or Windows Mobile platforms (Linux Maemo build instructions already available)
• continue the memory and performance profiling work to identify specific areas to focus on in the next phases including ARM specific work.
• build and test beta versions of the whole stack up to XULRunner on our target platforms (see below) to enable User eXperience (UX) experiments

Target Platforms

We will first focus our efforts on two platforms/devices running on ARM11 processors (ARM v6):

• Linux – first device working already is the Nokia N800 (possibly update to N810) running Linux (maemo)
• Windows Mobile 6 – a good first device is the HTC S730

These platforms are either already up and running or will be soon – and will allow our community to start testing UX with different hardware characteristics e.g. screen size (N800/N810: 800×480 vs. HTC S730 320×240) and touch-screen vs. non-touch-screen.

As many people will quickly notice there is no Symbian version here. We are aware of the millions of Symbian devices in the world and this is just a start and a good area to focus. We’d love help on Symbian if anyone is interested.

UX

On the UX side we have already started to develop a Firefox extension that will allow you to play with XUL on a limited size screen (link to extension will be posted shortly). We are exploring a variety of ways to improve the current browsing experience:

• alternative layout options accessible through XUL
• explore navigation options e.g. spatial navigation, directional tabbing, panning, mini map, allow extensions to control navigation, software cursor.
• integration with devices around text input (e.g. how do you design a UX that allows the use of Password Manager, Form Manager, the device dictionary and T9 in a form field?) and device widgets
• expose device capabilities (contacts, camera, etc.) through Javascript
  • deal with security issues
  • is there a way we can get a standard across devices?

Tools

We are also committed to improving the tools for mobile content developers
and people working on embedding Gecko in their own browser. In consideration right now is:

• mobile version of airbag (now breakpad) to assist with stack traces, memory dumps, ….
• debug device remotely though desktop Firefox (extension)
• improve packaging/deployment/debugging of XUL apps
• tools to assist content developers in measuring performance/code size

How do I get involved?

Come join us on irc at #mobile, on our weekly meetings or send me an email (christian at mozilla dot com). This is your opportunity to shape the browsing experience on mobile devices. Anyone can participate in the project and we are hiring a small team of full time contributors – email me if interested.

This week I received the keys to the Copenhagen office located in ITU (IT University of Copenhagen) on the 5th floor which is called 5te (which basically means “5th floor”). The office is rather small but it is in a very nice building with nice facilities (meeting rooms, cafeteria, ping pong table, foosball, ….) and lots of other companies, mainly startups. All we need now is some furniture and some people.

I took a few pictures to give an impression of the office but as it was after noon, it had started to get dark (kidding), so the pictures aren’t that good (not kidding). There is an official page that include a few computerized animations and some pictures from both the inside and outside of the building.