Delay send (to allow "UNDO")

[asfsgfdsfaber]

With Gmail one of the most valuable features to me is the UNDO feature. Basically it delays sending for about 30 seconds, so I can quickly click the UNDO button so that it doesn't send and I can fix errors and typos as I see them and then send. I do this on a vast majority of my emails. I would like to be able to set this to any length of time I want.

[davidmiller]

I do this on a vast majority of my emails.

If this is true it sounds like a human problem more than a software problem.

Maybe try proofreading?

[nifgraup]

This is a duplicate of #34

[jmthackett]

+1

asfsgfdsfaber notifications@github.com wrote:

With Gmail one of the most valuable features to me is the UNDO feature.
Basically it delays sending for about 30 seconds, so I can quickly
click the UNDO button so that it doesn't send and I can click errors as
I see them. I do this on a vast majority of my emails. I would like to
be able to set this to any length of time I want.

---

Reply to this email directly or view it on GitHub:
#93

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[ulikoehler]

I don't believe this is a realistic request:

• It would be nice, but doing it right depends on Mail-provider specific features, plus it will only work if both the sender and the receiver support it when using serverside features
• Not doing it right (IMO) would .... well, delay sending for 30 seconds. I don't want to wait an additional minute to get a reply. Doing it optional would be possible, but I don't think it's worth the effort, considering it also makes the UI more complex.
• As suggested before, proofreading would yield better results. Why not read what you wrote 30 seconds before you click send, not in the 30 seconds after it?
• I myself never used the Gmail feature. I accidentally typed ctrl+enter a few times, but you get used to it.

👎 therefore.

[tildelowengrimm]

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

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. If you don't want to wait 30 seconds to send an email, no problem: you can turn it off. For many people this fulfills a valuable story, and should be implemented.

[asfsgfdsfaber]

I'm not going to use mailpile until it has this feature.

[asfsgfdsfaber]

QUOTE @flamsmark
Good UX design involves building features around what users are going to do, not requiring users to change their behavior or be perfect.

I couldn't have said it better myself! :D

[ulikoehler]

Other mailclients expressing some behaviour is a good and valid point, however, there are, literally, hundreds of mail clients out there which don't express this behaviour. E-Mail-client marketshare is not 99.995 % vs 0.005 % after all, so there are plenty of users who don't used the aforementioned most-popular (I don't know which one you're referring to? GMail ? Outlook?) client.
Therefore, one could use the exact same argument to demand not to implement it.

Besides that, it doesn't address my concerns, specifically:

• I know a lot of users who expect their e-mails to be sent if they're shutting down the computer immediately after clicking send, not when they turn on their computer half a week later. I don't think there's a real possibility to implement a send-on-shutdown-mechanic reliably. There a dozends of shutdown types, including exceptions in the application itself. It might work most of the times, but that's simply not enough (especially in the I'm leaving for a 4-week holiday now, but I'll just send one last e-mail before case).
• To me it is an absolute neccessity that my emails will be sent (using SMTP) immediately (SMTP needs to start within 2 seconds). I can not wait 30 seconds in any case. It could be implemented as option that can be enabled, but it doesn't really solve the problem, as suggested by @davidmiller
• Why don't you simply proofread before sending as @davidmiller suggested? It's the same thing timing-wise, and it works way better! Un-sending might increase sloppiness, but it won't really increase quality (as in RFC1925).

If it's going to be implemented, I vote for making it an optional opt-in-style option, not the default. That should be OK with most users, but you'd have to think through all the consequences and side-effects before that.

I, personally, don't think the Mailpile core team should use any of their time to implement that in the forseeable future (but hey, anyone can submit a pull request).

[asfsgfdsfaber]

Duh, that's why most people don't use those other ones. As if there were more to choose from then actually less than 10.

And yes, OBVIOUSLY you need to be able to turn the feature on or off.

[ulikoehler]

All of the people I know do use between 30 to 40 mail clients. Literally, from Apple Mail to Zindra. It is true that a majority of users use a small number of mail clients. It is not true that no-one uses the others, or that users who use them don't matter.

And please, don't presume reasons why users are not using the same mail client you're using. Not everyone needs this feature as desperately as you do.

I might not be the best example, but I intentionally don't use features like that (and I usually don't use mailclients that support them), because I fully agree to @davidmiller and I proofread. It's simple, and it works. As I mentioned before, it doesn't really matter if you proofread in the 30 seconds before sending instead of proofreading (in a haste) in the 30 seconds after sending. Why don't you do it before?

[asfsgfdsfaber]

