AquaMail Forum
English - Android => How do I... => Topic started by: Sahara_blu on May 15, 2016, 04:16:29 am
-
Hi, in my Android standard mailclient I can refine my keywordsearch to "all" - "from" - "to" -“ in text“ etc.
How can I do so in Aqua-mail?
And how can I delete all mails in the result at once?
For example, I wanna delete all facebook-notificationmails. But only the mails "from" facebook, not the ones, where "facebook is mentioned in the mailtext of course.
And when these mails are listed to me, I want to delete them all at once.
Thanks :)
-
I recommend the following procedure.
Beforehand in the settings:
1. Enable "Pull to select"
> Settings > Message list > scroll down and enable the item "Pull to select"
2. Enable "Keep selection after action" (not really necessarily, but recommended)
> in the same settings section, three items below
3.1 Enable swipe feature
> Settings > Swiping > In message list (should be enabled by default)
3.2 Define a swipe action "Find by sender"
> in the same settings section (below: "right side" / "left side")
Now in the app:
4. In your accounts "Message list":
> find one of these "Notification messages" and sweet (right or left as defined in the settings) until the icon "Find by sender" (magnifying glass) appears - the background color of this icon will change to green
5. [UPDATED - as recommended by Paris Geek (thank you)] In the screen displaying search results, go to dotted menu -> Sort -> By sender
6. Swipe over the contact icons on the left from top to the bottom = "Pull to select (all)" or use the action "Select all" = tap on the 3-dot button (overflow icon) on the action bar to find this action
7. tap on the 3-dot button (overflow icon ) again > choose the option "Move to deleted" or "Delete permanently" (caution: this action will delete all selected messages immediately - on the server)
-
@Kostya, would you please add "from same sender" search as a new swiping action and search in "from" as a third way of search, to complete the two current types in search field.
Kostya, please find attached an icon "From" (I know its for donwloading, but it could be suitable here) to add to "Headers" and "Text", in search action.
@Kostya:
I support Paris Geek's suggestions
... and attached another idea for a specific icon "Search from same sender"
-
I think "search from" is a good idea (just not with the "download" icon, that's confusing).
"Search from the same sender" - might be a good idea... I haven't thought about it yet...
I actually like how the stock (?) mail app in my Droid Razr M has the choice "All:", "From:" "To:" "Subject:". (And I suspect the colon in "All:" means it's only all headers, not the entire text, but I've never tested.)
-
I think "search from" is a good idea (just not with the "download" icon, that's confusing).
"Search from the same sender" - might be a good idea... I haven't thought about it yet...
I actually like how the stock (?) mail app in my Droid Razr M has the choice "All:", "From:" "To:" "Subject:". (And I suspect the colon in "All:" means it's only all headers, not the entire text, but I've never tested.)
"Search from the same sender" is suggested to implement only as a "swipe action"
-
I think "search from" is a good idea (just not with the "download" icon, that's confusing).
"Search from the same sender" - might be a good idea... I haven't thought about it yet...
I actually like how the stock (?) mail app in my Droid Razr M has the choice "All:", "From:" "To:" "Subject:". (And I suspect the colon in "All:" means it's only all headers, not the entire text, but I've never tested.)
All means Text+headers. Samsung native mail app has the same (All, To, From, Subject).
4 icons could do the same in AquaMail. We already have ALL and Headers. Let's have a third one, "From" ;)
You dared me to check my guess. ;)
It appears that my guess was correct. "All:" in my stock mail app means headers only, at least for the local search (not on the server).
"Search from the same sender" is suggested to implement only as a "swipe action"
Thank you, and yes, I had understood that.
-
I don't like the idea with a separate swipe icon per search "type".
Poor usability (the user would have to change app settings just to do a search) and is a slippery slope in general (a new icon / command for "search by From" and then what, a new icon / command for "search by subject" and another one for "search by CC" etc.?)
Re: It appears that my guess was correct. "All:" in my stock mail app means headers only, at least for the local search (not on the server).
Checked this out on a Samsung S6.
If "all" means "all headers but now text", then how do you search by message text in Samsung's email app?
-
I don't like the idea with a separate swipe icon per search "type".
Poor usability (the user would have to change app settings just to do a search) and is a slippery slope in general (a new icon / command for "search by From" and then what, a new icon / command for "search by subject" and another one for "search by CC" etc.?)
@Kostya:
In my opinion there is only one search type necessary (... as a "swipe action"):
"Search (messages) from the same sender"
> no 'text' search needed in this particular case (= swipe action in message list): only searching within the 'from' field.
-
I am just showing how my Droid Raze M stock e-mail app shows search results with the options. The options are not visible initially, when starting the search. So, it is actually a "refinement ".
-
@Kostya:
In my opinion there is only
It's rather "Find (messages) from the same sender".
The result will be messages that have been sent by the sender of the swiped message.
Thank you Kostya ;)
String translations:
EN "From same sender"
FR "Du même expéditeur"
AR "من نفس المُرسِل"
IT "Da stesso mittente"
ES "De mismo remitente"
PT "Do mesmo remetente"
String translation:
DE "Von diesem Absender"
-
Re: search by 'From:'
Thank you for keeping this discussion alive as it mirrors a similar request/discussion that took place in a recent development build thread. Justification (use case) was offered there so I won't repeat here. Hope this feature makes it into a future release but recognize the concerns related to UI complexity.
-
I understand the use case and the idea just not sure about the UI. I also understand suggestions to add another different swipe action.
-
I understand the use case and the idea just not sure about the UI.
Okay, thanks.
I also understand suggestions to add another different swipe action.
I'm not sure, whether "we" really need another swipe action. In my opinion it's just an adjustment of the current "search" action:
> "Match on sender address" only. No 'text' search needed in this particular case (= swipe action in message list)
-
Re: Kostya, I can propose two different scenarios (with mock screens)
I can too, but there needs to be code behind those screens... :)
@Davey126
Can you clarify your needs in simple terms even I can understand:
- You're proposing "search by From address", correct?
- And for it to be available as a swipe action?
- And you'll be using it in the Sent folder? Where the From is actually your address? Seems to be a mismatch here, maybe it's just me?
-
Re: Kostya, I can propose two different scenarios (with mock screens)
I can too, but there needs to be code behind those screens... :)
@Davey126
Can you clarify your needs in simple terms even I can understand:
- You're proposing "search by From address", correct?
- And for it to be available as a swipe action?
- And you'll be using it in the Sent folder? Where the From is actually your address? Seems to be a mismatch here, maybe it's just me?
Primary use case is to uniquely identify items that I have sent for the purpose of reapplying the hidden 'sent' label in Gmail which can be inadvertently removed by non-Google mail clients including Aqua. Search would be executed from the 'all mail' folder. A 'move to sent' would then follow. Initially this would appear to move selected items from 'all mail' to 'sent' (yikes!) but the actual effect is a copy operation following a resync with the Google cloud. The effect may not be the same with other mail services.
A secondary use case is to identify all mail from a particular sender (eg: my better half).
-
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, ...
-
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.
-
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).
-
Let's see what Mr. @Davey126 thinks about it
-
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.
-
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.
-
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.
-
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"...
-
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:
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.
-
@StR that's good to know, thank you (forwarding or collection isn't something I use myself...)