Should non-existant files in a recently used files list be deleted without user prompt?

Say, you have this common thing of "recently used files" or "frequently used files" in your application.

It may easily happen the user moves or deletes a file they had opened recently/frequently. So what happens, now, if the user clicks on that file in your recently/frequently used list…?

  1. They should obviously get some feedback/notice that the file is not there anymore.
  2. Now, here, is the question: Should the application also automatically delete the file that it could not found from the list?

Arguments

Some ideas I have about this:

  • (+) Pro: The entry is absolutely useless, as a user can never open such a file anymore, anyway. It takes valuable space away if it stays there.
  • (–) Contra: In some cases a file can only be temporary deleted. While on Android this may e.g. never be the case, this can happen with network shares (think of FTP or samba or so) or so on desktop systems. In such a case the user may just be offline and a file can be opened later anyway.
    On the other hand, an application can blacklist these things. (from looking at the file path)
  • (+) Prompt: A user could also be prompted whether the file should be deleted. However, if the file is really gone, this may really not be useful in any way, as it's just another click and possibly obvious?
    • (-) Contra prompt: Confirmation prompts are usually not considered the best UX pattern, so actually an "undo" feature would make sense here. But how can this be accomplished in this case without totally confusing the user? (note we also need to do 1. to notify the user about the fact that the file could not be found…)
  • (-) Only manual deletion: We could also not automate that at all, and only let the user click on an "x" or so next to each entry, so they can delete it manually. However, IMHO this is quite lame as – while the feature may independently be useful/needed anyway – in the case when the file is gone, we can totally be clever as an application and at least offer the user to automatically delete it. Why should users first interpret our error message, think and then appropriately react by manually deleting the (correct) entry? (I guess this is "hard" and I doubt many users would even do so, which again could "accumulate" "broken" entries in our list.)
Tags: