Mike Connor wrote:
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.
Since I spend most of my online time in front of a netbook, saving screen real estate has become a lot more important to me. Gaining or losing 50px vertically has immediate implications on the usability of a number of websites that I frequent. In this regard, Firefox with its default configuration isn’t quite the product that I need it to be. At the same time, the default configuration makes sense to me, as I regularly use most of what it provides. So this isn’t just about cruft removal. I want the whole package for half the price.
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.
Firefox 4 mockup, published yesterday:
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.
If you happen to have written an extension that deals with the new lightweight theming feature in Firefox 3.6, please note that the lightweight-theme-changed notification will no longer be used for previews and actual selections, but only for the latter. If you want the old behavior, you should observe lightweight-theme-styling-update instead. This change will be included in the upcoming release candidate.
This is a central feature that HTML5 videos in Firefox lacked compared to flash videos. What we’ve implemented now is a start and still rough around the edges: the only UI to get into full-screen mode is a context menu item, switching to full-screen playback isn’t as seamless as it should be, the controls haven’t been optimized for that mode, and upscaling isn’t accelerated. Nevertheless, it works.
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.
The throbber as you know it from Firefox 3.5 and before does a decent job of indicating activity, but it doesn’t tell you how much progress has been made. A background tab may already have 90 per cent of its resources and be usable, or it may have stagnated at 20 per cent. The new pie-chart throbber addresses this by
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!
If you’re using a recent Firefox nightly, your browser is now capable of installing lightweight themes from Web pages — except that you probably don’t know a single site that offers lightweight themes.
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.
Starting with the very latest nightly, lightweight themes can be applied to XUL windows.
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.
For real this time! I just landed John Morkel’s patch for bug 465673 on mozilla-central. If all goes well, it will be in tomorrow’s nightly.
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.
Apart from the add-ons manager integration, I’ve recently identified three more implementation parts that need to be tackled for the upcoming lightweight theme feature, which will be based on Personas: