(Archived) No partial matches in Evernote iOS 7.0.2 search

[anjoschu 67]

Evernote for iPhone (7.0.2) doesn't seem to match from the beginning of words any more. You have to search for the complete word in order to get a hit. For example, a search for "elephant" returns notes containing "elephant", but not notes containing "elephants".

 

I also tested with Evernote for iPad 5.4.0, where a search for "elephant" returns hits for both "elephant" and "elephants".

 

For what it's worth, you can still search for "elephant*" (with an asterisk at the end), which returns all results, but makes for some very awkward typing on iOS. And I imagine that searching for partial words from the beginning is not an uncommon use case (and not constrained to varying inflections, there are many languages with richer morphology and longish words where you just want to search for the beginning of the word).

 

Can anyone duplicate this on their Evernote iOS 7.x installation? So that I know whether it makes sense for me to go through the day-long delete/reinstall/resync procedure. Thanks!

[jefito 5,589]

They may have removed this behavior because it conflicts with the actual search grammar (where you need to explicitly specify the wildcard '*'), but I've never minded that behavior myself.

[GrumpyMonkey 4,319]

It's an interesting conundrum. Some clients add the wildcard and some don't, so searches (saved and otherwise) take some getting used to. Currently, a regular search apparently does not use the wildcard, but a search within the note will use it. In other words, there are two search behaviors, but both look the same in the search field. At the very least, we ought to be shown what the search is actually searching (Android does this).

Personally, though, I think it would be much better if every client just left the wildcard off of the searches instead of trying to assume we want to search with it. If I want it, I will type it myself.

[anjoschu 67]

First of all, thanks for your answers so far. I kind of see your standpoint of keeping search "clean", I'm not here to complain. :-) However -- it's kind of puzzling to find that I seem to be the only one seeing this as an inconvenience or problem.

 

I'm just wondering whether a non-power user would accept the fact that "well, if you also want to find elephants (with an s), you need to say so explicitly!" To me this seems to be the exact opposite direction of where other search engines are going.

 

For me, in about 9 out of 10 searches, I also want to find "photos" when I search for "photo". If I am serious about only searching for exact matches on "photo", I can still put the word in quotes.

 

Adding an asterisk on the desktop client is not that cumbersome, but on iOS, it means a lot of extra taps (with summoning the secondary special character keyboard and all).

 

Am I really the only one who has trouble with this change in functionality?

 

P.S.: I am referring to searches across notes, not within notes (I am using the former around 50 times more often than the latter on iOS).

[GrumpyMonkey 4,319]

First of all, thanks for your answers so far. I kind of see your standpoint of keeping search "clean", I'm not here to complain. :-) However -- it's kind of puzzling to find that I seem to be the only one seeing this as an inconvenience or problem.

 

I'm just wondering whether a non-power user would accept the fact that "well, if you also want to find elephants (with an s), you need to say so explicitly!" To me this seems to be the exact opposite direction of where other search engines are going.

 

For me, in about 9 out of 10 searches, I also want to find "photos" when I search for "photo". If I am serious about only searching for exact matches on "photo", I can still put the word in quotes.

 

Adding an asterisk on the desktop client is not that cumbersome, but on iOS, it means a lot of extra taps (with summoning the secondary special character keyboard and all).

 

Am I really the only one who has trouble with this change in functionality?

 

P.S.: I am referring to searches across notes, not within notes (I am using the former around 50 times more often than the latter on iOS).

It's a matter of preference. It's neither right nor wrong, but it does need to be more consistent and obvious. Hiding the search and having different behaviors, even within the same client, is not a great idea in my opinion. Control over the search would be appreciated no matter what developers decide: If the wildcard is going to be inserted whether we type it or not, show us, and allow us to edit the search as we wish.

[BurgersNFries 2,407]

I'm just wondering whether a non-power user would accept the fact that "well, if you also want to find elephants (with an s), you need to say so explicitly!" To me this seems to be the exact opposite direction of where other search engines are going.

I think users, regardless if they are power or not, would have no issue with specifying the wild card of elephant* (or using two search words - elephant & elephants) if you want plurals.  That's pretty consistent IME.  I may only want to find notes with print or prints, but not all the false positives of printed, printer, printing, etc.  So my preference is for the app to not use a wild card unless I enter it.  But I agree with GM that it should be consistent across all the EN apps.  As for me, I am in the habit of using the wild card if I want the wild card specified.  That way I don't have to remember which clients automatically add it & which ones don't, including third party apps like Clever. 

[anjoschu 67]

Thanks everyone for your opinions so far. I'm surprised that the majority of senior users has a different view on this, so I guess it may be a question of preference after all. I hope some not-so-senior users will state their take on this here as well. ;-)

 

As I said, I don't mind this too much on the desktop client where the asterisk is just a shift-keypress away (but at least on the Mac, partial matching is enabled, go figure).

 

What I want to stress, however, is that we are talking about iOS (mobile), where entering an asterisk requires 3-4 additional taps for each word that needs to be partially matched (switchtospecialkeyboard1-switchtopecialkeyboard2-*-switchtonormalkeyboard). That just about doubles the time I need to enter such a search, and I want iOS searches to happen quickly (it's a mobile OS after all, and I'm usually in a situation where I need the information right there and then, e.g. in a meeting).

 

As said before, I still do understand the consistency argument (Personally, I find that speed should trump consistency in a mobile environment, but if it absolutely has to be consistent, so be it).

 

Maybe EN for iOS should just offer "searchterm*" as the first suggestion when entering the string "searchterm"? That way, one could just tap on it (which is quick), and the syntax used would be explicit (consistency). What do you think?

[BurgersNFries 2,407]

