On Mon, Oct 19, 2009 at 20:01, Wade Brainerd <[email protected]> wrote: > On Mon, Oct 19, 2009 at 10:12 AM, Eben Eliason <[email protected]> wrote: >> To stop the activity now now you must cancel your ongoing download. >> [Cancel download] [Continue download] > > This sounds well thought out, but imagining the experience in my head > makes me wonder a little. > > Two user perspectives: > 1) Do I want to keep downloading or not? Continuing the activity is > the implicit choice. > 2) Do I want to keep using the activity or not? Continuing the > download is the implicit choice. > > Since I clicked the [Stop] button, 2) feels more natural. Whether to > stop the activity should be the primary choice, with the download's > continuation being implicit, since stopping the activity was the > initiating action. > > In other words making a decision, then being asked an orthogonal > question (with an implicit effect on the decision I made), seems off. > > ....Side note: Since the Journal displays the progress bar as files > are downloaded, wouldn't it be cool if Browse just handed the download > off to the Journal? That would allow the download to continue even > after Browse stops. It would also allow the download to be resumed if > the machine is restarted, network connection lost, etc. Worthy > Journal feature request?
This was the desired user experience, but mozilla's architecture made it quite hard without losing the ability to download inside existing http sessions. I heard that WebKit has pluggable network backends, so that may make it possible. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning _______________________________________________ Sugar-devel mailing list [email protected] http://lists.sugarlabs.org/listinfo/sugar-devel
