Extensibility is a double-edged sword. It’s a keystone feature in Firefox – differentiating even now that just about every other browser has some vector for augmentation. However, along with the freedom and power of Firefox extensions comes the ability to slow the browser down. And worse, users and developers have little or no visibility into the causes of poor extension performance.

Not all extensions slow Firefox down. But they can. To prevent that, we need to do three things:

1. Make it *easy* for extension developers to keep their extensions fast.
2. Allow users to see the performance effect of their extensions.
3. Mitigate the effects of badly-behaving extensions in Firefox itself.

For Extension Developers

First, we need to loudly and clearly educate extension developers, and provide them tools. Some ideas:

• Write an extension performance “best practices” guide on MDC.
• Build warnings into Firefox, that highlight code that might perform poorly (bug 550242).
• Provide a try-server that allows extensions to be uploaded and installed into the test profile.
• Perform automated performance testing of extensions upload to AMO (bug 458990, maybe?)
• Ensure that Jetpack generates extensions that are models for good behavior.

For Users

Users should be able to make informed choices about the extensions they install, and be able to monitor the effect of extensions on their browsing sessions. We could:

• Provide performance information for extensions on their pages on AMO.
• Build a performance dashboard similar to about:memory, but tracking startup time, page-load time, and browser UI behavior such as menu responsiveness. Given a visualization of these things over time, users can see the effects of installing different extensions.

In the Core

There are also things we can do to mitigate poor performance in core Firefox code. This is being discussed in bug 533038.

We’re already working on some of the ideas listed above. Ping me in #startup on irc.mozilla.org if you want to help out. If you have ideas for other ways to improve extension performance, or to communicate back to users and developers, let me know in the comments.

The best designers in the world all have one thing in common – a really full trash basket.

Design takes time, patience and iteration. It takes sketching the same ideas out over and over again on a whiteboard, figuring out which bits work and which bits just seemed like good ideas at the time. It takes staring at other people’s ideas and jealously wishing that you’d thought of that, too, and wondering what bits you can take as inspiration without people accusing you of not being original. It takes many soul searching evenings of figuring out if being original is really the right goal.

Sharing those sketches can be hard to do, and often it’s done only in the context of the finished product. In the past when we’ve tried to share early sketches at Mozilla, the enthusiastic (yet often awfully harsh) feedback of the community ends up ending design explorations before they really get started. The result is that designers have waited until more fully fleshed out mockups and designs can be shared, but this comes at the cost of not being as transparent as we feel we should be, and not including our community in our design discussions.

So those of us working on User Experience at Mozilla are going to try something new: a virtual idea journal and sketchbook, which we’ve tentatively called “From the Bikeshed” (as you may imagine, picking a name proved tricky!) It’s a Tumblr microblog doohickey thinger that we’ll all be posting to throughout the days and weeks to come. It’s only been active for a few hours, and we’ve already started really filling it up.

The astute will quickly notice some things:

1. It’s really random. There’s really no rules to what type of content will get posted here. We’re sharing sketches, whiteboard diagrams, iterations of high fidelity mockups, half formed ideas, articles that we found interesting and relevant, even images or photographs that inspired us.
2. There is little context being offered. This is intentional. When we have more context to give, we’ll write a blog post, but for now, this is our design stream of consciousness. When we’re done with a meeting or sketching out something cool, we’ll post it right away without cleaning it up.
3. There is no place to leave comments. This is less intentional, but while we figure out how to enable comments on Tumblr, we’re also going to think about what sort of comments we want to enable. As always, people should feel free to give us feedback in the dev-usability group.
4. Some of the stuff has nothing to do with Mozilla. Yup, and that’s healthy. The best ideas often come from thinking about how to apply other solutions to your problems, so we often go around looking at other problems in order to figure out how to solve our own.

So far it’s been really freeing and enjoyable for us all to start sharing this stuff with you, and hopefully you like it, too. Thanks to Alex Limi for setting up the Tumblr and getting us rolling.

Progress:

---

• Landed on trunk – Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. This is the main patch for adding support for Custom action based on update xml after app update. As a side benefit there are now several mochitest chrome tests for the app update user interface. This will need to be backported without string changes to 3.6 and possibly 3.5.
• Submitted patches for review for Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All]. This will need to be backported without string changes to 3.5.
• Started working on Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All].

Future targets:

---

• Fix a new requirement for Custom action based on update xml after app update – Bug 549969 [Toolkit] – Add ability to save xml attributes from update xml that app update doesn’t care about [All]
• Figure out the implementation for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]. This is the front end patch for adding Custom action based on update xml after app update.
• Land on trunk – Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All]. This will need to be backported without string changes to 3.5.

I am currently working on some "baked in" developer tools for web and extension developers.  This is the current status on the "console" piece.

Republished from the Mozilla Status Board: http://benjamin.smedbergs.us/weekly-updates.fcgi/

Done:

Spent the entire week on DevTools: "HeadsUpDisplay" bugs (bug 546708 and bug 545266). I have pretty much completed the work on these bugs, and will be filing new ones for the next phase, which is writing xpcshell tests for the HeadsUpDisplay service and browser chrome tests for what is part of the browser UI and Javascript module (HeadsUpDisplay.jsm).

The only gotcha is my attempt to make "contentWindow.wrappedJSObject.console = new Console();" to actually work.

I thought I had it working, but the wrapper is not working from content scripts. In the meantime I can write tests from the chrome side to make sure my internal methods are doing the right thing.

Worked with Mak on bug 543888 "Places API skeleton (API design)"

Worked on a CSS bug for Linux: Progress "Line" indicator for background loading tabs bug 544818
Next:

More of the same. Plan on revisiting "Update action" bug 538331
Coordination:

Ask mrbkap about my use of wrapedJSObject

I spent the week on-site at Mozilla HQ in Mountain View, which was great.

• Talked with Bob Moss and others about expanding our startup tests to cover a variety of startup scenarios.
• Spent some time tracing file IO with the top 10 extensions on AMO installed, comparing it to an empty profile (empty, with extensions) for a bug Taras filed about extension-caused file IO.
• I also traced shell calls in the startup path, and found some weirdness, and yeah there are a bunch more calls with the top 10 extensions installed (empty, with extensions). Things like this should be “advertised” on extensions’ pages on AMO. I’m pretty sure there’s already some movement towards Talos testing extensions and posting results on AMO. I’ll file a bug for getting things like this watched as well.
• Taras has been making progress using Valgrind to get the function and data ordering sequence for improving code locality in our binaries.
• Ryan patched and landed a change to increase the buffer size used when reading in JSON files (something the search service does during startup).

(reference)

;-)

So, I finally got around to watching this video which has been been making the rounds as of late (not a Rickroll, I swear to god! WHY DOES NO ONE TRUST ME?! :-). I fired it up the 1080p version in fullscreen mode, and was slightly disappointed to find that while the video was playing back rather well, it wasn’t quite perfect. As the beer commercials say, “rich, but not smooth.”

So I next loaded it up in Safari, to see how it compared. Previous versions of Firefox have had some jerky-video problems (due to running garbage collection at bad times or doing too much main-thread disk IO for session restore), so I was fully prepared to file a bug on the problem — smooth playback in another browser would be a strong indication that something in our code was causing the poor performance.

However, what I found was that playback in Safari was much much worse that on the trunk Firefox build I was using. While Firefox yielded good playback with an occasional glitch, Safari gave a consistently poor playback of around 3 fps.

There’s one clear, inescapable conclusion here: Flash sucks. :-) But seriously, folks, I’m happy to see that trunk builds perform well. I should still file a bug to investigate if we’re responsible for the occasional stutter in playback (or if that’s just Flash), and if results on Windows are similar to OS X or not. But I’m still pleased to see that this arbitrary trunk nightly — not even beta quality — is doing a good job.

Here are this week’s news about our project to support multitouch screens. Besides moving forward on an events API, last week I filed some bugs that aim to improve the overall experience for touchscreens devices (single and multitouch) when surfing on the web. They are:

