I'm designing a simple application (an OS X Dashboard widget, in this case) which the user might use multiple times a day, or hardly ever. When it detects that a newer version is available, I intend to display a small dialog asking them what they want to do about it. For example:

Version 1.1 is now available; you have 1.0.

UpdateLaterSkip 1.1

If the user clicks "Later", they'll be reminded again after X amount of time has elapsed. My question is: how much later should "later" be? 5 days? 10? 15? A month? I imagine the answer might vary between different kinds of applications.

6 Answers
6

There is another concept I've seen somewhere, I can't remember where but I'll try to dig up a reference. The concept is to define this length of time by their previous actions. i.e. if it is the first time they have dismissed the update tell them again the next time they boot up/log in, however if they have dismissed it multiple times you don't want to keep annoying them each time they login so you might leave it a week before notifying them again.

The negative side to this is that although the user isn't annoyed by the updates, it also makes it easier for them to ignore the update altogether and continue using the old version.

+1 @rsparis The negative side could be tackled the same way. After the user postponed x times the messaging could change. Or, in case of critical updates, they could have a different, more highlighted message.
–
greenforestJun 28 '12 at 6:16

+1 But how is it a negative that a user may ignore an update and continue using an old(er) version? Surely, that is his choice?
–
Marjan VenemaJun 28 '12 at 6:30

1

@MarjanVenema I only meant it as a negative for the developer/company because it will cause fragmentation with many different people potentially running many versions of the software. Of course this would depend on how often updates are released, and it just means that more testing would have to be done.
–
rsparisJun 28 '12 at 6:57

@rsparis Every version should be tested, so whether a user implements them or not won't make a difference to the amount of testing. If older versions are found not to work with [software X] then presumably the release notes will say that (and a link to those should be included in the dialog so the user can find out about the update).
–
Andrew LeachJun 28 '12 at 8:58

In my particular case — a Dashboard widget — all instances of the application are meant to resume their state whenever the Dashboard "widget layer" is shown (as if they had never closed), and rarely be individually removed on purpose. Good ideas, though.
–
EvenioJun 28 '12 at 12:32

When the widgets are not shown, can you quickly update, restart them and restore their current state?
–
Danny VarodJun 28 '12 at 12:59

Unfortunately, no; widgets have to stop whatever they're doing and go dormant when the Dashboard is dismissed, to avoid usurping CPU cycles from apps the user is actually using.
–
EvenioJun 28 '12 at 13:28

Widgets usually don't have much of a user state and load pretty quickly. Couldn't you replace them on load without bothering the user (like Chrome does).
–
Danny VarodJun 28 '12 at 13:33

One option is to put an "Update Now" link somewhere unobtrusive but visible on the widget itself when an update has previously been deferred (or on the back of the widget would seem appropriate).

With Dashboard widgets you need to be careful not to throw up sheets or other modal alerts because the OS can sometimes expose them to the user (try running a proxy that requires authentication to get to the web and see how many login prompt sheets you get on the desktop in Snow Leopard at least).

The best option for me personally (as someone who uses the Dashboard a lot at once then not at all for a few weeks) would be to wait until the following day (and even then, only if the Dashboard is opened). The alternative is to give them a drop-down, like "Remind me in 15 mins/an hour/a day/never".

As a user I care more about knowing the changes in an update than being told when it's available (I skipped a huge 100 MB+ update to VMware since all it added was improved support in Lion, which I wasn't running at the time).

You raise some good points. The way it's planned now, the dialog will be in the form of a div which fades in over the widget itself, not a separate OS-native message window. (While I left that detail out in the interest of generalizing the question, I suppose it made my specific plans unclear!)
–
EvenioJul 1 '12 at 0:16

(continued) This is the layout I was originally considering, but I like your drop-down menu idea, too. Something like this, maybe? (Also changed the "Update" button to "Learn More" to clarify it was taking the user to an informational page, not executing the update then and there)
–
EvenioJul 1 '12 at 0:23

@Evenio: The only thing I notice is that the drop down (which I can't take credit for; it's a Windows Update thing at least) is a little uncomfortable in that tight space in that it has no button (presumably the idea was to submit onchange).
–
Kit GroseJul 1 '12 at 3:45

@Evenio: Given the way you're planning to implement it in Dashboard (relatively unobtrusively), it's OK to err on the side of too soon (one day at the longest), because it shouldn't affect the user's experience too much.
–
Kit GroseJul 1 '12 at 3:47

What I dislike about Firefox's updating, is that it sometimes starts doeing so when I want to quickly pull up a webpage. Thank <insert Deighty> updating/installing browsers doesn't require a system restart anymore even on Windows, but it is still an annoyance to be confronted with a "please wait while installing updates" dialog when I'm trying to quickly check the train schedule or something.
–
AndréJun 28 '12 at 5:15

Chrome takes it a step further and updates your program (usually) without you even noticing it. However, I extremely dislike it, as it makes me feel I have no control over the software I have installed on my computer. I'd like to be able to choose (as a user) when to install, update, and uninstall any program I use, and that's one of the reasons (not the only one though) that I don't use Chrome. Flash has it right by giving you the option to "auto-update" instead of notifying you every time there's an update.
–
ewinoJun 28 '12 at 10:58

That's not a bad option in some cases, although I'd still prefer to give the user the choice to update (releases won't be frequent enough to become an annoyance in and of themselves), and I'm not entirely sure I could do all of that from within a Dashboard widget. Besides, this widget can have multiple instances open, and I wouldn't want five widgets auto-downloading five copies of the same update, especially if they're about to try to install it five times over. The current behaviour of the "Update" button is to open a page in the user's browser with a changelog and download link.
–
EvenioJun 28 '12 at 12:21

While this may or may not be a good approach for updates in general, it's not really what the OP was requesting. It's specifically about if the user chooses not to install at that time, not whether or not that prompt should be shown to them.
–
JonW♦Jun 28 '12 at 11:35

a time derived based on the user experiance with the application would be better idea, a regular user requires a shorter reminder and casual user would rquire a longer reminder.
–
dilip kumbhamJun 28 '12 at 11:47

This is generally not possible as a Dashboard widget.
–
Kit GroseJun 30 '12 at 13:49