Undo instead of confirmation for mail deletion about thunderbird-android

[rezazarchi]

I do not know the progress of this issue but we implemented this feature like your discussion on a very old version of the K-9 code. I can reuse it and make a pull request if you are OK. @cketti

device-2023-04-04-160034.mp4

When we show that bar, the email is not actually deleted. When the undo button is clicked, the message disappears. If we don't react to it or close the activity, the message will be deleted.

[laurento]

I had to disable swipe actions :) A couple of times I archived stuff by mistake and without any chance to understand what I ended up swiping away. Indeed, I also believe a quick undo button like in Gmail app would be great to have.

[ocdtrekkie]

Obviously two million people don't review bad ideas on Github but "remove it and see how many people complain" is a terrifyingly awful development strategy.

[vt0r]

@ocdtrekkie - Please feel free to continue your discussion of material design hatred on the mailing list, as was asked of you before. Your input is not influencing development in any positive way at this point. You've stated your case, and there's no need to continue attacking others to continue defending your point in Github issues. These issues typically contain constructive information on how the fix(es) should be implemented or legitimate, objective reasons why the issues raised should not be fixed or are not actual issues. In design circumstances where subjective opinions are provided, they are simply stated, as it's in bad taste to simply justify your reasoning with statements about steaming piles of poo and the like. You're more than welcome to fork the project and continue ruling over your holo empire, as you've made it clear that keeping up with current Android design specifications signifies a project that's going "off the rails."

Back on topic, I believe the undo dialog sounds like the most elegant solution to this problem. 👍

[ocdtrekkie]

Isn't this a configurable option? In my case I rarely want a confirmation dialog for deletions personally, but I get really ticked off if I archive something on accident, and I like a confirmation dialog to archive.

[jancborchardt]

Even if this would be configurable then it would be good if undo would be the default.

When you archive something on accident then you will also get the notification that the mail has been archived, as well as the means to quickly undo it. That has the additional advantage of making it way quicker and less intrusive when you actually want to archive some mails.

[cketti]

+1 for getting rid of confirmation dialogs. Unfortunately, implementing proper 'undo' might require a larger change to the code base.

I'm not sure if there are enough users that want the confirmation dialogs to warrant keeping them as an option. I'm tempted to just remove them and see how many people complain.

[cketti]

@rezazarchi: I'd love to get a pull request implementing this feature.

[ocdtrekkie]

How would you make that look for archive/delete from the notification tray, @jancborchardt? I know in-app Gmail does like a little toast popup with the Undo option. But that wouldn't work well if you have a different app open, and I find Undo toasts disappear often way too quickly.

[jancborchardt]

Replace the notification tray entry with an entry saying »Message deleted« (or archived) and an »Undo« function on the right.

[ocdtrekkie]

