Small rant
I just lost a bunch of images because the "Empty Trash" behavior is different depending on if you are working with a Session vs. a Catalog. Apparently when you empty trash while working in a Session your files are gone forever. However, when working with a Catalog if you empty trash you are prompted to leave the files where they are.
This difference in behavior doesn't appear to be documented anywhere in the online help (or at least I couldn't find it). I just can't wrap my head around why the meaning of "Empty Trash" varies depending on what type of session/catalog you are working with. One is completely destructive (permanent data loss) and one is not? This is like telling someone that in one situation "go means go" and in another situation "go means stop."
Am I missing something? When emptying the trash why not move the original images to the OS trash can where they can be recovered?
Argh--
PP
This difference in behavior doesn't appear to be documented anywhere in the online help (or at least I couldn't find it). I just can't wrap my head around why the meaning of "Empty Trash" varies depending on what type of session/catalog you are working with. One is completely destructive (permanent data loss) and one is not? This is like telling someone that in one situation "go means go" and in another situation "go means stop."
Am I missing something? When emptying the trash why not move the original images to the OS trash can where they can be recovered?
Argh--
PP
0
-
[quote="ppmax" wrote:
Am I missing something? When emptying the trash why not move the original images to the OS trash can where they can be recovered?
Argh--
PP
My sympathies ... but I assume you have the orginal files backed up somewhere as well? Always a good idea with any computer system.
In the Session process the Session trash folder is treated like an application version of system trash so retaining a 2 stage process (if you use it) rather than a three stage process. As I recall people complain about 3 stage processes - or even 2 stage processes. Something along the lines of "When I have decided to trash an image I WANT IT TRASHED not just filed somewhere else cluttering up my machine ..." etc. etc.
As a system designer there are certain aspects of the system where you can never win unanimous plaudits from the user base - well, not without adding complexity for user, documenter and support activities as well as the development team for the entire period during which the product exists.
Grant0 -
Thank you for the reply Grant...it is calming to read a well articulated response. I appreciate your comments about 2 vs. 3 stage processes, and I think your example is a clear illustration of the sometimes competing (perhaps perpetually unresolvable) interests that can not be satisfied (or anticipated) by applied logic; how can one anticipate what the user intends?
However, I feel this example misses the point. The change in behavior which is manifest in the Empty Trash command is an example of ambiguity in the interface, not of ambiguity of intent. I didn't execute that command by accident. Based upon previous behavior experienced when using a Catalog, my expectations for future use of the command were set. But when using a Session, emptying the trash clearly does something different. While I wanted to delete the files from the "workspace" of C1, I had no intent of deleting these files permanently, and expected the behavior I experienced previously when using a Catalog (where the original files may be left in place).
This is bad. If the command does different things in different scenarios then it does not provide the same function. Imagine if hitting "reply" in an email meant "reply to sender" in one case, and "reply to all" in another? As a user, am I expected to remember if I'm in a Catalog or in a Session? Why would I care?
I understand that the ability to choose to use Sessions and Catalogs was likely not "by design," but likely the result of the growing and often times diverse needs of the customer base; choice is good. Being in a Session or in a Catalog may be the result of an explicit choice, or it may be happenstance due to the state of the application from a previous session. The fact that the behavior of shared commands changes opens the possibility for the user to affect unintended and unexpected changes to their data.
thx
PP0 -
Why not let the user decide - it's the way of the 21. century.
Like, let the user, in Preferences choose between...
- Send to system trash (default)
- Delete permanently
- Always ask
it would make a lot more sense to use resources towards this rather than on existing gimmicks such as offering a choice between "Solid" and "Pinstripes" for viewer and browser pattern.
Cheers,
Mogens0 -
Hi ppmax,
Deleting images is a serious topic, not to be taken lightly. Session and catalog differ in their main task (organise images) and as a result they differ in how image are moved, trashed and deleted.
I briefly summarise the commands in session and catalog (both managed and referenced images).
Session
Command: Move to Trash > image moved to session trash (with multiple images selected a warning appears)
Command: Empty Session Trash > warning that step is irreversible > OK > image gone
Catalog (managed image)
Command: Remove from Catalog > image is moved to catalog trash
Command: Empty Catalog Trash > warning that it is irreversible > OK > image gone
Catalog (referenced image)
Command: Remove from Catalog > message Remove File Reference with options, like moving to trash = System Trash (note that it is not going to the catalog trash)
I see different commands, I see warnings at the right moments when you are taking to make an irreversible step. The only small mishap I see is with managed images (catalog) where the command should be named like "Move to Catalog Trash" or something like that in analogy with sessions.
Can you give any suggestion how it would have been more clear to you, preventing unwanted permanent delete?0 -
I take your point PP. I don't use Catalogues (other than for one or two experiments with them) and I rarely bother to delete files - obvious no go images being the exception to that.
So I can't really comment from experience of catalogues. I suspect that most users, based on comments in the forum, use either catalogues (since V7) or sessions and so experience one delete process or the other.
On the other hand even catalogues, or so I believe, are not that straightforward since functionality depends on whether the original source image is referenced or stored in the catalogue. Thus even within the specific area of catalogue functionality there may be a need to be aware, all the time, of differences in process.
It's a tricky one. If the designers take all of these things into account and keep popping up warning messages and reminders power users will get annoyed. If they don't provide the warnings maybe everyone will get annoyed at some point. If the warnings are provided but, say, can be disabled by user preferences ... that leaves everyone in a kind of noman's land.
I usually keep backups in multiple locations - especially if the shoots were 'on the road' in which case they will usually be on a small portable device, a portable disk and, maybe depending on shoot volumes, still on the original cards by the time I get back to base. For anything vaguely important I endeavour to make sure I have at least one backup set tucked away somewhere - not much pint in having disk capacity and leaving it empty.
Later, once the images are to all intents and purposes archived even if still available, I sometimes take a little time to tidy up and dispose of those that really should be disposed of - although the cost of the time to do that vs the cost of disk capacity makes it a rather an uneconomic proposition ... Still, it's an excuse to trawl through older stuff to see if I missed anything interesting.
I see there have been two further responses as I typed this. I'm not sure that my next observation is relevant to you point but for completeness in Paul's list of commands one should perhaps mention that the user in a session also has the opportunity to perform an immediate delete bypassing the Session Trash should they so desire. (Use of the Alt key in Windows, presumably something similar on Mac - see the associated shortcut in the the drop down File menu.)
Personally I think there is nothing better than a solid backup strategy for greater peace of mind.
HTH.
Grant0 -
Thank you again for your thoughtful and well considered replies.
First: I am not blameless in this scenario. As Paul points out, indeed, the confirmation dialogs are different when deleting from Sessions vs. Catalogs. I clearly did not read the confirmation message closely enough.
Regarding:
>>Can you give any suggestion how it would have been more clear to you, preventing unwanted permanent delete?
I like the idea of a "monolithic" trash can; e.g. a "destination" for images that the user wants to remove from their Catalog or Session. The monolithic trash can would have a consistent behavior, perhaps one chosen via preference as mil20 suggests. This provides consistency regardless of what mode the user is in. I also believe SFA makes a good point about confirmation/warning messages that are annoying to experienced users.
An ideal behavior *to me* would be:
Delete an image from Catalog or Session; gets moved to "trash can"
Delete an image from trash can; gets moved to OS trash (where it may be recovered)
Delete an image from trash can (alternate, perhaps via modifier key); gets deleted *permanently* pending confirmation from dialog.
Regarding:
>>Personally I think there is nothing better than a solid backup strategy for greater peace of mind.
Agreed 😉 This incident just happened to take place in my "staging" directory for recently imported images that I exclude from my nightly backup scripts because I don't want to back up images that aren't keepers.
Thanks again for all your input
PP0 -
I too like the idea of when you empty a session trash, it moves the files to the OS trash instead of permanently deleting. I like to keep my sessions' trash empty and clean, but my OS trash is a mess that I never empty out 😂 0 -
[quote="NNN635396667004693641" wrote:
I too like the idea of when you empty a session trash, it moves the files to the OS trash instead of permanently deleting. I like to keep my sessions' trash empty and clean, but my OS trash is a mess that I never empty out 😂
One meets the strangest folk on-line ...... 😊
More seriously ....
Realistically any trash should be emptied. Much disk space wasted otherwise and for spinning disk that may also imply performance degradation. This is (or perhaps has been but not so much of an issue these days) a big issue for photography because of the inherently large size of the files - especially RAW files - compared to most other document types.
The problem adding the extra steps is that once you have broken the link to the session it would very likely be messy, for most people, to retrieve the files and put them back where they came from anyway, whereas the session trash leaves the session association intact.
Grant0 -
PP,
I'm not sure if this would still be a useful idea for you and you may think it not worth the effort but ....
you could try recovering the files using a data recovery program. If you have not been very busy on the system they or some of them may be as yet not overwritten.
That the system no longer presents them to you does not necessarily mean that the data are obliterated. Or at least it doesn't if using Windows. I assume Mac is much the same. Recovery programs can, potentially, find the bits of files scattered around the disk and put the indexes back to "re-ceate" them.
Just a thought.
Grant0
Post ist für Kommentare geschlossen.
Kommentare
9 Kommentare