Switch to partial match when searching for tags manually

[firepainting]

Overview

To search for a tag (one word), it must be completely typed in to appear in Search Results. Tags with spaces need quotes.

Steps to Reproduce

1. Create a sample entry.
2. In Tags, enter a one-word and a multiple-word tags, e.g., sample and spaces are here. Make sure these tags are not found anywhere else in the entry like Title, etc. Save the entry.
3. In the search input field at the upper right corner, type sam or samp or sampl. The sample entry will not appear until you completely type in sample.
4. Same with the multiple-word tag, but it needs quotes, i.e., "spaces are here".
5. Note: No need to do it like this: tag:sample or tag:"spaces are here" although those give the desired search results.

Expected Behavior

Search results should show the sample entry as soon as the first character(s) of the search term match those of the tag(s). Multiple-word tags should not need quotes when searching for them.

Actual Behavior

Search results do not show tags until they are completely typed in, and, for multiple-word tags, enclosed by quotes.

Context

KeePass (portable version 2.54, on mono), Standard Notes, and Firefox sync (bookmark tags), all of which are encrypted stuff and I use, do the Expected Behavior above. I use another (decrypted) note taking app and also does it.

IMO tags should be very easily searchable even when you type in just the first, say, four or five characters. I use tags a lot and I think, at least to me, their main use is for searching stuff conveniently.

As it stands, it's not really convenient and now I resort to just adding them in the Notes field like this:

Tags:
sample spaces are here

Fortunately that tagging workaround gives the Expected Behavior.

On the other hand, I love KeePassXC's placement of the Tags input field--it's immediately right there. In the original KeePass, it's not easily found: you'd have to click on the third "Properties" tab.

KeePassXC - Version 2.7.6
Revision: dd21def
Distribution: AppImage and PPA

Qt 5.15.2 for AppImage; Qt 5.15.3 for PPA
Debugging mode is disabled.

Operating system: Linux Mint 21.2
CPU architecture: x86_64
Kernel: linux 5.15.0-82-generic

Enabled extensions:
- Auto-Type
- Browser Integration
- SSH Agent
- KeeShare
- YubiKey
- Secret Service Integration

Cryptographic libraries:
- Botan 2.19.1

Operating System: Linux Mint 21.2
Desktop Env: Cinnamon
Windowing System: X11

Thank you!

[droidmonkey]

It is deliberate that tag searching is an exact match. You can very easily search one or more tags by clicking (ctrl click for multi select) in the Tags and Searches pane in the lower left. Check our our user guide for more information.

If you really want to search tags using partial match, just add an asterisk to the search term: t:tagsear*

[firepainting]

@droidmonkey Thanks.

It is deliberate that tag searching is an exact match.

Could you please expound on why that is the case? Can't seem to find it in the user guide.

You can very easily search one or more tags by clicking (ctrl click for multi select) in the Tags and Searches pane in the lower left.

My apologies I missed that.

On KeePass2 I do not use its Tags feature because I found it sort of counterintuitive so I just let it go. That is why I got excited on KeePassXC's Tags.

That said, I still hope you'll consider making tag searching more intuitive by:

