The Inside Track on Firefox Development.

« February 2005 | Main | May 2005 »

March 28, 2005

Welcome Brian!

I want to use this opportunity to welcome Brian Ryner to Google!

Brian has been one of the most crucial elements to the success of Mozilla software over the past few years, with his work all over the Mozilla code - I remember him first adding mousewheel support back in 2000, then moving with tenacity into many other areas of code. Over the past few years Brian has been invaluable to Gecko development, working on many areas that have resulted in performance improvements and new features, while also having time to work on application level features such as the Linux installer, GNOME integration and the password manager. Great to have you on board!

Posted by ben at 9:57 PM

March 23, 2005

Extension Manager Changes

I've been making a large number of changes to Firefox's Extension Manager over the past week or so, basically rewriting the way Extensions are installed. These changes when complete will offer a lot of improvements for Extension developers. Here's a quick summary of what I'm doing:

• Currently you can only install Extensions and Themes into the extensions\ directory under bin\ and profile\, and the assumption that these are the only two Install Locations is made across the Extension Manager. My changes replace this boolean setting with configurable Install Locations. It will be possible to register additional Install Locations with the Category Manager for discovery by the Extension Manager. This means it will be possible to create special kinds of Install Locations that suit the needs of your XULRunner application, e.g. an Install Location object that represents a Windows Registry key with GUID to path mappings instead of the traditional containment relationship.
• You will be able to install extensions by simply dropping their XPIs into containment relationship Install Locations (e.g. drop foo.xpi into profile\extensions and have it be installed automatically on next start) - this should be a boon for quick setup.
• You will be able to install and uninstall Extensions by simply adding and removing their GUID folders from the Install Locations - if you add/remove an entry, the Extension system will notice the discrepancy on the next start and configure/remove the item.
• You will be able to "point" to extensions which you are hosting elsewhere using a cross platform text format which is basically a text file with a GUID name in the extensions directory with a path to the directory where the Extension actually lives (e.g. elsewhere on a NFS home dir)
• The system will be more robust about upgrades, file removal, etc, and the API a little saner.

At some point it would be nice to abandon the per-type roots in the RDF graph, and the RDF XML text storage format itself, but my patch is already over 300K and I don't want to tempt fate.

Posted by ben at 12:16 AM

March 13, 2005

Navigation Systems

Since this is more widely read than my other blog (which I almost never post to anyway), and since this is still tech related, here's a new piece on automotive Navigation systems.

Most Needed Features of Car Navigation Systems

I have a 2004 Infiniti G35 Coupe, with the factory Navigation System. It has a number of features that make it pretty good compared to some of the competition, especially the rare and generally abyssimal systems used in German cars. I like the large, well positioned screen, the 3D/Perspective "BirdView", the variety of colors. But that's about where my praise ends. It's a pain to program, you can't program it while you're driving, the system updates slowly, yadda yadda.

Recently, I test drove Infiniti's new midsize luxury sport sedan, the M45. The M45 has a vastly improved Navigation system, which may now be the best in the industry. Not a lot of attention is given to the system when the car is marketed, so it may be one of the best kept secrets on a phenomenal automobile.

What follows is a list of things I think are pretty important for car Navigation:

Large, well placed screen

Pretty much everyone fails here, except Infiniti, Volvo, and maybe a few others I'm forgetting. If you have to look down and into the console to see the nav screen as you're driving, you have lost. Generally, the further the driver has to take his or her eyes away from the road, the higher the risk of accident becomes. If the thing diverting the attention of the driver is complex - a set of instructions, arrows, radio controls, a cell phone etc - then the risk is increased. It should be obvious that the closer the command center screen is placed to the area the driver is looking usually, the safer and easier its use will be.

Given that the screen can't be placed over the field of view, and that the main gauge pack generally resides just below where the driver is looking, down and to the right seems best - and that's where Infiniti and Volvo have been placing them. Infiniti took this a little further with the Fuga concept, placing the "next direction" icon in a LCD in the middle of the steering wheel. Sadly this did not make it to production, but the clever split screen mode on the nav system seems to take care of this.

An accessible interface

Generally, joystick controllers aren't the best sort of interface to use, especially while the vehicle is moving. It's for this reason that Infiniti disables most functions on the nav unit in the G35s while the vehicle is in motion. The G35's main input device is a 8 direction joystick which also acts as an "Enter" button when pressed in. When combined with the fact that the car's console stack was designed for the Japanese market and so the stick is on the other side, it is a real PITA to use. Nissan seems to have learned this lesson and has compromised on putting the joystick in the center of the console for all its new models. The other problem with the multifunction stick is that pushing it directly in to activate the commonly used "Enter" command since the stick has a tendency to rock in a direction... it's especially difficult to press in on the button directly when you're in a US car with the stick on the wrong side of the console.

The M45 improves this situation in a number of ways:

