In February, the Test Pilot team at Mozilla Labs rolled out a test to explore usage of the Firefox menu bar . This menu item usage study aims to help guide the UX team as they create a fully optimized design by answering 3 questions.

* Which menu items are the most commonly used?
* Which menu items are the least commonly used?
* How long do users spend exploring the menu bar contents before selecting each particular menu item?

After we received the raw data, Blake Cutler and Christoper Jung from Mozilla Metrics team did some great work to understand what this data is telling us. Here are a couple of preliminary findings regarding the first 2 of these 3 questions. Take a look!

This is pretty freaking impressive. Why don't agencies do this? Hell, most web development studios don't do this. If companies spent less on rich media and more on actually optimizing and iterating on the properties they already have they wouldn't have to go out and spend buckets of media every time they want to say something.

It seems like people only interact with about a dozen different functions regularly. I wonder if other applications follow a similar pattern. It would be an interesting exercise to design a website or application and say, from the beginning, "There will be 12 features, and only 12 features. What are they?" Literally, if you just started creating a list of all the functions you'd expect a user to want to use (or better, if you could do research like this ahead of time and find out for sure) and just design an interface around those elements and nothing else.

Developers have tried to overcome such barriers in the past with client-side enhancements like ActiveX, Netscape Plugins, Java Applets, but each in its own way was flawed and failed to gain mass adoption. It is possible that the Native Client project will change all this, but standardization of such initiatives across the browser landscape is a lengthy endeavor. For the near future the tools that the developer uses to provide a rich user experience remain JavaScript and ActionScript, plug-ins, such as the ones previously mentioned, are significantly limited by the architectural mismatch of performance requirements they place on the CPU.

It would be incredible, truly incredible, if hardware was designed specifically for web browsing. Can you imagine a chip designed specifically for rendering plugins? Imagine if JavaScript, Flash, and Silverlight all ran with hardware acceleration. Everything on the web would be faster, and CPU usage wouldn't be pegged at 100% when you try to watch an HD video in Flash. While I think it's cool that Mozilla is willing to entertain the idea of hardware accelerated JavaScript, I don't really see that happening. JavaScript engines are pretty fast these days. What we could really use is hardware acceleration for Flash and Silverlight (or at least a series of optimized instruction sets), and I don't really see that happening unless the runtimes are made open source.

Even if we get code running natively in the browser through the Native Client project, and HTML5 makes Flash video obsolete, I have a feeling plugins will return. It may well make sense to start engineering them with hardware acceleration in mind.