• allowing for partial match (hope I'm getting the term right?) instead of exact match
• allowing for multiple-word searches without using quotes

I can appreciate limiting searches by field like Title, Username, URL, etc.

But I think tags should be "all-encompassing." Tags help to search for stuff in ways you may not want to put in other fields, except arguably for the Notes field and those in the Advanced tab (additional click). By this premise, I find it ironic for the need to include tag: when searching for them.

But the Tabs field is already at its perfect spot (when creating an entry) so I thought improvements can be made; otherwise, I wouldn't have posted this Issue. I'd be sad to not use the Tags field when it's already there.

This can change of course, but I can imagine populating my Search and Tags pane with lots of tags, creating a long list to scroll, and I might still prefer just typing in the search box. The latter may still be more intuitive.

Also, I just wanted to share my experience with the other apps I use that behave exactly the same with tag searching. Of course it's what I'm used to, but I still maintain that it's more intuitive.

Thanks for your time.

[droidmonkey]

It's exact match because tags are very specific by name. Again use an asterisk at the end to eliminate this problem. We will never not use quotes around multi-word search terms, it is impossible to give you a good search experience otherwise.

Why exact match? Well take this simple example:

You have three tags: Test, Testing, Test Rig

If we did not have exact match then tag:Test would still return all three tags even though I only want the first one.

The more common scenario is someone wants an explicit tag to be searched. The less common scenario is a partial search. So in the less common scenario we let you do that by adding one character to your search: tag:Test*

[michaelk83]

It is deliberate that tag searching is an exact match.

Could you please expound on why that is the case?

The implementation detail (that users don't care about) that makes this required, is that tags are implemented as saved searches in KeePassXC. As droidmonkey explained, if you have the tags "Test" and "Testing", and you click on the "Test" tag, we want to show only "Test", and not "Testing".

But I agree that it'd be much more convenient if typed search would show results as you type, including tags, and that means partial matching.

@droidmonkey How about adding a search modifier to force an exact match? Then saved tags could use that modifier, while typed search could default to incremental search with partial matches.

I find it ironic for the need to include tag: when searching for them.

There is #7967 to search by all text by default. That would remove the need to add the tag: prefix. As a side-effect, it may also enable searching by multiple words without quotes, depending on how multiple search terms are combined by default.

edit: We could also define that the tag: prefix does an exact match (as now), but the #7967 behavior (without tag: prefix) is partial match. But I think that'd be more confusing than having saved tags use a generic "exact match" modifier.

I can imagine populating my Search and Tags pane with lots of tags, creating a long list to scroll, and I might still prefer just typing in the search box. The latter may still be more intuitive.

Agreed.

[firepainting]

The more common scenario is someone wants an explicit tag to be searched. The less common scenario is a partial search.

Gotcha. Thanks for bringing that up. I admit I find that hard to believe, though. I thought partial match was more common and more sensible.

If we did not have exact match then tag:Test would still return all three tags even though I only want the first one.

I would appreciate it if they all appeared when I typed in Test first. Because if I wanted Testing or Test Rig I would type those instead.

I'd rather have a shrinking but a complete list of search results as I "ramble" in the Search field to zero in on what I'm really looking for, than totally miss it because it's not in the search results in the first place. I think that's good search experience!

Also, to me, it would be better to just have the option to use quotes if and only if the user is after an explicit tag. I think that falls under "power user." An average user wouldn't think of quotes, they'd just type away, as I did.

Same goes for whether it's Title, Username, URL, or whatnot. If I type in for example gmail I would like it to show all entries that have a trail of gmail in all fields. If I wanted to search only in URLs then I'd do URL:gmail. "Power user."

Note that these tags can be months or years old before a user tries to retrieve them from their brain so it would be better to err to the side of the user finding it tricky to remember them.

Here's a possible use case:

I could create an entry for BANK CARD NAME. And then a year later I get ANOTHER BANK CARD NAME and they are associated with each other for whatever reason. I would then create a tag in each entry: ANOTHER BANK CARD NAME in the first entry, and then BANK CARD NAME in the second.

Of course there's the Tags pane already, but as I think about it more, I'd still suggest those improvements to you :)

I can learn KeePassXC's nuances of course, but it wouldn't hurt if it had the universal tag-searching behavior that other apps seem to have. I admit I'm not a fan of doing tag:"ANOTHER BANK*" when I could just type in ANOTHER BANK

FWIW, I have 450 entries in my database, after several years with KeePass2.

But maybe you're right, maybe doing partial match is the minority. I got no choice, then :))

Anyway, thank you, as always!

[michaelk83]

@firepainting Similar arguments have been raised before for other fields (and I agree). That's why #7967 exists.

How about adding a search modifier to force an exact match? Then saved tags could use that modifier, while typed search could default to incremental search with partial matches.

A closer look at the user guide reveals that in fact there is already such a modifier:

+ Match this term exactly

So saved tags should be defined as something like +tag:"name of tag", and regular search without the + modifier, even with tag:, should default to partial match. So for example "tag:Test" would match all tags that have (or start with?) "Test" in their name.

[droidmonkey]

The decision I made was to not have to add the + for the more common scenario of wanting an exact match for tags. I am all for adding tags to the "default searched fields" which will allow partial match by default.

I appreciate this dialog but there is a lot of arguing around decisions we have made that we think benefit our programs UX. Tags have been implemented as a "dynamic group" feature and were NOT implemented as "yet another thing to search against" feature.

[firepainting]

@michaelk83

The implementation detail (that users don't care about) that makes this required, is that tags are implemented as saved searches in KeePassXC.

I think this is the part where I disagree. Tags should not be made exact matches/saved searches, IMO. It makes searching harder when tags should make it easier.

I suggest the philosophy becomes: assume an average user first, so the "techie"/modifier/advanced stuff should only come as optional, not the default. I consider myself average.

In that vein, using modifiers and tag: etc. shouldn't be the default. Typing in anything and showing complete search results must be the norm. I wish for the "advanced" stuff to be only optional.

I think I already saw #7967 but I think using all: is redundant--this is the default I wish for. When you type in something, all that contain something anywhere (I'd go further to say even groups) should appear. There should be no need to use all:

Because if you want to narrow your search down then t: user: url: or whatnot are available at your disposal. And if you're an "advanced" user then that's no problem. But for those average users who can't be bothered to explore such black magic, they might lose interest or something.

All in all I consider KeePassXC intuitive to use, but its tag-searching kinda veers off from that feel.

[michaelk83]

the more common scenario of wanting an exact match for tags.

The question is whether that assumption is correct. I think there should be a distinction here between clicking on a tag in the sidebar vs searching tags from the searchbox. When selecting tags from the sidebar, I agree that the common scenario is (probably) expecting only the selected tag(s) to be displayed (exact match). But when searching for tags from the searchbox, especially if you have many tags, it may be more common to want all matching tags to be shown. The tag: prefix restricts the search to only tags, but if other prefixes don't default to an exact match, then the tag: prefix shouldn't either. That's what the + is there for.

Creating new tags is usually done from the tags field, where the + can be added automatically. If you save a tag:... search from the search box, then it's just a saved search, not an actual tag, and should behave however the search behaves.

Tags have been implemented as a "dynamic group" feature and were NOT implemented as "yet another thing to search against"

Searching against a large number of tags is a valid use case, regardless.

decisions we have made that we think benefit our programs UX

Consistency and simplicity of the default behavior lead to better UX.

[firepainting]

Chiming in but I wanna preface this that again I'm just an average user and I don't code.

The question is whether that assumption is correct.

This prompted me to Google something like "Do average users prefer partial match or exact match" and I found a good answer, I think: https://ux.stackexchange.com/a/1667

Google has solved this long ago - no use reinventing the wheel. ;)

I'd suggest you remove the need to choose, and do three searches at the same time: "exact phrase", "match all words", AND "match any". Then unite (SQL "union") those results in that order, and present them to the user.

Drawbacks:
more load on your database.

Positives:
more natural for the user: if someone enters several words, most probably they know what they are looking for; they're not shooting in the dark trying to get at least one word right
matches experience on search engines
saves one click in the interaction=saves time.
...
Also make sure the search works with keyboard only (i.e. without forcing user to use the mouse. search phrase + Enter should be enough to get results).

There's another I saw that agreed to the sentiment, and if, as an experienced user, he wanted to search by exact match, he can do so. But the default should be partial match.

When selecting tags from the sidebar, I agree that the common scenario is (probably) expecting only the selected tag(s) to be displayed (exact match). But when searching for tags from the searchbox, especially if you have many tags, it may be more common to want all matching tags to be shown.

I realized I was after a different solution than the one being offered, which is to use the Tags pane, which I'm sure is useful but not so much for me, which is okay. (I edited this Issue's title for that!)

Tags have been implemented as a "dynamic group" feature and were NOT implemented as "yet another thing to search against" feature.

As a layman, the way Tags work as they do now, to me, don't make them tags anymore, as they should be. I think they should be called something else.

but there is a lot of arguing around decisions we have made that we think benefit our programs UX.

Seriously I appreciate your work, thank you so much. Ultimately you have the final say on your product. I only hope these comments objectively help in making KeePassXC better. In the end it's a win-win-win if KeePassXC reaches more and more people because it's become very intuitive and all that good stuff.

[droidmonkey]

I am considering the change to use partial match in the search bar and using the + syntax in the tag view.