Overhauling Dolphin's search

There are both technical and design aspects to this, but I will first talk about UI/UX.

Current search UI:

We already had a fairly long chat room-talk about designing a better UI/UX for Dolphin's search a few weeks ago. I will copy the relevant section in the collapsible section right below and then try to summarise the broad issues:

Chat room discussion about improving Dolphin's search interface

Felix Ernst

kbroulik
maybe it’s best to rethink the Dolphin search interface altogethre. I still use KFind because the Dolphin one is way too limited

I don't even like the UX for the limited case. Buttons like "file name" and "content", "from here" or "your files" are not perfectly clear about what they do because one has to mentally add "search for search term in". It also doesn't make sense that we let users decide between searching for content or file name when file content indexing is disabled. I also dislike that the rest of the options are then exposed as drop-down menus instead even though they serve a similar filtering purpose as the buttons above. From the drop-down options I dislike that we show "rating" and "tags" even if a user doesn't use either. The search for date seems superfluous as well since we have a better UX for this now: "recentlyused:"

So yeah, completely rethinking the search interface makes sense to me.

kbroulik

It also doesn't make sense that we let users decide between searching for content or file name when file content indexing is disabled.

well, if indexing is disabled it searches through the file contents "dumbly" :) perhaps we should approach the VDG about a new better search UI ;)

isma

I've always thought about a "chip"-like approach, where search items (dates,tags,etc) gets added as chips that can be deleted

kbroulik

things I mostly miss and thus use KFind for (ignoring the fact how useful they are or whether we should put them in this UI):

search file name with content (you only enter a single search term which is either in content or file name)
size (at least nn mb or something)

Windows also has the ability to search through ZIP files, that would be cool to have, maybe

Felix Ernst: do you know the previosu search UI we had? That was a usability nightmare but it was quite flexible :D

http://2.bp.blogspot.com/_zDPqioLuxns/TEsBz1u1CFI/AAAAAAAAAL4/_X4IjuEdkRU/s700/search3.png search3.png

you could add arbitrary conditions

Felix Ernst

I had never seen it. ^^ I actually had to implement such a "programmer-focused" UI at uni once and didn't like that approach at all. ^^

kbroulik

http://ppenz.blogspot.com/ reading through old blogs by the original Dolphin author are quite enlighting on the evolution of those things

I had a look at windows search UI but the one in Windows 11 is a lot dumbed down compared to Windows 10. Wonder if I just overlooked something or they got rid of all the options again

Felix Ernst

Definitely doesn't seem easy to decide on an interface that is both simple by default and powerful when needed.

kbroulik

yeah

Felix Ernst

kbroulik

things I mostly miss and thus use KFind for (ignoring the fact how useful they are or whether we should put them in this UI):

    search file name with content (you only enter a single search term which is either in content or file name)
    size (at least nn mb or something)

I feel like we could get away with not having an "only search contents" option. Like we would have a "search only file name" and "search file name + content". size could be surfaced the same way the other filter options are.

kbroulik

I mean for "simple by default, poewrful when needed" for example we could do

Type: a few presets (documents, images, videos) like we have and then an "other…" which lets you pick or add a list of mime types to find
Date: a few presets (in the last hour, today, yesterday, this week, etc) and then again an "other…" which lets yo pick a before/after/between [date picker]

hmm, a "content only" search is something I do a lot through krunner. I just search for a word I know is in the document, irregardless of its name so while I tend to agree with a Include: [x] contents [x] hidden files [x] archive contents or something, I still think a "content-only" search does make sense it's just hard to make a good UX for that I guess same for Size: "empty/very small (< 4kb)" "small", "medium", "large", "very large", "other…" and there again you get a picker "smaller than/larger than/between" or so also Windows lets you do a search for either: "This computer", "This folder only", "This folder and its subfolders", which I quite like, though for "this folder only" we have the filter box mostly I guess I also really dislike the "From here" / "Your files" thing in Dolphin oh, and windows also has a "search again in…" in that list, so you can have a history of folders you searched

Felix Ernst

kbroulik
also Windows lets you do a search for either: "This computer", "This folder only", "This folder and its subfolders", which I quite like, though for "this folder only" we have the filter box mostly I guess

And we get bug reports because of this: https://bugs.kde.org/show_bug.cgi?id=469240

