After several clicks and long waits, I finally made it to this screen:

And things just stopped there.

It’s a good thing I had Safari so I could, like, browse the web.

You can go ahead and blame sqlite manager if you like, since it was probably that website that was down. However, it was Firefox’s development team that made the decision that updates should block, require multiple clicks and application restarts to install, and not have a useful Cancel button. The server being down merely made things slightly worse.

Namely, that’s the ability to zoom out to get the big picture of a web page.

It’s true that this is a lot less necessary on the desktop due to the large screens on many systems, but that doesn’t mean it isn’t necessary at all. On my PowerBook, a lot of things scroll. Even on this iMac I’m using write now, the “New Post” screen scrolls.

A large image is already zoomed out in desktop Safari, so why not a large web page? I should be able to hit, say, F7 and have the page fit my window and click to zoom in on a part of the page.

While Apple is at it, they can add some indication that you’ve been zoomed out to images.

Here’s an example of the current view, using Macworld’s website:

You see a bit of the page, and can scroll for the rest.

But here’s what the zoomed out look would look like:

(In reality, this might be zooming out too much.)

Now imagine that scrubbing with the mouse pointer shows the area in more detail:

We haven’t got an obvious win yet, but we’re well on the way to something useful. I bet Apple’s engineers could make this an obvious win.

I’ve done some thinking on this subject.

Should you wait on an update check before presenting the UI? Should you ask them if they want to update? If they do want to update, should they need to go through a web browser to download the update? Should it be a standard installer?

One principle I like for automatic update is this:

Assume the user launched your application because they want to do something.

All of these questions have answers that developers assume they know, but when you start looking at it from a user perspective, things are very different.

Update checks shouldn’t be blocking.

Should you wait on an update check before presenting the UI? Let’s imagine your host goes down, and the user is stuck waiting and waiting for your application to launch. Or maybe the host is just slow; that’s even worse. The best case is the user is disconnected from the Internet and failure is immediate.

This doesn’t mean you shouldn’t start a check, of course. Go ahead. Make it run in the background. If the check finishes before the UI is loaded, you can adjust the UI. Otherwise, you can remember for next launch.

Update requests shouldn’t be blocking, either.

Decide if you’re going to apply the update automatically or not. The answer should usually be no.

If the update does need to be applied automatically, install it when it won’t impose (if you can judge when that will be, and if such a situation even exists).

If the user doesn’t need to update immediately, offer the update in a prominent place within your program, but don’t make them click to refuse it. Clicking “Not Now” is just going to become a habit. And don’t just tell them a new version is available and direct them to a web site. When they want to investigate, tell them why they’d want it! Replace nagging with good information.

Make the update as pain-free as possible.

Download the update yourself. Whether automatically or on-demand, apply it yourself.

The decision whether to apply the update can be a painful one for users. It’s your job as a developer to provide the information users need to make that decision, and to do it in a way that encourages (rather than demands) the decision be made, and to eliminate any unnecessary pain associated with the update.