• Bug 547997 – Perform hit target detection/correction on tap clicks
• Bug 547996 – Be able to tell when a click was generated by touch
• Bug 548005 – Browser zoom should stay centered when coordinates are available
• Bug 548012 – Browser zoom should be cancelable to be handled by webpage

And there are some other already existing bugs so there’s now the meta bug 548100 to keep track of them all.

On the DOM Events API front, on the previous week I unbitrotted the experimental patch to apply to current trunk. And at the moment I’m investigating the Windows 7 API to understand how to deal with the limitation that you can either get raw touch input or touch gestures data, but not both at the same time.

My next goals is to work on the bugs to improve the user experience and to keep moving with the events api making sure to coordinate this work with mobile’s interests too.

The graph server is a powerful tool for visualizing the results of our performance tests over time. However, it has a few major problems that make using it in it’s current form difficult. It also lacks a few features that would make it far more useful for tasks such as regression-finding. I and a few other people are looking into improving the graph server. Before starting though, we need to know how you use the graph server, and your ideas for how the interface could be improved, so please let me know your thoughts in the comments!

Instead of copying around the table of high-priority startup projects, it’s now centrally located and updated on the Startup wiki page. A couple of front-end optimizations landed this week:

• Neil landed bug 354048 to not rebuild toolbars at startup.
• Ryan landed bug 522842 for the search service to not send notifications until all engines are loaded.

I’ll be in Mountain View all next week for the Firefox work-week.

Theme Bugs Checked-In

Dao and Markus have already started to land bugs pertaining to the new theme/ui:

Windows:

• #544999 – New toolbarbutton style for the main window – You may have noticed this on trunk
• #547752 – Adjust toolbarbutton paddings and margins for small and big icon modes

Mac:

• #546874 – New style for the bookmarks bar

Some new theme bugs have been filed

Windows:

• #548027 – Tweak New Toolbar Button Style to Match Designs
• #546259 – enable aero glass for the main window
• #549061 – [Windows] New Style for Tabs

Mac:

• #547787 – New style for the tab bar

 

Mockup Iterations now on SVN

I posted the mockup Photoshop files to an SVN repository: http://svn.mozilla.org/design/projects/newtheme/

This can be accessed through the web or with an SVN client.

 

Progress:

---

• Waiting on remaining reviews for Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All].
• Started looking at the implementation in the patch for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All]. Should have the implementation figured out next week.
• Started working on and have received ui-review on Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All].
• Started on a patch for Bug 548061 [Toolkit] – Billboard should handle 404 (other errors?) for billboard better [All]

Future targets:

---

• Get reviews for and land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]
• Figure out the implementation for Bug 538331 [Firefox] – On update perform action based upon the update metadata [All].
• Finish the patch for Bug 480178 [Toolkit] – Billboard should extend to available space and the update UI should be the same width for all locales [All].

Jetpack

Jetpack team preparing to release next week the first version of the reboot, which I think they’re now calling the Jetpack SDK. Its purpose is to elicit feedback on the new architecture, especially from people who know Gecko. Today, a release candidate.

Still finalizing many of the first-round APIs, which are targeted for the second reboot release the first week of April. Discussion in the group. Some already being implemented. I filed some simple storage bugs, wrote patches for a few, and that’s all I’m able to do at the moment. Awaiting Atul’s reviews.

Async bookmark folders

New patch and a miss on Mano’s blocker.

I just landed the patch for bug 512784 on mozilla-central. It adds a new module to the toolkit whose sole purpose is to expose memoized getters for common XPCOM services on a simple “Services” JS object. The first pass involved adding getters for the prefs service, observer service, window mediator, permission manager, IO Service, prompt service, and search service. This patch also updates Firefox’s browser.js to make use of the module, which means that trunk-based extensions that run code in Firefox chrome windows can start making use of it if they’d like.

Here’s an example of one of the changes:

+// Services = object with smart getters for common XPCOM services
+Components.utils.import("resource://gre/modules/Services.jsm");

 function getTopWin()
 {
-  var windowManager = Components.classes['@mozilla.org/appshell/window-mediator;1']
-                                .getService(Components.interfaces.nsIWindowMediator);
-  return windowManager.getMostRecentWindow("navigator:browser");
+  return Services.wm.getMostRecentWindow("navigator:browser");
 }

I expect to add some other services to it as I look at expanding use of the module (Mossop has some suggestions in the bug). We might also add an equivalent in Firefox for browser-specific services, if that proves to be useful. The end goal is to remove a lot of the XPCOM boilerplate junk we see spread around our front-end JS code, and a side benefit is the reduction of unnecessary getService() calls for services that are already guaranteed to be otherwise instantiated and kept around for the app’s lifetime. This necessarily implies that JS scopes where the module was imported will now have permanent references to services after their first use, which is worth keeping in mind, both when making use of of the module and when adding additional getters to it.

I’ve been posting weekly status updates for awhile now (since August 9, 2009). I think they’re an important part of communicating exactly what it is I (and the rest of the Firefox team) am working on, and how things a progressing. Not only that, it’s a great way of getting unsolicited feedback, as I often get comments on these posts. So from my point of view, these posts been a great success.

But I want to know if I can improve them. What would you like to see more of? Or less of? Should I have more detail on what I’ve achieved, or what I’m planning? Should I be less whimsical? Should I reflect more on the past week, and on life in general? Should the format be altered? Should I include more pictures of cute kittens with amusing captions?

Related posts:

1. Status update
2. Status update

Few days late on this – oops. I’ll be at the Mountain View office next week for a Firefox team work week – any hacking I get a chance to do will probably be on random things, rather than my usual projects. If you’re in the office and want to catch up or talk about anything, come and find me. No idea what area I’ll be in, but just look for the hairiest person you can find.

Extension Manager UI Redesign

Status

• Solidified some interactions and how views are implemented & interact
• Helped Mossop figure out some API bugs (turns out, extensions.ini is important!)
• Some progress on updating addons

Loose ends

• Still waiting on the project branch (bug 542910)

Next steps

• Install/uninstall/update/enable/disable
• AMO Search
• Help with API development

Target for next week

• None (getting the most out of the work week takes priority)

Tab matches in Awesomebar

Status

• Code review complete
• Waiting on superreview for API changes

Related posts:

1. Status update
2. Status update
3. Status update

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

The UX meetings are open to people from outside Mozilla — if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 13:30 PST. We post agendas to dev.planning and dev.usability before these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. Contact us a bit in advance to coordinate.

---

New & noteworthy

Alex Faaborg is giving a talk at ZURB interactive agency (open event) in San Jose this Friday at noon — sort of a lunch talk with questions about Firefox. More details on the ZURB site, with sign-up details if you want to attend.

Previous week

Highlights from the previous — short — week’s activities:

• Jennifer Boriss worked on some of the Extension Manager edge cases, and stepping back and updating the high-level mock-ups.
• Alex Faaborg worked on Weave stuff, we’re getting ready to land Weave on trunk — what needs to change immediately, what needs to change before we release it in a Firefox release.
• Stephen Horlander was recovering from being sick, and cleaned up resources and files and posted them in the UX SVN repository. First cut at the new buttons has landed in the nightly builds for Windows.
• Alexander Limi had a lot of small admin stuff to wrap up this weekend — interviewing UX candidates for Labs, some more updates to Resource Packages, and made some headway on the new Download Manager.

This week’s meeting

We mostly discussed our plans for the upcoming Mozilla Work Week, who should we schedule to meet with, what activities should we prioritize, etc.

Some priorities:

• Wrap up Firefox app menu contents & behavior/design, finalize URL behaviors.
• Meet with Markus to discuss the Mac theme.
• Get some straight answers from Linux people on theming capabilities.
• Possibly do a UX presentation on Firefox.next again.
• Revisit the UX index, update.

Individual goals & focus areas this week

Jennifer Boriss

Most Extension Manager stuff should be done by Friday, maybe schedule a work session to go over it this week.

