search

leggett / simplify

Issue tracker for Simplify Gmail, a browser extension to simplify Gmail's interface
https://simpl.fyi
1.64k stars 103 forks source link

True exclusion of threads in search for negated labels/attributes #624

Open hlwoodcock opened 3 years ago

hlwoodcock commented 3 years ago

Hi Michael,

OK, this one is a huge frustration for me (and I am sure a ton of people)... do you think it would be possible to make an option/function that would periodically "re-apply" labels to conversations/threads that have been updated with new emails?

The reason I ask is b/c I like to use the labels to organize my inbox and search (specifically exclude) labels to try to focus on specific things. The problem is that the way Gmail uses conversation threads makes excluding labels very challenging (i.e., new emails do not automatically get labeled - I suspect you know this behavior quite well).

Anyway, is there anything that can be done to correct/address this?

leggett commented 3 years ago

This is a major annoyance. I even tried to solve it when I worked on Gmail (details below).

Adding labels to all new messages on a thread isn't something I can do (I don't have the access required). And unless it ran with high frequency, it wouldn't always work.

BUT, your request reminded me of something I do hope to do: allow for exclusion searches to work as expected (conversation based, not message based). So if you search for -in:inbox, -is:starred, or -label:foo – I could detect that you had a negation in the search and hide any threads that you would expect to not be there. Detecting this would be a bit of work. Hiding it should be pretty easy. Coming up with the right UI so I could turn this on by default would be the real trick.

I'm working on bundles right now and I could see bundling (and collapsing) everything that was a partial match. I'd have to do some special things so that Select All didn't select them if the bundle was collapsed. It would probably get hairy quick but I don't think it is beyond my reach.

Thoughts?

P.S. Deeper thoughts on how Gmail search works

The tricky thing with Gmail search (and the Gmail backend) is it is actually all message-based while the UI is all conversation-based. So, say you have a conversation with a few messages back and forth. You archive it (this removes the Inbox label from all the messages in the conversation). Then a new reply comes in so the conversation is in the inbox again. The inbox label is actually only on that new message. If you search for "-in:inbox", that conversation will still show up because some of the messages in the conversation don't have the inbox label. It will also come up if you search for "in:inbox" because the most recent message in the conversation has the inbox label.

By adding a label when you archive mail, you are allowing yourself to look for the existence of that label on any message in a conversation instead of the absence of the inbox label on every message in the conversation. BUT this also means a conversation you archived and labeled will show up even when there are new replies that have the conversation also in your inbox. So your system isn't perfect either.

So negative search components (-is:starred, -label:test, -is:unread, is:read, etc) all kind of work but not fully as you might expect.

It is confusing. I wrote an extremely long and detailed proposal on addressing this when I was on the Gmail team and the backend team basically told me to bugger off. :/

hlwoodcock commented 3 years ago

Hi Michael - Thanks so much for your long and very very thoughtful reply!! Honestly, I would be happy with anything you could do to improve excluding labels/searches! Literally, every option you laid out would be an improvement over the way it is currently implemented.

One option I am curious about in contrast to this issue... would it be easier to implement a thread-like option (i.e., some way of grouping messages) that could be enabled in combination with switching away from the conversation/thread paradigm? Your mention of bundles made me think of this, but, honestly, this seems like it would be more difficult than what I asked for initially.

Also, in terms of re-applying labels... if this really was turned into a cron-like task where it just happened every few hours... it should be possible to do this with only very recent messages right? So basically, re-apply labels to all conversations that are less than 24 hours old... if they are older than that then they have probably moved on and can safely be ignored and you wouldn't be bombarding the servers forever. Anyway, this is just an idea that I'm sure, has MANY technical challenges that I am not aware of. Regardless, thank you so much for valuing this problem and thinking about ways to solve/work-around it!!!

BTW, I am sure the backend guys were just being lazy... in my experience, this is the root of many IT issues... front-end folks know the best way to do things, but backend folks just can't be bothered to change things to facilitate real user-level improvements!

leggett commented 3 years ago

You can probably apply labels to all the messages on a thread via an App Script of some sort. I just haven't invested the time to see what all I can do with these or figure out how I would distribute them to Simplify customers. They definitely would require greater access (something I've tried to avoid).

As for grouping messages, that is definitely harder than what you are requesting BUT I'm already waist deep in building it for bundles. I'm hoping to release an early version of it to canary.simpl.fyi in the coming weeks.