Skip to main content
User Experience

Return to Question

Tweeted twitter.com/StackUX/status/826386364971233281
casing
Source Link
stefs
stefs
  • 131
  • 5

swipe Swipe to delete (but not archive) on androidAndroid

myMy current project includes a list of messages plus a message detail view.

threeThree modes of deletion are requested (no other actions, like "reply", are possible):

  1. detailDetail view: delete icon in the toolbar + confirmation dialog
  2. longLong-pressing a list item switches to a multi-selection mode and shows a "delete selected" icon in the toolbar that allows deletion of several items after a confirmation dialog
  3. swipeSwipe to delete

i'mI'm not too happy with swipe to delete - iI think it's a bad idea, especially in our case. theThe reason is that there is no two-level deletion. onIn most mail clients, deleting a message from the inbox moves it to the trash first where you can recover it (so it's actually archival, not deletion). inIn our app the server doesn't have a "deleted items" flag or category - once deleted, it's gone for good. thisThis also works with unread messages.

weWe do plan to implement an "undo" button that vanishes after several seconds or when scrolling, but i'mI'm not satisfied. itIt works well enough in the gmail app when i'mI'm at home or in the office, but in noisier environments like the subway, on the bus or while walking it happened more than once that instead of scrolling up/down the gesture was interpreted as a left/right archival movement and then iI even missed the undo button. mostlyMostly no harm done thanks to them being moved to the deleted mails folder, but iI hate it when iI accidentally dismissed notifications (no undo) without even knowing what they said. forFor the record, iI don't think i'mI'm extraordinarily clumsy.

iI brought this up with my superiors and they suggested displaying a confirmation dialog after swipe-to-delete which in my opinion defeats the purpose of the smooth UI action.

myMy own solution: store ids of swiped messages in a temporary list, display a secondary toolbar containing something like "X items ready to [delete] / [undo]" was dismissed because it's not standard behavior (and "too much work").

now,Now my options are:

  1. stopStop putting so much thought in it, just do what i'm told and delete messages without having the user explicitelyexplicitly confirm it
  2. implementImplement the blocking dialog after every swipe-to-delete
  3. tryTry to convince them by bringing new facts (and solutions) to the table

canCan anybody help me deal with this situation? areAre there official recommendations for or against swipe-without-archival?

noteNote: weWe don't provide any hint there's "swipe do delete" functionality in the list because "it's standard"it's standard functionality.

swipe to delete (but not archive) on android

my current project includes a list of messages plus a message detail view.

three modes of deletion are requested (no other actions, like "reply", are possible):

  1. detail view: delete icon in the toolbar + confirmation dialog
  2. long-pressing a list item switches to a multi-selection mode and shows a "delete selected" icon in the toolbar that allows deletion of several items after a confirmation dialog
  3. swipe to delete