Alex Faaborg

Stephen Horlander

Working on updating Linux/Mac mock-ups, and update the wiki, file more theme-related bugs.

Alexander Limi

Update the Firefox Projects list to be in sync with our projects, and wrap up some tasks from last week: publish a spec for an improved Download Manager, get Test Pilot menu item study results from Jono.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

Jetpack team made plans for a cadenced reboot release cycle: Three weeks for development followed by at least another week for debugging, triage, doc and blog writing, preparation for release.

The purpose of the first reboot release, 0.1, is to demonstrate the framework Atul has built. It won’t offer any high-level friendly APIs, but it can be used to build honest-to-goodness extensions, including one example to be bundled in the release, and it will be documented. 0.1 freeze is February 22, with a release date targeted for March 1. After that, releases every month or so, with more high-level APIs introduced each time.

Myk is finishing up his analysis of the first-round high-level API proposals. Some good discussions in the user group.

I’ve started implementing simple storage. First I need to add some lower-level modules for things like text streams. Aiming to have all my patches submitted for review by the end of next week, but since there are several dependent pieces each needing review, we’ll see. I’m also responsible for implementing context menu support.

Taras blogged about the function ordering work he did while on vacation in Fiji (?!). Looks like the potential for a minimum 10% win there, very exciting. Follow along in bug 531406.

Other than that, no major updates:

• Zack found surprisingly large performance wins just from deCOMtamination patches in his CSS work. If you want to help out, bug 105431 is the deCOM tracker bug, and bug 545052 is about building tools for automating deCOMtamination.
• Static build: Still in reviews, need to figure out approach to binary tests on the tinderbox.
• Ben’s fastload cache replacement is still waiting on first-review from Ben Smedberg.
• Bug 354048 to not rebuild toolbars at startup, still cycling through reviews.

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Firefox UX team posts weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release.

---

New & noteworthy

For people outside of Mozilla: We have opened up the UX meetings to people from outside Mozilla, if you want to listen in, use the numbers for our conference call system and join conference room number 268 every Monday at 13:30 PST. We’ll post agendas to dev.planning and dev.usability up front for these meetings.

For people at Mozilla: We are scheduling regular work sessions at 13:00 PST on Wednesdays every week — as part of this we also accept drop-in visits if you want to get assistance with any user experience task. The doctors are in, office hours are in effect! Sending us an email up front with materials will make it easier, and also lets us plan accordingly. We’ll usually meet in Zombocom, Warp Core, or in that area, depending on which rooms are available.

Previous week

Highlights from previous week’s activities:

• Limi mostly worked on an upcoming post on improving the Download Manager, which should be ready this week. He also posted the final draft of the Resource Package specification — including defined behaviors around overriding and duplicates. It’s now ready for building into a prototype, and was posted to dev.platform as well as people from the Google Chrome team. We’re also asking for feedback from some of the largest web sites out there on the spec.
• Alex Faaborg put the Weave UX work on hold, and focused mostly on the new notifications. Figured out ways to deal with app-level notifications, and met with marketing to discuss how the notifications affects their messaging now that we're transitioning to having less dedicated update pages. Still filing bugs related to customization and cursor changes. A thread on dev.platform was posted, and you can track the meta-bug for the theme work here.
• Jennifer Boriss — Set up study on add-on categories, Mac installer simplification start, find-in-page animation sprint start, extension manager redesign (install use cases, weave integration), recruiting at Interaction10 in Savannah.
• Stephen Horlander got sick, so slow progress last week.

This week’s design session

There was no Monday meeting this week because of President’s Day, but we have a guest star from Toronto and the Firefox Mobile team visiting — Madhava Enros. We did a working session on unifying our directions and exchanging ideas and improvements that are relevant for both desktop & mobile. Among the subjects covered:

Syncing up concepts between Fennec and Firefox

We discussed generally about the need to carry design ideas between the two platforms, the need to keep things conceptually consistent, but also which areas should be different on purpose, since the way you use the two platforms is somewhat different. As an example, text input is more painful on a mobile device, so showing a bit more info and more navigation abilities — e.g. automatically expanded AwesomeBar results — makes sense.

Identity & security UI

Outcome: We want a consistent color scheme and approach for EV/SSL handling between the platforms, so the experience you have with security and identity carries over. Discussed opportunities to make both platforms better.

The unified “Firefox” menu & mobile

Outcome: The new, unified “Firefox” menu planned for the next version actually makes it easier to make the mobile version consistent with the desktop version. Of course, the contents of the menu will be somewhat different — less focus on printing, saving, and other device-specific operations — but overall we should be able to carry across the menu structure. On mobile, it will be implemented as a list of tiles, which scale to both landscape and portrait orientations.

Windows 7 mobile

Outcome: General discussion on the newly announced Windows Phone 7 Series, and its “intensely typographical” user interface. Microsoft seems to have sold everyone on the idea that they dropped everything and rewrote from scratch, but it's actually still mostly the same on the backend — so Fennec is in a good position to capitalize on this possibility quickly. Interestingly, Pocket IE doesn't really match the rest of the platform, and we believe Firefox Mobile can offer a much better and native-feeling mobile browser than what currently ships with the OS.

Favicon is a stand-in for URLs on mobile

Outcome: Fennec shows title instead of URL, so the favicon has increased importance in how you establish which site you're on. On the desktop version, we're currently removing the favicon from the URL bar and only showing it in the tabs, so there will be a difference here. Some discussion around various other approaches.

Combining favorites and “read later” functionality

Outcome: On a mobile device, a lot of the bookmarking activity is actually of the “Oh, this looks interesting, but it's 60 pages and I don’t want to read it on my phone” variant. Discussion around how we can enable a seamless experience here, using Weave as the central component.

Downloading on a mobile device

Outcome: Downloading files on a mobile device is less common, even if some platforms — like Maemo MeeGo — support it. Limi raised the idea of marking a file as something you want to download, and making the actual download happen on your desktop or laptop computer instead, using Weave as the mechanism for synchronizing this. So when you get back to your computer, there are some downloads already queued up.

First-run experience on Fennec

Madhava asked for some help in improving the first-run experience on Fennec. It currently has some discoverability issues, we suggested showing the UI on the edges, sliding it out of the way, and letting people discover it that way — instead of trying an abstract representation of the UI as is done in the current animation:

Individual goals & focus areas this week

Jennifer Boriss

Add-ons manager redesign (extended view, multiple screenshots & developers per add-on, personas integration), deploying study on add-on categories.

Alex Faaborg

Picking up Weave work again, continue filing theme bugs, clarifying and evangelizing with the platform team.

Stephen Horlander

Got sick last week, so essentially working on the same stuff as last week: File more bugs, coordinate with Dão/Gavin on resourcing, designs for download panel. Also adding theme resources to the upcoming design repository.

Alexander Limi

Get Download Manager article published, start specifying Home & App tab interactions. File more meta-bugs to keep the projects gathered under one bug. Get Test Pilot results from the menu study — scheduled to be ready this week, according to Jono. Also: Interviewing some Labs UX candidates.

---

Is there anything that you think can be improved in these updates? Send feedback to limi@mozilla.com.

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

The Resource Package specification we posted a while back has gone through multiple rounds of refinement and improvements, and is now ready to be handed off for an initial implementation in Firefox & other browsers.

Resource Packages provide a backwards-compatible, simple, efficient way to bundle up resources in a single file to make transfers faster and reduce HTTP overhead.

The changes made since the proposal was initially posted are:

• Added defined behavior for what happens when resources are defined twice.
• Added inline definition of resource package content in a manner that is compatible with HTML4/XHTML validators.
• Added Offline Resources support
• More FAQs answered based on feedback from mailing lists

We are now at a stage where I can hand this off for a prototype implementation — if you’re interested in helping out, let us know in this dev.platform thread. Check out the Resource Package specification here, and if you want to track its progress, you can subscribe to Bugzilla entry #529208.

