The wyDay blog is where you find all the latest news and tips about our existing products and new products to come.

wyDay blog

Posts in the ‘aesthetics’ tag

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.

A question I see raised often on forums is some variation on "how do I get menus that look like Vista's menus: icons with the baby-blue selection highlight." Or, how do I get my menus to look like Windows Explorer context menus:

Windows Explorer menu in Vista

The first thing you should notice is the light-blue gradient used for the selection highlight. The second thing is the alpha-blended icon (that is, the icon has partially transparent pixels that blend nicely with the light-blue gradient).

But how do you get that look without owner-drawing your menu items? There was a nice post over at Mircosoft's Shell Blog describing how to do it in C++. I've taken the applicable parts of the C++ code and ported them to a nice little interface for .NET languages. That is, you'll be able to use my code with C#, VB.NET, and any other .NET languages that exists.

Here's a screenshot of the interface I created (called VistaMenu) running in Windows Vista, Windows XP, and Windows 98:

VistaMenu on the InstantUpdate Designer

As you can see, I took the time to make sure the VistaMenu worked and looked good even in the older Windows systems.

How to use VistaMenu

You need to add ContextMenu, MainMenu, and VistaMenu controls to the Visual Studio toolbox:

  1. Download VistaMenu, and extract the zip archive somewhere on your computer.
  2. Right click the Toolbox and click 'Choose Items...'
  3. In the dialog that pops up, scroll down to 'ContextMenu' and click the check box.
  4. Also, scroll down even further to 'MainMenu' and click the check box.
  5. Now, press the 'Browse...' button and find the 'VistaMenu.dll' you downloaded and extracted earlier. Make sure it's checked in the list.
  6. Press 'OK' on the dialog box.

This should add all the necessary controls to the Toolbox. Now just drag the VistaMenu control to your form (you only need one VistaMenu per Form), a MainMenu, and any number of ContextMenus.

All you have to do now is click a menu items, and in the the Properties window select an Image. No messy ImageList is necessary:

Using VistaMenuYou should know...

As I mentioned parenthetically above, you only need one VistaMenu per form. This one VistaMenu component handles all the MenuItems for the MainMenu and all ContextMenus on your Form. If you add more than one 'VistaMenu' component you'll waste resources and your program will likely crash.

Also, VistaMenu is for ContextMenus and MainMenus, NOT ContextMenuStrips and MenuStrips. They're completely different controls.

Also out, SplitButton 2.0

Version 2.0 of the SplitButton adds support for ContextMenu in addition to ContextMenuStrip. Now you can use the shiny new VistaMenu with the SplitButton.

This is a breaking change, however. Previously you had to set the 'SplitMenu' property with a ContextMenuStrip, but in this version there are two properties: 'SplitMenu' and 'SplitMenuStrip'. Where 'SplitMenu' takes a ContextMenu, while 'SplitMenuStrip' takes a ContextMenuStrip.

Questions, comments, complaints...

Take a trip over to the forum and let me have it. No registration is required, and all input is welcome.

Download VistaMenu: Includes the source code, a compiled binary, and demo projects for both C# and VB.NET.

Download SplitButton v2.0: Includes the source code and the compiled binary. It works with every .NET language.

InstantUpdate 1.0 Release Candidate 2 is out now. This is a fairly large release; it has more bugs fixed and features added than any previous version.

New features:

  • InstantUpdate Client is now translated to 11 languages (Chinese, Dutch, French, German, Italian, Japanese, Korean, Portuguese, Russian, Spanish, and Swedish)
  • Create and edit translations using the new translation editor
  • InstantUpdate is now code signed which produces friendlier warnings when Vista's UAC elevation is needed
  • Appearance templates can be edited
  • Files can now be executed either before or after your update
  • Programs created with the .NET Framework are automatically optimized

Notable Bug fixes:

  • InstantUpdate Designer correctly supports Windows Explorer drag and drop.
  • Full support for custom set fonts, including Windows Vista's SegoeUI
  • InstantUpdate Designer starts and runs considerably faster
  • Keyboard accessibility improvements
  • Vista's UAC elevation is only called when absolutely necessary
  • Plus much more.

And, as always, the forum is open for questions, comments, bug reports, and general help of any kind. No registration is required, just drop by.

Download InstantUpdate 1.0 RC 2