On Thu, Dec 19, 2002 at 01:26:46PM -0800, Ian Clarke wrote: > (This email is more stream of thought - go to the bottom to see an idea > that everyone might like) > > > http://todesbaum.dyndns.org/freenet/new-splitfile-request/ > > This is very very cool indeed, and better than I expected it to be. But > I do have some high-level issues with this approach, all of which I > think can be solved without wasting any of your efforts so far: > > - Each individual download requires an entire browser window. This > isn't in-keeping with the way browsers normally work. I think > there is a good risk that users will be confused as to whether the > download will continue if they close the window. We cannot just use a progress bar. We cannot make it entirely transparent. 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. > - Frames will piss off lynx users (although I kinda like that idea) Any sort of graphical representation is likely to piss off users of not only lynx but even "links". > - One could argue that this is the kind of information an expert would > love to see, but it might be too much for a newbie. 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. > - On a more asthetic note, I think that the block-boxes could be much > smaller, each box is basically conveying one of 3 states, and I don't > think we need 24X24 pixels to do this. 16X16 or 8X8 might be better, > and would make more effective use of screen real-estate. Hmm, maybe. > > I completely understand the problem with the progress-bar not moving, > and that being discouraging for users. Yay, a breakthrough! > > I guess, right now I am thinking about an approach where: > > The user has the option of the interface as currently outlined, or they > can simply opt for a normal download, where an infolet provides them > with progress information. The normal download already exists. And will persist even if the user closes the progress monitor. Maybe it makes sense to have a way to get at the progress monitor for any given current download, for cases where the UI wasn't shown because of size or because it was downloading an inline, or where it has been closed. HOWEVER given the assumption that a user's IQ is about 60, and their computer literacy level is barely sufficient to drive windows 98, we CANNOT rely on them being able to find the panel. We must UP FRONT tell them that it is a splitfile download and that it is in progress, and something is happening, and not to abort it just because the download progress bar provided by IE doesn't advance for a very long time. > > It should be relatively straight-forward to share code between this > screen and the infolet to save duplication of effort. Yeah. > > 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? > > 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/a4076632/attachment.pgp>
