On Friday 06 November 2009 18:45:08 Matthew Toseland wrote:
> I apologise in advance to all those who think that user interfaces are a
> nuisance as they get us more users who need support and therefore are a
> nuisance. I promise there will be more technical issues soon. :)
>
> We should reconsider how we present progress bars. There are two major
> contexts:
> - Freenet requests.
> - Searches.
>
> Freenet requests are multi-stage processes where we only know the number of
> blocks to fetch, or even the number of stages, once we reach the last stage.
> Plus, moving from the last but one stage to the last stage can take some time
> - parsing huge metadata etc. We do have provision in the current metadata to
> specify the final file size in the top block, but in many cases (e.g.
> freesites) we do not even reach the top block until we have fetched several
> other smaller parts e.g. the freesite metadata, or other redirects; also it
> doesn't include the exact number of blocks, which it should. Finally,
> complications with old files can make Freenet show >100%.
>
> Currently, the progress bar jumps back and forth as it completes the
> different stages, and the percentage is shown differently depending on
> whether it has finished. And on the loading page after clicking a link, we
> even use words to explain that "The progress bar is likely to jump around as
> not enough blocks of the file were downloaded yet to know how big the file
> is."
>
> In an ideal world, all progress bars would start at zero, and would move
> linearly to the end. In a slightly less ideal world, we would meet user
> expectations by ensuring that stalls and jitteriness are at the beginning
> rather than the end, in accordance with a paper Ian referred me to. However
> the obvious linearisation strategy, of dedicating some percentage (or a
> declining percentage) to each stage, is IMHO pretty iffy for Freenet: We
> don't know how many stages there will be (although it's not likely to be
> huge), and each stage is likely to be slower than the last as each stage will
> often be bigger than the last: This will tend to aggravate users. Note that
> we display an ETA separately, at least on the loading-a-page page.
>
> So I propose that we try to represent this visually in a way that is still
> reasonably clear:
>
> We keep the ?'s. Currently we start at "0 (0%??)", this should probably be
> just "0%?". At each non-final stage, we show the ? and a progress bar with a
> light border, a border of the same color as the background, no border, a
> dotted border or something similar. The color of the progress bar itself, or
> its background, should change on each iteration. Once we reach the final
> stage, we show a solid border and use a fixed color for the progress bar e.g.
> green.
>
> Users would quickly get used to such a scheme and provided the colors aren't
> too horrible it should be quite workable. The only real challenge IMHO is
> that we actually use 4 colors in a progress bar:
> - Background/not finished
> - Succeeded
> - Failed
> - Fatally failed
>
> The last two can be combined, of course. They should be red. The text
> percentage is normally black.
> Then the question is whether we change the color of the background or of the
> succeeded blocks on each stage, and a suitable (readable) color rotation.
> IMHO we are not likely to have more than 5 or so stages, and we can rotate if
> we do. I don't want this to turn into a bikeshed argument, but any
> suggestions?
>
> We can improve this by changing the metadata to include the exact number of
> blocks in the final file at the top of the file. We would still have multiple
> stages for some files from freesites, but for most we would quickly reach the
> final stage, with an exact percentage, even if we are actually fetching the
> first of thee layers of metadata. :)
>
> Now, with Library searches, currently we show many progress bars, and quite a
> bit of text. We should really show a simple progress bar, but there are
> several complications: We can search across multiple indexes, and in each
> index we can have multiple subindex fetches (or index fetches) going on. The
> main index fetches should be satisfied from cache, and the files should
> usually be small, so normally each word fetch under the same index fetches
> the main index simultaneously, and then fetches the subindex in one stage, so
> combining the bars for multiple subindexes within an index should be pretty
> easy - we probably want two stages but we could simplify it to one stage.
> However, we can search multiple indexes at once, which can be at different
> stages. We might want to keep two progress bars in this (currently rare)
> case. Plus, the index parsing stage for each subindex can be very slow, and
> can occur while another subindex is still fetching. The combining and
> formatting stages are a bit faster but can still take a few seconds. We can
> resolve this by some fudging ... Having said that, I dunno how dumb users
> actually are - is it such a big deal that searching for multiple words in
> multiple indexes means multiple things happening at once? :)
>
Relevant bugs:
https://bugs.freenetproject.org/view.php?id=3667 - Better metadata for an exact
progress bar as early as possible, independant of the actual
multi-level-metadata stage.
https://bugs.freenetproject.org/view.php?id=3669 - The above still stands
however for freesites, and most of the time when a user sees a progress bar it
is when loading a freesite.
https://bugs.freenetproject.org/view.php?id=3668 - Library should have a single
progress bar in simple mode.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
URL:
<https://emu.freenetproject.org/pipermail/devl/attachments/20091106/8ec44081/attachment.pgp>