Extension Manager UI Redesign

Status

• Download progress widget done. Should be possible to do a fancy button -> progress transition.
• Local search done – including sorting based on relevance to search string
• AMO search not done – need API support and UX details
• Lot’s of UX questions for Boriss
• Weekly meeting notes here

Loose ends

• Waiting on project branch to be setup (bug 542910)

Next steps

• Install/uninstall/update/enable/disable
• AMO Search
• Help with API development

Target for next week

• Install/uninstall/update/enable/disable (assuming API support is ready)
• Otherwise, integration issues

Tab matches in Awesomebar

Status

• Another round of reviews. Getting there!

Loose ends

• None

Next steps

• Followups: 530209, 546253, 546254, 546255, 539357

Target for next week

• Landed? Plz?

Miscellaneous

• As a fun side-project, I’ve been playing with making the Firefox team’s projects page look pretty. You can see the result here: http://theunfocused.net/moz/status/status.html. Uses a bunch of newer CSS stuff, so requires Firefox 3.6+ (support for other modern browsers is next-weekend’s task). Using YQL, it pulls data from the projects page, whois page, and planet Firefox.

Reflections

• Learn like you know nothing

Related posts:

1. Status update
2. Status update
3. Status update

Application update is going to support an application provided string in the update xml which can then be used by the application to determine what to do after a successful application update.

Progress:

---

• Client side patches reviewed but still need to finish tests for Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. The xpcshell tests are finished but the mochitest chrome tests have shown there are leaks in the client code (it also asserts in debug builds) due to the work done to support remote html which was done for Firefox 3.0. As soon as I fix the leaks and assertions the tests should be done. This is taking much longer than I like but tests are important and it is very important to not add new oranges to the tinderbox.
• ddahl has started work again on Bug 538331 [Firefox] – On update perform action based upon the update metadata [All] as well as general cleanup of overridden attributes in the update xml.
• Reviewed code / provided guidance for Bug 523410 [Core] – Disable LSPs in WinSock for Firefox [Windows.]

Future targets:

---

• Finish up the tests for and land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]
• Write mochitests for Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All].
• Finish up Bug 538331 [Firefox] – On update perform action based upon the update metadata [All].

Jetpack

Jetpack team met and discussed use cases for each of the reboot’s first-round API proposals. Myk has started analyzing them holistically to ensure sense and consistency. He intends to finish early next week, after which the team will finalize the proposals and begin implementation late next week. Other reviews for Gecko and security dependencies may happen next week also, with chofmann involved.

Myk and chofmann wrote down a set of goals and principles that will drive design of the reboot’s APIs. Myk’s analysis will help refine some of it. I hope it also becomes one document we can point to when holy righteous extension vs. Jetpack clusterfucks reassemble, as they inevitably will, in part because a clear statement of Jetpack’s purpose by drivers outside the Jetpack team, if such a thing exists, is broken and buried in blog and newsgroup postings with unrelated titles.

chofmann filed a bug to track Firefox and Gecko dependencies. (We had been using [jetpack] in the whiteboard.)

Daniel started a page on FlightDeck, the contracted-out in-browser IDE that will supplement the reboot. I’ve asked him to keep it updated as development progresses.

Async bookmark folders

Still blocked on Mano’s view-related bug. He thought a new patch might be ready yesterday, but not yet.

Various minor updates this week:

• Static build: Ted did the first pass of review. Getting close. Will land on the Places branch once binary tests build, to see perf impact.
• Ben’s fastload cache replacement is still waiting on first-review from Ben Smedberg.
• Neil took up bug 354048 to not rebuild toolbars at startup, should reduce the DOM activity some at least. The patch is in review by Dao and Mano.
• Marco has nearly completed bug 542943, removing the bookmark redirect hash, which means less SQL at startup and less memory usage by the bookmarks service.
• I put a patch up on bug 545516 that fixes some bugs and cleans up the layout of the Performance Snapshot. Will get it landed next week.
• Started working with John O’Duinn and Mike Morgan to get a team together to work on the graph server.

For those who haven’t seen it, scam-detectives.co.uk has a really interesting 3-part interview with a former Nigerian scammer.

Scam-Detective: A reader has asked me to talk to you about face to face scams. Were you ever involved in meeting a victim, or was all of your contact by email?

John: I never met a victim, but I was involved in a couple of Wash-Wash scams.

Scam-Detective: Wash Wash scams? What does that involve?

John: We would tell the victim that we had a trunk full of money, millions of dollars. One victim met some of my associates in a hotel in Amsterdam, where he was shown a box full of black paper. He was told that the money had been dyed black to get through customs, and that it could be cleaned with a special chemical that was very expensive. My associates showed him how this worked with a couple of $100 bills from the top of the box, which they rinsed with some liquid to remove the black dye. Of course the rest of the bills were only black paper, but the victim saw real money. He handed over $27,000 (about £17,000) to buy the chemicals and was told to return to the hotel later that day to pick up the cash. Of course when he came back, there was nobody there. He couldn’t report it to anybody because if it had been real it would have been illegal, so he would have gotten himself into trouble.

Part 1, Part 2, Part 3.

We build tools in Firefox like stale-plugin warnings and malware blocking to help protect our users, to neuter the technological attacks they may encounter on the web. But we also try, and need to keep trying, to build tools that inform our users so that they can make better decisions. Our phishing warnings and certificate errors try to do this, but mostly by scaring users away from specific attack situations. I hope we’ll continue to build tools like Larry which try to give people some affirmative context as well, to lend some nuance to their sense of place online. I want us to help our users know when they’re on Main Street, and when they’re in an alley.

I know: People get conned in the real world, too, and certainly no browser UI is going to save you from an email-based scam. Stories like this, though, are just specific instances of what I believe to be a more universal principle:

the biggest security risk most people face is misplaced trust

John: Some of the blame has to go to the victims. They wanted the money too because they were greedy. Lots of times I would get emails telling me that they wanted more money than I was offering because of the money they were having to send. They could afford to lose the money.

Scam-Detective: John, I think you have been basically honest with me so far. Please don’t stop that now. You know as well as I do that not all of your victims were motivated by greed. I have seen plenty of scam emails that talk about dying widows who want to give their money to charity, or young people who are in refugee camps and need help to get out. You targetted vulnerable, charitable people as well as greedy businessmen, didn’t you? You didn’t care whether they could afford it or not, did you?

John: Ok, you are right. I am not proud of it but I had to feed my family.

If you have ideas for how we can help users place their trust online more deliberately and carefully: please comment here, or build an addon, or file a bug.

The URL shown here is making the rounds. WARNING: don’t visit this URL unless you’re prepared to have your browser crash (the screenshot is from a current trunk nightly, which survives the Flash crash due to Out Of Process Plugins support).

I’m getting all verklempt.

Yesterday I landed bug 538910, which introduces some new UI for when a plugin crashes. This builds on top of the fantastic Out Of Process Plugins (OOPPs) work from the Electrolysis team, which allows the browser to keep running even after a plugin dies. So, now that crashes from plugins like Flash, Java, Silverlight, and Quicktime don’t take down Firefox, we need to show the user something to indicate when a plugin has a problem and how to deal with it.

A picture is worth a kiloword, so let’s start with that:

When a plugin crashes, we now show a placeholder (as in the pic above) to indicate that the page is missing some expected content. The browser runs a single plugin process (per plugin type), which is shared across all tabs and windows, so any page using a plugin when it crashes will have it replaced with this UI. But if the plugin on the page is sized too small to show the UI (text and icon), we’ll instead show a notification bar.

Recovering from a plugin crash is easy — simply reload the page. It would be nice to restart just the plugin without reloading the whole page, but scripts on the page won’t be expecting the crash, and can break or misbehave. It would be an interesting future experiment (addon?) to allow attempting to do this anyway, but for now reloading the page is a simple, conservatative approach that we know will always work.

