Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
bastien wrote: Martin Langhoff [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. Yes it does: it contains entries that the system can safely delete without forcing the user to go thru the entries and sort them out on the fly. does the journal have a similar way of marking entries as feel free to delete this if i need the space? i think giving it hints as to what's expendable would be important. - no old-and-backed-up files we can safely remove? Prompt the user prompt the user, interrupting whatever they were trying to get done? that seems less than optimal. if my current UI-of-choice implemented disk full this way, i would have long ago created personal mechanisms help me organize my work into very important, must save, would be nice to keep, but i can recreate it if i want, and don't really need it, but i won't throw it away until necessary. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
[EMAIL PROTECTED] writes: does the journal have a similar way of marking entries as feel free to delete this if i need the space? i think giving it hints as to what's expendable would be important. That'd be better than no trashbin, but feel free to delete this if I need the space sounds too abstract to me: it involves hypotheses on possible situations, which the user don't really want to make. With a trashbin, there is no such hypotheses, just simple actions: - delete (put in the bin) - recover (fetch from the bin) - click yes when prompted whether it's safe to delete everything in the trashbin (the system decides under which conditions this happens) This actions are accessible to the user in circumstances that the system decides. The user has not to consider what are the possible circumstances under which she wants the system to take some possible actions. Again, I know that the new design of the next Journal will make it possible to emulate these actions (tick-to-make-expirable, untick, say-yes-when-prompted-for-deletion), but I'm not sure whether the UI itself will make the user *want* (or feel the need) to delete stuff. You only want to clean your desk and put stuff in your drawer when you actually have a drawer :) - no old-and-backed-up files we can safely remove? Prompt the user prompt the user, interrupting whatever they were trying to get done? that seems less than optimal. if my current UI-of-choice implemented disk full this way, i would have long ago created personal mechanisms help me organize my work into very important, must save, would be nice to keep, but i can recreate it if i want, and don't really need it, but i won't throw it away until necessary. That makes a lot of choices. At least for me, I like when organization emerges from the use of simple actions afforded by the UI, rather than having an UI that asks me to get a bit more organized. Then I feel too guilty! My 2cts -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
bastien wrote: [EMAIL PROTECTED] writes: - no old-and-backed-up files we can safely remove? Prompt the user prompt the user, interrupting whatever they were trying to get done? that seems less than optimal. if my current UI-of-choice implemented disk full this way, i would have long ago created personal mechanisms help me organize my work into very important, must save, would be nice to keep, but i can recreate it if i want, and don't really need it, but i won't throw it away until necessary. That makes a lot of choices. yes, but my point was that they're all choices we all already make, voluntarily: some things might go under change control, and/or we rsync to another server for redundancy. some things we back up compulsively onto a USB stick we carry in our pocket. some things we keep around, but don't back up. some things we download into /tmp, because we don't care if it lasts past a reboot. all choices regarding the importance of our data. a data management UI must make these sorts of choices transparent and easy. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
This is getting a little out of hand, here. Let's break this down again, because I think we're all arguing for pretty much the same thing. On Wed, Aug 20, 2008 at 12:19 AM, Bastien [EMAIL PROTECTED] wrote: Eduardo Heleno [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. This is, at least for now, independent of the trash can issue itself. On Wed, Aug 20, 2008 at 1:27 AM, Bastien [EMAIL PROTECTED] wrote: Martin Langhoff [EMAIL PROTECTED] writes: AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. Yes it does: it contains entries that the system can safely delete without forcing the user to go thru the entries and sort them out on the fly. This is no less true in the future Journal design. Anything which has been previously erased can be transparently deleted by the system without another prompt. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. The only difference is how the erased but not yet truly gone files get represented to the user. People now want deletion because the Journal is not optimal. They want deletion to sort out entries in the Joural and get rid of unfinished or useless entries. With too many entries, the (current 703/708) Journal becomes unusable. I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. That is, a button which basically shows and hides trashed files by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. When you are running out off disk space, we have two cases: - ds-backup has been doing its job, there's a copy of the files in the XS, so the journal has old-and-backed-up files that it can decide to rm I'm afraid XS servers won't be of use in *many* schools. That's fine. The backup solution is an enhancement, not a requirement. Consider the possible states for entries: 1. Normal: file stored locally on the XO 2. Normal+Backup: file stored locally on the XO, and also on the server 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate transient state 4. Lazy-erased+Backup: same as above, but also backed up to the server 5. Erased: not stored locally on XO 6. Erased+backup: not stored locally on XO, but still available on the server States 1, 3, and 5 are the basic states without backup in the picture. They map directly onto a file, a trashed file, and a file which has been emptied from the trash, respectively. Without a server, you can still recover anything in state 3. When you have a server, you can recover anything in states 3, 4, and 5 (call these the recoverable states). In all of these recoverable states, we will visually represent a the entry in a way distinct from normal, present entries, and the entries in these states will have buttons which allow them to be a) recovered or b) permanently erased. If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. - no old-and-backed-up files we can safely remove? Prompt the user I'm curious whether someone did this job of being prompted. How long does it take? If you can't remember what a file contains, checking if it's safe to delete it by trying to reopen it might be tiring. The Journal does (will do) better than many other systems. The preview is sadly underutilized at the moment, but it should provide a hint without the need to open it. We have a few ideas about how to encourage naming and tagging as well, which will improve this situation a lot. Finally, we have the notion of favorites in the Journal. If we encourage their use as well (which we will in the next version, since it will be possible to filter the list to show only favorites, thus eliminating the unwanted entries which currently make it difficult to find things), then it should be easy to at least preserve the things you've already indicated in the past mean something to you. We'll also have true versioning in the future, so it will be possible to prune the version tree, keeping fewer intermediate versions the further back in time we look. 2008/8/20 [EMAIL PROTECTED]: prompt the user, interrupting whatever they were trying to get done?
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
[EMAIL PROTECTED] writes: a data management UI must make these sorts of choices transparent and easy. Agreed. My concern is about low-tech environments: no XS, no USB keys, very little care about versioning. Then the trashbin seems rather useful in forcing the user to delete stuff safely. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
eben wrote: ... I hope this clarifies my position on this subject a bit, and paints a it does. thank you. paul picture which is really just a different perspective on the usual trash can metaphor, rather than an abandonment of it. - Eben =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
2008/8/19 Zarro Boogs per Child [EMAIL PROTECTED] #8041: Sugar lacks a Trash/Recycle bin system +--- Reporter: HoboPrimate | Owner: Eben Type: enhancement | Status: new Priority: high | Milestone: 9.1.0 Component: interface-design | Version: Development build as of this date Resolution:|Keywords: 9.1.0:? Next_action: design|Verified: 0 Blockedby:|Blocking: +--- Changes (by Eben): * next_action: never set = design * cc: christianmarc, tomeu, martin.langhoff (added) * priority: normal = high * version: not specified = Development build as of this date * milestone: = 9.1.0 * keywords: = 9.1.0:? Comment: The Journal is, by design, meant to make a trash system completely unnecessary, on account of an incremental backup mechanism that allows kids to peruse record of (preview, title, description etc.) things they've made and since deleted (much like looking in the trash), as well as restore individual files from backup if they want to recover them again (much like removing something from the trash). There will, of course, also be a way to permanently erase entries which they don't want any record of anymore (much like emptying the trash). Obviously, at some point, there won't be enough backup room either, and things will have to go permanently, but this can be handled in much the same way that the initial deletion process happens, which, as is described in many other places, should guide the user through their documents, suggesting a number of entries for deletion based on some heuristics (including backup-present, file size, favorite status, recency of use, frequency of use, etc.). -- Ticket URL: http://dev.laptop.org/ticket/8041#comment:2 One Laptop Per Child http://laptop.org/ OLPC bug tracking system But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. I understand the idea of the backup system. I still propose for the existence of a ~/.Trash directory, either on the XO, and/or on the users /home directory at the backup server, used explicitly to store erased entries, with strict limits on the size and age of items stored there. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
Eduardo Heleno [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. I'm not convinced myself, because I think the design of the (next) Journal is neat, and the concept of a trashbin too MS-ish/clumsy. The only thing I find it useful for: send visual affordance to the user so that he *wants* to trash things (in a safe way) rather than obeying the system when she's forced to delete stuff on a full disk. -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
On Wed, Aug 20, 2008 at 4:19 PM, Bastien [EMAIL PROTECTED] wrote: Eduardo Heleno [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. When you are running out off disk space, we have two cases: - ds-backup has been doing its job, there's a copy of the files in the XS, so the journal has old-and-backed-up files that it can decide to rm - no old-and-backed-up files we can safely remove? Prompt the user cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
Martin Langhoff [EMAIL PROTECTED] writes: But my point was that, at the moment, you can choose to Erase an item, and it's gone forever. I expect that many kids will do this, and will at some point regret erasing some item. Yes. This is a request that has been made here in Haïti. AFAIK, the plan is to *discourage* deletion until the disk is getting full. When you are getting to disk-full, trashcan doesn't help. Yes it does: it contains entries that the system can safely delete without forcing the user to go thru the entries and sort them out on the fly. People now want deletion because the Journal is not optimal. They want deletion to sort out entries in the Joural and get rid of unfinished or useless entries. With too many entries, the (current 703/708) Journal becomes unusable. They will eventually forget a bit about the trashbin when the Journal will get better. But even with a nicer Journal, the trashbin might still serve the purpose described above. When you are running out off disk space, we have two cases: - ds-backup has been doing its job, there's a copy of the files in the XS, so the journal has old-and-backed-up files that it can decide to rm I'm afraid XS servers won't be of use in *many* schools. - no old-and-backed-up files we can safely remove? Prompt the user I'm curious whether someone did this job of being prompted. How long does it take? If you can't remember what a file contains, checking if it's safe to delete it by trying to reopen it might be tiring. The whole idea of a trashbin has its limitation, but so does our brain! -- Bastien ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
