Saturday, November 14, 2009

Searching

If I compare the number of files on my current hard disk with the number of files I had 10 years ago, I'm quite amazed. How to deal with this increased number of files is topic of a lot discussions. Tagging, searching, filtering, relations, virtual folders... - terms, where from a KDE-developer's point of view Nepomuk comes to mind, which provides already all the technical base. Still there is the task to integrate Nepomuk into applications, so that users out there are able to benefit from this great technology.

It's a small step only, but at least one step further: During the last week I've integrated Addam Kidder's GSoC 2009 work into Dolphin. I know that some people don't see searching and filtering as "the solution" to deal with the increased number of files and I agree. Nepomuk offers a lot more, still the searching and filtering is a basic feature, that I personally require quite often during my workflow. The current state of the code is far from finished, still the basics are there now. As soon as the search-bar at the top gets focused, the search configurations pop up below as shown here:


Searching for files having the tag "Tree" is very simple. Selecting "Equal to" and the corresponding tag in the combo-boxes beside "Tag:" has the following result:


One goal of the interface was to minimize the number of clicks that are required to specify a search query. That's the reason why per default at least three (hopefully) commonly used search criterions are visible. For sure it is possible to create very complex queries with more criterions too:


Still I think users will use such complex search queries quite rarely. I had some discussions with Sebastian TrĂ¼g and Alessandro Sivieri regarding the faceted panel, that exists as prototype currently. The discussion convinced me that a common workflow for users might be:
  • Fill the search-bar with some keywords and trigger the searching.
  • Only if the number of returned files is too high, start a filtering step by step on those files.

This might sound obvious, but has implications on the user interface:
  1. The number of clicks to activate a filter must be minimized.
  2. It should still be powerful: The kind of filters should not be limited.
  3. Doing filtering step by step means that the user interface may not get hidden after triggering the first filter.
Especially the combination of point 1 and 2 have requires doing some compromises. Limiting the number of clicks requires more screen space. As there is only a limited screen space, the number of shown filters must be decreased. Finding a balanced solution is quite tricky.

I'm also unsure which data the breadcrumb should show: Visualizing a string like "nepomuksearch:/+lastModified<2009-11-13 +rating<8 +tag:Peter" to the user is something where I doubt Apple would do. Any suggestions would be welcome.

That's also one purpose to write this blog entry: Please let me know your daily problems when trying to search and filter files from your hard disk. I hope that I can integrate your input until KDE 4.4... Thanks!

18 comments:

Pascal d'Hermilly said...

Being able to search for a filename or the contents of a file would be a great start.

I've still to try a dist where it works out of the box.

Dion Moult said...

Really Pascal? Works and has worked for me for a long while :) I hope your strigi indexing and nepomuk is turned on.

Exciting development here indeed! I can't wait to try it out. I think by default no filters should be shown and a search by tag, filename and file contents should be done. Filters should be hidden always unless specifically requested.

The breadcrumb should be broken down into an assumed "how specific" a search is: eg Tag > Rating > Date. (I say rating before date because on the circumstance that somebody would want to search for rating they would probably value that more than the date filter) Pressing on each crumb will adjust the search to become less/more filtered.

I think the main issue after this lies in how to make tagging a lot more natural for users. Perhaps an application that auto-suggests tags for files based on their contents, filename and ext? What I think would be a _really_ useful app is a small systray app that says "you have # untagged files" where in your spare time you can start bulk tagging files. Because what's the use of searching for tags if you don't have any tagged files in the first place?

Of course nepomuk isn't all about tags - but personally as a user that's all I see at the moment. And what I do see of it isn't much, and so of course I'm really happy to see this change.

J. Cain said...

The "Basic" and "Advanced" screens look really good! I would think this would cover 90+ percent of how most people would need to search.

Well done! Good luck getting everything set in stone for 4.4.

@Dion Moult -
I agree - some type of "untagged files" filter would indeed be useful. As long as you can configure it by location and file-type.

Hans said...

First of all I have to say this looks very nice, first the search bar in Dolphin and now this. Without doubt it'll make Nepomuk much more useful.

1. "As soon as the search-bar at the top gets focused, the search configurations pop up below"

I'm not sure I like this, probably because I'm used to how you search in a web browser:

The search bar is something for fast searches, i.e. enter a few keywords and go. If I want to specify more options, I either entered a search and fill in the details on the search page, or go to the search page directly (sounds like the common workflow you describe).

This is what I would expect in Konqueror, but I don't know if it would make sense in Dolphin.

Other problems I see with the current ui:

a) Imagine using a fullscreen Dolphin window on a widescreen monitor - can't imagine it looking good. Of course, this can be improved.