You might have noticed that at the bottom of the placeholder UI there’s a message saying “A crash report was submitted.” Mozilla has an existing system for collecting Firefox crash reports, which are hugely useful for helping us detect and fix problems that users encounter. Plugin crashes are also able to generate these reports, and we can notify plugin vendors of their bugs. Crashes are annoying enough, so we decided that then was the wrong time to have annoying popups or checkboxes which require the user to make a decision about submitting a report. Instead, submission is controlled by a preference (exposed as a checkbox in the usual browser preferences window), and the browser will automatically submit the crash report when it’s enabled. The preference is shared with the existing Crash Reporter, so if you’ve previously told it to not submit crashes, that choice will continue to be honored (and, now you can disable submission without having to wait for a crash to happen — but we hope you won’t do this because these reports are so helpful for improving Firefox’s stability).

The visual style of this UI is also being used for what’s shown when a plugin is missing, disabled, or blocked. We’ve always had UI for those cases, but it was a bit barebones and ugly. Now it looks better, and further refinements are coming (see bug 545070).

If you’d like to check out this new UI, you’ll need to be running a current Windows or Linux trunk nightly. Sorry OS X, no OOPP for you yet. You can wait for a plugin to crash, or just kill it off from the OS’s task manager (look for a “mozilla-runtime” process).

Finally, here’s a particularly nice screenshot of how nice this UI can look in content. Thanks to Stephen Horlander for the beautiful visual design, and to Alexes Limi and Faaborg for UX. I think this will be the best crashed plugin experience you’ve ever had. (Oh, and don’t miss Sean Martell’s epic alternate version!)

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

As promised last week, the Firefox UX team will post weekly updates on what we’re up to. Instead of only posting individual after-the-fact updates, we’ll try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process.” It will hopefully also give you a bit more insight into how we do our work. Our current focus areas can be found at UX priorities for the next Firefox release, as usual.

---

Previous week

Highlights from previous week’s activities:

• Jinghua, Boriss & Limi performed the first usability study on URL bar behaviors & expectations performed in downtown Mountain View. Definitely a success, but needs a second session to have enough subjects for meaningful analysis. Limi will follow up on this, probably next week — since it’s not directly part of the upcoming focus areas.
• Both Alex Faaborg & Stephen Horlander did some major bug filing and also updated and consolidated all the wiki pages & mock-ups. Full details.
• Limi completed his Resource Packages update, now includes inline definitions of resources. The only thing missing is a defined behavior when two packages override the same path, as detailed by Laurence Rowe in bug #529208. We’re ready to get this started, look for a post in dev.apps.firefox soon for the next steps.

This week’s meeting

We had discussions around the following:

App tabs: Handling drag events when there’s no Home tab visible

Outcome: Surface drop zones when dragging event starts, in practice this means temporarily compressing the tab closest to the app tabs area to make room. When app tab is moved into this area, it changes shape to indicate that it’ll become an app tab.

App tabs: Opening a new window when app tabs are defined

Outcome: Similar to how BarTap works, don’t load the app tabs until they are activated, but keep them around. This should probably be added as a general tab capability, since we want to use this for session restore, optimizing memory use for long-lived tabs in marathon sessions, etc.

Doorhanger Notifications: Problems with notifications from the Firefox menu

Outcome: There won’t really be any notifications coming from the Firefox menu, major updates have a dedicated, modal window already (make sure it’s modal), everything else is site-specific, so will originate from the site area. Once we have a messaging channel (home tab), we can kill off the dedicated “you’ve been updated” page for minor updates — but keep for major versions to surface new features.

Discussion on Linux theme defaults

Outcome: No matter what defaults we choose to ship, we’ll need to be able to draw in the title bar. Faaborg will follow up on this, and make sure bugs are filed.

How to handle all the bugs in a given UX focus area

Outcome: Some discussion around using whiteboard tags to keep track, but has been abused in the past in attempts to associate unrelated bugs with a feature. Easier & more predictable to define a “meta-bug” for the feature (example) and then mark all the relevant bugs as blockers for the meta-bug. A good separation is to split it into “design bugs” & “implementation bugs.”

Goal: Have the meta-bugs with all bugs connected for our projects by the end of the week.

Individual goals & focus areas this week

Jennifer Boriss

Extension manager: more mockups to do and some use cases previously unhandled, start the category association Mechanical Turk study to help determine what (if?) categories will be useful. Starting a week-long sprint for find on page — Paul O’Shannessy is willing to take up the development gauntlet but wants an outline.

Alex Faaborg

First draft of the Firefox menu & full Weave UI, possibly reorganize list of dialogs to kill for the Doorhanger Notification project.

Stephen Horlander

File more bugs, coordinate with Dão/Gavin on resourcing, designs for download panel.

Alexander Limi

Publish Download Manager Improvements article to site — guest starring Mr. Stephen Horlander. Get Resource Packages resourced (hah!) & post to dev.app.firefox about it. Get the results of the Test Pilot study on menu item & keyboard shortcut frequencies, if possible. File meta-bugs to keep track of all remaining projects.

This week’s activities design sessions

The current week is mostly about getting a lot of administrative stuff in shape in addition to the design work we do individually, so there’s only one UX-related session reserved this week:

• Wednesday: Kept open for a general design session, should we need one. Nothing scheduled yet.

---

Let us know what you think of this new format. Anything missing? Anything that you think is redundant? Send an email to limi@mozilla.com with your feedback.

Theme Bugs Filed This Week

Note: I haven’t filed any Linux bugs yet and the Wiki page is out-of-date. Still working out some details there and should have that resolved this week.

This week I filed the first round of Bugs for implementing the new theme:

• #544815 – Allow for placing Tabs over the Navigation Bar with option for Tabs under the Navigation Bar
• #544816 – Attach combined Stop/Go/Refresh button to the Location Bar
• #544817 – Create Bookmarks Widget with placement dependent on Bookmarks Bar status
• #544818 – Progress “Line” indicator for background loading tabs
• #544819 – Create a basic Home Tab linking to the current Home Page
• #544823 – [Meta] Theme Visual Refresh
• #544820 – [Windows] Theme Visual Refresh
• #544821 – [OS X] Theme Visual Refresh

This is a pretty exciting step for me after having worked on the design for so many months.

 

Wiki Updates

I also spent some time getting all the mockups and thought processes on the Wiki current:

• Theme and UI Revamp
• Windows Theme Mockups
• Theme/UI Direction and Feedback
• Mac Theme Mockups
• Mac Specific Visual Design

Extension Manager UI Redesign

Status

• Planned for eventual mozilla-central landing – want to get initial parts landed before betas
• Major AMO integration will probably be done as followups
• Have been bringing UI up to speed with changes in mockups
• Started looking at install/updates before realizing it’s not in the API yet

Loose ends

• Boriss was away for the latest meeting, need to catch up
• Waiting on project branch to be setup (bug 542910)

Next steps

• UX discussions! UX discussions! UX discussions!
• Implement helper widgets
• Install/uninstall/update/enable/disable
• Search
• Help with API development

Target for next week

• Catch up with Boriss
• Implement various widgets – download progress, ratings, etc
• Start implementing search (only local, until the API supports AMO searching)

Tab matches in Awesomebar

Status

• Refactored UI for better toolkit/browser separation
• Renamed “open tab” concept to the more generic “open page”
• Must remember that adding a constant doesn’t mean the interface needs a change of UUID
• Waiting on next review, then SR

Loose ends

• None

Next steps

• Land
• Tackle followup bugs

Target for next week

• Landed on mozilla-central

Reflections

• I need to get better at estimating time required for larger projects
• I’m having far too much fun for this to be considered “work”

Related posts:

1. Status update
2. Status update
3. Status update

Started a Firefox project page to track Jetpack and its integration into Firefox. Atul typed up a reboot glossary. Anyone who talks to other human beings about Jetpack going forward should read it. Preview:

Jetpack: Synonym for Cuddlefish. Currently, we prefer using the term “Cuddlefish” to disambiguate it from the Jetpack Prototype, which is a completely different animal.

