wyDay blog

It has to be our most frequently asked question: "When will you guys add automatic updating ability to wyUpdate?"

Our answer: soon Now!. As of v2.5 wyBuild ships with a free AutomaticUpdater control.

Checking vs. Updating

First I need to clarify some confusion. Theres a difference between automatic checking and automatic updating. Its an important difference.

Automatic checking simply checks for a new version and tells your application if there's an update. You can do anything you want with that information. Usually, people just opt to distract their users and launch the updater.

Automatic updating is the full shebang. There isnt an off-the-shelf updater in existence that offers true automatic updating. For an updater to be truly automatic it has to handle everything from checking for updates (the easy part), to quickly and quietly installing the updates (the hard part).

Lies, Damn Lies, and Automatic Updating

Most off-the-shelf updaters tout their ability to do automatic updates. Its a lie. Ive personally tried all of our competitors products and the best thats offered is automatic checking with the option of launching the updater to distract the user and, oh yeah, update their product.

Dont believe me try them yourself. A quick google search will give you a list of 20 of our competitors. I wont bad mouth them by name.

Whats currently in wyUpdate?

As of wyUpdate 2.1 neither automatic checking nor automatic updating is included. The reason we dont include even the bare minimum (automatic checking) is that it introduces a huge usability problem that you, the programmer, have to solve.

Namely, what do you do once the automatic checking reports back that theres a new version? The easy answer the wrong answer is you show your users wyUpdate and force them to update immediately.

This is wrong for 2 important reasons.

1. It will distract your user. Theyre using your program for a reason. If its a business app, they have work to get done. If its a consumer app like a browser, they have Facebook to visit.
2. It will piss off your user. They will soon associate your program as the one that keeps bugging them about stuff they dont care about.

If you bug your users enough theyll start looking at your competitors products longingly. Dont push them to the edge.

You should care about updates. Your users almost never will.

Thats not completely true. Your users dont care about updates, they just want a better experience. They care about bug fixes. They care about the new great feature. But they dont want to play janitor and keep their programs in tip-top condition. Its just too much of a hassle.

Frankly, youll be lucky if 1% of your paying users actively search your website for the latest installer. Its your job to deliver it directly to your users.

Or, to put it another way, if you run a supermarket your customers will expect clean floors and fresh food on the shelves. They dont want to clean the floors or stock the shelves. They dont even want to see someone doing it. But they expect it done. If its not done, theyll only think about it in retrospect:

Hey, remember that grimy store with moldy bread? Yeah, thank God we finally have a Wal-Mart!

How will wyUpdate 2.5 solve this problem?

How do you keep your users up-to-date without bothering them? Thats our problem.

In reality its several hundred mini-problems: how do you install an update quickly and quietly when the users in a rush?, what happens if the user shuts down the computer mid update?, what if the user isnt an administrator?, what about Vista UAC?, should the updater be run as a service or a process?, how often should the updater discreetly check for updates?, what happens if the user manually checks for updates when the automatic updating is currently in progress?, what if the files are read-only?, etc, etc, etc.

Weve solved these mini-problems in wyUpdate 2.5. Were currently integrating and testing our solution for the thousands of edge cases.

Besides all of the behind-the-scene changes were making to wyUpdate, were also creating a new open-source component that you can include with your .NET application. It will handle all of the complexity that goes into integrating auto-update directly into your program.

Here are a few screenshots to show what we have in store:

Download the wyUpdate C# source

You can watch our progress as we add automatic updating ability to wyUpdate by checking out the sources from our subversion repository:

svn checkout http://wyupdate.googlecode.com/svn/trunk/ wyupdate-read-only

Or you can wait until its finished and read our full tutorial and download the full source zip file. The tutorial will be extra technical and will feature loads of C# code.

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.

What's FileZilla Client?

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.

First encounter with the updater

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:

First 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.

Playing Russian Roulette (clicking the Next button)

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.

Downloading

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

Installing would you like fries with that?

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.

First run: Welcome!

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.

Manually checking for updates: Welcome!

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.

What can I learn from FileZilla's updater?

The FileZilla Client updater did a few things right. Here's the things you should copy:

1. Give your users a reason to update (always show what's changed in the latest version)
2. Add automatic checking (something our own wyUpdate is missing)

The FileZilla Client also made some pretty big usability mistakes. Here are things you should avoid at all costs:

1. Non-clickable links. No one wants to transcribe your links into their browser. They just don't care.
2. Stupid welcome screens.
3. More information than users need. (e.g. download FileZilla.exe from a server located in California instead of downloading FileZilla)
4. Prompting the user to save files. (Just save your file to a temp folder. Clean up when you're done.)

Why are you picking on open source software?

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.

What's next?

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.

If you've done any Windows Forms designing then you've undoubtedly used the LinkLabel control. You've also likely noticed its hideous look:

The ugliness of the LinkLabel that ships with Windows Forms is four fold.

1. The repulsive navy blue color reminds me of Netscape Navigator (anyone else remember the graceful Illegal Operation crashes?).
2. There's no hover effect. OK, I lied. There's a hover effect but you have to code it. And if you do code it, you better put on your epilepsy goggles it's gonna flicker.
3. The non-standard hand cursor is missing the shadow and the gradient.
4. The LinkLabel font is oddly rendered:

The Windows.Forms LinkLabel looks as though the text was drawn to the screen once, then drawn again without erasing the first copy. This gives the LinkLabel a jagged, blocky look.

LinkLabel2 - How I fixed it

It was a simple bit of code. I used 'TextRenderer.DrawText(...)' to do the actual drawing. The hand cursor was simply a matter of intercepting the WM_SETCURSOR message to my LinkLabel2 control:

[DllImport("user32.dll")]
public static extern int LoadCursor(int hInstance, int lpCursorName);


[DllImport("user32.dll")]
public static extern int SetCursor(int hCursor);


protected override void WndProc(ref Message m)
{
    //WM_SETCURSOR == 32
    if (m.Msg == 32)
    {
        //IDC_HAND == 32649
        SetCursor(LoadCursor(0, 32649));


        //the message has been handled
        m.Result = IntPtr.Zero;
        return;
    }


    base.WndProc(ref m);
}

But what about SysLink?

SysLink is a link control added to ComCtl32.dll in Windows XP. So, why not use SysLink? Because SysLink doesn't exist in Windows 2000/98.

Maybe in 3 years, when Windows 2000 is dead, a simple SysLink wrapper for C# can be written.

Get it

It works with all the .NET 2.0 + languages (C#, VB.NET, etc.).

Download LinkLabel2 now

Also while you're at it download wyUpdate, or any of my other open source projects.

Go to the LinkLabel2 site for further updates.