The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.
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 person?
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.
wyUpdate & wyBuild 2.0 are now out. This new version has several improvements, most notable is the speed increases in both wyBuild and wyUpdate.
Now you can build update patches and release them to your users faster than before.
Managing past and future versions of your software is simple. Just drag the files into wyBuild. Adding registry modifications is just a simple and intuitive. You won't even need to visit the help documents or the forum (but they're there just in case you get stuck).
New in wyBuild 2.0 is an improved tab bar for version management. Not bullshit market-speak improved either. Really improved.
What happens when your version tabs exceed the width of the tab bar? Popular browsers like Internet Explorer & Google Chrome squish down the text to unreadable widths:
The w and Sou are some of my favorite sites. Clearly IE's and Google Chrome's tab management approaches are flawed. We took the Firefox approach and kept the tabs at readable widths so can actually tell the difference between 1.0.3 and 1.0.4 (or as IE would show it 1.0... and 1.0...).
Plus, in wyBuild you can just hover your mouse over the version tabs and scroll your mouse to see all of the versions.
We're thinking about releasing the C# source code to this. Tell me your thoughts in the comments.
wyUpdate now comes with full multi-lingual support. You can add, edit, or select any of the many languages in wyBuild and include them with wyUpdate. The correct language is then used when wyUpdate automatically detects the language of Windows and applies that language.
The wyUpdate source code is now hosted over at Google Code. You can now checkout the source code using subversion:
svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate-read-only
Or, if you prefer the zip of the source, just head over to our wyUpdate page.
wyBuild 2.0 solves a few major problems with patch creation. The biggest fix is that wyBuild now properly support patching files with Unicode filenames. This fix will be especially noticeable for our non-English speaking users.
The patches created by wyBuild are much smaller than just zipping files. And much much smaller than releasing a new installer for every update to your program.
An example to illustrate my point is Nero Burning ROM. Nero Burning ROM is CD/DVD writing software that has been popular for many years, and Nero is updated frequently. One big problem, though, is their lack of a good update creation and distribution method. Instead of using a program like wyUpdate, they release full installers as their updates. That's over 300 megabytes for very small changes to Nero.
The graph below shows how enormous just the bare minimum installation of Nero Burning ROM program is. Notice the tiny size of the update when created with wyBuild (just over a megabyte!):
We're now offering free licenses to people developing open source programs. See the details of the offer. This offer also applies to educational institutions.
Celebrating the 2.0 release, wyBuild costs only $20 until July 20th. Buy it now.
I've gotten a few e-mails about the wyUpdate source being corrupt. It wasn't. It just appeared that way if you used any decompressor other than 7-zip. This was because I used LZMA compression for the file. Only 7-zip understands that brand of compression.
At any rate, I've uploaded the newly zipped wyUpdate source code that should work with generic compression programs (WinZip, WinRAR, etc.).
I've also been testing wyBuild and wyUpdate with Windows 7 - it looks nice. I especially love the subtle touches to the taskbar buttons. The background adapts to the color of the wyBuild icon when the mouse hovers over it:
On these pre-release versions of Windows 7 both wyBuild and wyUpdate run perfectly.