I created this agent when I saw that Thunderbird and other mailers had this feature.
And it’s very useful when we want to send an email in a specific date.
For example, for a customer it’s useful to create a mail when he has time, and send it at a specific date (perhaps he will be in vacation).
So I started it during 4.11 development, and finished it this week (I know after beta2 but didn’t have time before with my others KDEPim project).

As it’s an agent it’s not necessary that KMail is launched to be sure that mail will be send.
It’s an other feature which can be outside KMail (it’s a good thing for the future).

Now how does it work ?
Firstly it will be use when you click on “send later” in the composer, before it just stored it in send folder and that’s all.
In 4.11 it will open a dialog box and you will able to define at which date you want to send it. I added 4 buttons:
- send 30 minutes later
- send 1 hour later
- send 2 hours later
- send at specific date/time

And finally you can be send mail as recurrent (each x days, x months, I will add x years in 4.12, because it can be useful for sending an email for birthday for example, not useful for me I remember each important date:) )

Email  was be stored in Template folder.

I hope that it will use by you.
I think it’s a good new feature.

“Send Later Agent” configure dialog:

“Add send later agent”  dialog:

Update:

After read comments I changed UI:

Trackback

15 comments untill now

  1. Very good. Just recently I determined that this was missing in kmail.

    I think that the 2nd window (add send later agent dialog): need some improvement. Perhaps less buttons, or nicer aligned? The 30 min, 1 and 2 hour later buttons could be shared in 1 drop down menu (giving the possibility for many more delay periods).

  2. Will look at to how to improve it in 4.12.
    Thanks

  3. Great new feature. Ill make heavy use of it :) . Thank you.

  4. Alejandro Nova @ 2013-07-07 02:30

    Please, keep up the good work. We all love KDE PIM!

  5. Great idea!
    However, please do not release the feature as it is. It would only hurt KMail’s reputation in its current form, when it could instead be a great feature if the usability is improved.
    Here are my suggestions (in order of priority):

    1. Remove the “send now” button. It’s an unnecessary source of user error: Usually in KDE the “apply” button is the leftmost, so users are likely to click “send now” instead of “send later” when they actually want to send the mail later (that’s why they clicked “send later” in the toolbar in the first place, right?).
    Actually, I’d consider the “send later” button in the leftmost position a critical usability bug, which has to be fixed before the 4.11 release. It will result in lots of errors and user frustration (imagine accidentally sending that birthday mail a week too early just because you clicked the leftmost buttons like you usually do!).
    If people decide that they want to send immediately after opening the dialog, they can still click “cancel” and then “send”. This is no problem because it won’t happen often (usually users only click “send later” in the toolbar when they in fact do want to send later).

    - Generally, a dialog should only have one confirm button. Currently, you have six confirm buttons, all in conflict with each other. Actually, I don’t see much use in the “30 Minutes Later”, “1 hour later” and “2 hours later” buttons. Are there clear usecases for them? I think they confuse more than they help. Either I want to send a mail asap or I want to send it at a specific time, those thee intervals just seem arbitrary.
    If you think they do indeed represent common usecases, place them above the date and time picker and make them automatically set the picker, so you don’t have conflicting widgets.

    - The setting for the date time should not use a spin box. Use a KDateComboBox and a KTimeComboBox instead (we’re planning to create a combined widget, but until that’s available, you’d have to use both), they work best for entering a date and time.

    - Buttons changing labels dynamically are not a good idea. I don’t think a button should be used there at all, because users will forget to click it and wonder why the recurrence is not set. Turn it into a label instead (and remove the “around”, see above) and when the user clicks “send later”, the recurrence is set as well (because the button confirms the dialog as a whole, which includes the settings for the recurrence.

    - “Send around” together with a date/time with precision down to seconds looks really weird. Either it will be sent at precisely the indicated time, then it should read “send at”. If it’s imprecise, than users should not be able to set an exact time.
    Of course if it’s not possible to send at the exact time (e.g. because you’re not connected to the internet at that point or the server has a problem), it’s sent later, but that should be clear to users anyway.
    The “send around” just gives the impression that the system is unreliable (may send a few minutes earlier or a few minutes later, nobody knows), which is not good.

  6. @thomas: Ok good idea to improve it.
    But you want to remove “send later button” but if we remove it we can have old feature which is just “send later” without date, so for me we force to define a date/time for sending it no ? Sometimes we just want to send when we want.
    1) ok we can click on cancel it’s right.

    2) “actually, I don’t see much use in the “30 Minutes Later”, “1 hour later” and “2 hours later” buttons” just for helping to define small interval. Otherwise it’s necessary to change date/time for it.

    3) “KDateComboBox and a KTimeComboBox” oki why not.

    4) with ktimecombobox we can’t set second so ok.

    “The “send around” just gives the impression that the system is unreliable (may send a few minutes earlier or a few minutes later, nobody knows), which is not good.” told to user that it’s be sure that it will send a exact time is not good too. For me it’s better to write it. IT’s more true.

  7. “But you want to remove “send later button” but if we remove it we can have old feature which is just “send later” without date, so for me we force to define a date/time for sending it no ? Sometimes we just want to send when we want.” add a button => “put in outbox” => as previous function

  8. Hey Laurent,

    First: SUPER COOL FEATURE!

    Second, I do agree with Thomas on the usability issues. I think the dialog should have a ‘schedule’ and ‘cancel’ button on the bottom – cancel should simply close the dialog so the user can send the mail normally (or re-open the dialog picking the schedule button on the tool bar). That is assuming that this shows up in the kmail mail editor on the toolbar or at least in the menu. Which seems to make most sense…

    About 2) – the intervals, if you make setting time/date easy enough you don’t need this.. The current solution isn’t very nice. I suppose the suggestions by Thomas are good enough.

  9. Ah, so by “send now” you actually mean “send at specified time”? That means the labels are really really confusing ;)
    1) I still think the classical “send later” can be removed. If I want to compose a mail but don’t yet know when to send it, I can still save it a draft. No need to store it in the outbox. I don’t think keeping the old “send later” is worth the added confusion.

    2) The date should default to the current date, so you’d only have to set the time (which is not hard with a KTimeComboBox). Again, I don’t think offering a quick way for selecting one of three arbitrary values is worth the added buttons.

    4) True, but I don’t think people will often actually want to set seconds, since you don’t know how long the mail will take to arrive, so you cannot predict arrival down to seconds anyway.

    If we cannot tell exactly when it will be sent, we should not give users the tools to set a precise time. Why set exact seconds if I don’t know when exactly it will be sent anyway? When users can only set hours and minutes, the “around” can stay, as it’s not confusing anymore.

    I think with the improvements in place, it will indeed be an awesome feature!

  10. Ok I fixed cleaned UI see new screenshot.

    Thanks Thomas, Jos
    Regards

  11. Awesome, I think this is much cleaner. The only issue left is the alignment of the widgets but I couldn’t tell you how to do better… Aurelien probably cam, perhaps ask on the kdepim ml?

  12. Yes it’s in my todo list (fixing layout)

  13. I agree with Jos, it looks way cleaner now. Great improvement!
    Only one more thing: “Recurrance each” doesn’t make much sense in English. I consulted with a native English speaker (d_ed) and we concluded that it should be “Repeat every:”
    Other than that (and the alignment, which isn’t critical for usability though), I think it works well now. Thanks for reacting to our comments so quickly!

  14. Thomas thanks I fixed english pb too.

    (and layout was fixed to so all is ok now)
    Regards

  15. You’re the best!

Add your comment now