The Inside Track on Firefox Development.

« October 2005 | Main | December 2005 »

November 29, 2005

The Wait is Over

Firefox 1.5 is available now, the first major upgrade to Firefox since 1.0 shipped just over a year ago. Firefox 1.5 is the result of the contributions of thousands of volunteers from around the world. 1.5 is a midpoint on our track to our next release 2.0 - which will contain significant improvements to the user interface. The focus in 1.5 has been on developing various underlying sections of the application to provide a better overall user experience. We did not originally intend it to take this long, but you know how software is, and we wanted to get you the best software possible.

Notably,

  • Firefox 1.5 features a year and a half worth of improvements to the Gecko layout engine, including several significant new features: <html:canvas>, Scalable Vector Graphics, a prototype implementation of CSS columns support, key architectural changes to improve security and many performance enhancements. Part of this includes instantaneous back and forward navigation, which makes the 1.5 browser feel signifcantly faster than anything else out there.
  • There are numerous subtle enhancements to the browsing experience, including the ability to reorder tabs, many small UI improvements, more convenient Privacy controls, new Options, more migration options for Mac users, the list goes on and on.
  • Things are a little better for extension developers, with new directory and registry Install Locations that make it easier to developer and deploy extensions.
  • And at last keeping up to date with the latest security patches will be as simple as using the product. Firefox 1.5 checks with Mozilla.org every day to see if there are updates, and downloads and applies security fixes automatically in the background.

I want to express my thanks to everyone who has contributed to this release at all levels - without you, we would not be in this position today.

Draft plans for the content of the 2.0 release are forthcoming. A lot of ideas have been bounced around in various forums. We have many ideas, and the future is bright for web users everywhere. Stay tuned for more information.

-Ben

Posted by ben at 2:24 PM | Comments (30)

November 18, 2005

Improve Firefox. Get Paid.

Are you a Software Engineer who loves Firefox? Want to get paid work on it? Want to work at Google? We now have a requisition for you! We are looking for strong software engineers who want to help contribute to Firefox as part of our collaborative engagement with the Mozilla project. Go here for more information: Software Engineer, Firefox - Mountain View

Posted by ben at 10:15 AM | Comments (7)

November 14, 2005

Extension Development for 1.5

A couple of months back I wrote an article at the Mozilla Developer Center about building extensions for Firefox and Thunderbird 1.5. I realized I hadn't linked to it from here.

A while ago I posted about the changes that had been made to Firefox in the upcoming release to make extension development easier. This tutorial shows how to get a boilerplate extension up and running, usually in less than 5 minutes on most systems.

Posted by ben at 4:13 PM | Comments (6)

November 7, 2005

New Zealand

I grew up in New Zealand. It's a great place, a place that I think about often as I clack away at my keyboard here in Silicon Valley. New Zealand is great not just for its unique collection of astounding natural wonders, but also because people there seem to "get" merging nature with community more than some of the civic planners in say San Jose have. This makes places like Auckland very pleasant to live in. I'm going to go back for Christmas next month for a few weeks, and am really excited.

Webstock Web Conference Wellington NZ May 23-26 2006

I'm also honored to be invited to speak about Firefox at Webstock next year in Wellington alongside these esteemed folk.

I love New Zealand, I look forward to seeing more of it in the next six months!

Posted by ben at 9:02 AM | Comments (23)

November 3, 2005

Improving Tabbed Browsing

A lot of us are fans of tabbed browsing. It's one of the most useful changes in window and document management since the Task Bar on Windows. People who like to work with multiple documents like quick, convenient access to them. It's part of the reason Microsoft moved Office to a SDI model. That said, Firefox is a browser for everybody, and a lot of people don't use a lot of windows. In one of the PDC videos released a month or so back, a Microsoft representative said that they had done studies that showed that users generally had no more than 5 windows open at a time. This surprised them because they, like most of us, were used to browsing with tens of windows. The challenges that face us building the Firefox UI is how to make Tabbed Browsing useful to those who want it, discoverable to those whose lives would be made easier by it, and transparent to those who don't need it.

The first step in this process was to look at what people were used to right now. Most people are still using IE, and the model there, at least until IE7 ships and consumes the IE marketshare numbers, and the model in IE6 is a document-window based one. So, we should look at how windows work, and how tabs work, and see if there are any areas where tabs don't work as well as windows and try and improve those areas, as well as other unrelated improvements.

Here at Google, we did some usability studies on the tabbed browsing feature. Our usability analyst designed a study to see how well people responded to tabs and how easily they were able to switch between them and close them. In these studies, a build of Firefox 1.5b1 was used, with a single configuration change - the new "targeted links open new tabs instead of windows" preference was set, to force users to encounter tabs as they browsed around (rather than having them hear a spiel about the tabbed browsing user interface and have to think to use it, as we're all trained to do by now, this seemed a more natural flow). The results showed that the set of people sampled were generally capable of recognizing the tab strip, and switching between documents. We found though that unpredictable behavior of the back button (new tab = blank session history) is still a problem, since users expect clicking back to go back. What we also found is that the users we sampled were by and large using the context menu to close tabs. Some tried to close the entire browser window first, and most paused before trying the context menu. We also found people were surprised by the z-index used by the virtual stack establed by the tabbed browser. Tabs opened by links with target attributes, when closed, select the adjacent tab, not the tab that opened them. All our subjects used computers fairly frequently as part of their daily work, and seemed familiar with the basic GUI concepts of the environment.

Some of the issues felt by the test subjects echo ones that we have felt personally, but probably moreso since we use tabs pretty heavily. At Google, we are constantly bit by the z-index issue since we use a lot of web apps (like web mail), and links opened from web mail, forums and other such apps generally open things in new windows. When you have targeted links open new windows, when you close the opened window the page you came from is usually the window behind it, so it works out nicely. With tabs, not so much.

So here are a couple of things we have been experimenting with.

  1. Put close buttons on the tabs. This makes it a lot easier to close tabs with the mouse. People weren't seeing the close box in the usability test. It's also out of the way and not connected with what's actually being closed. Mindful of stealing space from the tab strip when there are many tabs, the close boxes on inactive tabs are hidden when the tab width falls below a certain minimum value.
  2. Implement a simple heuristic for z-index handling. When a new tab is opened in the foreground by any operation (targeted link, external application link, Ctrl+T, etc.), set the new tab's "owner" to be the tab that opened it. When the user closes it, select the owner, not the next adjacent. So that the mass-close condition doesn't become annoying (with selection jumping around as many tabs are quickly closed), forget the owner property when the tab is switched away from. This more closely matches behavior of window z-index.
  3. While we're here, consolidate the preferences for links sent from external applications vs. targeted links internally into a single pref: "Open links that would open new windows in tabs" instead, since web applications are becoming more advanced to the point where it seems odd that clicking on a link in Thunderbird should open a link one way, but clicking on a link in GMail should open it a different way.

Here's a screenshot of the tab strip:

Screenshot of new tab strip with close buttons

I used this opportunity to significantly polish the appearance of the tabs in the selected and non-selected state, as well as the focus rings. Also, on MacOS X the close button appears to the left of the favicon, similar to other Mac browsers and Mac windows in general.

We've been testing these changes and they're working really well. I've been producing some test builds. I'll have them linked here shortly. The Windows one is here. There are older Mac and Linux ones in the Tabs experimental directory on ftp.mozilla.org. Try them out and let us know what you think.

Posted by ben at 10:47 AM | Comments (118)