b) It doesn't look like it "belongs" to the search bar.

c) "Save" looks out of place, in my opinion. From my experience, most people aren't familiar with saving searches. I would rather have this option after doing the search, and call it "Save Search".

d) I haven't used it, so I don't know about this one. But it looks a bit annoying to me, in the sense that you don't expect something to "pop up" just because you've focused a textfield.

2. "I'm also unsure which data the breadcrumb should show: Visualizing a string like "nepomuksearch:/+lastModified<2009-11-13 +rating<8 +tag:Peter" to the user is something where I doubt Apple would do. Any suggestions would be welcome."

How about thinking each criteria as a further filtering of the previous search? In this example it would be:
nepomuksearch:> lastModified < 2009-11-13 > rating < 8 > tag: Peter

Clicking on "lastModified < 2009-11-13" would remove the two later criteria (rating and tag).

The bad thing about this approach is that you have to edit the "path" manually if you want to exclude lastModified or rating only.

3. What do you think about adding text to the plus button, e.g. "Add new search criteria", to make it clearer? Besides, it's good for keyboard users.

Keep up the great work!

Unknown said...

"If I compare the number of files on my current hard disk with the number of files I had 10 years ago, I'm quite amazed."

I am using computer more than 10 years, since '96.

Main reason for me to switch to Windows Vista from XP was Windows Explorer. Search in Windows 7 is amazing.

'Search' is for me one of the most important features... Not just in Dolphin but also in DigiKam, Gwnenview, and other apps.

I don't know what are capabilities of Nepomuk (it's turned of for me since it's using too mush of RAM) but Dolphin should be able to perform advanced and powerful searches even when NEPOMUK is turned off or when searching in non-indexed locations.

If you care about feature of KDE and Linux in general, this is one the most important areas to work on.

How do you find file you want fast if you have more than 100,000 images and more than 4000 mp3 and 1200 documents and you receive 20 emails every day? What will happen in 10 years from now? What about files that are not on local hard drive?

Check out this tread http://forum.kde.org/brainstorm.php#idea77070

Fri13 said...

I agree on most things with Hans.

What I noticed is that the search area is big and it makes almost impossible to use on netbooks with the 1024x600 resolution.
Same time it makes the results area a very small.

I suggest we use a sidepanel for this, like "Places" and "Information".

What Hans said about searchbar being just for fast searching, I can not do more than say that is it's purpose. It just should be fast way to get finding files, not a complex way. So lets not go back to KDE3 direction here ;-)

Then same things what Hans, said about "Save" > "Save search". The + icon is just something what I find typical with the - icons.

I like the current file searching on nepomuk (Mandriva 2010 here where nepomuk works great!) but I miss the feature to limit the results.

Like if I search "mockup", I get tagged files and different development files as well the files with names "mockup". Sometimes I just need to get the specific results what would go like "mockup +tags +names" so it would leave files inside out of the results.

Thats why I think we should have a special searches on the searchbar for powerusers with + - <> markings. Like "nepomuk -tag +date >5 -.png"

And give normal users the advanced search with the button to sidepanel what would not cover the file view.

Anonymous said...

"If you care about feature of KDE and Linux in general, this is one the most important areas to work on."

Has Peter ever given the slightest impression of *not* caring about "KDE and Linux in general"?

Unknown said...

"Has Peter ever given the slightest impression of *not* caring about "KDE and Linux in general"?"

No. I was not talking about him.

wilder said...

Very good! finally we can search thru our messy collection of files (I hope I could use some nepomuk in real life).
A few comments/suggestions:


"The number of clicks to activate a filter must be minimized.It should still be powerful"
There's a trick, which you can see for instance in kmail when filling in the "To:" field of a new mail. Each time you fill in the last lineedit a new empty one is spawned. What about doing something similar in this case?
In this way 1) you don't give a hey-thats-too-complicated-for-me first impression with too many filter lines and 2) you clearly give the impression of the unlimited number of filters that you can add.

"I'm also unsure which data the breadcrumb should show"
If you switch the order of two filter, nothing changes, whereas the same for two directories doesn't make much sense. So in principle one solution would be to show each filter in the breadcrumb and be able to remove a filter (and just that) by clicking on it (ideally a X should appear on hover)... have a look at gwenview filtering for instance.

Some thoughts on the layout; looking at the pictures I notice that there's lots of wasted space, so it would probably make a lot of sense to squish things in a sidebar, substituting (or merging with) the information pane; I would put each filter on two lines: "tags contain" above and "whatever" below; the plus and minus buttons should be much smaller.