i'm not too happy with swipe to delete - i think it's a bad idea, especially in our case. the reason is that there is no two-level deletion. on most mail clients, deleting a message from the inbox moves it to the trash first where you can recover it (so it's actually archival, not deletion). in our app the server doesn't have a "deleted items" flag or category - once deleted, it's gone for good. this also works with unread messages.

we do plan to implement an "undo" button that vanishes after several seconds or when scrolling, but i'm not satisfied. it works well enough in the gmail app when i'm at home or in the office, but in noisier environments like the subway, on the bus or while walking it happened more than once that instead of scrolling up/down the gesture was interpreted as a left/right archival movement and then i even missed the undo button. mostly no harm done thanks to them being moved to the deleted mails folder, but i hate it when i accidentally dismissed notifications (no undo) without even knowing what they said. for the record, i don't think i'm extraordinarily clumsy.

i brought this up with my superiors and they suggested displaying a confirmation dialog after swipe-to-delete which in my opinion defeats the purpose of the smooth UI action.

my own solution: store ids of swiped messages in a temporary list, display a secondary toolbar containing something like "X items ready to [delete] / [undo]" was dismissed because it's not standard behavior (and "too much work").

now, my options are:

  1. stop putting so much thought in it, just do what i'm told and delete messages without having the user explicitely confirm it
  2. implement the blocking dialog after every swipe-to-delete
  3. try to convince them by bringing new facts (and solutions) to the table

can anybody help me deal with this situation? are there official recommendations for or against swipe-without-archival?

note: we don't provide any hint there's "swipe do delete" functionality in the list because "it's standard".

Swipe to delete (but not archive) on Android

My current project includes a list of messages plus a message detail view.

Three modes of deletion are requested (no other actions, like "reply", are possible):

  1. Detail view: delete icon in the toolbar + confirmation dialog
  2. Long-pressing a list item switches to a multi-selection mode and shows a "delete selected" icon in the toolbar that allows deletion of several items after a confirmation dialog
  3. Swipe to delete

I'm not too happy with swipe to delete - I think it's a bad idea, especially in our case. The reason is that there is no two-level deletion. In most mail clients, deleting a message from the inbox moves it to the trash first where you can recover it (so it's actually archival, not deletion). In our app the server doesn't have a "deleted items" flag or category - once deleted, it's gone for good. This also works with unread messages.

We do plan to implement an "undo" button that vanishes after several seconds or when scrolling, but I'm not satisfied. It works well enough in the gmail app when I'm at home or in the office, but in noisier environments like the subway, on the bus or while walking it happened more than once that instead of scrolling up/down the gesture was interpreted as a left/right archival movement and then I even missed the undo button. Mostly no harm done thanks to them being moved to the deleted mails folder, but I hate it when I accidentally dismissed notifications (no undo) without even knowing what they said. For the record, I don't think I'm extraordinarily clumsy.

I brought this up with my superiors and they suggested displaying a confirmation dialog after swipe-to-delete which in my opinion defeats the purpose of the smooth UI action.

My own solution: store ids of swiped messages in a temporary list, display a secondary toolbar containing something like "X items ready to [delete] / [undo]" was dismissed because it's not standard behavior (and "too much work").

Now my options are:

  1. Stop putting so much thought in it, just do what i'm told and delete messages without having the user explicitly confirm it
  2. Implement the blocking dialog after every swipe-to-delete
  3. Try to convince them by bringing new facts (and solutions) to the table

Can anybody help me deal with this situation? Are there official recommendations for or against swipe-without-archival?

Note: We don't provide any hint there's "swipe do delete" in the list because it's standard functionality.

edited tags
Link
stefs
stefs
  • 131
  • 5
Source Link
stefs
stefs
  • 131
  • 5

swipe to delete (but not archive) on android

my current project includes a list of messages plus a message detail view.

three modes of deletion are requested (no other actions, like "reply", are possible):

  1. detail view: delete icon in the toolbar + confirmation dialog
  2. long-pressing a list item switches to a multi-selection mode and shows a "delete selected" icon in the toolbar that allows deletion of several items after a confirmation dialog
  3. swipe to delete

i'm not too happy with swipe to delete - i think it's a bad idea, especially in our case. the reason is that there is no two-level deletion. on most mail clients, deleting a message from the inbox moves it to the trash first where you can recover it (so it's actually archival, not deletion). in our app the server doesn't have a "deleted items" flag or category - once deleted, it's gone for good. this also works with unread messages.

we do plan to implement an "undo" button that vanishes after several seconds or when scrolling, but i'm not satisfied. it works well enough in the gmail app when i'm at home or in the office, but in noisier environments like the subway, on the bus or while walking it happened more than once that instead of scrolling up/down the gesture was interpreted as a left/right archival movement and then i even missed the undo button. mostly no harm done thanks to them being moved to the deleted mails folder, but i hate it when i accidentally dismissed notifications (no undo) without even knowing what they said. for the record, i don't think i'm extraordinarily clumsy.

i brought this up with my superiors and they suggested displaying a confirmation dialog after swipe-to-delete which in my opinion defeats the purpose of the smooth UI action.

my own solution: store ids of swiped messages in a temporary list, display a secondary toolbar containing something like "X items ready to [delete] / [undo]" was dismissed because it's not standard behavior (and "too much work").

now, my options are:

  1. stop putting so much thought in it, just do what i'm told and delete messages without having the user explicitely confirm it
  2. implement the blocking dialog after every swipe-to-delete
  3. try to convince them by bringing new facts (and solutions) to the table

can anybody help me deal with this situation? are there official recommendations for or against swipe-without-archival?

note: we don't provide any hint there's "swipe do delete" functionality in the list because "it's standard".