What’s the Future for Add-ons Management?

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:

  • Installing add-ons without restarts
  • Presenting more detail in the install dialog
  • Simplifying the UI
  • 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.

24 thoughts on “What’s the Future for Add-ons Management?”

  1. Hi
    I was thinking about the following enhancements:

    For regular users:
    – systematically include a “what’s new” page for any extension, that would displayed after restart (or extension installation if no restart needed)
    – easy and obvious access to the “what’s new” page for an extension with a new version BEFORE update, from the “Pending update” panel (or whatever his name is 🙂

    And some things more useful to advanced users:
    – integrate features that extensions like “Extension List Dumper” or “Filter Extensions” offer for management of installed extensions: search within the installed extensions, filter on extension status, export of list of installed extensions in various format
    – add more info (last upate date, …) like “Extension manager extended” does

    And for even more advanced users:
    – be able to save the list of currently installed extensions, with indication of activated/deactivated status; then be able to restore the reactivated/deactivated all installed extensions according to such a previously saved list – this would ease the detection of conflicting extensions, IHMO.

    Hope this helps 🙂

  2. About install.rdf…
    Remove the RDF requirement because this is currently what makes parsing install.rdf far more difficult than it has to be.
    But keep it XML, because it is pretty easy to edit (humans and computers) and validate/verify.
    And don’t miss to care about update.rdf as well 😉

    Oh, and most importantly, don’t break everything again, especially late in the circle.
    Some examples.
    * the security requirements (updating manifest signing in particular), that feels like most user input was ignored, that have no official command line signing tools available, just a GUI client that lacks proper key sharing/backup capabilities and seems to be more a “hack” than a real application. You likely know all of that; you implemented it.
    * Removing the help viewer damn late in beta5 without communicating the change at all or investigating who else might rely on it before. Yet another example for the classic “who cares about extension developers”.
    * contentaccessible anyone, that was even post beta5 and where nobody seemed to take care about the real implications. The “workaround” to restore chrome.manifest compatibility orginated from Wladimir and not the folks who designed the patch. Venkman is still broken for example: https://bugzilla.mozilla.org/show_bug.cgi?id=428848
    Or in conclusion: Don’t make all those extension authors feel like they are third-class citizens, again.
    And don’t try to get them to support beta3 just to later break a lot of stuff again in beta5 or even later.

    I would really welcome it if MoCo would employ somebody who is actually responsible for “extension author relationships”, and only for that. Somebody that would be responsible for communication changes to authors and communicating issues/concerns from the author crowd back to the fx/toolkit dev teams/owners/planners.
    Somebody who would remind the core developers that there are things called “extensions” that may add tremendous value to the product and fucking with the authors because of “careless/don’t care at all” might be not the best thing in the world.

    Enough ranting for now :p

  3. Dave, thanks for opening this topic. One of my fav’s as you can probably guess.

    – One of the things I’d like to see is explicit support in the Add-ons Manager for add-on locale packs. We’ll need some good UI design in order to not overwhelm the existing interface while managing these new entities
    – For extension dependencies, it would be great if it can auto-retrieve (like Mac ports or apt-get) not just warn the user
    – This is more about the run-time (maybe not) – a security sandbox?
    – Run-time characteristics of add-ons (e.g. mem used?)
    – Include info about source of installation (e.g. was it installed from local disk or what site?)
    – Allow install option for all users or only current user
    – If user allows it, enable sites to query whether you have an add-on installed
    – Add-on backup and restore from/to repository (perhaps via FEBE + Weave?)
    – Update channels! (Similar to how Firefox has AUS channels for managing Fx installations). Add-on authors have requested to be able to update only beta users. If we had channels, we can implement targeted updates of add-ons.

  4. Re: Deprecating install.rdf and replacing with a simpler xml or json format

    This applies to install.rdf but also generally:
    As much as possible please avoid breaking things for marginal benefit. I maintain many extensions but I also have a full time (non-programming related) job and something of a life. I’m not interested in having to spend time to figure out a new system that doesn’t provide significant benefit. I’ve developed extensions for over 5 years now and when firefox was new, lots of flux was understandable, but now I crave a stable platform.

  5. short and sweet – a sortable “installed date” column. i’m up to 99 add-ons (yeah, i’m addicted :-).
    after updates are automatically installed, i like to check for “what’s new” or “changelog”
    links. it can be hard to remember what was just updated.

  6. Offhand,

    – Better search on addons.mozilla.org so users can find extensions more easily now that you can search a.m.o from the extensions manager

    – Addons installation / upgrade log so you can see what extensions were updated to what versions and when, for when things go wrong

    – Command line extension install, upgrade, uninstall, e.g. “firefox.exe –uninstall {ID}” at the app and profile level

    – “Disable All” and “Uninstall All” ability in the extensions manager would be useful when troubleshooting

    – End Of Life alert: The ability to mark versions as EOL in the update.rdf which alerts all users with that version of the EOL with the option to upgrade or uninstall.

    Thanks,

    Jon

  7. A specific em:type for extension language packs (like Firefox does). For example distribute an extension with only one or two languages and the rest can be installed afterwards without installing the whole extension again – just the needed language. I guess this can be done today with install.js but it is depreciated right?

  8. Just came here to second Mark Kennedy’s suggestion that he’s already posted about an add-on manager that provides sorting abilities — whether by alphabetical names, or criteria of installed/uninstalled, enabled/disabled, the installed date, etc. – it really would be a blessing with people have lots of extensions

  9. Something seems to be incongruent relating to extension ID case sensitivity. Apparently, when you change the case for an extension ID in a new version, it still gets updated, but the new install doesn’t actually work until you reinstall it. Would be nice if that got fixed somehow.

  10. Similar to the dependencies and dependency resolution idea: conflicts and conflict resolution. There are a bunch of addons out there that are known to conflict with other addons and it would save a lot of headaches if the users were warned of the conflicts and given help resolving them (i.e. disable addon A, disable addon B, ignore conflict(?)) before installing.

  11. Thanks for the post. My main feedback:

    “Installing add-ons without restarts” <– Absolutely necessary. Add-ons should work as seamlessly as web pages in the vast majority of cases. Even most application installs in Windows don’t require restarts anymore. Firefox (already a great app in many ways, and thanks much) could benefit a lot from this should-be-expected feature.

    By the way, I consider this to apply to upgrade and uninstall, too.

  12. Since it’s the Add-Ons Manager, it would be marvellous to see an integration of the Search manager. Right now it’s separate but functions in much the same way as the other Add-Ons do. Benefits would allow adding custom search engines (i.e. ‘Add a keyword for this Search’ context menu option could add a physical search engine), renaming existing search engines and changing other options.

    The same could go for dictionaries (along with language packs as a Languages tab?), but perhaps offers less of an improvement for the user in relation to the effort required to implement.

  13. Hi, I posted my suggestions (in Spanish) in my blog: http://www.zonafirefox.net/2007/09/5-cambios-que-necesita-urgentemente-la-pestana-de-extensiones-de-firefox.html. The first suggestion was included in the add-ons manager, so here a short explanation of my other 4:

    Date of add-ons install/update, in order to control changes and troubles by defective add-ons.

    Exportable add-ons list (like Extension List Dumper or Infolister).

    Uninstalling history.

    Multiple selection for uninstalling and deactivation of several add-ons.

  14. I wholeheartedly support your initial suggestions, though I don’t see anything overly complex about the UI (but you all have a great track record so far, so as long as you don’t dumb down the functionality…)…

    Install without restart would be sweet as would auto-dependency resolution. For the latter, I’d also like to see an option to upload some base software to the addons site which could be shared by other extensions (e.g., especially if it were a large and not frequently or independently changing download), but which wasn’t itself an extension.

    Last time I checked the Addon site didn’t provide the developer’s version notes to show up when More Info was selected during an update, which would of course be a nice interaction, though I presume someone might be on top of that already.

    The install.rdf is still a bit prohibitive I think (though depends and bounds better than the requirements before) and a simpler XML format (just one namespace please) would be great to encourage newbies, allowing people to easily try it out, is the first step to getting new developers. I’d also suggest merging the chrome.manifest data into the install.rdf file, avoiding emphasizing the JAR capabilities (make clear to newbies that they can avoid at least one zip hassle, esp. for debugging), and ideally even foregoing the need for the manifest data in the first place, at least if the user followed the typical content/locale/etc. directory structure. Seriously, unnecessary installation/packaging hassles really are a big deterrent to a lot of us in getting going initially on the platform, even if they might not seem too bad to others who’ve been through that hazing already. Installation is like filling out school worksheets, while programming is creative expression. 🙂

    For live editing/debugging, can there be a clear way of consistently refreshing the JavaScript and XUL without the need for a restart (no restart feature and addon to do so has not been updated). The extension manager extension used to do that but it’s not installing in FF3 and it causes all windows (chrome or non-chrome) to be lost rather than just refreshed. Quick feedback loop is very important (something winning me over to Mozilla development over PHP). Maybe you could even release a developer’s build of Firefox which included an updated “Extension Developer’s Extension” because that has some critical development tools.

    And thank you! Great to see these ideas being out there for real consideration….

  15. I navigated here trying to suggest something. In Firefox if I highlight some text and right click I can select (among other choices) to search Google for the text. Can another option be added to search YouTube also?

    I am likely in the wrong place but you can pass this along to the correct people/developers.

  16. In terms of dependencies with automatic resolution …

    If you could get a report when problems occur. For example, a crash manager report that includes installed adons when crashes occur. Possibly a report triggered by other non-crash events?

    Then apply bayesian statistics similar to the way that thunderbird automatically hunts for spam. You would search for patterns in the installed sets of extensions that are present when crashes occur. It could tell you what extensions are most crash prone, as well as particular combinations of extensions that cause problems.

    Of course, you would have to weight the algorithm by the number of downloads of a given extension. Otherwise, a popular extension would show up in many crashes even thought it is not a problem.

    Michael

  17. Don’t remove install.rdf, it would make it annoying for developers who want to add support for older versions of Firefox (because not everyone updates to the newest version).

Comments are closed.