Feature: Undo & Better UI Notification Bubbles

[raphaelbastide]

I really love Gmail's "Undo" option after an email is sent.
It could be awesome to find it back in Mailpile.

[jancborchardt]

Yes, it’s also in their mobile app since some time. The way it works is that it just lies to you about sending the email. It’s withheld for 5 (or 10) seconds, or until your next action, whichever comes first.

Same thing for deleting emails and probably many other actions.

[ghost]

If this does get implemented there should be at least the following:

1. an option to turn this on or off
2. clear information informing the user of how this works (the thing with the lying, etc.) when switching the option on; or, in the the case of an opt-out solution (which should also be discussed in detail), before the first use of this functionality

[raphaelbastide]

I totally agree.
I suggest to turn it off by default.
As this is a “trick”, it has to be chosen consciously.

If On, Off is a solution, another one could be:

Delay before sending: 0sec

…Where 0 is the default value.

[jancborchardt]

It’s just a 5–10 second window to undo a mistake. Making people »choose consciously« sounds like a design choice which should be done by the software rather than the users.

[raphaelbastide]

As this is a “trick”, it has to be chosen consciously.

I mean “enabling the option” has to be chosen consciously.

Making people »choose consciously« sounds like a design choice which should be done by the software rather than the users.

Not a strong argument but Gmail allows me to custom the time for my grandma :)

[malexmave]

@raphaelbastide I think @jancborchardt meant that the default value is a design choice that should be done by the software, with the option for the user to change it. I may be wrong though.

[ulikoehler]

I think because Mailpile is running locally, there is a danger that mails can't be sent because the user is disconnecting Wifi / shutting down immediately after clicking send - the system could recover unsent mails, but if the user wouldn't turn on his computer for some weeks (holiday etc), it wouldn't be sent even if the user would expect it to.

A server-installation (like Gmail) wouldn't usually have this problem.

Most of the cases where this could happen can probably be fixed, but I think it's nearly impossible to fix all of them.

[dClauzel]

As the current libre email protocols don't provide the possibility to retract a sent item, the 'undo' must be made locally by the sender. The solution to have a configurable posting delay to allow that is perfectly fine, for me. Gmail did it right.

[ulikoehler]

@dClauzel I agree, there is no universal other way than to implement it client-side. GMail has an advantage to local-mailpile: The server still runs after the client exited, an it's still connected to the network.

I probably wouldn't use it but a configurable send delay would also be OK with me, as long as the default is 0 (no delay).

This would allow users to choose the option without introducing any delay or unpredictability per default.

[tildelowengrimm]

[Transposing my comments from Issue #93, a dupe of this issue. I've added more here.]

@ulikoehler Gmail, the most popular mail client in the world, does "undo" client-side. That's the right way to provide this feature, and Mailpile should do it this way too.

When you hit 'send' in most mail clients, there's some delay (often seconds) before the message is actually sent, as the client connects to the server, does a handshake and then starts sending. Some mail clients batch send every few minutes, or only on user request. Indeed, batched sending (rather than sending messages individually) has some privacy benefits if using an encrypted connection to and between mail servers. With batched sending, it's harder to work out who's sending mail to whom by passively watching where messages of similar size go. That's certainly a tradeoff, but my main points are that sending isn't instant in most mail clients.

There's always going to be a small window between hitting send and being able to yank the cord and still know your message has gone out. An "undo" window makes that period more explicit, because you can see the notification that you still have the option not to say those things about that poor chap's mother. There are lots of people for whom additional seconds or minutes of email delay are tolerable. They may not notice, especially if email is more like correspondence, and less like a real-time conversation for them. Some folks connect to their mailserver over Tor or other exotic malarkey, adding additional delay. The point here is that many email users are tolerant of delay for various reasons.

At the end of the day, people sometimes hit "send" too soon. Good UX design involves building features around what users are going to do, not requiring users to change their behavior or be perfect. "Undo" is an incredibly powerful design pattern, and it should be present in a mail client. For many people this fulfills a valuable story, and should be implemented. Others can just switch it off.

[ulikoehler]

@flamsmark Thanks for your expanded comment. I can see you point much more clearly now!

TL;DR: Optional sender-side undo should work well enough, but please with default=0 -- users will compare Mailpile default settings performance with other clients.

It's interesting that GMail does client-side-delayed sending (didn't know that, I always supposed it's server-side, so thanks for the clarification!). I absolutely agree with client/sender-side being the right way, because all other ways will only work with 'special' mailservers, and there are probably other issues with server-side. Bottom-line: Server-side won't work.

I also agree with all email-clients having a send delay (or email in general having a receive delay), even if it's only the network delay. However, when sending an email over GMail-SMTP w/ TLS, it takes me about 2.5 seconds until the mail is sent and the client has disconnected (using DSL). When using my own (virtual) Mailserver w/ TLS, the same operation takes about 0.3-0.8 second (because my server has virtually no CPU/IO load on average). This is almost two orders of magnitude faster than the 30 seconds suggested in #93 or ~1 order of magnitude less than the 5-10 seconds suggested here.

Therefore I think while it's technically true to say there are delays, 1+ orders of magnitude might matter a lot, depending on the particular usecase - in this case you compare between a delay which could be smaller than the time the average user needs to think about what he wants to do next, to (assuming 30 seconds) a delay where he could close all programs and click shutdown - or do something else that might have unexpected side-effects on the program waiting to send the mail.
Sure, when sending mail over TLS over a bad GPRS connection, the sending probably takes longer than the intentional delay (...they sum up).

30 seconds is 9900% the time of 0.3 seconds. This is important and users will notice.

If you use default=0 and you just assume the user partially thinks about what he's doing when he's switching it on, there are no negative side-effects at all. Not with the default setting, but you still have the aforementioned advantages, if you want to use them and accept the potential problems.

When Mailpile is stable and usable for normal users, they will compare Mailpile to other clients in regards of speed. 11 seconds (say 1 second for a fast mailserver + 10 secs delay) are visibly slower, by 900%, than the 1 second send-immediately-delay. If you ask users, they will say it's OK, but if they then use another (faster) mail client, they'll say "Wow, this is fast". And they will stop using Mailpile.

Generally I'd say Mailpile shouldn't be cluttered with feature options, but one additional option won't make too much difference.

Most users will not change defaults. Therefore I believe default=0 is the only option that does not impact Mailpile negatively in any way, but keeps the feature if one wants to use it.

[smari]

I'm tagging this as a plugin idea

[BjarniRunar]

Taking this issue.

The current plan: Undo will be implemented when possible, via the new Event Log - commands which mutate state in a reversible way will record the transformations to the Event Log and the UI will then offer an option to undo each mutation. Once a pattern has been established for implementing this kind of work-flow, I'll file new low-hanging-fruit issues for implementing Undo of individual operations.

[bnvk]

First implementation added with 6e5e33e

[bnvk]

This has been implemented as of the last commit, so closing!

[BjarniRunar]

Clarification: Undoing send has not yet been implemented. However, tagging can be undone; unfortunately the send action is more than just a tag, the message is finalized and becomes immutable. That might need to change. :) Commenting further on #1077.