What I want to stress, however, is that we are talking about iOS (mobile), where entering an asterisk requires 3-4 additional taps for each word that needs to be partially matched (switchtospecialkeyboard1-switchtopecialkeyboard2-*-switchtonormalkeyboard). That just about doubles the time I need to enter such a search, and I want iOS searches to happen quickly (it's a mobile OS after all, and I'm usually in a situation where I need the information right there and then, e.g. in a meeting).

Yes, but in the 'print' example I posed above, this could also be a detriment, if you need to filter through all the false positives.  So...as my father used to say, six of one, half a dozen of the other.  Which is why, IMO, it's best to not use wild cards as a default & only use them when specified.  And as I mentioned above, if you want plurals, you can either use the wild card (which can generate false postiives) or enter two words: elephant & elephants. 

[GrumpyMonkey 4,319]

Thanks everyone for your opinions so far. I'm surprised that the majority of senior users has a different view on this, so I guess it may be a question of preference after all. I hope some not-so-senior users will state their take on this here as well. ;-)

 

As I said, I don't mind this too much on the desktop client where the asterisk is just a shift-keypress away (but at least on the Mac, partial matching is enabled, go figure).

 

What I want to stress, however, is that we are talking about iOS (mobile), where entering an asterisk requires 3-4 additional taps for each word that needs to be partially matched (switchtospecialkeyboard1-switchtopecialkeyboard2-*-switchtonormalkeyboard). That just about doubles the time I need to enter such a search, and I want iOS searches to happen quickly (it's a mobile OS after all, and I'm usually in a situation where I need the information right there and then, e.g. in a meeting).

 

As said before, I still do understand the consistency argument (Personally, I find that speed should trump consistency in a mobile environment, but if it absolutely has to be consistent, so be it).

 

Maybe EN for iOS should just offer "searchterm*" as the first suggestion when entering the string "searchterm"? That way, one could just tap on it (which is quick), and the syntax used would be explicit (consistency). What do you think?

Your fast is my slow!

I almost never want a wildcard. Nowadays I have to supply quotation marks around terms for every search. This is quite annoying, and the behavior changes without any indication in the app from update to update, so it is a constant headache to stay on top of everything. Don't even get me started on Asian character sets, which have caused me no end of trouble in the past (quotation marks are necessary for everything, and mixing English with Asian character sets used to be highly unpredictable). I cannot tell you how many times I have had to redo all of my saved searches over this stuff, and this was pretty tough when they removed the ability to edit saved searches on the Mac for a while. Unfortunately, consistency is not (yet) Evernote's strong suit. It could be, though! All they have to do is follow the rules they first put in place way back in 2008

Frankly speaking, I don't want them to make any special adjustments to any of the clients. Just make it work the same across every client and I will be satisfied. I can tolerate typing an asterisk on mobile if it means no more broken searches for me.

[jefito 5,589]

I actually like the Windows behavior, as it's kind of what Google does. In other words, search for "Everno" in Google and you will fine sites related to Evernote (but also a little blurb that asks you whether you were really intending to search for "Evernote"). If I want explicit search, I can always enclose it in quotes.

Of course, I can do the opposite, too.

[GrumpyMonkey 4,319]

I actually like the Windows behavior, as it's kind of what Google does. In other words, search for "Everno" in Google and you will fine sites related to Evernote (but also a little blurb that asks you whether you were really intending to search for "Evernote"). If I want explicit search, I can always enclose it in quotes.

Of course, I can do the opposite, too.

Quotes are always available, of course, but if the argument is that the wildcard makes things faster, then for someone like me, who wants to do precise searches, it turns out to be slower.

If Evernote wants to suggest something (unlikely to happen on iOS) I don't mind. I just won't click it. It's when my search is changed, especially when it is done without my knowledge, and it is done in ways that I cannot predict (I have to test searches every update) that I find it frustrating.

As for Google, I have to use quotation marks there as well, and I would prefer if it did not do fuzzy searches. I don't like it much, but I can live with it, because the search is at least consistent every time. Well, kind of. To be honest, Google has gotten a lot more clumsy recently, and changes on the backend have made searching a lot more difficult. Searches that used to produce one kind of result produce another, and pages that used to appear, no longer do. I am sure that overall it is better (that's what Google tells me, anyhow), but in my experience, the changes aren't working in my favor.

[jefito 5,589]

Quotes are always available, of course, but if the argument is that the wildcard makes things faster, then for someone like me, who wants to do precise searches, it turns out to be slower.

Yes, I understand the dynamic very well. It's probably a 50-50 proposition, and so (sans a preference option), 50% of the users lose. Actually, it's probably more like 25% want it one way, 25% want it the other way, and 50% don't care. But I think you can see what I mean...

[GrumpyMonkey 4,319]

Quotes are always available, of course, but if the argument is that the wildcard makes things faster, then for someone like me, who wants to do precise searches, it turns out to be slower.

Yes, I understand the dynamic very well. It's probably a 50-50 proposition, and so (sans a preference option), 50% of the users lose. Actually, it's probably more like 25% want it one way, 25% want it the other way, and 50% don't care. But I think you can see what I mean...

I obviously have a strong preference one way, but in the end I am more interested in consistency. Plant the flag, tell me where it is, and I'll get myself over there even if I don't agree with it. We can afford to have some people unhappy with the decisions, and it is probably something we ought to expect every time a decision is made.

However, move the flag around on different days for different clients, or worse still, hide it so that we have to guess where it is, and I think close to 100% of the users walk away unsatisfied because they don't understand what is happening. For example, how many users know that the iOS client has two kinds of search behavior depending on where you search? I am guessing it is just the three of us here in this thread. That kind of inconsistency is no good for the app.

[anjoschu 67]

I upgraded to 7.1.2 and search functionality has been restored to it's previous glory (or disgrace, depending on your viewpoint). I for one am happy. :-)