Version 1.6.2-dev3.2 - "work in progress"

[Davey126]

re: could this be done without turning the UI into some sort of monster?

Thoughts:
- post #26 offers one potential implementation that avoids messy input validation as it leverages swipes; just need to add a couple more choices to the dropdown (currently offers 10 options + none). Translations may be the biggest headache.

- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:

[IMAP.2270]  I  Sending: kman35 SEARCH CHARSET US-ASCII OR FROM {25+}
                         I  Sending search literal
                         I  Sending: (OR TO {25+}
                         I  Sending search literal
                         I  Sending: (OR CC {25+}
                         I  Sending search literal
                         I  Sending: (OR BCC {25+}
                         I  Sending search literal
                         I  Sending: SUBJECT {25+}
                         I  Sending search literal
                         I  Sending: )))

A simple FAQ (possibly toast) could guide users to valid keywords and allowed syntax. In this scenario the UI remains largely untouched unless searching by header. A more advance presentation would allow picking keywords from a list. While convenient I think this adds unnecessary UI complexity for a feature arguably targeted at more advanced users. As a point of reference the browser Gmail client take this approach for more advanced searches (https://support.google.com/mail/answer/7190?hl=en). Seems like a reasonable compromise and avoids building a complex search dialog.

Well - those are my silly ideas. Can't wait to see what you and others come up with! And yes, I do realize in the end nothing may change if the perceived benefits don't outweigh the added complexity.

[Kostya Vasilyev]

Yes, #26 is the proposal to add a third kind of search.

[mikeone]

Kostya,
I just have noticed that the Undo feature will not appear when using "Delete all".
-> You know, the option if the user long press on "Deleted" or "Spam" folder.

I think the Undo feature would be very useful especially for this case.

[Kostya Vasilyev]

Yes, correct, no Undo for Delete all. But there should be a confirmation (unless turned off).

[mikeone]

Yes, correct, no Undo for Delete all. But there should be a confirmation (unless turned off).

Yes, there appears a confirmation window if activated in settings (I assume that this option is / should be activated by default)

[Kostya Vasilyev]

Yes, confirmation are enabled by default.

( it just has to do with Delete All dealing with too many messages, potentially some never seen by the app at all )

[mikeone]

Yes, confirmation are enabled by default.

( it just has to do with Delete All dealing with too many messages, potentially some never seen by the app at all )

Okay, I understand. Thanks for your additional explanation.

[StR]

- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:

I don't have a strong opinion, but let me offer my thoughts, why that might not be a good idea.
1. While it could be a powerful way, it seems like a somewhat "bulky" for a mobile UI, where the paradigm is to minimize typing, especially where it must be so precise. And if it is not precise - that's a cause for frustration.
2. IIRC, in SMTP and IMAP specifications "From", "To", etc. are case insensitive.
So, here you create the case where it is different (at least for that small portion of Aquamail users who are familiar with those specs). Besides, with otherwise case-insensitive search, it could also be rather confusing.

For super-geeks: 
3. If one were to choose the specialized search language, - one can base it on e.g. Ovid search syntax (used for 20+ years in bibliographic engines):
http://resourcecenter.ovid.com/site/help/documentation/ospa/en/syntax.htm

 So, it would be something like
   Davey126.from.    (in From:)
   Davey126.to.cc.    ( in To: or Cc:)
   Davey126.from. or kmansoft.to.  (From Davey126 or To kmansoft)

(Ducking out before it's too late.) 

[Davey126]

- another option: allow a single uppercase keyword followed by delimiter (eg: 'FROM:') to be entered as the first term the header search box. If Aqua detects a valid keyword has been entered (SUBJECT, FROM, TO, CC, BCC, etc) it could adjust/narrow the command string sent to the server:

I don't have a strong opinion, but let me offer my thoughts, why that might not be a good idea.
1. While it could be a powerful way, it seems like a somewhat "bulky" for a mobile UI, where the paradigm is to minimize typing, especially where it must be so precise. And if it is not precise - that's a cause for frustration.
2. IIRC, in SMTP and IMAP specifications "From", "To", etc. are case insensitive.
So, here you create the case where it is different (at least for that small portion of Aquamail users who are familiar with those specs). Besides, with otherwise case-insensitive search, it could also be rather confusing.

All valid points IMO. I suggested case sensitivity to help distinguish keywords from the search argument but that could easily accomplished positionally where only the first word entered was considered as a potential search modifier. I don't think there is a need offer multiple keyword support (eg: this OR that) in the first iteration - or ever for that matter! As for typing most of the keywords are short (2-5 characters) and the longer search argument can be inserted via paste. Not ideal - but perhaps a reasonable compromise.

[Davey126]

Q: Are the changes in 1.6.1.5-17 baked into 1.6.2-dev3.2? I'm (of course!) curious what's in the former but can wait for GA if relatively minor.

[Kostya Vasilyev]

Re: changes in 1.6.1.5-17 baked into 1.6.2-dev3.2

Not yet.

Will be in 1.6.2-dev4, which I'm planning to post here (and as first Google Play "beta" for the 1.6.2 branch) later tonight. It's only 11pm

The most recent fix there is for a specific issue with Push mail + using it on Deleted folder.

[Davey126]

Hi - there was an active discussion in the latter half of this thread regarding modification/extension of the embedded search function. Curious if that idea still has legs and if so, whether some portions might make the 1.6.2 development tree.

[Kostya Vasilyev]

Won't happen in 1.6.2, I've still got a long to-do for this cycle.

I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?

[Davey126]

Won't happen in 1.6.2, I've still got a long to-do for this cycle.

I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?

Thanks. Must have overlooked the suggestion (sorry). I'll look back and give it a whirl.

[Davey126]

re: I proposed a possible solution for your specific use case (and maybe other users'), but seems like you were not very interested?

OK - I'm stumped. Looked back through the thread but could not find a specific workaround. Maybe my 'personal bias' filter is obscuring the obvious ...