On Fri, Nov 6, 2009 at 1:45 PM, Matthew Toseland <toad at amphibian.dyndns.org> 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. :)
Some of that nuisance could also be alleviated through improved documentation. Then again, improved documentation might bring enough more users to offset that :) > > 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%. Presumably Freenet knows, as soon as it downloads the broken block (before then?), that said block is unusable. It should simply not count that block as part of the progress bar. This has other implications too. I think the stalled downloads bug is fixed, but it would have been nice to not have to wonder whether some instances were actually broken progress bars. If it shows 100%+, it should either be decoding or indicate a stalled download type bug. > > 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. :) > Another idea for improving progress bars: divide them vertically. Say we're downloading the second layer (known not final) of a splitfile. The top 1/4 of the progress bar is shown full (the already downloaded top block), the second 25% is shown part-full (current layer in progress), and the bottom half is empty (all future layers). Always have the bottom layer take up 50% of the vertical space, and divide the top 50% evenly between all past / current layers. The idea is to give a visual indication of what's happening: we're making forward progress, but the goalpost is moving. It's a little complicated, but I suspect it gives the right idea visually. Details would need to be tweaked after looking at a mockup, of course :) Of course, having good info in the top block would help as well. (BTW, 3667 is a semi-dupe of 3369.) > 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? :) I think most of our users are smart enough to figure it out :) There's the other question, though: why does it take 5-10 *seconds* to go from having the index downloaded to displaying results? It's only a few tens of MB of data, and it's in a fairly simple format. Several seconds to parse that on a multi-core, multi-GHz machine is abysmal. Does Library really need such a huge memory footprint? Freenet can decode the file fine without more memory, but Library regularly OOMs on large indexes with the default memory limits, even though it isn't actually using that large a piece of the file. Evan Daniel
