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.

Update Later Skip 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.

  • Don't forget the 'never' option. :-)
    – PhillipW
    Jun 28, 2012 at 13:33
  • Because of the simple function of the widget, I don't exactly foresee updates coming hard and fast, so the "Skip" button should be almost as good as "Never". :)
    – Evenio
    Jun 29, 2012 at 2:31

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.

  • Great pattern! I'd take a step further by increasing the snooze time immediately - +1 day, +2 days, +4 days, etc.
    – dnbrv
    Jun 28, 2012 at 4:45
  • +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. Jun 28, 2012 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? Jun 28, 2012 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.
    – rsparis
    Jun 28, 2012 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). Jun 28, 2012 at 8:58

I would offer non-time related delays e.g.

  • Next time I open this application (when there are no other open instances)
    (useful if update is fast and does not require restart)

  • When last instance of application has been closed
    (useful if update is not fast and does not require restart)

  • Before I next shut down/log off/restart my machine
    (useful if update requires restart)

  • 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.
    – Evenio
    Jun 28, 2012 at 12:32
  • When the widgets are not shown, can you quickly update, restart them and restore their current state? Jun 28, 2012 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.
    – Evenio
    Jun 28, 2012 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). Jun 28, 2012 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!)
    – Evenio
    Jul 1, 2012 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)
    – Evenio
    Jul 1, 2012 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 Grose
    Jul 1, 2012 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 Grose
    Jul 1, 2012 at 3:47

Is there any reason why the user will want to skip an update?

I actually like the way Firefox deals with updates, which I think can also work in your case:

  • Update is downloaded silently.
  • On next boot up or application start, the application updates automatically.

If the application does not need a restart after installation, you can even install the updates silently, and then pop up a small message saying that it has been updated.

  • 3
    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, 2012 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.
    – ewino
    Jun 28, 2012 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.
    – Evenio
    Jun 28, 2012 at 12:21

I would suggest to install it silently without annoying the user,when user next time use the application just say that you are updated.But it depends on the kind of application and kind of updates.

  • 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, 2012 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. Jun 28, 2012 at 11:47
  • This is generally not possible as a Dashboard widget.
    – Kit Grose
    Jun 30, 2012 at 13:49

I'd go with rsparis's approach, but would also consider using a bit of behavioural thinking - consider a message that indicates to the user that a majority of other users of the application have already updated - see http://www.psychologicalscience.org/observer/getArticle.cfm?id=1762 for how this concept was applied in hotels.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.