Rethinking the Progress Bar (2007) [pdf]
chrisharrison.net
Rethinking the Progress Bar (2007) [pdf]
1–10 of 63 posts
Re: Rethinking the Progress Bar (2007) [pdf]
#2Re: Rethinking the Progress Bar (2007) [pdf]
#3Results:
Participants tended to prefer (i.e., perceive as faster) whichever function they saw first. Of the 990 paired com- parisons, the first function was preferred 376 times (38%), the second 262 times (26%), with no preference 352 times (36%).
Re: Rethinking the Progress Bar (2007) [pdf]
#4These researchers presume that their goal is to make users think that an operation is happening quickly, even if it is slow.
I thought the goal of a progress bar was to report reality, not manipulate users into thinking that your slow code is faster than it actually is.
Since when have dark patterns infiltrated academic HCI?
Re: Rethinking the Progress Bar (2007) [pdf]
#5I'm still waiting for a neural net progress bar as a service that pipes in all available device data, measurable progress and a task id and spits out a prediction based on previous runs across _all_ previous tasks.
Should eventually figure out what tasks are IO bound, what are CPU bound, what are fixed time, etc. as well as what device configurations effect that. Could also predict a service is down given enough scale...
Re: Rethinking the Progress Bar (2007) [pdf]
#6Cool to see article by someone I know on here! Really liked this paper, something else I find tricky about them is how hard it often is to accurately measure/report/track progress when writing software. In my experience a lot of these bad behaviors in progress bars come from programmers not having good way to actually track the real progress and instead just have to aggregate or estimate progress from each "stage" or "step" or whatever your software abstraction for a unit or work ends up being
Re: Rethinking the Progress Bar (2007) [pdf]
#7Good to see Chris Harrison doing good work after being fired from hosting the Bachelor.
Re: Rethinking the Progress Bar (2007) [pdf]
#8These researchers presume that their goal is to make users think that an operation is happening quickly, even if it is slow. I thought the goal of a progress bar was to report reality, not manipulate users into thinking that your slow code is faster than it actually is. Since when have dark patterns infiltrated academic HCI?
Its a bit harder than that, I'd say. Imaging a progress bar showing progress of two consecutive operations eg. download and process. How should that progress bar be displayed? 50% for each? If download is 30 seconds and process is half an hour that is skewed.
I am having that exact problem in an application I am developing.
Re: Rethinking the Progress Bar (2007) [pdf]
#9I'm still waiting for a neural net progress bar as a service that pipes in all available device data, measurable progress and a task id and spits out a prediction based on previous runs across _all_ previous tasks. Should eventually figure out what tasks are IO bound, what are CPU bound, what are fixed time, etc. as well as what device configurations effect that. Could also predict a service is down given enough scal…
How would that work exactly? Do you mean that you’d ship the monitoring code to all users in production, and it would monitor losing times, system attributes, etc. and phone home to your servers, where you’d use that to train a NN and ship that model back to all users?
Re: Rethinking the Progress Bar (2007) [pdf]
#10These researchers presume that their goal is to make users think that an operation is happening quickly, even if it is slow. I thought the goal of a progress bar was to report reality, not manipulate users into thinking that your slow code is faster than it actually is. Since when have dark patterns infiltrated academic HCI?
Progres bars have several goals, but making yours users happy secure that they know how long they'll spend and not feeling like they waited too long is certainly one of them.
Why do you classify that as a dark pattern? It's not harming people in any way, but the opposite.