On Friday 06 November 2009 23:44:52 Evan Daniel wrote: > On Fri, Nov 6, 2009 at 1:45 PM, Matthew Toseland > > > 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 :) > Can't we just stick at two bars? (if I understand right, there are 3 bars here) Do we really need to have the first 1/4 of the bar to show the progress of the top block, or could we just consider it as a layer? If we can, we could have the main progress bar (with past/current layers), and a second progress bar showing current progress (with a text on the bottom saying what we currently are fetching). It simplifies a bit, and could be a good compromise?
I don't know if you proposed to have one progress bar divided in 3, or 3 progress bars, but I also think we should separate them, because they're not displaying the same thing (and by separate, I mean with a space, not only with a border line). Another thing I wanted to say about the progress bar (I dunno if it's still like that), is that we don't need to display the menu. We should have a very clear and simple progress bar (well, 2 or 3), and display only the minimum amount of information : I always have the impression I'm still in freenet when loading a site, when I just want to browse it. I dunno if I'm clear, I hope so. We could just have a link at the bottom of the page : "go back to the freenet menu" or something like that (I let you the wording part :p). > 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 > _______________________________________________ > Devl mailing list > Devl at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
