[tahoe-dev] "rethinking the progress bar"

[zooko]

A blog post about  Windows XP vs. Windows Vista progress bar:

http://www.codinghorror.com/blog/archives/001058.html

A human factors study of user preference for different behaviors of  
progress bars:

http://chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf


The blog post referenced above says that file copy on Windows Vista  
feels slower to users than file copy on Windows XP, for files larger  
than 256 KiB, even though it is actually faster.  There are three few  
human factors reasons for this, all of which are relevant to Allmydata.

1. The big one issue is that Windows Vista doesn't send the progress  
bar away until the it is actually finished writing, unlike XP which  
closes the progress bar window when the last byte has been put into a  
write cache.  Vista is therefore safer -- for example, if you need to  
urgently turn off your computer, or if it is about to run out of  
power, and you are wondering if your copy will complete in time or if  
you should cancel it.  But the added delay for flushing the write  
cache is less pleasing to users because it makes it seem like the  
copy takes longer.

Lesson for Allmydata:  I firmly believe that Allmydata should resist  
the temptation to cut corners by reporting operations completed  
before they are actually completed -- the advantage of appearing a  
bit faster is outweighed by the potential disadvantage of a user  
losing their work.

2.  Another one is that the Windows Vista progress bar doesn't start  
estimating duration until the first 12 seconds have passed.  Users  
like "instant gratification" -- they launch the operation, and then  
they wait for the "okay it is now fully running" signal, which signal  
includes the display of the estimated duration.  Vista makes them  
wait longer to see that signal.  They hate that.

Lesson for Allmydata: the alacrity of transfer is important to users  
even if they aren't consuming the head of the file themselves.

3.  Another one is that the Vista progress bar is allegedly more  
sensitive to fluctuations in speed than the XP one is.  A controlled  
trial (described in the paper referenced above) shows that users  
prefer a progress bar with consistent speed over one with more  
varying speed.

Lesson for Allmydata: consistency of speed of progress meters has an  
effect on user experience.


Ticket #252 -- "smaller segments would facilitate better client  
progress indicators and better alacrity" -- is relevant to points 2  
and 3.  I suspect -- but have not proved -- that the 1 MiB segment  
size causes some user agent's progress meters to wobble.  I'm sure  
that the relatively large segment size causes alacrity to be a bit  
slower -- maybe 8 seconds longer on a 1 megabit-per-second connection.

Nobody, to my knowledge, has yet tested whether reducing the segment  
size from 1 MiB to 128 KiB makes a noticeable difference with  
Firefox, Internet Explorer, MacFUSE or Windows SMB.  If you try it  
out, please post to the list what you find!

Regards,

Zooko

tickets mentioned in this e-mail:

http://allmydata.org/trac/tahoe/ticket/252 -- "smaller segments would  
facilitate better client progress indicators and better alacrity"