I had a torrent selected in the Transfers list and accidentally pressed the Delete key. A dialog popped up asking whether I wanted to Delete, Trash or Keep the files. Naturally I selected the Keep the files option. Unfortunately, all this did was retain the incomplete files on disk, whereas it seems the torrent entry itself was immediately removed from the Transfers list as soon as I clicked on Del. This is bad UI/UX design - any data, including the torrent(s) in the list, should be deleted only after the user confirms the deletion. Imagine if multiple torrents are selected and Del gets pressed - it's silly to have all the entries removed with no warning whatsoever!

Since Tixati doesn't store the .torrent files themselves by default, I had a tough time locating a copy of the .torrent online so that I could re-add it and continue the download.

There can be many possible solutions to this but one seems fairly easy to implement - simply ask the user first, "Do you really want to delete N torrent(s)?" (where 'N' is replaced by the actual number). Only if the user selects Yes in this first dialog should the second dialog to Delete, Trash or Keep the files be displayed.


( Ideally speaking, every selected torrent should have a separate dialog displayed for Deleting/Trashing/Keeping files. Why should one answer apply to all? However, that's a different issue for the future. )

I remember this was one of the toughest points in my translation because you want it to sound clear, distinct and unambiguous to each other.
Despite this effort (the translation is as clear as the English original), the original itself only works for users with a lot of experience with all kinds of computer and desktop interfaces to make out and understand the difference between the three buttons. You also impose (assume) the understanding between "Delete", "Move to trash" and "Remove transfer, but keep files". It's sad but if the users struggle with concepts such as file system hierarchies, we need to go back to the 90s with self-teaching interfaces.
https://www.techspot.com/news/91434-students-dont-understand-concept-computer-files-folders.html

I agree with your explanation and I think the only solution is to rewrite the buttons into full width sentences, on three separate lines. They would clearly describe the action of a button and eliminate the requirement of long time experience with UI as I said.

Wouldn't it be much simpler to just add a fourth option to the dialog?

Delete, Trash, Keep, Cancel.

The last should cancel the operation altogether and keep everything as it was. Don't do anything until the user's choice is made.

Yes, I agree, a cancel button is extremilly basic and essential, is unbelievable that this button don't exist, what is more interesting is that if you click on X (close), this can't cancel the process, the X don't work as a cancel button, is like a one-way ticket. And the Remove and Delete Local Files window, would accept enter to confirm, so you can delete a torrent just using delete and enter keys, just with keyboard, what is very intuitive and easy. But with the current behavior you need to click in Delete Files button to confirm, and this is weird, who want to start the deleted process with keyboard and end the process with mouse? hauhauhauha Anyone! Don't make sense, because if he started with keyboard is because he want to use keyboard for the job. Need at least one setting to enable this "enter shortcut", to focus the Delete Files button, like on Load Transfer window, the focus is on Start button by default.

Absolutely true notaLamer. Besides the data loss the general UI/UX in that dialog is just bad, and I bet not at all self-evident to many users.

A Cancel button would indeed be a far simpler solution, but would obviously require the selected torrent(s) not to be removed from the list before the Delete/Trash/Keep dialog even pops up. I too found the lack of confirmation before removing data to be simply unbelievable. (The common dialog for multiple torrents is weird too.)

Don't get me started on all those deficiencies now! :)

It might be due to the common UI framework (GTK) used across Windows and Linux versions, but this app on Windows at least fails to follow basic accessibility and usability guidelines, such as having accelerator keys (underlined letters) for all clickable items/buttons, having default dialog options mapped to Enter, having Esc cancel and hide dialogs etc. etc. I too find it very irritating when apps force me to reach for the mouse just because they have failed to define accelerator keys, proper tab orders and so on.