Opened 10 years ago

Closed 7 years ago

Last modified 3 years ago

#1859 closed feature-request (Fixed)

"Remove torrent" action in GTK GUI is error prone and should be split in two

Reported by: nixar Owned by: Cas
Priority: minor Milestone: 2.0.0
Component: GTK UI Version: 1.3.1
Keywords: usability Cc: kernja@…

Description

One of the most common action in the UI is removing completed torrents.

In the current state (FTR I'm looking at 1.3.1), the same UI is used to address two very different user intentions:

  1. After a torrent is completely downloaded, stop deluge from dealing with it (seeding) but keep the data around.
  1. Whether the torrent is entirely downloaded or not, stop dealing with it AND remove the data.

The current UI is inappropriate for several reasons, and I speak from both a theoretical UX point of view and practical use:

  • The user already knows whether he wants the data deleted or not before he selects "Remove torrent," yet we have to interrupt them with a modal dialog box.
  • It's _extremely_ easy to delete data by mistake when that was not their intention, they just need to misclick by a few pixels, and there is no warning (note: warnings are not the solution anyway).
  • There is usually no reason to keep the data around when a torrent is not 100% downloaded. They can just pause if that's what they want. In the extremely unlikely event (1 in a million uses?) they want to keep the incomplete data but outside of Deluge, they can always go to the temp folder and copy it. No need to confuse the user, however slightly, in the 99.999% of cases.
  • It pops up a modal dialog box. Modes are evil.

Proposed alternative solutions:

  1. Separate "Remove torrent" and "Delete files" actions in the menu. Since the former is both less destructive and more common than the latter, bind it to the "Backspace" AND "Del" key. No confirmation dialog for "remove" required since no data is lost you can easily reopen the torrent file. Confirmation dialog could be considered for "delete files," but it would be much better IMO to move the files to the desktop environment's trash without confirmation, since this is reversable.
  1. Only offer "Delete files," bound to DEL/BS when torrent is not complete; files are moved to trash (hence user undoable). It changes to "Remove torrent" (does not delete files) when torrent is complete, same keybinding. Optionally offer "Delete files" in the latter case, but not as bound to DEL/BS in that case.

Attachments (4)

statediag-deluge.png (23.7 KB) - added by nixar 10 years ago.
state diagram for solution B
remove_torrent.png (11.2 KB) - added by James_Kern 10 years ago.
remove_with_files.png (14.0 KB) - added by James_Kern 10 years ago.
remove_torrent.patch (11.6 KB) - added by James_Kern 10 years ago.

Download all attachments as: .zip

Change History (15)

Changed 10 years ago by nixar

state diagram for solution B

comment:1 Changed 10 years ago by nixar

state diagram for solution B

comment:2 Changed 10 years ago by s0undt3ch

You do have a point, yet, I still like the ability to delete(data included) completed torrents(Ie, it was not what I was after), so, both options should be shown, ie don't base them on torrent state.

About key bindings, DEL, delete torrent, keep data around. SHIFT-DEL delete torrent, data included.

Different behaviours based on torrent state for the same keybind, this I dislike.

Just my one cent, lemme known what's decided and I might take up the ticket, though, if anyone else want's to pickup the ticket, go ahead.

comment:3 Changed 10 years ago by nixar

Well this proposed solution is based on the following principles:

  • Reduce the cognitive load for the user: don't overwhelm with options, don't require the user to have to think too much when doing something common
  • Don't surprise the user: no dialogs when they can be done away with, actions should always be reversible

Keybindings that change meaning may be slightly unusual (however DEL/BS already do mean something different when either in a list or in a textbox), but they are better UI wrt the stated principles than the alternative.

Changed 10 years ago by James_Kern

Changed 10 years ago by James_Kern

comment:4 Changed 10 years ago by James_Kern

  • Cc kernja@… added

Attached a couple screenshots for how I propose this is addressed. Basically move the "Remove with data" button to a checkbox, which when selected shows a little warning. I don't want to really change to workflow, but I would like to minimize the risk of someone accidentally deleting files due to misclicking by a few pixels.

Changed 10 years ago by James_Kern

comment:5 Changed 10 years ago by James_Kern

Attached a patch implementing the changes I described.

comment:6 Changed 10 years ago by HolgiH

Speaking as happy Deluge user: this looks like a great idea! +1 :-)

comment:7 Changed 8 years ago by Cas

  • Milestone changed from Future to 1.4.0
  • Owner set to Cas
  • Status changed from new to assigned

comment:8 Changed 8 years ago by Cas

#1679 marked as duplicate of this ticket

comment:9 Changed 7 years ago by Cas

  • Resolution set to Fixed
  • Status changed from assigned to closed

Fixed in develop: [739d8f329]

comment:10 Changed 6 years ago by Cas

  • Milestone changed from 2.0.x to 2.0

comment:11 Changed 3 years ago by Cas

  • Milestone changed from 2.0 to 2.0.0

Milestone renamed

Note: See TracTickets for help on using tickets.