User Experience Stack Exchange is a question and answer site for user experience researchers and experts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am working on an app that starts installing any pending updates when a user logs off the (Windows) workstation. The finished app will look like this (minus 'button1'):

enter image description here

Our branding is in the corners, so when it's full screen it won't be so bunched together.

As some of us know, system updates are a thorn in the typical user's side. Perhaps they don't understand the necessity of the process, don't care, or both. So, there will likely be some frustration involved as the users see this. In the middle is a traditional Windows Progress bar that hooks to a timer, which updates the progress every 5 seconds (it's tied to the progress of the actual updates, so it's fully functional and won't move unless there's real progress made).

My aim is that when user's can see the progress and that will ease some tension, of course the main goal is to limit calls to the helpdesk in the process of deploying updates.

I was thinking about adding the name of the update that is currently installing, and/or the current time: Something to let users know that the install isn't frozen.

My question: Is this the most effective way that this can be done? With regards to presentation of progress and lack of information, both done with the goal of lowering frustration.

share|improve this question
Why, why, why at log off? When I log off, I want the computer to shut up as quickly as possible. There is hardly anything more frustrating than telling my laptop to shut down and then having to wait for updates before I can go home... Rethink your strategy. Download the updates during normal application usage, perform the installation of the update as soon as downloaded and regardless of whether the app is running. If you can't replace the running executable you can often rename it and put the new version of the exe there as well. Next time user starts the app, it will be with the new version. – Marjan Venema Jun 7 '13 at 16:13
@MarjanVenema I understand what you're saying, but it's either at log off or during some time when the user is using the machine. These aren't app updates, but Windows Updates. Since this is UX it is very much on par to warrant a separate question, so I'll probably ask it to see what the consensus is. – BigHomie Jun 7 '13 at 16:41
Do the users need to perform any action after the update? – rk. Jun 7 '13 at 18:22
A reboot may be necessary, depending on if the files were in use during the initial attempt. – BigHomie Jun 7 '13 at 18:38
up vote 1 down vote accepted

There is some research that has gone down in this field. One is the Rethinking the progress bar, where researchers found that halts in the process; where the user couldn't see that anything was happening, was detrimental for the perceived time of process. Even though two processes took the same amount of time, the one that displayed more feedback of what was actually happening was perceived as being a lot faster. Thinking about it logically it makes a lot of sense.

In your case I would therefore encourage you to update the progress more often than every 5 seconds. And let me emphasise that you only need to update it visually, even though you only get actual process updates every 5 seconds you can still provide visual reinforcement to the user that the process hasn't halted. Update the label of what's being done in the middle of the process with another text, add an animating ellipse, animating progress bar, etc...

In addition to this, what the researchers also found was that the perceived time of a process was greatly decreased if there was an exponential increase of speed as visual feedback. Meaning, if two processes started at the same time where one started off slowly to later catch up in speed and finishing very fast and the other went along the same speed for the entire process, the one with the acceleration behaviour was perceived as being faster.

share|improve this answer

Your Answer


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.