Addoncon Userpoints Idea

At Addoncon, there was a lot of talk about how to compensate Firefox add-on developers. One of the ideas mentioned was some sort of user point system where points could be allocated to add-on developers by users and also based on usage and then the add-on developers could either donate it to a cause, turn it into merchandise, or turn it into real money.

What this does is provide a way to compensate add-on developers for the contributions they are making to the overall Firefox brand equity.

I have a longer summary of this idea on the Addoncon blog and would love to get feedback.

CCK Wizard Status

With the release of Firefox 3.6, people are already asking me about a new CCK Wizard. I am working on an update. You can get a beta of that here. Primary changes are more information on the proxy page, ability to open an existing CCK and better coexistence of multiple CCKs.

Most interesting news on the CCK front is that I've decided to move it to Google Code instead of maintaining in the Mozilla trees. The URL is http://code.google.com/p/ff-cckwizard/. My primary reason for doing this is honestly that I'm not really contributing to Mozilla/Firefox proper anymore and messing with Mercurial isn't worth it for me (I know, lame excuse.) It has some other advantages, though, like having my own bug reporting system and not having to get any reviews/approvals for checkins.

So if you have ideas/suggestions/bugs for the CCK Wizard, please open them in Google Code.

Also note that CCK Wizard is something I do on the side, so my time is limited. Contributions help. I know there are a lot of folks who depend on this for the business. Any and all love is appreciated.

Extensions, Personas and Jetpack! Oh, My!

As a result of Mike Connor's post, there's lots of discussion about extensions, theming, Personas and Jetpack. This is my livelihood, so I definitely have to jump in.

First, let's talk about Personas. I hate to burst everyone's bubble, but:

Personas is not lightweight theming. Personas is wallpaper.

We've had it since Windows 3.0 (may be even before). It's pretty wallpaper, but it's still wallpaper.

Lightweight theming is a different beast. Lightweight theming is the ability to theme the browser window WITHOUT theming the rest of the browser. So lightweight theming might involve changing things like browser background images (more than one), toolbar buttons, and possibly the URL bar or the tabs. I'll be a little self serving and say that everything Brand Thunder does is lightweight theming. You can see examples at the gallery.

Personas is not a suitable replacement for Firefox theming. It doesn't even come close. And looking at the designs for future versions of Firefox, Personas becomes irrelevant - there's very little browser chrome to even see the background images. (Clue to Firefox developers - make the new tab window transparent like Chrome).

People point to Personas and say "look how popular it is - people must want theming that way."

Personas' success is about marketing.

Personas is the only extension that Mozilla markets. They market it on first run pages, download pages and home pages. It has a dedicated domain. It has special privileges for being installed without the add-on security warning. It was a recommended add-on from day one. They even have a custom bundle of Firefox that includes Personas!

So please don't tell me that Personas is the future. Personas is the present. Clearly a completely new solution will be needed for future Firefox versions.

Now let's talk about Jetpack.

Jetpack is like giving me an Erector set when I used to have a Home Depot.

Let's look at the problems that Jetpack attempts to solve and see if a new programming model was necessary to solve them.

Install without restart -
If extension developers were given a specific set of APIs that they could use that didn't require restart, then extensions could be marked as "doesn't need restart" and this problem would be solved. All Jetpack does is pre-grab parts of the Firefox UI so that when things are placed there, Jetpack handles their placement, not Firefox. This could be done with any extension API. It doesn't require Jetpack.

Ease of creation -
A learning curve is a learning curve. I don't know jQuery, so Jetpack has a learning curve for me. Jetpack is simply trading one programming model for another. I've been to presentations where HTML developers were shown how extensions work and within one hour they could create extensions. Doing very interesting things with extensions might be difficult to learn, but that's why you create an API. And that API does NOT have to be Jetpack specific. Packaging can be a little tricky, but again solvable outside of the context of Jetpack.

