Empty trash dialog misleading
Submitted by an unknown user
Link to original bug (#717191)
Description
---- Reported by shotwell-maint@gnome.bugs 2011-01-10 00:21:00 -0800 ----
Original Redmine bug id: 3082
Original URL: http://redmine.yorba.org/issues/3082
Searchable id: yorba-bug-3082
Original author: Richard B. Kreckel
Original description:
The empty trash dialog features three buttons:
[Cancel] [Only Remove] [Trash Files]
Out of three people I've asked (well, that includes myself) everybody agreed that “Trash Files†sounds much harder than “Only Removeâ€. Nobody would have guessed that after “Only Remove†the photos would be gone for real while after “Trash Files†they would end up in the desktop's trash. After reading the “Would you also like to move the files to your desktop trash?†some start looking confused but they still believe that “only†must hint at something less dramatic.
I suggest to rename the buttons. I propose “Remove†and “Move to Desktop Trashâ€.
---- Additional Comments From shotwell-maint@gnome.bugs 2013-05-01 11:46:00 -0700 ----
History
Comment 1
Updated by Jim Nelson almost 3 years ago
- Priority changed from Low to High
This seems reasonable. I've bumped this to high for consideration for 0.9.
To clarify something: “Only Remove†means only remove from Shotwell -- the files themselves are untouched. “Trash Files†removes the files from Shotwell and moves them to the desktop trash. In that sense, it's the “harder†command.
Is that not be behavior you were seeing?
Comment 2
Updated by Richard B. Kreckel almost 3 years ago
Replying to [comment:2 jim]:
To clarify something: “Only Remove†means only remove from Shotwell -- the files themselves are untouched. “Trash Files†removes the files from Shotwell and moves them to the desktop trash. In that sense, it's the “harder†command.
I wasn't aware of the fact that “Only Remove†does leave the files in the library directory. The documentation explains that “Only Remove†removes photos from the library but leave the photos in their location on the computer. What if the photos were copied at import and the library has in fact become the location on the computer? I find that confusing.
Comment 3
Updated by Richard B. Kreckel almost 3 years ago
Indeed, that seems to be my problem:
After having hit “Only Remove†a number of times, my library directory is filling up with photos that cannot be accessed using Shotwell. There doesn't seem to be a way to purge these files, right? IMHO, this makes the entire “Only Remove†concept totally confusing. (Well, unless the files have only been imported in place, as opposed to copied, perhaps.)
Comment 4
Updated by Adam Dingle almost 3 years ago
RBK,
it's not super easy to purge these files at this point, but you could use some UNIX tricks to make a list of all files which are in your library directory but not in the database. See this mailing list thread:
http://lists.yorba.org/pipermail/shotwell/2010-November/001297.html
Now that you understand that “only remove†does in fact only remove the files from the library, do you still think that we should change the button labels and/or this dialog, and if so, do you have a concrete proposal for the change? (If not, I'd be inclined to simply close this ticket at this point.)
Comment 5
Updated by Richard B. Kreckel almost 3 years ago
Replying to [comment:5 adam]:
Now that you understand that “only remove†does in fact only remove the files from the library,
I see now. But this is horribly confusing.
When copying a photo/video into the library, users believe that shotwell assumes ownership of the copy (by tracking it in its library and storing the copy in ~/Pictures/). Later, when a user tells shotwell to remove an item that it owns (i.e. nobody else may claim that item) she intuitively expects shotwell to relinquish ownership and, because nobody else claims that item, the item to disappear.
Comment 6
Updated by Richard B. Kreckel almost 3 years ago
Having said that, I think that the only intuitive semantics for remove and for trash for items that have been copied into shotwell is to remove the items from ~/Pictures/ resp. to move them from ~/Pictures/ into the desktop trash. Does that make sense?
Comment 7
Updated by Adam Dingle almost 3 years ago
When we designed the delete feature, we thought about this for a while. I agree that most of the time, when the user removes photos which are in their library directory (e.g. ~/Pictures) they probably want to move them to the trash. But:
-
What if the user selects a group of photos in the Shotwell trash, some of which are in ~/Pictures and some of which are in other folders, and then presses Delete? Presumably we need to display some sort of confirmation dialog to the user, but should this ask only about the fate of the pictures in other folders, not those in ~/Pictures? It would seem a bit tricky to explain this all to the user.
-
It may be that some users have lots of photos in their library directory, import a bunch of them into Shotwell, and then later want to remove some of them from the Shotwell library but leave them in the library directory. This is probably not a typical usage pattern, but users want to use files in all kinds of different ways. Moving files to the trash is a relatively destructive operation, so it seems tolerant to give the user to give them some way to remove without trashing, even when files are in the library directory.
-
You suggested that Shotwell should always trash “items that have been copied into Shotwellâ€. Shotwell today has no knowledge of which items were copied in (e.g. from a camera) and which items were always in the library directory even before the user first ran Shotwell. We could conceivably add a flag like that, but it would not be present in any existing Shotwell libraries.
For all of the above reasons, we've decided to take the path which seems most straightforward, i.e. simply asking the user what to do on every delete operation, which puts them in charge and gives them maximum flexibility.
Yes? Or do you see a better way, given all the points above?
Comment 8
Updated by Richard B. Kreckel almost 3 years ago
Thanks a lot for dwelling on this topic and providing a great explanation. I now understand why things are as they are.
But: Isn't it weird that a seasoned programmer has trouble intuitively understanding this entire concept? My guts feeling tells me this is excessively complicated. We are still far away from easy-to-use products, methinks.
Why not provide a much simpler way of using Shotwell? Let Shotwell assume full ownership of ~/Pictures/! Shotwell could then assume that nobody else is messing with ~/Pictures/. This could be made an option. If explained well, this could even be done for existing ~/Pictures/ directories full of stuff.
-
It wouldn't ask how to import a photo: it would always copy them.
-
It wouldn't ask how to delete a photo: it would always move them to the desktop trash.
-
Besides tracking missing photos, it would have to scan ~/Pictures/ for elements it doesn't know and ask the user what to do with them. It could do this at startup, maybe.
I think that 80% of the users don't need more control.
Comment 9
Updated by Jim Nelson almost 3 years ago
I appreciate your thoughts on this, and I really do appreciate that this caused quite a bit of confusion on your end. Library file management is an area we've spent quite a bit of time thinking and developing.
It's possible that your 80% figure is correct (although I'm not sure about that). Even so, that doesn't mean the 20% are seasoned computer users. For example, we have a number of users who store all their media on an external USB drive. They're not savvy enough (or haven't bothered to) move their XDG Pictures directory to that drive. Some of them use symlinks, which we still need to fully support (#2983 (closed)) and some don't even bother linking to, just import straight off the drive. But don't confuse this setup as something only the hacker crowd uses.
The point is, copying in this situation would be very bad -- they have them stored externally for a reason. Pulling all those photos into the boot drive would totally screw things up.
This is just one use-case. There are a dozen more. And people don't always import from the same device. Think of (a) importing from camera, (b) importing from photos already on the boot drive, © importing from an external mass- storage drive, and (d) importing from a USB stick. There's mild variations to all of these that a single checkbox in the Preferences dialog won't solve, and a single user might go through all of them.
I'm not saying it's futile to improve this or that our current system is the best. But from listening to our users, big simplifications won't work. That's why we went with our current approach of asking on each import and asking on each deletion.
Comment 10
Updated by Adam Dingle almost 3 years ago
- Status changed from Open to 5
- Resolution set to invalid
- % Done changed from 0 to 0
I'm going to mark this ticket as invalid, since this discussion has gone well beyond the original question of the wording in the empty trash dialog. I do agree that the question of who owns the files in ~/Pictures is tricky and that many use cases are possible. If you'd like to suggest signifcant changes to the current model (e.g. an option where pictures are copied to and deleted from ~/Pictures automatically without asking, as you suggested) then I think a mailing list discussion would be a good place to start. If there's consensus from users we can always open another ticket focused on the specific proposal.
Comment 11
Updated by Charles Lindsay 7 months ago
- Status changed from 5 to Invalid
--- Bug imported by chaz@yorba.org 2013-11-25 21:49 UTC ---
This bug was previously known as bug 3082 at http://redmine.yorba.org/show_bug.cgi?id=3082
Unknown Component Using default product and component set in Parameters Unknown version " in product shotwell. Setting version to "!unspecified". Unknown milestone "unknown in product shotwell. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Resolution: RESOLVED INVALID