Lowering the barrier to entry to attract users

Flickr photo by greensambaman
Flickr photo by greensambaman

There’s an interesting article out that points to the fact that every day there are 10,000 canceled installations for Firefox; this meaning that each day 10,000 people download the Firefox installer, “fire up” the *.exe and then click “Cancel”. (A further 40,000 apparently downloaded the setup file, but didn’t even make it far enough to start and then subsequently cancel the installation)

Even more interesting were the reasons why the 10,000 canceled their install. A large part of the respondents were “confused” with some part of the install process (nearly half) while most of the other half identified that they did not have the proper permissions to complete the install.

Not simple enough?

The results seem to indicate that the installation process is not as easy as it could be. However, it’s dismiss the results by saying that Firefox is already easy enough to install, because after all, how hard can it be to just click “Next” a few times? But this ignores the central problem, that is, assuming everyone is technically proficient enough to find such things routine.

For example, to a mechanic an oil change would likely be an easy five-minute operation. For someone like me, who’s rarely popped open the hood of a car, much less done anything underneath it, such a task would likely entail reading a manual (or just Googling for the answer), then carefully following the steps one-by-one; I’d be lucky to get the whole thing done within 30 minutes.

The same can be said for software installation. Something that seems routine for most developers or power users may only seem routine because we’ve dealt with it countless times, or because we’ve dealt with more daunting situations that required manual workarounds and hacks in order to get things working. One person’s routine can be another person’s out-of-this-world experience.

The value of feedback

This is why Mozilla is actively taking steps to improve the process by collecting feedback from users who canceled the installation.

Users who canceled could optionally provide the reason why they canceled, how the installation made them “feel” as well as any suggestions or comments they had. This formed the basis for the feedback results Mozilla compiled:

mozilla-firefox-cancel-feedback

The fact that a significant percentage of the respondents were “confused” shows that they are some issues that the installer could make easier. The vast majority of this confusion stemmed from the fact that installer could not close an existing/running Firefox process, a step required for the installation/upgrade to proceed. This is a legitimate technical issue that can hopefully be solved.

Installation rights

The other significant factor, based on user feedback, was the lack of permissions required to install Firefox. Normally, Firefox requires administrative privileges on the machine in order to install it. This wasn’t a problem during the days of Windows XP, when users by default had these rights, but with the advent of Windows Vista this is no longer the case. Instead, users will typically be hit with a UAC prompt when trying to install software, which may deter them from completing the installation if they are unsure or unaware of what it means, something that is exacerbated by a user’s inexperience.

This article by TG Daily shows how some other browsers have simplified the installation process. Apple has started to bundle Safari as an “update” in an aggressive attempt to gain market share, while Google’s Chrome uses a lightweight online installer to speed up the installation process.

Easy or flexible?

Chrome’s installation approach is particularly remarkable in how it works. It requires less user intervention and furthermore, installs itself in the current user’s Application Data folder, which does not trigger a UAC prompt. (This also means that it must be installed for each user on a system, rather than being installed on a system-wide basis) Google also installs its updater, which runs in the background to keep any Google software up to date on the target system. Such a system is highly convenient for non-technical users, who don’t want to be bothered with manually keeping things up to date, but has drawn complaints from those more technically-oriented.

This highlights the differences a developer faces when creating an installation procedure. Typically, developers will lean towards providing the end user with as many options as possible because it’s the easiest way to solve a design decision. Can’t decide between X and Y? Let the user choose! This also goes along with the philosophy of power users, (a group that developers are pretty much a subset of), who like to know exactly what’s being installed on their system and what’s being done to it.

This contrasts with the needs of the typical user, who just wants the software to install as seamlessly as possible. I’ll have to admit, the Chrome installation procedure irked me a little, as I was more comfortable with the “normal” Firefox installation procedure, which gave you the option of where you wanted to install the software, etc. But ultimately, the Chrome installation process likely worked for 95+% of the users, so in the end that way wins out.

Lowering the barrier

Much can be learned from these results if you’re trying to get users to sign up for a service. In many ways, the process for signing up a user is like the process of getting the user to install software. Both require the user to entrust their resources to your service, and both require them to go through a series of steps. If the user really wants your service, they’re likely to put up with more of a hassle, but in general your aim is just to get them to try out what you’re offering, so you have to make things as simple as possible.

This is what I’ve tried (not sure if I’ve accomplished) with the RunTrackr registration process. Obviously, there are changes/improvements to be made. If the service were to get more popular, I’d have to implement more anti-spam/anti-bot measures, some of which might impede usability. But in general, I like the one-step registration process.

One of the things I decided from the get-go was to allow users to create routes without registering; this lowers the barrier required for them to create content and allows them to try out the service before committing to registration. However this has resulted in a lot of “unowned” routes created as an initial use. Following this, even if the user registers, they are unable to “claim ownership” of the route. One improvement I’d like to make is to tie in a “quick registration” option after the unregistered user has created their first route, allowing them to register and claim ownership of that route. I haven’t figured out the best way to do this, though.

However, I’ve been looking at Kijiji as an example of how this might be done. Kijiji is a localized online classified ads site, owned by eBay, and it allows users to post wanted/for-sale ads without registration. (The user must enter an email address to provide confirmation, as an anti-spam measure) However, after posting an ad, Kijiji makes it easy for that user to quickly register in one step and claim ownership of the ad they’ve just created. I suppose this is easy, since they already have the user’s e-mail address, but I would still like to implement something similar to improve the user experience.

Comments for this entry are closed

But feel free to indulge in some introspective thought.