Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 7 down vote favorite
2

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.

share|improve this question
Don't forget the 'never' option. :-) – PhillipW Jun 28 '12 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 '12 at 2:31

6 Answers

up vote 5 down vote accepted

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.

share|improve this answer
Great pattern! I'd take a step further by increasing the snooze time immediately - +1 day, +2 days, +4 days, etc. – dnbrv Jun 28 '12 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. – greenforest Jun 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 Venema Jun 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. – rsparis Jun 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 Leach Jun 28 '12 at 8:58
show 7 more comments
up vote 1 down vote

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)

share|improve this answer
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 '12 at 12:32
When the widgets are not shown, can you quickly update, restart them and restore their current state? – Danny Varod Jun 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. – Evenio Jun 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 Varod Jun 28 '12 at 13:33
up vote 1 down vote

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

share|improve this answer
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 '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) – Evenio Jul 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 Grose Jul 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 Grose Jul 1 '12 at 3:47
up vote 0 down vote

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.

share|improve this answer
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 '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. – ewino Jun 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. – Evenio Jun 28 '12 at 12:21
up vote 0 down vote

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.

share|improve this answer
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 kumbham Jun 28 '12 at 11:47
This is generally not possible as a Dashboard widget. – Kit Grose Jun 30 '12 at 13:49
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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