Possible Possum


Actually, a probable possum. The cats alerted us to something sneaking around the woodpile last night, and it turned out to a giant-rat-like critter. After our initial hopes of an ROUS, some poking around in google images lead us to the possum hypothesis.

As well as giving me the chance to say ‘possum’ a lot, which is a treat in itself, it was also another in the list of cool American critters I’ve been lucky enough to see. It joins coyotes, tarantulas, scorpions, bobcats, rattle snakes, king snakes, racoons and black widow spiders. The black widows are also prone to hanging around our house, which adds a certain edge of danger to walking to the hot tub at night!

If you want to see more nature in LA, a good place to start is the Santa Monica Mountains Trails Council. Liz sits on their board, and maintains the website, including a trail and plant of the month.

How to promote your add-on – The Message

The previous two posts were about the mechanics of how to contact potential users of your add-on. I’m now going to cover a much fuzzier problem, how to persuade them to consider using it once you are in their field of view. This is an area I need to improve on for PeteSearch, so a lot of it will be practical examples of how I’m trying to change things to be more persuasive.

I met with Mrinal Desai over coffee last week. He’s the chief evangelist for the wonderful Crossloop, and he’s done an amazing job with the app. From being unknown less than a year ago, it’s now got thousands of users all over the world almost entirely through blogs, digg, and other word-of-mouth marketing. They recently crossed the three million user-minutes mark! So, he’s somebody whose advice I value.

He asked a pretty simple question; "What is PeteSearch for?" My immediate response was ‘to make search better’, but this didn’t feel concrete enough, even to me. It reminded me of Guy Kawasaki’s advice from The Art of the Start, to have a three word mantra that describes the difference you’re trying to make to people’s lives. Once you have that, it’s the start of both a coherent, understandable marketing message, and a test for decisions you make about the product.

You may think you don’t have a marketing message, but everything from the name of your add-on, to its description on distribution sites, to its home website, is material that people use to make a decision about using it. The fundamental question you need to answer is "What does it do for me?", how will it improve your potential user’s life? Your answer to this should be your mantra, and everything else should build a convincing case to persuade a user that it does solve their problem.

As a practical example, PeteSearch is trying to improve search, but no user wakes up in the morning and thinks "I need improved search". Users have much more concrete gripes; "I wish I didn’t get so many 404 links when I searched", "It’s annoying to go back and forth between the search and result links all the time", "Why is the text summary so short?", "I wish I could use the keyboard to navigate through results, rather than the mouse". At the moment the add-on is trying to solve all these problems at once, and they’re all equally prominent in the marketing.

This is a problem, because a single user is unlikely to have all these gripes at once, so most of what they read in the marketing is solutions to problems they don’t have. Even a lot of the UI in the extension itself ends up being clutter. This attempt to solve everyone’s problems actually ends up solving nobody’s.

To fix this, I’ve decided my mantra will be "Better Search UI", and I will focus like a laser on adding great keyboard navigation to Google. This will make describing it a lot simpler. I’m even considering a name change to GoogleHotKeys, to make it a lot clearer to potential users what’s in it for them.

PeteSearch may be unusual, many add-ons are built with a much clearer, specific need in mind, but if you’re struggling with a your site or description, I found starting with a mantra really helped me to improve my message.

More posts on add-on promotion.

How to promote your add-on – Distribution


Getting your extension distributed on sites such as addons.mozilla.org or Windows Marketplace will help you find an audience in several ways.

Discovery. People who are interested in finding new add-ons browse these sites. You’ll be in front of an audience of early-adopters who are interested in experimenting. This can be very powerful if you’re trying to solve a problem that applies to a lot of people, rather than a more niche issue. Most people won’t invest the time to try your plugin unless it’s offering a solution to a specific and painful problem, but this audience is curious and more willing to take a chance.

Legitimacy. Nobody’s heard of you. Unless you’re a big company or celebrity, or you’re targeting a niche audience in an area where you are well-known, you’re a stranger who wants to install software on their computer. This sets a very high trust barrier to overcome! Distribution sites effectively lend their sponsor’s reputation to your add-on, making people feel comfortable installing the add-on because they know the sponsor has a lot to lose if they do distribute something malicious. To protect their reputation, the sites generally have a vetting process to check add-ons before they’re allowed on the site.

Promotion. Distribution sites exist to show off all the cool extensions that exist, and are generally set up by the creators of the main app. Having a good collection of add-ons is an important selling point for the browsers, and so some extensions are included in their established marketing efforts. If your add-on gets picked as a great example, and prominently featured in their marketing, you’ll reach a lot of people. This will usually happen after you’re an established add-on, with proof that you appeal to a large audience already, so don’t make any plans that rely on this, but it’s a great bonus if it does happen.

So, getting on a distribution site is a good idea. How do you do it? For PeteSearch, I’ve only made it onto the Firefox site so far, so I’ll focus on that process, but I’ll be attempting to get the IE conversion up on Windows Marketplace soon, I’ll cover the practicalities of their vetting process once I have.

To get started with Firefox, go to their addons site and register as a new user. Once you’re registered, you can then upload the extension you’ve created. You’ll need to provide information about it, and some basic checking will be done when you upload the file, to make sure it supports the correct versions of Firefox for example. Once you’ve got it uploaded, you then chose to make it publicly visible. This places it into the sandbox, which is a sort of purgatory for plugins, where they wait to be approved. They are only visible to people who create mozilla accounts, and change their account options to make sandbox add-ons appear. The idea is to distribute the approval process by getting reviews from people who browse the sandbox, so that the final mozilla reviewers have something to base a decision on. In practice, very few add-ons receive reviews in the sandbox, I’m assuming because very few people are browsing it.

Since an add-on with no reviews will be rejected if you nominate it for the public site, this can be a problem. For PeteSearch, I was able to work around this by gathering links to all of the external reviews, and including them with my developer notes, after it was rejected the first time.

More posts on add-on promotion.

How to promote your add-on – External Blogs


So, you’ve written an IE or Firefox extension. Now, you need to tell people about it! In this new series, I’ll be covering what I’ve learnt going through that process.

External blogs. A lot of my users have come from four main-stream blogs who I contacted directly about PeteSearch; John Batelle’s SearchBlog, Gary Price’s ResourceShelf, WebWorkerDaily and Hackszine, but I’ve also had some good traffic from blogs who discovered it themselves, like Pete Prestino’s, BrainsFeed and NetWizz.

I would recommend finding authors who’ve written about the problem you’re trying to solve, and emailing them, or leaving a comment on a relevant article. Invest some time on their site, try to contribute to their community, and get a feel for the readership’s needs. Be very respectful of their time, they are all dealing with a lot of unsolicited emails, so be clear and concise on what your extension offers. That way they can quickly decide if it’s something their readers may be interested in.

Don’t be offended if you don’t hear back, expect the majority of your attempts to reach out to have no response. If they do reply, or post on their site, make sure that you thank them with an email!

Treasure any feedback you get, especially the negative. Remember, almost all people will silently stop using your addon if there’s a problem with it, so someone who tells you why it sucks is doing you a big favor!

More posts on add-on promotion.



One of the great unsolved mysteries of BHOs is how to catch refresh events. When the user refreshes a page, DISPID_DOCUMENTCOMPLETE and DISPID_NAVIGATECOMPLETE are not sent, as they are with a normal load. Add-ons rely on that to know when they can start changing the DOM, so it’s a pretty serious problem.

There are some suggested solutions that use the DISPID_DOWNLOADCOMPLETE event, which is sent on a refresh, but only after all images have been downloaded. Since you get one of those for every document complete, you can do some jiggery-pokery to spot if you get one of those without a corresponding navigate complete to spot refreshes.

It seemed like there had to be a more reliable way than this, so I’ve cooked up a solution that detects refresh events directly. You can download example source code here.

