On Thu, Dec 19, 2002 at 04:38:47PM -0800, Ian Clarke wrote: > On Fri, Dec 20, 2002 at 12:06:48AM +0000, Matthew Toseland wrote: > > > Very cool! Only thing is that it might be just as well to make the > > > colors contiguous as in Simon's screen-shot, I am not sure that there is > > The colors were not contiguous in simon's screenshot. > > Yes they were. By contiguous, I ment that we don't try to represent > each individual block. The file attached to his mail, "splitfile.JPG"... He had more than one section in each color. If you and I can't agree on what it means what chance do the lusers have? And I can't see any mention of redundancy in it. There is no line indicating where to stop, the colors are not sorted, there are several sections with each color. > > Matthew, you can nit-pick all you want in an effort to disguise the > fact that you have lost every argument you started today, but you If I argue against one proposal, and another completely different proposal pops up, I am perfectly entitled to accept the new proposal. That does not constitute losing the argument. And even if it does, I don't give a photon. Fuck the politics, the question is how do we do the interface. And AFAICS we can do one or more of: a) Implement Bombe's original scheme, with or without the bottom frames. (for large screens and freenet-savvy users, a log pane would be nice, as would a detail pane for each block when you click on it - or at least for in-progress and failed blocks). b) Implement two (or more) progress bars c) Implement one progress bar with one contiguous block of each color, the successfully fetched blocks starting at one end, and some indication of where the successfully fetched blocks section has to grow to in order to have the whole file. IMVHO, this should be indicated by a different color border up to the 2/3 point on the top/bottom/left of the progress bar, with a line down vertically across the colored blocks at that point. AFAICS Ian is suggesting that we do it with a different color or something. It doesn't matter, what matters is that it is immediately obvious that this subset is the area that needs to be filled. d) Implement all of the above and provide some easy way to stick them together - something vaguely resembling infolets, with maybe a user modifiable template. e) Implement something else that nobody has suggested yet f) Implement something else that somebody has suggested but I missed or didn't understand. g) Use the current incredibly ugly interface! :)
So, we have a number of elements we can combine to make a page: * Simple progress bar (of file or the segment) * List of blocks with individual icons, optional second pane with details of blocks * Log * Status of each current file being fetched * Unsorted multi-colored map of the current segment * Bar with distinct single color blocks representing groups of blocks of different statuses. * The same, but with an indication of where the completed chunk (or the failed chunk, approaching from the other end) has to get to to complete the segment. Any more suggestions? As far as the combination goes, a simple string substitution is easy enough to do, and as long as you can define more than one custom combination at once you can even do [i]frames with no extra coding. > aren't fooling anyone :-) Normally I wouldn't gloat, but you are being > so damn arrogant it is hard not to. Whatever, sometimes I have communication problems. Can we make some sort of truce, or am I still being arrogant, patronizing, argumentative and wrong? > > > > So, the first length of the bar could indicate downloaded/failed blocks > > > (perhaps blue downloaded, red DNF, orange RNF), these can be mixed up if > > > so-desired, or separated. Separated will make the table render much > > > faster. > > No, we need to have a failed-but-going-to-retry color, as well as a > > failed-but-not-going-to-retry color. > > Not necessarily, it would be easier, when we are going to retry a node, > to put it back in the green state, but even if we were to do that, it is > a pretty trivial modification to my proposal. Ok. > > > > The third stretch of the bar - maybe green, indicates the number of > > > blocks which must be downloaded to reassemble the file. > > Eh? Sorry, I don't understand this bit at all. IRC? > > You need 100 blocks, out of 150. You have successfully downloaded 20, > with 10 failures. The green area would be 80 blocks in length, > representing the number of blocks you must download at this point to > successfully reassemble the file. I'd like to see a mockup... I still think we ought to box in the 100 blocks, so that when the box fills up with green (or whatever the color for success ends up as), or when red (failed, given up on) intrudes into it, the game is up. Or do you mean something like... <20 blocks: success><80 blocks: waiting><PARTITION> <10 blocks: also waiting><30 blocks: failed> Where we either ignore the difference between blocks that have never been retried and blocks that are on their last time in the queue, or we represent them by slightly different shades? Finally, w.r.t. opening the window - when you click on a download link from a freesite, you usually go through the anonymity warning. Even if we eliminate this... how can we go directly from the freesite to a new window? We don't want to go from a freesite to some sort of intermediary screen and then open the new window as well. So we open a new window direct from the freesite, which means without using javascript? What exactly did you have in mind? > > Ian. > > -- > Ian Clarke ian@[freenetproject.org|locut.us|cematics.com] > Latest Project http://cematics.com/kanzi > Personal Homepage http://locut.us/ -- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/1/03 http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021220/e031ce57/attachment.pgp>
