The Personas and Jetpack projects were experiments designed to make extending the platform easier, and dramatically reduce the overhead involved in version updates/UI changes. We knew from the beginning that we would have to trade off truly limitless customizations to produce a more stable API/pseudo-API [...]

This is a strategic product decision, intended to grow our developer ecosystem and broaden the scope of potential developers as much as possible, and deliver a much better user experience with customizations across core application updates. Deprecating the old systems in favour of the new systems is a required part of the strategic plan, because it is not enough to simply build a better system, we must migrate our users and our developer ecosystem to that system to reap the benefits.

In this context, I think deprecation includes the intent to remove the thing after a transitioning period. If I got this wrong, please tell me so and stop reading here.

If removing the current system is indeed part of the plan, then I don’t understand the reasoning. The last quoted sentence says that the need to migrate users and developers to a better system implies the need to deprecate the current one. But once a truly better system is widely available, making it easier to write and maintain appealing extensions, then developers will migrate, users will follow. Why wouldn’t they?

This would fail if the new system was actually less attractive (e.g. harder to learn) than the current one, but that would undermine the whole campaign anyway and make a forceful migration unfitting.

It would also fail in cases where the new system lacks capabilities of the current system (it needs to lack some, for it shouldn’t inherit the compatibility issue). Trashing the current system wouldn’t magically migrate extensions depending such capabilities, it would rather trash them as well. Would this be acceptable if 10%, 30%, or 50% of the current extensions were affected, including some of the more popular ones? Are we, and if so, why are we confident that the remainder would be sufficient for maintaining our lead in extensibility rather than pulling us down to Chrome’s level? How would users who already opt out of major updates because of their favorite extension react to this? Would losing them be better than letting them wait for an extension to become compatible?

It seems wise to me to allow a smaller set of dedicated people to create traditional extensions and indeed maintain them over years. Carrying around a minority of these extensions doesn’t mean you couldn’t reap any benefits. You’d still get more developers involved in the new system, you’d still get people to depend on fewer traditional extensions.

In this post, I will describe how I got there:

The menu bar. I use it every day, but not so often that I need to see it all the time. So I just implemented what IE does. Starting with Firefox 3.6, every Windows user will be able to hide the menu bar in Firefox and show it temporarily with the Alt key.

The bookmarks toolbar is my only place for bookmarks. The bookmarks menu hasn’t grown on me, although I’m not sure why. I definitely don’t and won’t use the clunky bookmarks sidebar or the Library to access a particular bookmark. So the toolbar it is. But like the menu bar, I neither need nor want it to occupy space permanently. And as with the menu bar, the solution turned out to be simple. I took the bookmarks button that Firefox provides in the toolbar customization palette and made it show/hide the bookmark toolbar rather than the sidebar. You can get the extension for this here.

The status bar is trickier. I mostly need it for exposing link targets (since the progress bar is redundant). I tried to stop depending on that, but it didn’t work. I need the URLs to be displayed, even if I won’t read them out most of the time. Existing solutions for Firefox show the status bar temporarily or display link targets in the location bar, both of which didn’t feel ideal to me. It took me months to figure this out, but I think Chrome gets this right: It displays the URL in a small panel in a bottom corner of the browser window. This allows me to look there when I need it and ignore it otherwise. Just what I need. So I implemented something similar for Firefox. You can get the extension here.

Opera 10.5 pre-alpha screenshot, published today:

The history of Opera’s user interface isn’t exactly a success story. I wonder whether we should be proud of leading them the right way or afraid of heading the same way as Opera.

To test this, just get the latest branch or trunk nightly and visit an open video source of your choice. I believe the biggest ones are still TinyVid, Wikimedia Commons and The Video Bay. openvideo.dailymotion.com won’t work because it prevents the user from opening a video’s context menu.

1. filling itself up as progress is made and
2. starting to pulse when progress is slow or has stalled, indicating that the browser hasn’t hung up and is waiting for more data.

As a pleasant side effect, the new throbber also eats fewer CPU cycles than the old one.

Grab a nightly, give it a try, report bugs!

I’ve spent some time creating such themes based on my various website styles. Basically I just had to make the header images wider and specify some colors. You can see the result here.

Note that any site can offer lightweight themes. Each theme installation needs to be confirmed by the user, unless the site has been whitelisted to install extensions and themes (via Page Info > Permissions). Whitelisted sites are also allowed to preview themes to the user without selecting them persistently.

If you’d like to create and distribute your own themes, take a look at the source of the simplified example page that I prepared.

Update: getpersonas.com started working with trunk and 1.9.2 branch builds without the Personas add-on.

There’s no UI for installing or managing these themes, but you can still test it. Just open the Error Console and execute this:

Components.utils.import("resource://gre/modules/LightweightThemeManager.jsm"); LightweightThemeManager.currentTheme = {id:"2538",name:"LOLFace",dominantColor:"#6b6b6b",textColor:"white",headerURL:"http://getpersonas.com/static/3/8/2538/LOL.png",footerURL:"http://getpersonas.com/static/3/8/2538/LOL2.png"}

Your Firefox main window should now be styled with an example theme, and this should persist across sessions. To get rid of it again, execute this:

Components.utils.import("resource://gre/modules/LightweightThemeManager.jsm"); LightweightThemeManager.currentTheme = null

The next steps will be to list lightweight themes in the Add-ons manager and to provide a way to install them from the Web.

Read beltzner’s original announcement for a detailed description of this change. That description is still 100% valid, except that this can’t possibly make it into Firefox 3.1 anymore.

1. A service that maintains a list of recently used themes and sends a notification when a new theme is selected (the individual windows and the add-ons manager are expected to listen to this). This should live in toolkit, although I’m not quite sure where exactly. A prototype implementation is in bug 511108, feedback welcome.
2. Front-end code that enables chrome windows to use local as well as remote header and footer images. This should also live in toolkit, but again I’m not sure where exactly. A prototype implementation is in bug 511107, feedback welcome.
3. A way for web content to install lightweight themes. Details in bug 511771, input welcome.