Skip to content

Some notes on WebExtensions discovery

As I was preparing for my presentation at FOSDEM, I tried to approach WebExtensions from a beginner’s perspective and document the entire process. I wrote it all down on this Etherpad, if you’re interested in the raw notes. This blog post is about the first part of the notes: discovery.

We have a history with naming at Mozilla, where project codenames often end up taking over, project names are reused, and all sorts of confusion ensue. I wanted to see what showed up running various queries through the most popular search engines, and here’s what I found:

  • Searching for “web extensions” will often point to domain extensions, rather than any Mozilla docs. Maybe in time our docs will get higher ranking.
  • Searching for “WebExtensions” will most often point to our wiki page, which makes sense since the project is only taking off. However, we would want these queries to eventually point to MDN instead. Again, it might be only a matter of time.
  • Searching for “firefox extensions” and “develop firefox extensions” generally yield useful results, though they are inconsistent. Some point to AMO while others point to the add-ons blog. We want MDN to be the place to find add-on docs, so we’ll need to work on this.
  • didn’t show up. While this site is mostly aimed at developers interested in the progress of the API, I think it would be useful if it showed up among the top results.

My main takeaway is that we have our SEO work cut out for the coming months. Maybe WebExtensions isn’t the best of names for this new technology, but it’s been out there long enough that there’s probably no turning back. And choosing names is hard anyway.

The complete results are in the Etherpad. Of course, your results may vary, since many search engines personalize rankings based on past searches, and I ran this experiment 3 weeks ago. The pad also has some notes about the documentation and how easy it was to port a relatively simple add-on to the new API. There’s also a good blog post about porting a Chrome extension to WebExtensions in the Mozilla Hacks blog, which I recommend you read next.

{ 5 } Comments

  1. Colby Russell | 2016/02/18 at 11:00 PM | Permalink

    Just call them browser plugins. It’s what most laypeople call them anyway, regardless of any explanation or education. Cowpaths and all that.

    NPAPI is going away, so the distinction is more unimportant than ever. And since they’re going to be using a well-defined, limited API, the need to communicate the power in “extensions” is gone/misleading.

    “Add-ons” was a nice effort as a catch-all, and it would have been nice if the rest of the software world would have standardized on it. I started messing with MonoDevelop a couple years ago. They’ve got an Add-in Manager. For installing and removing *add-ins*. Ugh.

    So “add-ons” should probably get retired, too, but that’s a suggestion that probably won’t go over as well.

  2. jorge | 2016/02/19 at 12:10 PM | Permalink

    WebExtensions is a term for developers, so they can tell them apart from previous APIs. The discussion about add-ons/extensions/plugins and so on is separate, but also important. I think ultimately we will settle with add-ons and will stop using the other terms as much as possible.

  3. Colby Russell | 2016/02/19 at 3:05 PM | Permalink

    The users/developers distinction that the fx team has adopted is depressing.

  4. jorge | 2016/02/19 at 4:34 PM | Permalink

    Not sure what you mean here. There is terminology that is important to developers but irrelevant to users. A user shouldn’t care if an extension is built using XUL, the Add-ons SDK or WebExtensions, but it matters a lot to developers. The distinction between the different kinds of add-ons (extensions, plugins, themes, etc.) is another example where technical terminology ends up confusing users unnecessarily, so I agree it should be unified as much as possible. But there’s clearly different messaging to be done for end users and add-on developers.

  5. Colby Russell | 2016/02/19 at 6:32 PM | Permalink

    It’s a viewpoint that categorizes users into “those who are coders” and “those who aren’t coders”, and assumes that things are frozen that way—that people on the right side would never be interested in moving to the left. But that’s beside the point.

    Brand extensions-ng as “Firefox plugins”, and you can stamp it all over the new docs for the developers you’re targeting. It has the nice benefit of coinciding with the terminology of the user who thinks these things are supposed to be called “plugins” anyway, and the docs will be there for any one of them who asks himself or herself, “Hey, could *I* make a Firefox plugin?”.

    XUL and the Add-ons SDK are meant to sunset eventually, anyway, so it doesn’t really matter if “plugin” sounds more inclusive than it is.

    WebExtensions itself is a misnomer, because they only thing they have to do with the Web is that the application they’re targeting is a web browser, but they’re not really “of” the Web.

Post a Comment

Your email is never published nor shared. Required fields are marked *