When the deleted object is a folder, I suggest the toast should show how many children the folder had. That can help the user spot if they accidentally deleted a full folder instead of an empty one, which they can then quickly undo.
On one hand I can understand the potential benefit of what you’re suggesting, on the other hand:
How often does one delete actually empty folders? I would assume deleting non-empty folders is the norm rather than the exception (it certainly is my case, I never empty a folder before deleting it.)
It would complicate the string and make it longer to read, whereas the toast notification has a rather short duration, so I tend to think that quick readability is preferrable here.
It would imply doing a recursive count of the contents of a folder, which would certainly have a non-negligible impact when deleting large folders, especially on slow locations (MTP, removable media, remote locations, etc.).
I think it happens often enough that this would be a noticeable quality of life improvement for many people. I certainly do it often enough.
I think that the visual of something appearing is already feedback that those that aren’t interested in the numbers can rely on without having to parse the text.
However, I also think that a single number like
“Folder ‘Foo’ deleted (7 children)”
is easy enough to parse quickly.
Firstly, deleting the folder will require a recursive descent anyways. I’m not sure if it’s desired to show a toast about the folder being deleted before it’s actually deleted.
But I do agree that it might be more difficult to implement.
When it comes to remote folders, these currently do not show this toast at all.
Will it, though? I would’ve thought filesystems are more efficient than that, or you couldn’t instantly rm -R a huge folder with a zillion things in it.
I don’t know. But if the filesystem does the traversal then that is a problem because it might do it asynchronously later when the toast should already be shown.
At any rate I think showing a count of direct children would be enough.
Not sure what you mean by this, since the message also contains the name of the folder deleted. That has a clear benefit since the user can easily double-check their decision and undo it in time. This would just be adding slightly more information.
It’s possible to make mistakes like this other than when “deleting things without knowing what they are”. You don’t necessarily use the name of a folder as the main thing guiding your actions moment-to-moment, and it’s entirely possible that you deleted a folder because you selected it earlier, or you were moving quickly, or you’re just confused in the moment about what the name was.
In general, asking people to just not make mistakes is a bad idea. Why is the “Undo” button there in the first place? For exactly this reason: People make mistakes. This is going to let more people realise they made a mistake.
The whether a folder is empty is a very notable difference in my mind when I delete a folder. I don’t delete a folder usually without knowing whether it’s empty or not.
The aim isn’t review what you deleted, the aim is to have an undo button without interruption to most users. Otherwise we would need to show a list of every top level item deleted to review. If you need to review deletions, you need to open the trash.
The whether a folder is empty is a very notable difference in my mind when I delete a folder. I don’t delete a folder usually without knowing whether it’s empty or not.
It’s better to not show the message if a folder is empty, like I already said.
I think having a split second to reconsider things is in fact helpful. The information in the tooltip absolutely can help you in deciding whether you want to undo or not.