The Inside Track on Firefox Development.

« December 2005 | Main | February 2006 »

January 26, 2006

Another Feed Question

What are the common types RSS and Atom are served up as? Not just the "correct" types but also the common other values, server misconfiguration or not?

Posted by ben at 6:52 PM | Comments (15)

Feed Reader Questions

I have a few questions for users of client side feed readers, since I'm putting together the feed handling system for Firefox2:

1. How do client side feed readers register themselves as the default handler for feeds? Register for various content types? If so, which ones? Use the feed: protocol? Do they do this at all? I want to be able to detect what a user's default is, if there is one.
2. Is there a common repository on Windows that stores a list of all installed feed readers? (Not just the default). I want to be able to populate a list of available choices.

If the answer is "no" to number 1, I'm going to recommend feed readers register at least for the common RSS/Atom types... but obviously not for generic types like text/xml etc that are handled by the web browser. Firefox will detect that you are the handler of one of the more specific types and use that as a key.

Posted by ben at 2:23 PM | Comments (13)

January 22, 2006

Battling Firefox Bloat

This is the first in a series of essays about Firefox design and development.

One of the core goals of Firefox has always been to provide you, to our best approximation, with the browser you need. The way we handle features and configuration follows the following approximate formula:

Feature used by majority of people	Included, on by default
Feature used by significant minority	Feature included, perhaps disabled by default
Internal feature configuration and finetuning	Configurable via about:config
Feature used by minority	Feature not included, use an extension

It is by maintaining Firefox's extension system that we allow people to experiment with new and interesting ideas, or create esoterically useful features. It is not however the role of the core browser to support minority preferences when clear defaults and probable parameter ranges are well understood.

Over the years, Firefox has grown in size, due to an increasing level of polish and number of required features (the Software Update System that shipped with Firefox 1.5 is an excellent example). At the same time it has grown in unfortunate ways. Some necessary systems (like the Software Update System) are too complex, this is in part due to our (read: my) lack of understanding of how the system would work over time from a user perspective. In future releases, we will simplify it. But this is not happening in other parts of the browser.

All too often, code in the core browser has been extended in unnecessary directions in the interest of power user geek-dom. Such changes are usually made as hidden options, configurable through about:config.

about:config is not a back door for old-world style feature and user interface design

But this is what is happening. As engineers, adding hidden "toy" features to the browser under the secret protection of about:config (or other suitably obscure invocation paths) is problematic for at least the following reasons:

• You increase the complexity of all the surrounding code by adding to its bulk, thus increasing the mental bandwidth required by other engineers on understanding what's going on.
• Your feature won't be as well tested since it's not on by default or exposed through the user interface, nor will it likely figure prominently enough to feature on any test plan.
• Even if your feature is documented so that engineers making changes nearby know about it, you increase their testing burden and the difficulty that they have at making more legitimate changes.
• Since it's not likely to be well tested, your feature may be broken by API changes, and when it ships in the product be useless, so that if someone does stumble across it it may (at best in this circumstance) not work, at worst do something destructive.
• You add another site that people changing APIs have to update and maintain.
• You add to the ever-increasing download size of the product. One of Firefox's advantages is its trim size, and every line of code you add, even well-compressed JavaScript robs a small amount of download size. It may not add much to the bottom line - it's more of a principle thing, a way of operating. Playing fast and loose with bloat in one area indicates to others that it is acceptable overall.

Firefox is not a playground where every patch has its day. It is professional software and working on it requires discipline, not just discipline in code quality but also in feature quantity. Look at the list above. It all adds up. The more features you add, even subtly hidden ones, the more fragile the house of cards becomes.

What I'm Doing

I'm being ruthless (did you expect anything less from me? ;-) I'm evaluating all code I touch and figuring out if it can be simplified. Good engineering practice tells us functions should be succinct and well documented. Remove whatever you can. As you do so, the maintainability of the surrounding code will rise implicitly. If you remove a feature (features aren't just big ticket items on PRDs - anything controlled by a pref, no matter how tiny, can be considered a feature), write it up somewhere on the Mozilla Wiki and if you like that function encourage extension developers to build an add on. Or do it yourself.

If you are writing major new features, do make them configurable to test the best possible workflows, but once these become clear, try and simplify them. If you want to add an esoteric backroom workaround to an existing feature stop and think - is this so useful to the world at large that it requires a UI pref? If it's not, then reconsider. You're doing no one favors - especially not the Firefox project and its success at large - by adding more bloat.

Posted by ben at 12:06 AM | Comments (41)

January 18, 2006

Racing Towards 2

It's going to be an exciting year. Not since the run up to Firefox 1.0 have I been so excited about the content of a release. Firefox 2 is going to be great.

I've updated the Firefox 2 Roadmap Page on mozilla.org with some more detail about how we're going to get there, based on Chris Beard's blog about Mozilla Product Strategy. I'll summarize briefly here, and call out some of the important work that's getting done right now.

Firstly, Firefox 2 is based off the same Gecko branch that shipped Firefox 1.5, so they should be compatible from a web developer's point of view. APIs might be added, but none should be changed.

From a development point of view, the idea of Firefox 2 is to deliver significant user experience enhancements on top of a relatively stable rendering engine as significant retooling is done on the main development trunk for what will become Firefox 3, and deliver them in a timely fashion. By being deliberately cautious with our goals for the rendering engine, we hope to avoid long cycles of shake and bake that delayed Firefox 1.5 (which had more substantial Gecko changes than user interface changes).

So, without further ado, some of the most important features from the planning brainstorming page:

New Bookmarks and History

Improve the browser's Bookmarks and History systems to improve their effectiveness as renavigation aids while at the same time improving the back end for speed and extensibility.

Tabbed Browsing Enhancements

Make tabs behave more like windows in the operating system environment, making them behave more as users would expect.

Improved Basic Content Type Handling

For things like RSS/Atom feeds, mail links etc. Improve discovery and handling user interfaces.

Web Search

Improve the discoverability and adaptability of the search UI within Firefox.

Bug Fixing

Bug fixing at all levels where risk is low and yield high, e.g. the blank tab download bug, platform stability, etc.

Some additional things we would like to look at in the Firefox 2 timeframe include:

Visual Uplift

A freshen of the visual design of Firefox while maintaining high levels of system integration.

Inline Spell Check

The rise of applications like web mail, blogging etc highlight the weaknesses of HTML's textarea widget. We should at the very least offer people the ability to spell check their submissions.

Exit Survey

We'd like to know why people leave Firefox. A survey on uninstall would help us find ways to make the software better in future versions.

UI Consolidation and Simplification

Consolidate and simplify user interface in the browser window tying together features in meaningful ways where possible.

There are many other ideas floating around, this is just a brief snapshot of some of the high priority items on our plates. If we get this done, we'll be satisfied!

Posted by ben at 9:45 PM | Comments (172)

©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