A few months ago the Mozilla Labs and the Metrics Team, together with the growing Mozilla Research initiative, launched an Open Data Visualization Competition.
Using data collected from Test Pilot users (people who agreed to share anonymous usage data with Mozilla and test pilot new features) Mozilla asked its community to think of creative visual answers to the question: “How do people use Firefox?”
As an open data geek and Mozilla supporter the temptation to try to do something was too great. So I teamed up with my old data partner Diederik Van Liere and we set out to create a visualization. Our goals were simple:
- have fun
- focus on something interesting
- create something that would be useful to Firefox developers and/or users
- advance the cause for creating a Firefox open data portal
What follows is the result.
It turns out that – in our minds – the most interesting data set revolved around plugin memory consumption. Sure this sounds boring… but plugins (like Adobe reader, Quicktime or Flash) or are an important part of the browser experience – with them we engage in a larger, richer and more diverse set of content. Plugins, however, also impact memory consumption and, consequently, browser performance. Indeed, some plugins can really slow down Firefox (or any browser). If consumers had a better idea of how much performance would be impacted they might be more selective about which plugins they download, and developers might be more aggressive in trying to make their plugins more efficient.
Presently, if you run Firefox you can go to the Plugin Check page to see if your plugins are up to date. We thought: Wouldn’t it be great if that page ALSO showed you memory consumption rates? Maybe something like this (note the Memory Consumption column, it doesn’t exist on the real webpage, and you can see a larger version of this image here):
Please understand (and we are quite proud of this). All of the data in this mockup is real. Memory consumptions are estimates we derived by analyzing the Test Pilot data.
How, you might ask did we (Diederik) do that?
GEEK OUT EXPLANATION: Well, we (Diederik) built a dataset of about 25,000 different testpilot users and parsed the data to see which plugins were installed and how much memory was consumed around the time of initialization. This data was analyzed using ordinary least squares regression where the dependent variable is memory consumption and the different plugins are the explanatory variables. We only included results that are highly significant.
The following table shows our total results (you can download a bigger version here).
Clearly, not all plugins are created equal.
Our point here isn’t that we have created the definitive way of assessing plugin impact on the browser, our point is that creating a solid methodology for doing so is likely witihin Mozilla’s grasp. More importantly, doing this could help improve the browsing experience. Indeed, it would probably be even wiser to do something like this for Add-ons, which is where I’m guessing the real lag time around the browsing experience is created.
Also, with such a small data set we were only able to calculate the memory usage for a limited number of plugins and generally those that are more obscure. Our methodology required having several data points from people who are and who aren’t using a given plugin and so with many popular plugins we didn’t have enough data from people who weren’t using it… a problem however, that would likely be easily solved with access to more data.
Finally, I hope this contest and our submission helps make the case for why Mozilla needs an open data portal. Mozilla collects and incredible amount of data of which it does not have the resources to analyze internally. Making it available to the community would do to data what Mozilla has done to code – enable others create value that could affect the product and help advance the open web. I had a great meeting earlier this week with a number of the Mozilla people about this issue, I hope that we can continue to make progress.
Pingback: Nav Sunroof | New Convertible Car
Neither screenshot shows anything to do with Flash (or I’m missing it in both) which seems an odd omission. Can it not be analyzed, or is there another reason for excluding it?
Hi Jim – I think I addressed this question, please refer to the second to last paragraph in the post.
Thank you for reading!
The reason why Flash is not included is that to be able to make a prediction we need people who use Flash and who don’t use Flash. As Testpilot users are generally biased towards more advanced users there are few people who do not have installed Flash. There are estimates for Flash memory usage but they are not statistically significant and that’s why we didn’t present them.
I like this as a way of making the data useful, but I wouldn’t call it a ‘visualization’. It’s a table of data presented as a table of data (albeit with a bit of styling).
Well, it’s data. That’s been made more visualize (see second chart).
It may not be the sexiest visualization but our goal was to maximize usefulness, not sexiness. It was also data that wasn’t straight forward to generate (we didn’t just take something they gave us). If the only critique of this we get is “this isn’t really a visualization” then I think we’ll be pretty happy.
Pingback: Linux Blog » Blog Archive » Mozilla nabídne statistiky spotřeby paměti pluginů
In Firefox 4, most plugins will be in their own processes, which means that it’ll be easier to tell how much memory is in use for a given user at a given time. A slightly ambitious extension could query the operating system for that information, and display it in the about:plugins or about:addons page.
Yes – what would be really useful would be not only how much memory a plugin takes at initialisation (which IIUC is what is being shown here), but also how much it’s stolen after a period of use – Flash, I’m looking at you!
Pingback: Honourable Mention! The Mozilla Visualization Challenge Update | eaves.ca