Hello!
Can anyone shed light on why the following are the results of the shown search queries?
I would either search query expect to only show one of the results. If the both showed both, I wouldn’t be happy, but at least not confused :-D
Thanks!
Hi @sandrok! Sorry about the confusion here.
When searching, OmniFocus matches each search term individually. This means rather than looking for the complete phrase “prepare a,” with its space, OmniFocus checks for “prepare,” then checks separately for “a.” Since the task “prepare b” has an “a” in it – right in the middle of the word “prepare” – it’ll match the search string “prepare a.”
This might be a little clearer if you search for something like “prepare prepare.” Obviously, no task here has the word “prepare” twice in a row, but since OmniFocus matches each word individually, both “prepare” tasks will still pop up in search results.
Hope that clarifies things a bit!
1 Like
Hello!
Yes, that clarifies it a bit. Even though it’s quite uncommon behavior I would say. An “any word” search isn’t, but “a” is not exactly a word there…
Either way, how would you explain the following?
Does OF decide to ignore the FBA in the search because “prepare” and “shipment” already match? Because I can’t find an FBA in “Prepare Retoure Shipment” :-) Or does that match because the title of the project contains FBA?
Thanks!
Yes, that’ll match because of the string “FBA” in the project title. When considering search results, OmniFocus checks not only the task name, but also the containing project and context names (if set), and the contents of the task’s note.
Okay, got it.
I have to add though, that this behavior will probably require the user to do some naming Yoga at best and the search useless at worst.
Any plans for extending any of that?
Or other tipps for my situation?
Thanks!
I definitely understand where you’re coming from. Our intent was for search to be relatively inclusive so that people could easily scan down a list of results and pick out the item(s) they were looking for. It’s also easier to make a search more specific to continue narrowing results, but a little harder to find out why a specific search didn’t hit the result someone expected, or how to broaden the search to make it “work.”
I know some folks have had luck with putting specific key phrases or even special characters in the names of projects and tasks for the express purpose of searching for them later. For example, if you need to distinguish between FBA and Retoure in the example above, prefix both of them with a pound sign: #FBA and #Retoure. Then, when searching, you could look for “prepare #fba shipment” and have it match #FBA but not FBA. (Variants of this are also possible: [FBA], !FBA, etc.)
We’re also very open to suggestions and comments about how OmniFocus can better suit individual workflows. If you have recommendations to how we can improve search to meet your needs better, please don’t hesitate to send in an email – we track all that feedback carefully, and use it to inform future changes in OmniFocus.
Thanks for the discussion, and for using OmniFocus!
I have indeed used that workaround (prefixing with #) in a different situation, but it still feels like a hack and I certainly don’t feel like paying attention to this when setting up my projects…
I’ll send a mail as you suggested and will replicate it for completeness right here:
"Hello!
Based on <> I’d like to suggest/request an extension of the search functionality.
My Problem was, that the search that I set up yielded too many results, because the search net was cast to widely.
I therefore suggest to leave the “or”-search as it is (any word found in the search field will be a match), but to allow for more specific searches as well, like
forcing a phrase match as found in Google Search -> ‘abc xyz’
maybe extending that with a wildcard search -> ‘ab* xyz’ or ab? xyz’
and adding field specifiers -> title:‘abc xyz’ (inspired by Evernote search)
I think this syntax is easy enough to understand to be useful for a wide range of users and would greatly enhance the searching abilities (or perspective specification abilities for that matter).
Thank you! :-)
Sandro"
