"Wyatt Says..." is a collection of articles by Wyatt O'Day talking about wyDay products and the things we've learned along the way.
This is the first part in a series of posts analyzing updaters in the real world. I’m doing this for programmers considering writing their own updater, people considering buying wyBuild & wyUpdate, and for usability freaks like me.
I hope to teach you a bit about the usability aspects of delivering updates to your users. Ultimately, though, I want to teach you about building a great updater from scratch.
FileZilla Client is a popular FTP program for Windows, Mac, and Linux. I’m going to be showing you the updater the Windows version of FileZilla Client. Specifically I’ll be running it in Windows XP SP3.
To test the updater I installed the version previous to the latest version. Upon my first run of the FileZilla Client I was presented with the updater screen:
The first updater screen is spartan and to the point. It lists the changes and gives the user a reason to update. Plus, the “What’s new” box lists versions all the way back to the version installed. (Instead of just the changes in the latest version)
But there are a couple of problems. The visit link “http://filezilla-project.org …” isn’t clickable. It’s useless. No user will type it into their browser. If they do anything at all it will be to go to google and type “FileZilla”. Non-clickable links are a waste of space. Never ever add them to your program or updater.
What’s “Next”? If your users don’t have a sense of how long the process is going to take they’ll just give up. Don’t give them a reason to quit. Make it a specific action; change the “Next” button to “Download” or “Update”.
Clicking the ‘Next’ button brings some of the oddest behavior:
A save dialog? Really? I don’t care about saving anything. I want to update. Don’t think for a second about mimicking this behavior. For the users it doesn’t confuse, it will piss off.
What they should have done, and what you should do if you’re building your own updater, is silently download the update file to a temporary folder. Then, after the updates have been installed, delete the file.
The downloading screen is another spartan screen. And the information it does have is useless to the user. The user doesn’t care where the file is being downloaded from. They might care what is being downloaded.
Don’t write “Downloading http://downloads.sourceforge.net/filezilla/FileZilaa_3.2.6_win32-setup.exe”
Write “Downloading FileZilla 3.2.6” or “Downloading update”
Now you have to decide if your time is more valuable that your users’ time. The FileZilla developer thought his time was more valuable. Instead of quickly installing the update while remembering all old settings, FileZilla instead chose to show an installer:
The more usable thing – the right thing – to do is to handle all of the details without asking. Users don’t want to change settings, they want all the benefits of bug fixes without changing what was working before. In other words, don’t nag your users with minutiae. You’re the programmer, you make the decision.
The updates are installed, and the installer prompts me to run FileZilla Client. Here’s the first screen I see:
This is a completely useless dialog. There’s not one bit of actionable data. Or to be more cruel, let me analyze it line-by-line:
“Welcome to FileZilla 3.2.6”
An utterly pointless statement. Imagine if every application on your computer welcomed you.
“Please report all bugs you may encounter”
This is like saying “be nice.” The people who are already nice don’t need to be told, and your going to need more than that to convince the mean people.
So, don’t tell people to report all bugs. Most won’t. And the few that do report bugs, do report bugs. (I sound like Forrest Gump). Plus, there’s not even a link to a bug reporting form! Do you think people will spend 15 minutes searching for FileZilla’s bug tracker? Unlikely. If you’re going to bug us, at least give us a link.
Everything you saw above was due to FileZilla automatically checking for updates. But what if you’re a bleeding edge type of guy (or girl)?
FileZilla gets the first part right. Adding a “Check for updates” to the help menu is so common it’s practically a standard. But once you click the menu, they screw it up:
Another welcome screen! I don’t want to be welcomed. I clicked “check for updates” because I wanted you to check for updates. Just do it. If there aren’t updates, say it. If there are, then show me what’s changed and let me update.
We’re not in the dialup era. We don’t need to be warned before downloading a file. Especially not in an FTP application.
The FileZilla Client updater did a few things right. Here’s the things you should copy:
The FileZilla Client also made some pretty big usability mistakes. Here are things you should avoid at all costs:
Because I’m an asshole. Also, because I use FileZilla almost as much as I use Visual Studio, Photoshop, and Word. It’s that good.
Plus, FileZilla’s updater makes a lot of the same mistakes that proprietary updaters make.
I plan to add a few more articles to the series (Adobe’s updater is next). Then, I’ll top it off with an article or two on building a good updater from scratch. Stay tuned, subscribe to the RSS feed.
Give me your feedback – I want to hear from you.
Subscribe to the 'Wyatt Says...' RSS Feed and keep up to date on on my articles on updaters, usability, open source C# components, and software licensing.