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? :) -------------- 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/0817eaa3/attachment.pgp>
