#8041 HIGH 9.1.0: Sugar lacks a "Trash/Recycle bin" system
Zarro Boogs per Child
bugtracker at laptop.org
Wed Aug 20 12:41:49 EDT 2008
#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:
--------------------------------+-------------------------------------------
Comment(by Eben):
I pulled this in from the mailing list, since I think it summarizes a lot
of the discussion. This is my response to the thoughts of others. (Sorry
for the length.)
{{{
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 <bastienguerry at googlemail.com>
wrote:
> "Eduardo Heleno" <hoboprimate at gmail.com> 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 <bastienguerry at googlemail.com>
wrote:
> "Martin Langhoff" <martin.langhoff at gmail.com> 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 <pgf at laptop.org>:
>
> 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".
Well, not entirely. The system can transparently remove entries in
state 4, when it has been lazy-erased and is also backed up, since
this doesn't change the perceived state of the file (that is, the
child said "I don't need this" already, and has to hit restore to get
it back. The restore would have been faster before the erasure of the
local copy, but as long as restore works, things are fine).
Also, the intention for the alert, again, is to have the Journal
indicate to the user that things are getting full. When this happens,
the Journal will create a suggested list of files/entries it thinks
are expendable. This list will be created with knowledge of what
things are favorites, what things are backed up, what things have ben
recently used, or used frequently, how large they are, etc. Thus, the
Journal will cheerily aid you in sorting everything into piles, and
then let you review its efforts to make sure it didn't make a mistake.
The goal is to make this step as painless as possible, if its ever
even required. (We can, of course, indicate to the kids that "The
Journal is getting full" well before we indicate "The Journal is
full"; only in the latter case do we need to pull them away to deal
with the issue Right Now.)
I hope this clarifies my position on this subject a bit, and paints a
picture which is really just a different perspective on the usual
"trash can" metaphor, rather than an abandonment of it.
}}}
--
Ticket URL: <http://dev.laptop.org/ticket/8041#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system
More information about the Bugs
mailing list