On Thu, Dec 19, 2002 at 01:56:42PM -0800, Ian Clarke wrote: > On Thu, Dec 19, 2002 at 09:48:55PM +0000, Matthew Toseland wrote: > > We cannot just use a progress bar. > > Oh? What was wrong with Simon's proposal? I see no reason that we > couldn't do that. Redundancy, for starters. > > > We cannot make it entirely transparent. > > No, but we can do our best. Without using javascript? Remember, we advise users to disable javascript in their web browsers if they can, because something may always get through the filter. Lack of control over client side scripting is of course one of the wonders of client independance (i.e. not writing a browser plugin). > > > What do you prefer? Obviously we can lose the bottom two > > frames, but the top and middle frame (which could be a single document) > > need to stay unless we change the concept radically. > > Well, We can definitely keep this concept for a "Show details..." type > dialog, but by default I think we should do something similar to Simon's > suggestion. > > > Any sort of graphical representation is likely to piss off users of not > > only lynx but even "links". > > Not really, it is possible to make most graphical representations look > ok in text if you are smart about it - but I don't think you can ever do > that with frames. Or tables. Or anything. Besides, I have explained already that we don't strictly need the bottom two frames and we can combine the top two into one file. BUT the interface will still look dire in links, never mind lynx... [GOT ][GOT ][NOTGOT][NOTGOT][NOTGOT]... is the best we can hope to achieve without browser specific code (yuck). > > > The newbie must see something. A progress bar that stalls for an hour > > while downloading the first 128MB is completely unacceptable. EVEN if it > > is backed by a fuller interface _if you know where it is and dig for > > it_. Lusers don't read if they can avoid it and they have relatively > > little curiosity - we can't expect them to know that there is a full > > status monitor buried on the web interface somewhere. > > I don't disagree, I think Simon's proposal addresses this concern. Simon's proposal is not a solution, it is a half-baked idea. It may form a component of a full fledged solution however. But we would end up with two bars, organized the same way Bombe's cellular system works. In other words, we have a plain progress bar, which fills from one end and represents the total blocks downloaded, and we have a color coded strip that represents all available blocks (as slices) - one color for fetching, one color for failed permanently, one color for failed but going to retry, and one color for not tried yet. This would be 1.5x the length of the first bar, (or 1.5x the width). > > > > Another idea, which on thinking about it, might be more attractive to > > > you guys, is to pop open a borderless window which conveys this > > > information, but tries to look at-least something like a normal download > > > window that the user will be familiar with (similar size etc). > > Um, you were complaining about javascript hacks before. Can you open a > > borderless window without using javascript? > > I ment a browser window with no tool-bar, not completely borderless. The question stands. > > 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/20021219/638033f7/attachment.pgp>