kbroulik :D fair enough heh, seems macos actually still has that "+" view I showed above to add criteria

Felix Ernst

I think the band-aid solution for the bug report is still having the search "only here" button in the search interface that then opens the filter bar. ^^ That's somewhat terrible UX long-term but even then makes more sense to me short-term than what we do now with cleanly splitting those two.

kbroulik

can we add ChatGPT ;)

Felix Ernst

Hmm, we hide the the dropdown bar with "types" etc. when indexing is disabled for the current folder which doesn't make sense when the home folder is searched instead.

kbroulik

yeah the whole "we change the UI" doesnt make sense. this is an entirely implementation detail

and the filename search could also search by mime type...

tough to get that in sync, though, I dont think the mime types baloo considres documents is really "public" or "static". it’s determined by the filemetadata extractors...

Felix Ernst

I made a mockup

isma

kbroulik
yeah the whole "we change the UI" doesnt make sense. this is an entirely implementation detail

the problem there is offering many filters that doesn't apply to filenamesearch, would probably make sense if extended (if only for the dates)

kbroulik

What "many filters" are there though? Rating and tags

And even those we could in theory read from xattr as we went along

I'm more concerned about the Metadata semantics. Filenamesearch does a pure content contains(...) check whereas Baloo / file Metadata "understands" the formats

isma

well, it's one out of four (mimetypes), and non-fully synchronized 😃

kbroulik

Felix Ernst
DolphinSearchBox.png

Hmm not really a fan of a "+" UI

I like showing all the (not that many tbh) filters at all tikes

But I see the appeal of a simple "just gimme everything by name" search which the "+" will present

Felix Ernst

kbroulik
I like showing all the (not that many tbh) filters at all tikes

It gets a lot more busy if we show all available filters. We would IMHO at least need to visually de-emphasise all the filters that aren't currently filtering anything ("any files", "any time", "any rating", "any file size", "any tags"). Like they would float there as semi-transparent ghost filters until they are used to actually filter items.

Not sure if that would still be a bit too busy when most users probably don't use filters all that extensively.

kbroulik

Windows Explorer in Window's 10 has the advantage of already having a massive Ribbon bar. Adding a Tonne of combo boxes in there doesn't make it worse :D

Felix Ernst

Hard to make things seem cluttered when one has already lost overview. ^^

kbroulik

But I don't want to hide the filters behind a "show filters" toggle either.. Unless we make it remember that so it's just always automatically shown in my cade

If we were to add a "+" I'd expect much more filters, like search by author and what not..

Maybe we should have that :D But that wouldn't really work without Baloo

Felix Ernst

kbroulik
But I don't want to hide the filters behind a "show filters" toggle either.. Unless we make it remember that so it's just always automatically shown in my case

That could work.

kbroulik

Perhaps its back to the "facets" search again. Have a "name" facet and a "content" facet and all the others filters Easy to make it super complicated :/

Felix Ernst

kbroulik
But that wouldn't really work without Baloo

I guess this is the most complicated part of all of this. This is sort of a UI that is supposed to be the interface for Baloo (with different configs), a dumber direct search, and also (in a perfect world) the Dolphin filter functionality for the current folder.

kbroulik
Perhaps its back to the "facets" search again. Have a "name" facet and a "content" facet and all the others filters

I am not sure such a completely general approach makes sense for Dolphin. I am honestly not sure we should/can completely replace tools like KFind (unless we have an explicit optional "advanced" UI at which point we might as well defer that functionality to KFind et. al.)

But maybe I am wrong in trying to design more for the computer-illiterate user and thereby ignoring the more advanced workflow too much.

kbroulik

Yeah, maybe we should revisit and focus on the strengths. Old farts like me can still use KFind. But right now it sucks that it “randomly” doesn’t find files because they’re not indexed

Definitely something we should involve a designer ;)

So the basic design issues is that we have one search interface that tries to strike a middle ground between being small, easy to use but still provide some advanced functionality. However it is neither that simple to use currently, some of the buttons don't seem useful for a majority, and it is still lacking much functionality which a dedicated search application like KFind provides.

Technical limitations and quirks in the background are the cause of some of these issues, but it might make sense to first have a clear goal/UI in mind before working on those.