Wow, you are a massive fucking liar.

Nobody but a fucking dumb ass without a job uses 40 mail clients. Why can't they have a job? BECAUSE THERE ARE ONLY 30 DAYS IN A MONTH, NO ONE HAS THE TIME TO CHECK FORTY DIFFERENT EMAIL CLIENTS. You stupid dumb ass retarded fuck.

As for why don't I change my usage: Why the fuck should I? Why don't you go fuck yourself in the ass? Get a job you stupid fuck and stop saying retarded shit on the internet you fucking dumb ass.

Go away dumb ass troll.

[ulikoehler]

@asfsgfdsfaber Please don't use such words here, thanks!

Why are you calling me a liar? I did not lie. If some of my statements came across as harsh, I'm sorry and I'm happy to take them back if they are objectively false. Calling me a liar and repeatedly h1-quoting @flamsmark (which has, as I mentioned before, a valid point), doesn't really help anyone.

[ulikoehler]

I believe you misunderstood me. It's not that people are using 30 or 40 mail clients at a time. What I meant (I'm sorry if that was unclear) is that there are (about) 30 to 40 mailclients used by a non-negligible userbase. I agree with you that any particular user would only use ~3 mailclients.

Again, I'd be grateful if you'd not use such words here and you'd not repeatedly h1-quote @flamsmark. Repeating a valid point again and again doesn't make it more or less valid.

[asfsgfdsfaber]

QUOTE @ulikoehler All of the people I know do use between 30 to 40 mail clients.

It doesn't take a genius to realize it's not in any way practical for ANYONE to use even more than at most 3 mail clients INCLUDING mobile clients (ONE primary), not to mention FORTY. So for you to say "everyone I know uses 40 email clients" is so fucking retarded that it goes without saying you're a fucking liar and a fucking troll.

And you're fucking retarded if you think anyone is stupid enough to believe such a dumb ass comment. That's like saying, "yeah, every day I visit all 50 states, and so does everyone I know."

GO AWAY TROLL.

[smari]

Okay, this is getting out of hand. People: Be civil.

[ulikoehler]

Thanks @smari ! Your moderation is highly appreciated!
Sorry if anyone feels offended because of my opinion! It wasn't intended that way. I'm not a native-english speaker so I might not be able to express what I mean exactly in any occasion. Please allow for some margin therefore, I might just have mis-expressed myself instead of offended you.

TL;DR: For me, personally, an option to enable this, with default=false would be OK, but I, personally, wouldn't use it.

In order to prevent further misunderstanding I'd like to try summing up my own, personal, maybe biased-by-own-behaviour opionion on this matter:

• Implementing this server side isn't really possible, because most mail servers don't seem to support this. What is discussed here - a client-side implementation - an could technically be implemented.
• I think there are plenty of users who use the feature, and plenty who do not. I do know about 100 times more persons that don't use it, but they are not representative at all --> Both groups are non-negligible.
• I know many users, including myself, who don't use the feature, not only because their mail client does not support this. In most cases I know of this is because these people got used to proofreading in the first place.
• I think a client-side-implementation has a large number of possible caveats (it's near impossible to fix any of them) that might cause an e-mail not to be sent before computer shutdown / application exit. I don't think there is a way to reliably guarantee that after the user clicked send, the email will be sent no-matter-what (unless he clicked undo). One of the reasons for this is Mailpile is supposed to run locally and not usually on a server.
• As noted by @flamsmark , The most popular email client in the world (don't know which one that is, but it doesn't really matter) supports delayed sending. That is a valid point, but there are plenty of other widely-used e-mail clients and a significant subset of them does not support that feature, leading to a singificant amount
• @flamsmark also noted that a good UI design should not require the user to be perfect. That is also a valid point, but you could also apply that argument to users not expecting delayed send.
• Agreeing with @davidmiller (not specifically pointed at asfsgfdsfaber , but in a more general sense), I think this is more of a human problem, you should proofread in the 30 seconds before sending, not in the 30 seconds after. This solution might take some time to get used to, but it's usually worth the effort.
• However that does not mean that implementing it would be totally useless to implement it in Mailpile, see @flamsmark 's points.
• I use E-mail in a way that most of the time 30-second delays are not acceptable, plus most of my mails are way too long to proofread in 30 seconds.
• I would prefer the other features (as outlined in the Mailpile blog) to be implemented with higher priority than the delayed send.

[ulikoehler]

I suggest to close this issue and redirect further discussions to #34 - In my opinion #34 contains more valuable information than this post.

[smari]

Done and done!