API -
If the extension API isn't very user friendly, fix it. Isn't that what FUEL was trying to accomplish? If you want a stable API that doesn't change from release to release, create one. There's no need this API needs to be created as a part of Jetpack.

Forward compatibility -
Extensions break from release to release of Firefox. That's just a fact of life. The only way to prevent this is to give extension developers a very tiny sandbox in which to play. We don't want this. Give us a big sandbox and if we break, we break.

The problem is not that you break us. The problem is short release cycles

Right now, the Firefox team is aiming for six month release cycles. For an extension developer, the last two months of that cycle are when we can really start checking out things and it's only in the last month that we can actually release addons that have the correct version in install.rdf (due to AMO restrictions.). Most extension developers have multiple extensions and probably a day job. Updating five or 10 or even hundreds of extensions can be quite problematic.

Jetpack simply creates a new set of problems and a new context to solve those problems. We should try to fix those problems in the existing context.

I think the core problem here is a disconnect between Mozilla Labs and the rest of the Mozilla community. Mozilla Labs operates in a very closed community, completely contrary to the way other Mozilla projects are done (at least for the initial phases of a project). I think that contributes to their myopic vision of the future of the browser. I'd much rather see Mozilla Labs work with the community to propose ideas and foster those ideas to create a real open source lab versus coming up with ideas and then trying to force those ideas on me.

And incidentally, Internet Explorer is a great example of what happens when you give people a limited set of APIs to work with. They come up with elaborate hacks in order to make things work. And those definitely break from release to release. If you limit people, they will come up with ways around those limits. Please don't limit me.

New Rebranding Wizard

I've just uploaded a new version of my add-on Rebrand to AMO. Until it is approved, you can download it using this URL. This new version adds support for SeaMonkey as well as Firefox 3.6.

Rebrand is a fun add-on that lets you change the name and branding images of Firefox, Thunderbird and SeaMonkey. It walks you through the rebrand process and then generates an add-on. Disclaimers apply, and they are shown during the startup of Rebrand.

To celebrate this release of Rebrand, I've created a very special rebrand package
the Netscape rebrand. If you long for the good old days, you can install this add-on in Firefox or SeaMonkey and relive them.

netscape

Do you have a need to completely rebrand Firefox? Kaply Consulting can help.

MetroFAIL Merchandise

This is for my Austin folks. I started a site on CafePress.com selling MetroFAIL merchandise. You should go there and buy stuff!

Tired of Capital Metro's Epic FAIL around commuter rail? Show how you feel with MetroFAIL merchandise.

MetroFail

Great Article on Mozilla Contributions

Josh Lowensohn from cnet has a great blog post up about Mozilla Contributions that echoes some of the things I posted earlier.

One interesting observation:

Of the 500 or so developers who are participating in the program, the average contribution falls somewhere between $5 and $6, with the largest thus far being $150.

Assuming there has only been one $150 donation, that is one I received for the CCK Wizard. To be fair, though, that person has been trying to give me money for the CCK for years, and as soon as they had the opportunity, they took it. That's the only contribution I've received for the CCK Wizard.

I'm still optimistic that someone will figure out how to monetize Firefox addons well. Maybe that's a good topic for the upcoming Addoncon.

Does your company want to build a Firefox add-on? Let Kaply Consulting help.

New Rebrand Add-on Finally Available

Version 1.0 of my Rebrand Add-on is finally available.

The Rebrand add-on allows you to change the names and images that are used by Firefox and Thunderbird. You can change it to whatever you want. Here's my browser:

About screen for FIRM Airwolf

Disclaimer: This extension is for entertainment purposes only. Do not try to ship your renamed browser. Also this add-on doesn't fully rebrand on the Mac - the menubar name can't be changed with an extension.

Enjoy!

Do you have a need to completely rebrand Firefox? Kaply Consulting can help.

One Add-on Developer's Perspective on Contributions

Recently there was a post on on the Mozilla Add-ons Blog about Contributions. While that information was interesting, what I'd much rather see is individual developers talking about their experiences with Contributions. Hopefully my post will start a trend. (For those who don't know, Contributions is a way for people to donate to the developers of Firefox Add-ons.)