Began a couple of API proposals for the reboot, context menus and simple persistent storage. Others on the Jetpack team have started proposals also. Met today to discuss and shape what we’ve got so far. Plan: Iterate on them together in the coming weeks.

Talked with Mano and Marco about async bookmark folders, new WIP patch. Mano is working on a new view-related bug that now blocks. Once his is done, should be fairly straightforward to finish.

Nothing major to report. Some of the big projects are in the final stretch, which is great to see.

• Static build: Joel’s in cleanup phase, making sure the mobile tinderboxes build with the changes. Core patch is waiting on first review from Ted.
• Ben’s fastload cache replacement is waiting on first-review from Ben Smedberg.
• Zach has more data on the effect of the CSS parser optimizations he’s been working on.
• Asaf put up an experimental patch for making the bookmarks toolbar all JS, no XBL.

Related work I did this week:

• Started updating the Performance Snapshot. Fixing a couple of bugs and making the percentages relative to the 3.6 branch.
• Spent some time poking at the graph server. It’s got serious performance problems, and is lacking a few features that’d make it immensely useful, instead of only somewhat useful. It just needs a little love, that’s all.
• Landed bug 506471, moving FUEL out of the startup path.

I’m going to give weekly blog status updates a shot. I suspect planet already gets inundated with them near the end of the week, so maybe I’ll try adjusting my schedule by a few days. Or maybe I’ll end up just posting them on wikimo instead. Either way I’ll try to keep them interesting!

I didn’t think I was going to end up doing this, so I didn’t take detailed notes of everything I’ve done this week. I’m going to try to get better at that.

Accomplished this week:

• tried to keep the review queue cleanup rolling from last week, but I think I netted out even (or slightly negative). Current state: 33 pending requests.
• reviewed dolske’s plugin crashing UI patches (bug 539848, bug 538910)
• helped test the 1.9.3 alpha 1 branding changes (bug 543564)
• wrote some additional tests for bug 512784 (consolidated smart getters for common services). ready to land once it gets rs=Mossop
• spent some time reviewing patch for bug 480350 (tab matches in awesomebar)
• wasted a bit of time arguing with RSnake on his blog

Up next (roughly in priority order):

• shorlander’s going to be filing bugs for proposed theme/UX changes, will need to triage/prioritize those with dao
• need to make progress on browser.js cleanup/simplification – I want to get a list of actionable items by mid-next-week and get patching
• I have some mobile blog post ideas and notes that I really need to turn into posts
• try not to give up too much ground on review queue clearing
• want speak to Ryan about some changes required for bug 511017 (allow default search plugins to be updated, allowing them to get locale-specific search URLs to avoid redirects through google.com)
• would like to resolve bug 479334 (improved en-US spellcheck dictionary, including better merge scripts to ease taking changes from upstream hunspell and chromium). just needs a final test run and a couple of tweaks before landing, I think.

Ideally I think my “upcoming” tasks would be as granular and clearly defined as my “completed” tasks, I guess, but they’ll probably be easier to split out into specific tasks once some of the planning/exploratory work is done.

One common thread running through the many different and interesting WebGL projects out there is that they all need to do vector and matrix math, do it quickly, and do it in JavaScript.  To date, developers have either rolled their own, or they've used Sylvester, a fairly featureful vector and matrix JavaScript library.

One of the problems with Sylvester is that while it's fully featured (arbitrary NxN matrices and vectors can be created and manipulated), it suffers in performance because of it.  Since this is such a crucial part of a successful WebGL program, I've put together a small package that I'm calling mjs.

mjs is designed around speed and simplicity.  For example, it doesn't attempt to stuff vectors and matrices into JavaScript objects.  Because the language offers no operator overloading, there's very little benefit in treating these types as discrete objects, and lots of performance and memory usage downsides.  Instead, it provides a set of functions for performing operations on vectors and matrices, which can be any array-like object.  For any function that returns a vector or matrix, an existing array can be passed in to take the result, or the function can create a new one.  Array reuse ends up being important because of the potential for expensive garbage collection churn eating away at performance.

Here's a sample of the API:

var r = M4x4.rotate(Math.PI/2, V3.$(0, 1, 0),  M4x4.I);

Note that V3.$ and M4x4.$ are shorthand for creating a new V3 or M4x4 (I wanted to use V3() and M4x4(), but that didn't work out too well since functions have a length property).  However, because all they return are just new array-like objects, you could also write:

var r = M4x4.rotate(Math.PI/2, [0, 1, 0], M4x4.I);

If the WebGL types are available, those will be used for newly created vectors/matrices.  They are a significant performance boost especially for repeated operations; but for specifying one-off vectors such as the above, literal array syntax is fine.

The rotate function internally makes a rotation matrix, and then multiplies it by the given matrix.  So the above could also be written as:

var rotation = M4x4.makeRotate(Math.PI/2, [0, 1, 0]);
var r = M4x4.mul(M4x4.I, rotation);

(The last line being redundant given that we're multiplying by the identity matrix.)

All methods that return a vector or matrix take an optional final argument, that of an existing object to reuse.  For example:

var m0 = M4x4.$();
r = M4x4.mul(someMatrixA, someMatrixB, m0);
// r == m0, so the assignment isn't necessary, but it's handy for chaining
// .... do something with r ...
r = M4x4.mul(someMatrixB, someMatrixC, m0);
// r == m0 still
// ... do something else with new results ...

Without allocating any additional temporary objects.

As mentioned before, one of the goals of mjs is performance.  Matrix multiplication is one of the most common tasks, so here are some numbers comparing mjs, Sylvester, and native C code.  This was run on a Core i7 desktop using a local build of Spidermonkey, which included one patch that's about to go into the tree that fixes the no-reuse tracing case.  (Without it, the no-reuse tracing case is much larger because it's never actually jitted.) The test is simple: it multiplies two matrices together in a loop 1,000,000 times.

Test	Time
mjs, JIT, matrix reuse	140ms
mjs, JIT, no reuse	533ms
Sylvester, JIT, no reuse	5,280ms
mjs, no JIT, matrix reuse	25,833ms
mjs, no JIT, no reuse	26,681ms
Sylvester, no JIT, no reuse	41,996ms
Native C++, SSE2, matrix reuse	71ms
Native C++, SSE2, no reuse	142ms

(I also have numbers for MSVC without the SSE2 compile flag, but the numbers vary greatly depending on whether the values eventually go to infinity or not; if the values end up trending towards 0, the non-SSE2 code tends to win at around 52ms vs. 71ms; if the values trend to infinity, the non-SSE2 code takes around 11,000ms!)

Those numbers are pretty encouraging -- having native code be only 2x as slow for something like this is pretty nice to see. Granted, this is only a very isolated test, and I'm sure there are some tricks to optimizing the native code case (it's currently just a fully unrolled set of multiplies and adds). The "no JIT" case is less nice, but I'm sure that our Jaegermonkey folks will be all over this testcase (right, guys?). In any case, ideally most WebGL rendering loops will be fully traced in Firefox, so it would be less of an issue.

mjs is still very much a work in progress; it's missing a test suite and a whole bunch of features. You can find it hosted at Google Code, at webgl-mjs. (Side note: I couldn't just call the project mjs because a project called mjs was abandoned on Sourceforget 5 years ago, and Google Code complained.) There's also some documentation, viewable online here.

Bugs and contributions welcome!

Bugzilla is the devil we know. It’s more complicated than we’d like it to be (albeit mostly by our own hand), it’s pretty intimidating to new users (though I recognize the efforts to improve that), and adding the features we want can be a slog (I’m looking at you, multi-state flags).

It’s also essential to the way we manage our project at scale, though, and enough of our project’s history and daily activity lives there that understanding it is not really optional. Certain edge cases aside, you can’t really be effective in the Mozilla project without at least a passing ability to wade through Bugzilla.

