This week has been the Firefox work week where almost all of the team, including me, made our way to Mountain View. This pretty much means that you spend the entire week in meetings since when you’re remote it can be hard to keep in sync on everything. Of course this means that the amount of coding is pretty low for the week so there isn’t a great deal of progress to report here.
Status
This week, Alex and I met to come up with a rough design for what this is going to look like now that we know that the doorhanger notifications we were hoping for aren’t going to make Firefox 3.6.
This is a weekly status update on the feature to notify users about add-ons that third-party installers have added to Firefox. You can read more about it in last weeks blog post or on the project wiki.
Status
There has been little progress this week mostly due to waiting to see whether the doorhanger notifications UI was going to arrive in time for Firefox 3.6. It looks like it isn’t so instead we are discussing using an in-content page to describe the add-ons that have been installed and allowing users to disable them.
Regular readers of my blog will probably spot that this is very similar to an idea I had a couple of months ago. What we’ll probably try to do is integrate both new third-party add-ons and new add-ons installed by the user into the same in-content page. It’s possible that we won’t be able to go the full stretch and allow add-ons to add their own content into this page in the first pass, that will depend on time constraints. I think that even without that this is still a very worthwhile feature.
Next steps
Develop more detailed UI mockups.
Implement the in-content page to read the already available data on new add-ons.
You may have noticed many of the Firefox team starting to blog progress reports on Fridays. This is a part of our new plan to clearly define the main projects we are all working on and communicate a much as possible about them rather than just having users surprised to see them turn up in nightlies. So here is my report for this week:
I’ve been working on improving the level of information and control we give users over add-ons installed by other applications on the system (think Skype, Java, AV tools etc.). The work for this is being tracked in bug 476430 and on the project wiki.
The basic problem is that sometimes when another application installs an extension into Firefox the user either isn’t told so by the application, or more likely the information is missed in installer pages that users click straight through. It is then a surprise when users later find this thing in the add-ons manager, sometimes when it is causing problems. The goal is to make sure that this never happens by telling users that something has been installed and giving them the option not to use it.
We considered a couple of principles for the design here:
Firstly we should not delay starting Firefox. If we present UI asking a question before startup then users will just click through it.
Secondly we shouldn’t just run Firefox with the new extensions enabled, users should be given the option whether to use them before they are run for the first time.
Thirdly the eventual result of a user taking no additional action should be that the new extensions should be enabled. If we default to disabling these items then the majority of users will never enable them. This would make other applications stop using these mechanisms to integrate with Firefox and seek out more hacky, less controllable ways to do it, something that no-one wins from really.
The resultant plan is a hybrid approach. The first time Firefox runs after a new extension is detected it will not enable it. Firefox will tell the user what has been installed and tell them that the extension will be enabled the next time Firefox restarts. The user can then choose to disable it permanently (or at least until they choose to re-enable it in the extension manager). The user will probably also be presented with a quick way to restart Firefox to use the new extension.
Status
The backend code that disables detected extensions during the first run is complete, as is the frontend code that marks them to be enabled after a restart. The UI still needs to be connected but that will require the doorhanger notification API to be completed.
Add-on developers face a bit of a challenge when it comes to helping users get the most out of their add-ons. Even once you are past the first hurdle and have got a user to install the add-on, you then need to help them get up and running quickly after Firefox has restarted. Presented with just the blank Firefox window it can be difficult for a user to know where to go next. Many add-on developers have taken to including a first-run experience to give the user some help. Display a webpage with some instructions or open a wizard to start setting up. As this practice started it was generally acceptable. Few add-ons actually did anything so it was helpful. These days though many add-ons are doing it, no doubt with more to come. It is starting to be an annoyance in some cases. Others have already been discussing ways that we can improve this.
In Firefox 3.0 we introduced a small feature to try to alleviate a little of this. After restarting Firefox the user would be shown new add-ons that had been installed so they could configure them. It also provided a little consistency across the restart which was normally done from the add-ons manager.
The current post-install display
This UI had the additional small benefit that it would also display when other applications installed extensions into Firefox without the user’s knowledge. However as a post-install experience it really hasn’t worked out all that well for a few reasons:
It’s invasive. It pops up in front of the user after the restart and they feel the need to close it before doing anything else. This makes it almost as bad as some of the first run experiences provided by extensions.
It’s confusing. It can be pretty difficult to identify just what add-ons have been installed especially when the list is long.
It provides no next steps. Although if you click on the new add-ons you might get a chance to configure it, it doesn’t actually help push the user in any direction.
We’ve been thinking about ways to improve this for a while and there are a few different ideas floating around. I’d like to float one of them here and see what people think. The goal is both to let users know that new add-ons have been installed and let the add-on help the user move forward without needing to show popup dialogs or inundate the user with a webpage per add-on. It also needs to work in applications that aren’t Firefox. Excuse the poor mock-up, my UI skills aren’t all that hot.
Proposed first run experience
The idea is that in Firefox this would display in the webpage content area. It might display immediately after startup, or it might be better to use an alert to tell the user new add-ons are there and then display it when they click on the alert. Other applications can open this in a new window or wherever they wish.
It’s designed to be clear exactly what has been installed and give the user things to do with those items. Preferences at a bare minimum, but the yellow highlighted areas are the interesting bit. Those represent overlay points where the add-on can put whatever UI it likes. This might be a simple message to tell the user how to get started. It might be a few of the most common settings, maybe a login box. It might be a button to launch further UI like a wizard.
I think, even if this were to open immediately in Firefox, this addresses the main deficiencies of what we currently do. I’d hope that many add-on developers could then stop their custom first-run stuff and instead just use this, but I know there are lots of different needs out there so I’d like to hear where this doesn’t work to see if we can accommodate.
This is really not the ideal set of interactions between the extension manager and its related components. Unfortunately changing it is going to be hard.
Extension manager inter-dependencies
Unfortunately adding any new features is also pretty hard until at least some of these dependencies are broken.
One of the biggest requested items I see in the add-ons newsgroups and IRC channel is from developers asking how to perform some work when their add-on is installed or uninstalled. Previously it has been vaguely possible to do this, but there is a lot of hassle involved and it wouldn’t always work right.
As part of my roadmap for improving the extension manager we are talking about adding real support for these sorts of activities. The draft specification covers the proposal in more details but in draft it allows the following:
Add-ons will be able to provide code to run when their add-on is installed, uninstalled, disabled, enabled or upgraded.
Add-ons will be able to provide a list of files in the profile folder and preferences to be removed when the add-on is uninstalled.
There are a few restrictions so if you are interested check out the full specification and let me know what you think. There’s still room for change, but I think the proposal provides real benefits for add-on developers as it stands.
Some time ago (wow was it really 5 months!) I blogged about some plans I have had for the future of the extension manager. I think it’s time for a short review of what it going on.
I said at the time that any of the timescales mentioned we’re very rough and certain to be underestimates, but I didn’t quite appreciate how true that was at the time. Despite tripling most of the times we’re still almost nowhere along implemented most of the ideas.
The main reason for this is simply the delayed launch of Firefox 3.5 (previously 3.1). At the time I was working on the plan I was anticipating 3.1 to release fairly quickly, or at least my part in its release would have trailed off. That didn’t happen and, as is the nature of these things, there hasn’t really been any time for me to work on the kind of rolling improvements the roadmap talks about while we’re trying to ship the next big release of a product. Blockers and bigger ticket items will unfortunately always get in the way.
Releases come in bursts though. My work on 3.5 is basically done and the next big release won’t be for at least half a year, maybe longer. Once I’ve taken a small break I hope to start making progress on the extension manager work again. I think I’m going to work things a little differently. The first thing I will try to do is come up with some good specifications for all of the features. The idea is that if we have good consensus on the details of each then it’ll be easier to get more people working on them in parallel.
For some time now I’ve been throwingaround ideas for new features that we may want for the add-ons manager. After lots of thought and trying to take on board comments from anyone that would pipe up I decided it was high time to put together an actual plan for what features I have decided should be pursued and what order to start tackling them.
The roadmap itself should be pretty self explanatory, just remember that nothing is ever set in stone. I’ll try to keep it updated as things change, features seem less important or new items are added. But for now this is how I see the add-ons manager evolving over the course of about the next year or so, which may be the next two versions after Firefox 3.1.
Obviously the ordering of the goals may not be quite to everyone’s taste, but I’ve tried to strike a balance between getting new features done and getting groundwork laid to make things better in the future. I’m happy to take any comments people might have into consideration for altering the plan, but chances are I won’t be making any big changes unless you have some pretty damning evidence that a change is necessary 🙂
With Firefox 3 getting ever closer to release it is time (well, past time) to start thinking about the future. The Extension Manager has seen quite a number of improvements since Firefox 2. Many were designed to be invisible, generally improving stability and fixing oddities. Some are extremely visible such as the new security requirements and the addons.mozilla.org integration. The question is, what’s the next step for add-ons management?
Here are a few ideas that are floating around my mind to get you started:
Deprecating install.rdf and replacing with a simpler xml or json format
Add-on dependencies with automatic resolution
So what have I missed? Please keep any comments restricted to add-ons management, either as a user installing and using add-ons or as a developer writing add-ons. While I am interested in the future of Firefox as a whole I don’t want this to be a mass feature request for the product.
Since the disclosure of potential vulnerabilities in the way Firefox (and other Mozilla applications) automatically update your add-ons we have been discussing how to tighten up the system in a way that is hopefully unnoticeable to users and not much extra work for add-on authors.
After a process of listening to authors on the newsgroups, forums and by email we now have a rough proposal of what changes we are looking to make. There’s still a few minor details to be ironed out of course. This is mainly of interest to add-on authors since there is an impact depending on how you host your updates. I’ve started threads on the newsgroup and forums so if you want to discuss the proposal there then that’d be good. I’d prefer it if you didn’t edit the main page of the wiki but feel free to stick small comments onto the discussion page.