• the control interface is now in the center of the console stack (especially important as the car is much wider than the G35) the enter key is a discrete button in the center of the control stack
• the back button is better labeled (with the familiar back arrow from web browsers!)
• the car features a jog dial for simplified and smoother navigation through menu items
• up/down and enter functionality is duplicated on the steering wheel via a scroll switch!
• a comprehensive voice command interface is included.

The M45's voice recognition isn't quite artificially intelligent, you still need to feed it information in a structured way, but it's recognition is generally very good and it affords one important feature I have not seen on any other car:

• You can enter an arbitrary address into the system while the vehicle is in motion.

Basically, you push the voice button and then say something like "Destination" / "California" / "Mountain View" / "Amphitheatre Parkway" / "Sixteen Hundred"

I've looked at other voice controlled systems from other manufacturers such as Lexus and Honda, and all of them limit what you can speak to the system to invoking specific commands or addressbook entries. Now tell me, what's the common case? That you want the system to take you somewhere you know, or to take you somewhere completely new? My experience is that it's always pretty much somewhere I've never been before.

The M45 does not offer a touch screen interface as the Lexus GS430 does - firstly because its high, visible placement puts it out of reach of the driver's hands (probably for the best - saves it from getting fingerprints) - secondly because it's not really necessary: the other input mediums are so good.

A flexible Search interface

The nav system knows exactly where you are. It should be able to do a much better job than it does in the G35 of locating things around you. If you're looking for a business, you're going to be using the Point of Interest function(*)... in the G35 unless your POI fits a predefined category, there is no way to find matching entries nearby. E.g. if instead of going through the theatrics of searching for Fast Food and then having it show nearby McDonalds, you just want to say Business: McDonalds (this involves fewer menus, fewer clicks and is thus better from a usability point of view), the system should scan its database and show you N results starting at the closest to where you are right now. N is some arbitrary number of results - significantly less than the total number in the State, which is what you get right now in the G35 if you don't manually enter the city you're searching within.

(* badly named, since you're hardly ever looking for a Point of Interest, most often a Business - it should be called "Business/POI" "Business/Location" or something that better emphasizes that).

... which leads me to my next point. As I said, the car knows where you are. So please, please, prefill not only State but City for POI searches! When you're looking for something without a specific address in mind, you're generally looking for something Nearby.

Optimize Also for Area Familiarity

Most nav systems UE design today is focused on providing a solution for users who are completely out of their element in the area they're in right now, and want to give up everything and let the nav system tell them how to get to their destination.

This does not really help the case when the user is somewhat familiar with the lay of the land, and is in the midst of a complex environment, such as the SF Bay Area where there is a myriad of Freeway choices. Depending on the time of day, the standard shortest distance/shortest time choice may actually be by far the worst.

Consider this example:

- I am headed to an event in San Francisco. I have the address of the venue but don't know exactly where it is. I am familiar with the SF Bay Area though, and its freeway system. I am between Menlo Park and Redwood City, roughly midway up the Peninsula. I am on a surface street. I am not familiar with this area. It is rush hour. I would like to get to the city, and then to my destination itself. If I stop and program my G35 nav it will want to take me to US101, which is a disaster at this time of day. What I want to do is get to I280. The problem is I don't know where the nearest entrance ramp is onto I280. I know of one further up in Redwood City off Woodside Road, but maybe this isn't the nearest to me. Since the nav system only lets me enter an intersection, I'm sort of out of luck.

What I want to do is say "Take me to I280" with I280 as the destination. The system should find the nearest intersection to 280 and direct me there. Once I reach that point I can read the final address to the system. This is a system optimized for someone with basic familiarity of the area.

Responsive UI

My testing with the GS430 showed there to be a slight but perceptible lag between pressing a hard or soft button and a response from the system. In particular the touch screen seemed set up to take slow, deliberate presses. I'm a software engineer. My fingers move lightly and quickly, and I expect the system to keep up. If your navigation system is going to employ a touch interface, make it (best case) adaptive or (worst case) user adjustable. Lag from hard buttons is inexcusable.

The G35's search UI had an awful habit of locking up for extended periods while it was loading the results list. This is also frustrating... the result you want should be in the first few entries depending on your search and the quality of the search engine - so having to wait as all of the fast food restaurants in California are loaded into a list is annoying.

No arbitrary limits

The G35 has a number of very arbitrary limits in its software design, some of which can be exceptionally frustrating. To wit:

• The size of the address book is limited. This forces the user to have to worry about what things are important enough to go into the address book.
• The search history is limited
• I'm pretty sure the Avoid Areas function is limited in this respect too, but I can't recall since I've never actually used it.

Don't force the user to program anything

Users hate pre-programming things. That's why programming the system via voice while on the road is such a huge, huge deal. Making the user get out of their desired workflow (which in the car case is getting somewhere they really want to be) and deal with the inadequacies of your system shows that you have not done a good job. For this reason:

• it should be possible to set and save "Avoid Areas" during the process of entering a destination. For example, when I set my destination to San Francisco, I should be able to at that time tell it not to take me on US101. And then save that in a "Avoid Areas history", so that next time I enter a destination it's there as one of the available options.
• If you look at the way it works in the G35 today (and probably others, even the new M although I have not verified) - when you get the car you need to sit down and think about all the areas you might want to avoid... and then once they're set, they're pretty much in effect, even if US101 is only worth avoiding during rush hours and just fine later at night.

Intelligence

Real time traffic data such as that used by the Acura RL simplify tasks for the user by creating software that does what they want while requiring them to think less. This is a good thing.

In the absence of reliable traffic data, or at least in the presence of other factors, intelligence applied to results sorting for the listing interface is appropriate, e.g. identifying common avoid areas or routes used for specific start and end points, times of day etc, and pushing those up the relevance stack so that the car learns what its operator likes to do, and suggests those items more prominently, or simply does them without prompting.

Work with the User

I have sometimes described in this document several ways to accomplish the same thing - notably the two methods I used to avoid US101 in rush hour: firstly by telling the nav system to take me to an alternate freeway and then feeding it my final destination, and secondly by programming the nav system up front and having a smart Avoid Areas/Intelligence system to have it do the right thing for me. The key thing is to offer a seamless, simple experience to the user that integrates with their desired workflow.

A 3D view

We're used to 2D when viewing maps because well, we're reading maps. Maps are 2D because of the limitation of their medium - paper. The 3D/birdview is the superior view when driving because it more clearly shows you the relationship between streets, objects etc. and the direction that you're driving.

Attractive UI

This is 2005. Infiniti sets a high bar with the M45's brilliant anti-aliased gradient shaded graphics, 3D view, etc. I found the GS430's to be rather pedestrian. We should be able to expect to have at least high quality high-color 2D graphics from today's technology.

Summary

Why do I expect all of this? Because car nav systems are generally priced at $2,000 or higher, they're as costly as a high performance desktop PC - a desktop PC with software that is vastly more complex than nav system software, high performance graphics capabilities and network ability. If $2,000 is only going to get you navigation, it should get you navigation that is excessively usable.

Automotive Navigation is a topic that is of great interest to me, has been ever since I got my G35. I'd like a new M45 Sport (Umbria Grey/Bourbon with Tech-Sirius, Journey Sport, and hey Mobile Entertainment while we're at it - may as well also throw in the aero kit w/spoiler). Sadly while the car is a decent value I still can't quite stretch myself to buying one. I do however think I have a lot to offer when it comes to critiques on these systems, so would gladly take a car fitting the description above in exchange for ongoing analysis, feedback and UI ideas if any Nissan/Infiniti execs happen to be reading ;-) [email me at ben at mozilla dot org!]

Posted by ben at 3:08 AM

March 10, 2005

Firefox Alive and Kicking :-P

There's been some talk lately about the future of Firefox. We believe Firefox has a bright future, and we are all working hard towards our short and long term goals.

First off, we are executing on the Firefox 1.1 Plan. This is an important incremental update to Firefox 1.0 that includes major enhancements to the Gecko platform we are built on, as well as a few application level enhancements.

Secondly, we are developing a plan for Firefox 2.0, which will include many feature enhancements and generally make browsing faster and easier than before. Coupled with the releases on the way to 2.0 will be significant platform enhancements that make it easier for people to build their applications on Gecko.

The way the Firefox browser releases generally go is this - we come up with a loose plan of features we want in a particular release, assign engineers to the various tasks, and go. Firefox releases are generally content driven, not time-cycle driven. When we set a date we try to hit it, but we try to avoid a churn since we know our customers want meaningful updates.

To help spread the load more evenly, I'm pleased to announce that Mike Connor will be taking over management of the downloading front end, Benjamin Smedberg will be assisting with the Extension Manager, and Brian Ryner will be helping Chase, I and others with the client aspects of the Software Update system. If you are interested in helping with these and other areas please let us know - either by helping us plan for the future at the Mozilla Development Wiki or by filing and patching bugs.

This will allow me to spend more time managing the releases: driving bugs, reviewing code and helping people come up to speed. In the coming year I predict I will return to some long neglected areas of Mozilla code - Bookmarks, History, Search, and be pitching in with XULRunner where I can be valuable, as well as continuing to direct UI and product content for Firefox.

Posted by ben at 1:48 PM

©1997-2006 Ben Goodger. All Rights Reserved.
Opinions expressed here are my own, and not those of any organization that I may be affiliated with.
Reload icon is © Stephen Horlander;
Firefox logo is by Jon Hicks, and is a trademark of The Mozilla Foundation.
GetFirefox buttons are from rakaz