Sorry for the lengthy comment :P

Leo S said...
This comment has been removed by the author.
Leo S said...

Neat idea. If only I could figure out why nepomuk doesn't work on Debian... *sigh*

Anyway, I think the full set of lines is pretty heavy to be dropping down whenever the textbox is focused. Most of the time you don't need to filter your searches (and if you do, nepomuk needs work).

Apple does it with a progressive disclosure method. I think this is much less threatening for someone who just wants to do simple searches most of the time, but still can get all the power.
Here's a progression of screenshots in Finder.

http://i33.tinypic.com/143nh3n.png

1. Blank search box (I think the box should be smaller in Dolphin as well).
2. Typed word. We get one small bar with where to search and how.
3. I pressed + and got one more bar with the criteria that apple thinks is most common. However I can click on the "Kind" combo box and change it to whatever criteria I want.
4, 5. I click + again, and by default it gives me the next most common search criteria. I can always change what criteria is where, but I never have to look at more than I need to.

Makes for a very clean UI. Yes, if someone very regularly needs to specify wickedly complex searches they will need a few more clicks, but that's pretty unlikely (and you can save searches). Also the plus icon is on each little bar, so you can actually just click 3 times and it will add three more.

By the way, apple just hides the breadcrumb entirely during searches. I doesn't add much since all the criteria are already in the search bar, and you can save a search too.

toddrme2178 said...

It may also be worth checking out an alternative way to implement the search functionality by integrating it with the filter bar and adding a quick way to integrate more complex searches:

https://bugs.kde.org/show_bug.cgi?id=210716

or

http://forum.kde.org/brainstorm.php#idea38890

Unknown said...

Great work, Peter.

I wish I had contributed more to search in 4.4 after the summer ended, but school has kept me pretty busy. I'd like to find some time for KDE next summer.

Alessandro Sivieri said...

I think I agree with the difficulties on a 1024x600 resolution, which I think exists also for side panels (and I have noticed it also for my faceted panel mockup, which is linked on the post); the problem I think is that put all the query form parts on a widget with a short width is very hard...

About the breadcrumbs: probably the best solution (but I don't know how everything has been developed, so I don't know if it is feasible) is to split the query into parts, in which each part is (for example) a line in the form, so a user can select only the "date > xxx", and this selection may delete the piece from the query or focus its line in the form itself.

Nathan said...

About the breadcrumbs:

If I understand them correctly, right now they are linked in a sort of hierarchy. If so, I think this is the main problem for searches and filtering. IMO, it would be better if you could add to or remove from the breadcrumb regardless of the order it appears. This may be similar to what Sir Alex was suggesting.

I'll try to illustrate. BestBuy.com has a way to filter searches for items in their online catalog. You select the category from the menu. Then there is a sidebar from which you can choose to narrow the search. Each of these filters can be added or removed at any time. Their "breadcrumb" just lists the filters in the order they were added to the search. On the sidebar, you have the option to remove the filter.

Would it be possible to remove filters directly from the breadcrumb (maybe using an "x" icon like tabs do)?

I know that searching for random files involves much more than searching for items in a store; however, I wonder if we could do something similar. Maybe we could have "top level" categories show up either before or after the initial search - things such as music, document, photo, video, etc. If the user selects one of these "categories," we could have several filters available for that particular category. For instance, for music, we could have artist, album, date, genre, etc. If they chose artist, maybe Nepomuk could list (in the sidebar) the artists that the user has available. They select the artist, and, while the search results are narrowed, they still have the option to choose another filter from the sidebar. They choose the album filter and Nepomuk shows the albums available by that artist, etc.

I know there would be issues to deal with for this concept to work (scrolling to see all of the filter options, for instance), but I do like the idea that I can search for something without having to type anything. Just select categories and filters to narrow the results.

Exodub said...

I agree with the second comment: this advanced search bar should be hidden most of the times. Selecting the search bar in dolphin typing a word and hitting enter should trigger a search with some sensible default settings, without showing this panel.
It's way too much information for 95% of the use cases.
The panel should show when the user hits ctrl+f or something similar, when he explicitly requests advanced search functions.

Unknown said...

@all: Thanks a lot for your comments! I've read all of them and will apply some changes to the current code :-) Sorry that I cannot comment on each suggestion individually, I think a blog is just not the right forum to do detailed discussions about such a (IMO) tricky topic.

Anonymous said...

Looks good. But right now if you want it and want it to work, use Windows 7 or Mac OSX. My nepomuk index and database are 7GB and nepomuk+virtuoso are still too slow to use it for anything. Right now, that's just the way it is.