When Contributions was first made available, the mechanism was flawed. You were asking a user to contribute when first downloading an add-on (which is unlikely since they haven't actually tried the add-on), or somehow expecting the user to make it back to the add-on page to do the contribution (which is again unlikely since most users never go back to the add-on page since updates are handled through Firefox.). The AMO team tried to remedy this problem by creating a first run page, but this has the same problem - a user isn't likely to contribute money at first run because they haven't actually tried the add-on yet. But the existence of this page allows us to take advantage of displaying a request at a much better point than download or first run - upgrade.

Presenting a contribution page after an upgrade is a much more logical scenario, since your users have probably had your add-on installed for a while. I chose to use this method with the Operator add-on.

We need some numbers to put this post in context. As of today, Operator has about 160,000 downloads with around 14 to 15 thousand active daily users. (I've made my dashboard public so people can see these numbers.) That means I've had about a 10% download to user conversion rate.

As a side note, this 10% number seems to be pretty common. If you look on the AMO page today, you'll see 1,624,545,716 downloads, 170,724,304 users. This works out to about 10%. I've actually seen this number with other companies and add-ons as well. It would be interesting to see if other people see this trend as well.

I released an update to my add-on on October 12, 2009. This update contained a first run page that would be seen by all users including upgrades. This page is hosted on my website so I can easily track page views. From October 12, 2009 to October 19 ,2009 (1 week), that page has received 11,469 hits from which we can reasonably conclude that there were at least 11,000 upgrades, which is a considerable amount of my users.

I set my contribution amount at 5 dollars before I released the update. During that week I received 8 contributions of 5 dollars.

So to summarize, 1 week, 11,000 upgrades and views of the contributions page, 8 contributions. That works out to about a 0.07% conversion rate. I don't know much about advertising or these types of things in general, but my understanding is that ad conversion rates typically run anywhere from 1% to 4%, so this is extremely low.

I certainly don't have any complaints about this scenario - I'm not trying to earn a living from Operator, and any funds I receive are just extra. But I was surprised at how low it was. I pictured Operator as kind of a ""niche" add-on so I thought more people would be interested in supporting it.

Some other random observations:

  • I put a picture of my family on the developer page per a recommendation early on. No idea if this influenced folks.
  • More granular data from the AMO folks would be useful - in particular from which page (AMO vs. first run) contributions came from.
  • I believe these numbers would be even lower if I had my developer profile as "Kaply Consulting." I believe people are far less likely to donate to a company vs. an individual.

Any other add-on authors interested in sharing their experience?

Do you want to leverage Firefox add-ons to grow your business? Kaply Consulting can help.

Operator 0.9.5 Finally Available

I'm finally making Operator 0.9.5 available. You can download it from AMO. (It might not be there yet).

This version has a very significant change - I've removed the ability to have Operator present itself based on actions versus the data. I don't believe this will affect most people - data has been the default for a long time, and I would bet that is what most people use. If there is significant pushback, I'll reconsider. The reason I made this change is because I now allow you to turn individual actions on and off and I thought it would be very confusing to have the ability to specify actions on a toolbar, as well as turn off individual actions.

You also might find that some of your user scripts are not working anymore (particularly ones that install new microformats). I'll be working on solving this problem over the next few weeks. Basically the problem was that I had told people to explicitly import the Microformats API but if you do that, you don't get the new Microformats API included with Operator. I haven't found a good way to completely solve this problem so for now I had to disable anything that tries to include Microformats.js. I'm working on a way to sandbox my API from the Firefox API.

So to summarize the changes:

  • Actions view is no longer supported
  • You can turn individual actions on/off
  • Actions always open in a new tab
  • The new value class date patterns for microformats are fully supported (http://microformats.org/wiki/value-class-date-time-tests)
  • RDFa support has been tweaked a little so you should see Resources where you didn't before.
  • First run page
  • Various bug fixes
  • More translations