It works by attaching a hook to IE’s main window procedure using
This calls back to the function we specify, after every call to IE’s message loop. By looking at what happened during a refresh, I spotted that a WM_COMMAND message is always passed, with a LOWORD(wparam) of 0x1799 for a refresh caused by pressing F50xa220 for one triggered from the main menu, and 0x179a for the context menu. These values are consistent across both IE 6 and 7.

I’ve set up my hook function to get called after the app’s message handler, so when I see a refresh command has just gone through, I override the default refresh behavior by explicitly calling IWebBrowser2::Navigate() to the current page’s URL. This causes IE to go through the normal loading events, so BHO’s now receive the usual document complete call.

Here’s the pros and cons of this new approach:


Simplicity. Compared to the book-keeping needed for the event counting approach, it’s a lot easier to code.
Identical to normal loading. A refresh now triggers exactly the same page-loading events as loading a new page.
Right time. The event counting approach only detects a refresh when it sees a download complete event, which can be some time after the document is actually ready.

Voodoo-esque. Relying on details of IE’s internal implementation is risky. The fact that it’s been consistent for several years makes it less scary.

Redundancy. If more BHOs use this approach, you could have the code called multiple
times for a single refresh. In practice this doesn’t seem to cause any noticeable problems.
Misses script refreshes. If a script calls window.location.Reload(), this won’t be detected.
IE’s refresh behavior
. This is probably the most serious issue, since I
know there’s multiple meanings for refresh, depending on whether shift
is held down, etc. In production code, I’ll probably limit the forced
reload to pages where I needed it (eg search results for PeteSearch)

Overall, this seems better than the alternatives for my purposes. I’d prefer to avoid the whole thing, but since the bug’s been a known issue for at least four years, I can’t rely on it being fixed soon.

I also looked into some techniques that relied on adding a handler to the document or window’s onload event. Unfortunately using attachEvent(), there was no call back to the handler on a refresh, even though script handlers within the page do get called back. It’s possible that setting the onload handler for the window explicitly would have worked, but this can be overwritten by scripts, and so isn’t reliable.

More posts on porting Firefox add-ons to IE



This ZDNet article really reminded me why I started PeteSearch. It’s from 2004, and laments the lack of progress in searching, and not much has changed since then! Sure, there’s been iterative improvements, more flexible term matching, search history and the like, but nothing that a Google user from 2000 would be surprised by.

Part of the problem is that Google can copy most foreseeable outside innovations if they turn out to be popular. It’s really hard to make a business case for funding a company that would in effect be providing them with free R&D, with little prospect of a return. Google themselves are experimenting with new models, but without real competition, they’re in no rush to cook their golden goose. Ask have been the most innovative with their search UI, but even that is still based around the same basic layout.

One phrase really struck me from the article: "Don’t expect users to apply more than the basic tools and techniques to acquire information from a search engine." The stats show that only three percent of people used quotes or other advanced syntax.

A lot of people have concluded that this means people don’t want anything better, and there’s no point trying to improve the page-of-links presentation of results. My firm belief, and the reason I’m experimenting, is that I think it’s just a local-maximum in the space of possible UIs. Why not have a grid of 25 thumbnails, with the positions of the terms marked on each? Or live snippets of the actual rendered page below each link, not just the text? Or a micro-fiche-style view, where you cycle through all the pages at speed in full-screen? Sure, these are random examples, but are people in 2030 really still going to be using plain pages of links?

Wiki guide to writing BHOs


I’ve had a really good response to my series of articles covering the basics of writing an add-on for Internet Explorer. It led to some really interesting discussions with other people who are working in the same area and finding it hard to discover good documentation. It feels like we’ve all got different pieces of the puzzle, so to help gather that knowledge together, I’ve set up a wiki:


I’ve started it off with articles on the basics of creating a BHO, and some of the quirks and issues I’ve run into. It’s publicly editable, so I’m hoping that you folks will help add to, correct and improve it!