On Sat, 15 Nov 2008, Jenna Fox wrote:

> I've found with these sorts of things, taking turns between downloading and
> installing, no matter how granular the progress, no matter how good the
> testing, the progress bars never move at a consistent rate, makes me feel
> distrusting and makes them less valuable as an indicator.

They are difficult to get right: is it in terms of time to wait, tasks
to be done, data to move?  It's all left a bit vague by the entire industry.
There has been some work mentioned on a blog whose location I forget, saying
that progress bars should start off slowly and speed up, that way people
feel they take less long.  It's all about human factors, and humans are
such unpredictable systems... :-)
> 
> It would be most awesome if it had a custom progress bar where the bar was
> marked out in two different colours.. downloading and installing, so you'd
> know what to expect in the immediate future as it progresses.

That's a really nice idea.  It occurs to me that Vimeo's videos do this,
theres a grey bit for data downloaded, and a red bit for how far you've
played.
> 
> Another option I really like is the one Flickr does, where each atomic
> operation has it's own progress bar, and even though they just go one after
> the other, it still feels dependable and good to me. We could have an itsy
> bitsy progress bar for each operation, one for each download, one for each
> install. All this information would make sure the user knew what was
> happening, and for the creators of the code it would give a nice visual way
> for them to see how rubygems operates.

Cygwin has 3 progress bars, one for the current download, one which tracks
that for the whole lot, and one for how much disk space you have. Only the
first two need be borrowed.
> 
> Still, all of this is just wild fantasy until we can get reasonable progress
> from the installation side of things. Maybe we could somehow track the line
> number a makefile is up to? pure ruby extensions don't take long at all to

Not sure about that, Makefiles don't work in a linear manner anyway, they
are essentially a dependency graph, so actions jump about the place...

> install and so are less of a worry, and I imagine could give progress simply
> as x out of y files have copied in to the local repository.
> 

This is all good stuff though: shoes is pretty strong on human factors,
so it would be good to work towards this.

        Hugh

Reply via email to