Refine the search by keyword and delete all?

[mikeone]

A secondary use case is to identify all mail from a particular sender

This would bei my main case:

> Identify messages from a particular sender in Inbox (... or in any other folder) and mark them (all at once) as read, move them to a specific folder, delete them, ...

[Davey126]

Re: ...reapplying the hidden 'sent' label in Gmail which can be inadvertently removed by non-Google mail clients including Aqua.

It's important to note this behavior (IMO) does not reflect a design flaw or execution error in Aqua or other mail clients. Rather it offers the flexibility for users to organize mail in the manner that best suits their needs. So, if opt to move the third message within a six message conversation to a different folder Aqua honors that instruction even if it results in removal of existing labels including 'sent'. Native Google mail clients prevent this behavior which is a design choice on their part and may not be desirable in a generic mail client like Aqua.

[Kostya Vasilyev]

Here is what I'd like to propose then:

The current "search dialog" (the one which supports Paste) has a two-state toggle button, for choosing search on "text" vs. "headers".

I can extend this to add a third state, "sender", with appropriate visual feedback (right now the icon changes, and there are help prompts).

So to search on "sender", one would 1) bring up search 2) enter a query 3) tap the button twice to take it to "search by sender" state 4) press submit.

And then separately from that we can discuss what should be done with the current "search all headers with a swipe command" - should there be a new one, or should it be left as is, considering the user can refine search from a search results view.

Let's not conflate these two parts but keep them in mind.


The proposal is actually for something very very similar to Samsung's search UI, but more compact, and it also leaves room for the list of suggestions (previous searches).

[Kostya Vasilyev]

Let's see what Mr. @Davey126 thinks about it

[Davey126]

Here is what I'd like to propose then:

The current "search dialog" (the one which supports Paste) has a two-state toggle button, for choosing search on "text" vs. "headers".

I can extend this to add a third state, "sender", with appropriate visual feedback (right now the icon changes, and there are help prompts).

So to search on "sender", one would 1) bring up search 2) enter a query 3) tap the button twice to take it to "search by sender" state 4) press submit.

And then separately from that we can discuss what should be done with the current "search all headers with a swipe command" - should there be a new one, or should it be left as is, considering the user can refine search from a search results view.

Let's not conflate these two parts but keep them in mind.


The proposal is actually for something very very similar to Samsung's search UI, but more compact, and it also leaves room for the list of suggestions (previous searches).

The enhanced "search dialog" proposal looks good (actually delayed responding to give it a reasonable think)! It will address my immediate interests and hopefully those of the thread OP and others with a similar need. Although I don't own a Samsung android device I like the idea of mimicking an existing UI design for the reasons given.

Yes - save swipe discussion for another day as some back-and-forth will likely ensue as ideas are tossed about.

I do have a question that is unrelated to the proposal at hand but may impact the effectiveness of certain 'From:' searches. Which header field is used? Here's why I ask.

I have several conversations with (nearly) identical subject lines but different originators. The originator name, email and image clearly show in each message. Replies are appropriately addressed to the original sender. Of course I like it this way (mimics Gmail) but it's not suppose to happen with sender+subject grouping logic. I believe the messages are grouped because they originally went to a secondary account that auto-forwards to my primary account. Depending how the search logic is coded one may not be able find messages from the original senders as Aqua may think they both originated from an intermediary secondary account.

I am happy to share the full messages and/or headers with Kostya if helpful.

Note the above scenario is NOT a problem for me as my primary use case is to identify messages that I sent - not those that others sent to me. Others may have a different view.

[Kostya Vasilyev]

Re:  Which header field is used?

Now: From, To, CC, BCC (in case it's there) and Subject, that's what "search headers" looks at

Proposed: From

I'm a little lost in the details of the scenario you posted, here is what I was able to understand:

Re: I believe the messages are grouped because they originally went to a secondary account that auto-forwards to my primary account

If they're *forwarded* (say foo@yahoo.com is set to forward to bar@gmail.com) then they'll be seen in the app as coming from foo@yahoo.com (there are some special headers that would let me collect the original sender, before the forwarding, but this is a little used scenario and I'm not sure what the code does now).

So yes, they are grouped.

Had you set up bar@gmail.com to *pull* mail from foo@yahoo.com, the original sender would have been preserved.

[Davey126]

Sorry for the confusion; likely a head scratcher trying to pull out the relevant points ... 

re: Now: From, To, CC, BCC (in case it's there) and Subject, that's what "search headers" looks at
re: Proposed: From

Yep - got that; all good. 

re: I'm a little lost in the details of the scenario you posted, here is what I was able to understand:

You understood perfectly! As long as you are aware of what users might experience/report there there is no issue. I agree this is probably an edge case as few make use of auto-forwarding capabilities from secondary mail accounts (I use this frequently to obscure my primary email address). Pull is less efficient and not always timely so I will stick with push (ie: auto-forward).

Personal usage note (just an FYI): I will likely broaden the use of secondary email addresses forwarded to my primary as it indirectly yields conversation grouping by subject only which is my preference and mirrors gmail's native grouping behavior with no apparent loss of functionality. A reasonable personal work-around as most Aqua users seem to prefer conversation grouping by sender+subject.

[Kostya Vasilyev]

Re: As long as you are aware of what users might experience/report there there is no issue

Email, by its nature, is very flexible.

And users always find creative ways to "do something"...

[StR]

Re: I believe the messages are grouped because they originally went to a secondary account that auto-forwards to my primary account

If they're *forwarded* (say foo@yahoo.com is set to forward to bar@gmail.com) then they'll be seen in the app as coming from foo@yahoo.com (there are some special headers that would let me collect the original sender, before the forwarding, but this is a little used scenario and I'm not sure what the code does now).

So yes, they are grouped.

I apologize for intervening, but I just wanted to point out that there are different ways of how automated forwarding might be implemented. And in some cases it might not behave as you described above.

In one of them, if I set the forwarding as a "virtual user" in sendmail configuration, all you'll see in the headers of the ultimately delivered message is the in one of the Received: headers, it will have a change in the portion  " .. for <new_addr@new_domain> "

So, it will look:

Code: [Select]

Return-Path: <sender@domain1.com>
X-Original-To: addr3@domain3.com
Delivered-To: addr3@domain3.com
...
Received: from domain2 by domain3 with ESMTPS id
    u4JHHVoS001006
    (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)
    for <addr3@domain3.com>; Thu, 19 May 2016 12:17:33 -0500
Received: from domain1 by domain2 with ESMTPS id
    u4JHHUm9056978
    (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT)
    for <addr2@domain2.com>; Thu, 19 May 2016 12:17:03 -0500
....
From: original sender <sender@domain1.com>
To: original recipient <addr2@domain2.com>

Obviously, in this case, Aquamail seeing messages as being sender@domain1.com should not group them as coming from addr2@domain2.com .
It looks like it is not relevant to @Davey126's situation. So, no reason to worry in this case.
Kostya, I just wanted to mention the situation where your assumption may break.

[Kostya Vasilyev]

@StR that's good to know, thank you (forwarding or collection isn't something I use myself...)