Relative baseline problem

[orschiro]

Hi @rosulek,

I had an idea to address the relative baseline problem. As I recall correctly, you were saying that there is no way for you to know the relative date for conversations older than a week. I would like to know from you whether the following could work:

Let's say the last email conversation from a conversation dates back to Friday, 17 April. If I assign the label tomorrow to it, it would immediately come back into my inbox because Saturday, 18 April had already passed. But what if we calculate the relative date based on the date at which the label had been assigned? In that case, tomorrow would become relative to today because I assigned the label today (and this could be calculated based on the hourly trigger, right?).

Looking forward to your response!

Robert

[rosulek]

In the documentation I mention that I don't know a way to find out the date a label is applied. But if you learn of a way, please let me know. I agree it would be useful here. On Apr 20, 2015 1:41 AM, "Robert Orzanna" notifications@github.com wrote:

Hi @rosulek https://github.com/rosulek,

I had an idea to address the relative baseline problem. As I recall correctly, you were saying that there is no way for you to know the relative date for conversations older than a week. I would like to know from you whether the following could work:

Let's say the last email conversation from a conversation dates back to Friday, 17 April. If I assign the label tomorrow to it, it would immediately come back into my inbox because Saturday, 18 April had already passed. But what if we calculate the relative date based on the date at which the label had been assigned? In that case, tomorrow would become relative to today because I assigned the label today (and this could be calculated based on the hourly trigger, right?).

Looking forward to your response!

Robert

— Reply to this email directly or view it on GitHub https://github.com/rosulek/gmail-tickler/issues/6.

[orschiro]

Will try my best and get back to you!

[orschiro]

Without having received an extensive answer, a user on stackoverflow reports that the suggested approach might work.

http://stackoverflow.com/questions/29752621/gmail-google-apps-script-find-out-the-date-a-label-is-applied/29754907?noredirect=1#comment47757443_29754907

[lehrblogger]

I've been thinking about this problem too, and how to effectively recreate the tonight/tomorrow/this weekend/etc snoozes I became so accustomed to in Mailbox (R.I.P.). A few thoughts:

• I realize that I could use the email-based snoozing to set the thread's baseline to now, but there's something about mixing data (email) with metadata (snoozes) that gives me an irrational yet unshakable uneasy feeling. I also worry that I'll confuse myself if I mix my tickling techniques.
• The script could be modified to keep track of label application timestamps in a separate datastore, but I'd really prefer to avoid the additional dependency and maintenance burden.
• My next best idea was to modify the script to automatically create the labels I most commonly wanted, but based on specific dates i.e. jan20 7am rather than tomorrow). I'm trying https://github.com/lehrblogger/gmail-tickler/commit/5314db5e98f9473405b5f901bd3756327340ccc6 out now, but don't love the clutter in my label list, and figuring out which label corresponds to this weekend is a bit tiresome. I'm sure I'll eventually make a mistake and something will fall through the crack for one day too many.
• But there is hope. Why can't the script, when it encounters a protected label like tomorrow for the first time, remove that label and replace it with the corresponding specific jan20 7am label using the time at which the script is running as the baseline? I've got my trigger running every 15 minutes (I tried 5 minutes and hit the quotas), and perhaps it could take that FUDGE_FACTOR into an account and apply the error label in ambiguous cases.

At some point I'll probably take a stab at implementing that last idea, but thought I'd think out loud here in case others had suggestions.

[rosulek]

That is a nice idea and I'd be in favor of it (especially if you implement it!). So any relative date/time specification would be replaced by the absolute one as determined by the current time (first encountering the label).

The script supports multiple labels on a single email, like tickler/tomorrow + tickler/7pm. Internally it just concatenates them together into tomorrow 7pm and parses that deadline. It might be tricky to nail down exactly how to update the labels in this case: replace just tickler/tomorrow with tickler/jan20 while leaving the other one? Replace both labels with tickler/jan20+7pm? Probably the latter since we lose the information about which term of the deadline came from different labels.

[lehrblogger]

Thanks for pointing that out! I've got some travel coming up so it might be a few weeks before I can implement this, but every time I tickle an email I'm reminded of it, so eventually :)

[lehrblogger]

I know it's been forever, but I still plan to work on this, hopefully in the next few weeks...

[rosulek]

I have started a new dev branch in which I implement my take on this. In fact, there was a bunch of other refactoring I wanted to do and basically everything except the date-parsing has been rewritten. I just pounded this out today and haven't tested very rigorously.

The main thing is that there are two "namespaces" for labels. Users will add labels of the form tickler/*. The script manages "internal" labels of the form tickler/@/*.

• The script scans tickler/* labels for tickler commands to move to the internal namespace. For example, if it finds a thread with label tickler/7pm tues, it will replace it with tickler/@/2016-10-11 at 19:00. Importantly, the deadline is calculated based on the time the script first notices this thread (as an approximation of the time the label was applied), not on any time of an email within the thread.
• The script scans tickler/@/* labels for emails to restore to the inbox at the appropriate time.

Other changes:

• No longer tries to merge several labels. If you add tickler/7pm and tickler/friday to a single thread, then it will process each label independently, and the thread will end up with 2 deadlines. It will show up in your inbox on the earlier deadline.
• Got rid of the email-address mechanism username+tickler+tomorrow+7pm@gmail.com to specify tickling. It would not be hard to add back, but I don't really use it anymore.

Comments welcome!

[rosulek]

I added the tickle-by-email-address functionality back (again in dev branch).

Overall I am enjoying the new workflow. I like that both mechanisms put the thread in tickler/@/* in a common format. I like being able to look at a glance in tickler/@/* to see what's there. I think internally things should scale better since it looks at labels first, then only if it needs to take action does it load actual threads within that label.

I'd be interested to hear your impressions @lehrblogger since you seem to use the tickler much more extensively.

[lehrblogger]

In general, this looks great! I've been using the new version for the last couple of days, and haven't noticed any issues. Personally, I don't use the email tickling functionality because the clients I use make it easier to apply labels, but it's fine with me to keep it.

I like how you've organized things in this branch. I'll continue to try things out, and might submit smaller PR's after it's been merged into master as needed.

The new error handling in particular is great. The client I use on my iPhone doesn't make it easy to tell what labels have been applied to a thread, so if there are new messages after I initially tickle the thread, I often inadvertently choose a different snooze time, creating an error state that's a hassle to clean up. Untickling at the earliest time seems like a much better solution.

There might be a small bug where threads tickled to the very near future require two passes of the script to appear properly in the inbox, rather than just one. I had accounted for this before here.

One thing I discovered while working on a different Scripts project is that it's pretty simple to split things into multiple files. On one hand, the code is more organized with a utils.gs and config.gs and so on, but on the other hand, it's more inconvenient to update everything with a new version with one copy-paste. It's not that obvious from the Scripts UI that you can have multiple files, so I thought I'd mention in case you had a preference.

[rosulek]

I am closing this after the merge #19 to master. Re-open if there are problems related to this new approach. I'll open another issue about the "very near future" problem.