Timeline for How to tell the users about a unpredictably long process?
Current License: CC BY-SA 3.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 25, 2017 at 11:27 | history | edited | Dominik Oslizlo | CC BY-SA 3.0 |
Additional idea.
|
| Mar 24, 2017 at 12:51 | comment | added | T.E.D. | @WumpusQ.Wumbley - That is a lot of people's first impression. But the program goes unresponsive while that eye is scanning, while KITT you can't shut up. So its clearly not KITT, but something much more nefarious. | |
| Mar 24, 2017 at 12:17 | comment | added | user46933 | @T.E.D. As a child of the 80's they indicate to me that K.I.T.T. has taken over my computer, and I may use Turbo Boost once per episode | |
| S Mar 24, 2017 at 10:43 | history | suggested | Ismael Miguel | CC BY-SA 3.0 |
Grammar changes, improved writting consistency and smaller corrections.
|
| Mar 24, 2017 at 10:11 | review | Suggested edits | |||
| S Mar 24, 2017 at 10:43 | |||||
| Mar 23, 2017 at 18:27 | comment | added | Shane | @T.E.D. I think you might be conflating 'user happiness' with 'user perception of time'. But yes, If you tell your users that it will take 10 minutes but you finish in 5, they'll be pleasantly surprised. Whether you value 'pleasant surprises' or 'giving accurate information' will depend on the app type of being used, the duration the bar will be there, and on the type of users using the app. If I'm seeing the progress bar once a month, I'd like to get good surprises. If I see it wrong 20 times a day, eventually, it will annoy me. | |
| Mar 23, 2017 at 18:17 | comment | added | T.E.D. | @DominikOslizlo - As a child of the 70's those always indicated to me that the Cylons have taken over my computer, and are waiting for a good moment to strike. | |
| Mar 23, 2017 at 18:10 | comment | added | T.E.D. | @Shane - Which again goes against the studies I've seen, which IIRC indicate users happiest with progress bars that accelerate rather than either decelerate or move at a constant rate. Theoretically a truly accurate one would move at a constant rate. Here's one (pdf) that I think shows this. | |
| Mar 23, 2017 at 17:55 | comment | added | Shane | @T.E.D. Dominik is talking about accuracy of the continual progress. Users don't like to see something climb up to 75% in four seconds, wait there for 5 minutes, then jump to 100% and be done. What users is want is to be able to say that if it took 1 minute to go from 0-10%, it should finish in around 9 more minutes. | |
| Mar 23, 2017 at 9:44 | comment | added | Dominik Oslizlo | @roel - Indeed, the back-and-forth bars are not, in fact, progress indicators, they only communicate that the system is busy at the moment. | |
| Mar 23, 2017 at 9:40 | comment | added | roel | @T E D There is a difference in a progress bar, going from 0 to 100% and then the job is done. And a bar that goes back and forth. Like a spinner, but then a bar. For the last one, it is indeed so that users are happier if it accelerates. | |
| Mar 23, 2017 at 9:22 | comment | added | Dominik Oslizlo | @Martín-BlasPérezPinilla - well, I would not generalise here. I think often they are, however they may just seem so, as the most perceivable thing about a progress for a User is time while progress bars often refer to what is happening in the background. And remember that in some cases you can make the "progress experience" a real masterpiece: youtube.com/watch?v=77k-eNscp2k :) | |
| Mar 23, 2017 at 8:35 | comment | added | Martín-Blas Pérez Pinilla | Usually, progress bars are a total fraud. | |
| Mar 23, 2017 at 6:59 | history | edited | Dominik Oslizlo | CC BY-SA 3.0 |
Grammar, one obsolete word removed.
|
| Mar 22, 2017 at 22:54 | comment | added | Dominik Oslizlo | @jlmg – I think you may be right about a lot of situations, but for another lot of them the actual, verbose status does not matter until the User feels there is a problem – only then they refer to it. As an example, I never had a need to analyse what happens behind all these dial-up sounds back then: youtube.com/watch?v=gsNaR6FRuO0 The only thing I was waiting for that really did matter was that sweet sound of silence at the very end of them. | |
| Mar 22, 2017 at 22:01 | comment | added | JoL | @DominikOslizlo but even if he can't comprehend what they mean exactly, when he sees the text change, that tells him that progress is being made, and that the program is not infinitely stuck. I think that's the main value these lines have over a simple spinner, as long as it doesn't stay stuck on one particular line for too long (in that case one might want to split it up into its constituent steps). | |
| Mar 22, 2017 at 21:18 | comment | added | Dominik Oslizlo | @WoodrowBarlow, this is a really good idea, as long as the things that happen behind the scenes are something that User can comprehend. | |
| Mar 22, 2017 at 21:14 | comment | added | Woodrow Barlow | if the wait is inexact but known to sometimes be quite long, what about also displaying which phase of the process you're on? like, display "Connecting to server...", "Accessing profile...", "Making changes...", "Closing connection...". i will admit i don't have any UX training, but that usually makes me feel more comfortable when i've been staring at nothing but a spinner for 30+ seconds. | |
| Mar 22, 2017 at 20:23 | comment | added | Dominik Oslizlo | I think this is very true if you only can assure that the process concludes within some short time. Should it be guaranteed 3-5 seconds, I would not hesitate displaying 0-40% progress within the first two secs, then topping it up after the process is done. But one minute - well, that is a lot of time to get frustrated... | |
| Mar 22, 2017 at 17:55 | comment | added | T.E.D. | Interesting that this and other answers are insisting on accuracy in the progress bar. I had read that users are actually much happier (and think it went faster) if you tweak the bar so that it accelerates. | |
| Mar 22, 2017 at 10:18 | history | answered | Dominik Oslizlo | CC BY-SA 3.0 |