I put together this video to help people who don’t really live in Bugzilla learn how to at least manage themselves. If you’re inclined to thank me for it, thank Deb and Dan instead – they’re the ones that actually made me sit down and finish the job.

Until wordpress stops eating my video tags, you can get the open-web, flash-free, unencumbered-codec goodness here.

If you’re using a browser that doesn’t understand ogg, I’ve put a copy on Vimeo as well:

<object height="375" width="600"><param name="allowfullscreen" value="true"><param name="allowscriptaccess" value="always"><param name="movie" value="http://vimeo.com/moogaloop.swf?clip_id=9205730&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1"><embed allowfullscreen="true" allowscriptaccess="always" height="375" src="http://vimeo.com/moogaloop.swf?clip_id=9205730&amp;server=vimeo.com&amp;show_title=1&amp;show_byline=1&amp;show_portrait=0&amp;color=00ADEF&amp;fullscreen=1" type="application/x-shockwave-flash" width="600"></embed></object>

Firefox’s tab strip is necessary, I think, but its usefulness degrades when you open lots of tabs. In those cases I usually tap the tabs menu, which sits quietly at the end of the strip. The menu works well with a moderate number of tabs, but I often open enough to actually force it to scroll. It’s annoying to have to frequently mouse to its bottom.

So I wrote an extension that sorts the tabs menu in most recently used (MRU) order. Like, if you select tab A, then B, and then C, the tabs menu will show C, B, and A, in that order. Tabs that you often use rise to the top, those that you don’t sink to the bottom. (Like how Ctrl- or Cmd-Tab works for applications in your OS. Dão implemented something similar for tabs in Firefox.)

After using it for a week, I’ve found that the new menu is nice when I forget what I’m doing and need a reminder: The top tabs tell me. It’s also nice when switching to a different task: I know its tabs aren’t at top. But I’m still occasionally surprised when I open the menu and see an ordering different from the tab strip’s. That happens mostly when all tabs are visible in the strip. And the use case I hypothesized would be best served by an MRU menu—selecting one tab when many aren’t visible—sometimes isn’t. The tabs related to a single task usually end up clumped together, so using the strip or key shortcuts is better.

I tried to be smart about performance. You don’t pay for MRU when you open or select tabs. You pay when you open the menu, and then it’s O(n log n), n = number of open tabs. (You were already paying O(n) for the standard, non-MRU menu.) It’s easy to imagine other approaches with different time-space trade-offs.

I’ve been working on Jetpack. Different people have different ideas of what Jetpack is supposed to be, but one of its early goals was to make extension development simpler than it is now. It took me an evening and 250 lines to write this. The menupopup is an XBL binding, so all I had to do was write a replacement and hook it up with a single CSS rule. A reminder that traditional extensions can be both powerful and simple to make, if only for a certain group of people.

• Install
• Source

(You are encouraged to read this article with its formatting and typography intact, instead of in this RSS reader)

Now that Firefox 3.6 has shipped — yay! — we thought we’d try to make some improvements to how the UX team here at Firefox communicates with the outside world. Instead of only posting individual after-the-fact updates, we thought we’ll try to post more about what we’re about to do — which is usually a bit more interesting and higher-level, as well as gives you the chance to engage with us while we’re “in-process”. It will hopefully also give you a bit more insight into how we do our work.

Every Monday, we have a meeting to start the week and look at what we’re working on for the rest of the week, and we thought it’d be a good idea to share that here on a regular basis.

Last week, we narrowed down the priorities for the next release of Firefox — which may be a 3.7, may be a 4.0 — in this document: UX priorities for 3.7, main points reproduced below:

• New Theme for Windows, OS X, Linux (Horlander + everyone) — includes:
  • Site identity improvements
  • URL bar improvements
  • Tabs on top/bottom capabilities
  • App menu and general menu cleanup
  • Toolbar cleanup (ie. combined stop/reload/go buttons)
  • Site-centric prefs (zoom level, geolocation permissions, other)
  • Personas testing
  • Better animation and affordances, especially when dragging tabs (drag, detach, close)
  • Improved progress bar
  • Recently closed tabs in the tabs menu
• Home Tab and App Tabs (Faaborg/Limi) — the simplest thing that can work, probably just a browser-hosted search page for the home tab for now, as well as basic support for app tabs.
• Notifications (Faaborg) — includes web app notifications from app tabs and elimination of unnecessary notifications and dialogs in the current interface.
• Extension manager redesign (Boriss) — the first part of the larger Prefs redesign, exploring content-hosted preferences and a simpler setup.
• Download Manager + MIME type improvements (Limi) — includes better defaults for common file types, cleaning up the Applications pref panel, better file type indicators, binary content (PDF, MP3, video, Office) in-browser display + cursor indicator.

• Resource Packages (Vlad/Limi until we have resourcing sorted out here) — This should be pretty straightforward, and Limi will provide numbers and pretty graphs as part of testing & evangelism. Chrome has expressed interest, I think we can get Opera on board too, once we have some real-world numbers.
• Mac installer improvements (Taras, Joel? + Limi on UI & dialogs) — includes compression-on-install for Snow Leopard, autodetecting that you're starting FF from outside of the Applications folder, etc.

Less eligible for backport, but a useful thing we can land:

• Tab matching in AwesomeBar + retiring the old URL dialog (limi)

Depending on release scope and duration, we might look at these, in unprioritized order:

• Prefs cleanup to match what we do with Extension Manager, site-centric cookies/geolocation/passwords etc.
• More capable Home tab
• Improve toolbar customization UI
• Places improvements
• Improving the "major update dialog" (faaborg)
• Turn off unneeded system level notifications (growl, toast) users don't need real time updates about updates (faaborg)
• Session restore improvements (limi, faaborg)
• Reduce UI and amount of menus (everyone)
• Zoom indicator (limi)
• Recently closed tabs in tabs pulldown + deemphasize (remove?) visible tabs (limi)
• Greater control of plugins (Always load / on click / never) (limi)
• Theme change for private browsing mode

Individual focus areas this week

Jennifer Boriss

Extension Manager improvements, usability testing with Limi/Jinghua.

Alexander Limi

Download manager improvements, usability testing, Labs UX interview candidate.

Stephen Horlander

Getting Wiki completely updated and filing Theme bugs, generate design ideas for the last remaining elements (download pane, progress bar, etc.)

Alex Faaborg

Filing platform bugs for the theme, exploratory home tab work, new notifications.

This week’s activities and design sessions

The current week has the following UX-related activities:

• Monday: Design session on Boriss’ new Extension Manager UI, and where it fits in the future Prefs redesign
• Tuesday: Design session on the Download Manager, Limi will present the current work, and we will refine and see if there are other things that need to be improved.
• Wednesday: Usability testing of three key concepts that should inform our future direction around the URL bar improvements:
• Combined search and URL bar.
• Action-like functionality in the URL bar.
• Inline search results that are in the URL bar results instead of in the content area.
• Friday: Limi interviews Labs UX candidate.

Let us know what you think of this new format — this first attempt is a bit more verbose because of the list of priorities, future updates should be more succinct. Anything missing? Anything that you think is redundant? Send an email to limi@mozilla.com with your feedback.

This update will ideally be posted every Monday, but got delayed one day due to the dangers of testing alpha release software on my server. But it was totally worth it! Shiny new Plone! —Limi

It's been a while since I posted a progress update (or really any blog post, ahem), but porting Firefox/Fennec to Android is progressing at a good clip. After working out a few kinks (and setting the all-important "you're allowed to touch the network" permission), I just got our first page load:

Mouse events sort of work, toplevel windows sort of work, keyboard doesn't work yet but shouldn't be hard to hook up.  This is running in an emulator at the moment for ease of debugging, but it's working just fine on physical hardware as well.

You'll note that this is the full Firefox interface, and not the Fennec/Firefox Mobile UI; we're testing with the full interface because it's significantly more complex than the mobile UI and stresses Gecko much more.  So, if the full UI works, then Fennec should work fine as well.  Given the interest in Android on netbook and tablet devices, an updated version of the full Firefox UI might find a home on some of these.  Android has been pretty great to work with so far; it's a bit unusual platform for us due to its Java core, but with the NDK we're able to bridge things together without many problems.