By and large, most people will want to dismiss that notification. (Either it's up too short a time and people can't hit undo, or it's up too long and instinctively people will want to clear it from their tray.)

So you're just trading a confirm click for a dismiss swipe. And a tray notification to let you know an app did what you asked it to is very strange UI design.

[jancborchardt]

Of course the undo would vanish after some seconds (5 or 7, whatever …) so you can just ignore it. It’s definitely not an equal trade since the modal is blocking, undo is not. Also people tend to click »ok/confirm« on popups anyway – please read the article I linked: http://alistapart.com/article/neveruseawarning

I’ll wait for one of the devs to chime in and see what they say before discussing further. cc @cketti @obra

[ocdtrekkie]

Yes, there's a wonderful user design nerd writing an article. There are many of those.

Personally, nothing angers me more than discovering that some obscure icon without text explaining what it does did something I didn't want it to without any sort of confirmation that I actually wanted to do it. (This happens a lot between all the archive and folder buttons on mail apps these days.)

I'd far rather be asked for confirmation than given a whole extra notification to cancel it doing something outright, that may or may not still be there when I realize what I just did.

[ocdtrekkie]

...I'm complaining now? But then, it already seems there's a fork to abandon all sense and reason for UI, so I guess I should shut up, install a fork, and acknowledge that this project has spun off the rails already.

[mjdavids]

I use them (irritating or not). [But then, I am getting 'older' every day…
just saying.]

—Martin J… D…
On Apr 27, 2015 7:10 PM, "cketti" [email protected] wrote:

+1 for getting rid of confirmation dialogs. Unfortunately, implementing
proper 'undo' might require a larger change to the code base.

I'm not sure if there are enough users that want the confirmation dialogs
to warrant keeping them as an option. I'm tempted to just remove them and
see how many people complain.

—
Reply to this email directly or view it on GitHub
#624 (comment).

[cketti]

@ocdtrekkie Your opposition to this idea (and others) has been noted. But I hope you realize you're just one person out of almost 2 million. Being louder than many others doesn't make your opinion more important.

@martinjdavidson I guess it's not so much a question of who is using the confirmation dialogs now, but who absolutely couldn't live with 'do action + allow undo' instead of a confirmation dialog.

[maniac103]

The undo indeed most definitely is a better solution, but also quite a bit more involved to implement...

@vt0r He's voicing that kind of hatred seemingly for every project he's using :( See e.g. slapperwan/gh4a#227

[ocdtrekkie]

@maniac103 Just hate good apps going to waste, man. And people who aren't willing to listen to common sense. Near impossible to change a stubborn maintainer's mind.

[maniac103]

@ocdtrekkie Weird that all maintainers are stubborn though, isn't it? And that there even are users who agree with them? Maybe your understanding of common sense just isn't everyone's?

[obra]

This thread is far off topic at this point. Please take this to email, guys.

On Apr 27, 2015, at 10:27 PM, maniac103 [email protected] wrote:

@ocdtrekkie Weird that all maintainers are stubborn though, isn't it? And that there even are users who agree with them? Maybe your understanding of common sense just isn't everyone's?

―
Reply to this email directly or view it on GitHub.

[meghalagrawal]

Is there anyone Working on this?

Can this task be assigned to me?

[cketti]

@meghalagrawal: Feel free to work on this. However, it's not an easy issue and it involves quite some design decisions, regarding both UI/UX and code architecture.
My advice is to present your plan in this issue before starting the implementation. Otherwise you risk writing code that won't be merged.

[meghalagrawal]

Thanks,

Let me make a plan and get back to you.

[beneficadoramocaba]

Having just moved to k9, no ability to undo is definitely a loss that's felt when trying to organize my messages. To be clear, I think the ideas above related to showing an undo notification are too complicated, and to be honest I don't know how I feel about Delete being an option from the notification screen at all.

What should be a fairly simple change to implement, and more frequently useful, is having a time-limited pop-up while in the app. If I swipe to delete a message, grey out the message for ~3 seconds while a small bar along the bottom shows "Message deleted. [Undo]" When the timer runs out, action the delete request. I suppose this would need to be a queue in case you consecutively remove more than one message before the timer runs out, and the pop-up would need to reflect the most recent action. Likewise if multiple messages are selected, the action would be cancelled for the whole set if the Undo button is selected.

[cketti]

What should be a fairly simple change to implement, and more frequently useful, is having a time-limited pop-up while in the app. If I swipe to delete a message, grey out the message for ~3 seconds while a small bar along the bottom shows "Message deleted. [Undo]" When the timer runs out, action the delete request. I suppose this would need to be a queue in case you consecutively remove more than one message before the timer runs out, and the pop-up would need to reflect the most recent action. Likewise if multiple messages are selected, the action would be cancelled for the whole set if the Undo button is selected.

That sounds like a good idea if you occasionally delete a message. But if you triage a lot of messages you'll probably delete or archive messages faster than at a rate of 1 per 3 seconds. And now you have messages with an expired timer disappearing from the list leading to the remaining messages being animated to fill the gap while you're trying to select/delete/archive the next message.

[beneficadoramocaba]

That's true. I'd have to confirm how my old favorite app does it (Moto Email, circa KitKat), but there are a few alternatives for the animation issue: not actioning the "to delete" queue until the last countdown has been expired for a few seconds, or (more likely how it was handled by Moto), showing the pop-up at the completion of the slide out animation. I realize this doesn't work perfectly for all use cases, but I think for most people the main use case is upon accidentally removing one message, and likely not knowing what it was - then having to go hunt for it in the deleted/archive folder.

[jancborchardt]

@beneficadoramocaba @cketti if instead of greying out the message(s), the app just acts as if it does the action and actually hides the message, it will work for both people who rarely and often use the functionality.

And that can then also be paired with a longer undo timer (like 5-7 seconds) cause the message will not be sticking around in the list. :)

[jancborchardt]

@rezazarchi looks really good! :) Design-wise, a quick collapse animation of the entry would be nice to show what happens (otherwise the list jumps) and an expand animation when "Undo" is used.

But as @cketti said – would be awesome if you submit a pull request for that! :)

[schmitmd]

Yes please! This would be extremely useful. @rezazarchi is there any way I (and others) can help?

[rubcap]

Started using K-9 a couple of weeks ago after years of using the GMail app.

After you delete a mail in the GMail app, you get a toast message that allows you to undo your action. The toast message appears for like 3 seconds max. Personally, I like this better than a confirmation box, which gets in the way when you delete a lot of mails.

A similar feature in K-9 would be very welcome!
@rezazarchi It'd be great if you could reuse your earlier code. Although I must say, I'd prefer the app to delete my mail right away if I ask for it (with an option to undo), instead of deleting it only after a few seconds. I think it would be perceived as more responsive/user-respecting/logical, as you can't undo something that hasn't actually happened yet ...? Now it can be perceived as "K-9 will wait a few seconds before acting upon your request" which is totally different from "K-9 has acted immediately upon your request, but here is a button to undo it". Maybe you can try out GMail's implementation?

Thanks for reading!!

[jayb-g]

I'd love to get a pull request implementing this feature.

Amazing @rezazarchi

we implemented this feature like your discussion on a very old version of the K-9 code.

If it was already implemented, why was it removed afterwards? Currently the app has no way to address the accidental swipes.

@cketti @rezazarchi almost a year and no pull request? This would be great to have implemented.