We're still a ways  to go before any kind of usable alpha release, but we're certainly one step closer.  We'll also be able to accelerate our progress now that we have some of the basic scaffolding in place.  I know I'm looking forward to running Fennec on my Droid, and there are tons of Android devices coming out that should be great platforms for Fennec.

Progress:

---

• Patch almost ready for review – Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All]. The changes are backward and forward compatible which should minimize releng’s pain when implementing this on AUS. This is the app update work to support Bug 538331 [Firefox] – On update perform action based upon the update meta-data [All] as well as general cleanup of overridden attributes in the update xml.
• Landed Bug 536547 [Toolkit] – 3.5.6 is downloading the same version for an update [Windows]. This prevents resuming the download for an update with the same app version with the same build id.
• Landed Bug 540356 [Toolkit] – Enforce a sane minimum interval for app.update.timer [All]. There have been several bugs filed over the years due to using extremely low values for this timer along with the app update timer interval during release testing and this is the first of a couple of fixes to prevent this from happening in the future.
• Landed Bug 543312 [Toolkit] – Remove the dependency on nsTryToClose.js from app update’s ui [All].
• Landed Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]. This has caused several bug reports over the years during release testing.
• Met with Ken Kovash to define new app update metrics for Firefox Lorentz.
• Rewrote Software Update:Manually Installing a MAR file.

Future targets:

---

• Land Bug 530872 [Toolkit] – app.update.url params / update.xml cleanup and addition of a custom string property for apps [All] and ddahl should have Bug 538331 [Firefox] – On update perform action based upon the update meta-data [All] landed as well. The remainder of the work to enable this will be done on AUS and I’ll get an ETA for this from nthomas during the week.

• Write mochitests for Bug 538533 [Toolkit] – If a complete update fails the update prompt should state the error and offer a link to download the update [All]
• Start coding for the new app update metrics for Firefox Lorentz

No progress at all. Another week closer to being dead.

• Async bookmark folders
• Jetpack reboot

No big changes from last week, so I’m not going to knock you over the head with the big table, but here are some notes on the progress of some of the projects and areas of research:

• Joel has patch in Ted’s review queue for the static build changes. He’s also working on getting Windows builds un-broken, with help from Ben Smedberg and Brad Lassey.
• Rob Campbell enabled PGO on the Mac, and found no detectable difference in performance. I built PGO on Linux, and found the same. It could be that there’s no improvement to be had. It could be that our profile-generation approach doesn’t target the codepaths that our performance tests measure. Not sure yet!
• I talked with Rob Stong about the fast-startup component, and he brought up a bunch of problems with enabling it in multi-user environments. I’m pretty convinced that there’s no way we can ship with it enabled. And I’m still convinced that it should be exposed as an option to users. I did get it actually working on Windows 7, and as expected, first startup post boot was 60% faster. The scary part is that it took 40% of startup to do the rest…
• I researched code locality options for Linux, and haven’t yet found a way to specify a function order like you’re able to on Darwin. Joel’s been spending some time looking into this on Mac, but gprof is broken on Snow Leopard – instrumented builds just hang. Boo.
• Joel talked with some Apple developers on the Darwin list and got some more information about compressing with HFS+. They thought it was pretty hacky, recommended improving code locality instead (See previous comment about gprof being broken. *sigh*). Compressing locally does break our code-signed builds, so might not be feasible anyways. Next is to look into compressing on the release side.

And so it came to pass, after months of watching and opining and speculating, that in mid-December we got the letter from Microsoft’s attorneys. The European Commission had adopted a decision settling its current tying case with Microsoft. Among other things, this decision introduced a mandatory browser choice screen for Microsoft Windows users. Would we like to participate?

(Yes, we would.)

Our deliverables had to be submitted by January 15. Others in our (amazing, amazing) community did all the real work, but since I was asked to pick up the coordination and delivery of those pieces, I wanted to talk about them a little.

In broad strokes, Microsoft asked us for 3 things:

1. An icon for the choice screen itself
2. Localized content for each supported locale
3. Administrative pieces that aren’t really interesting here.

First things first, then.

Icon

Among the many things for which I take no credit, I take no credit for this. Patrick Finch and Jennifer Boriss worked the logo question up and down. There was market research in more than a dozen countries, there were mechanical turks, and a great deal of analysis from all quarters. Taking the research as a whole, this design led the others by a healthy margin. It beat other background colours*, it beat other styles, and it beat versions that omitted the word “mozilla” to focus harder on the product brand. Design decisions tend to be very personal, but Patrick and Boriss ran this thing like champs, and by the numbers.

[*Curiously, in Italy a version with an orange background did significantly better than the green. We asked if we could provide an icon per locale. No such luck.]

Localized Content

We were also asked to supply a 140-character* product description in each of 23 languages, specifically:

Bulgarian, Croatian, Czech, Danish, Dutch, English, Estonian, Finnish, French, German, Greek, Hungarian, Italian, Latvian, Lithuanian, Norwegian (Bokmal), Polish, Portuguese, Romanian, Slovak, Slovenian, Spanish, Swedish

In what is fast becoming a pattern, I can take no credit for making this happen, either. Patrick (always Patrick) worked with Staś, Seth, and our amazing localizers, and collectively they got it done.

Got it overdone, really. Our team noted that while the EU has 23 “working” languages (and two more that are official EEA languages), we were quite capable of providing several more as well. They also pointed out that there were some surprises in the list supplied – it was similar, but not identical, to the EU working languages list. Maltese and Gaelic had been dropped, Croatian and Norwegian had been added. We offered to supply the missing ones, along with some others, but we heard back that, no, the choice screen will be limited to those 23. You can see our complete submission, here.

[*No, I do not believe that this limit was introduced in order to make them more tweetable. Tip o' the hat to old Friedhelm though.]

Next Steps

Content! We have a little more than a month before the Browser Choice page goes live, and that means the localization and web dev teams (and Patrick…) are pushing to get everything ready for our new visitors. While we get that together, Microsoft will be running QA on the page itself in all 23 languages. We don’t get to QA the pages ourselves, but they have been responsive throughout this process; I trust that any issues they discover with our content will be brought to our attention quickly.

We did confirm that users in locales outside of the 23 requested will be shown the en-GB version of the Browser Choice page, which may give us the ability to wire up the Tell Me More and Download links with additional locale smarts if we want to provide extra information for those users.

So there you have it. We got the first pass done on a tight schedule, and we’ll get the rest in on time, too. At the end of the day, though, I think Mitchell put it best:

While the ballot mechanism represented by the choice screen has received the most attention, Mozilla is most pleased with the core principles Microsoft will be adopting that protect the choices a person has already made. These principles won’t be obvious to a person using Windows. That’s the point — once a person has chosen an alternative browser, IE should not keep reappearing. These principles are expressed in several components of the commitments and together should result in a greater respect for individual human decisions.

In addition to the UI and appearance changes we have been exploring for Firefox, we have also been exploring how to better improve the user experience through animation.

One area that animation would be very beneficial is with tab interactions. Specifically moving/arranging tabs on the tab strip, closing/opening tabs and tearing off tabs into new windows. Presently the feedback here isn’t as good or as elegant as it could be.

 

New Tab Animation

Some of the goals for animation are to make browsing feel faster, adding visual affordances that makes tasks more understandable and to make the browser more visually appealing. There is much more detail on the Wiki articles linked above. My goal was to quickly demo how this would actually look and feel because still images and wireframes can only convey so much.

Click the image below for the animation that shows how a new tab animation could look. It’s pretty short and fast.

 

It is hard to tell from the video how this would work frame by frame. The general idea is that after you click the new tab button that button itself grows into the new tab.

 

Tab Tear Off

This demo shows both tab rearrangement and tab tear-off.