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!

Information Panel and Tooltips

Dolphin for KDE 4.4 will provide a refactored information panel and refactored tooltips. The goals of the refactoring have been:

• Show the same data in the information panel and the tooltips. Up to now the information panel did not provide any information about the permissions or the owner of a file. The tooltips have shown this kind of information already, but they did not provide informations like rating, comments or tags.

• Prevent a possible blocking of the user interface, even when a slow Nepomuk backend or a buggy Strigi analyzer is installed. Although in KDE 4.3 some improvements had been done already, there have been still problems in this regard especially for tooltips.

• Improve the layout of the information. The rating, comment and tags information are not handled in a special manner anymore.

• Simplify the interface for editing tags and comments.

Although there is still a lot of finetuning necessary until KDE 4.4, it is obvious already that the tooltips...


... show the same information as the information panel:


Originally it was planned to move the refactored widget to kdelibs, so that applications like Mailody, Gwenview and Okular can show the informations in a similar way. However there have been some usecases especially in combination with Gwenview, where the interface of widget was not sufficient yet. So we decided to leave the widget in Dolphin for KDE 4.4, but I'm confident that we find a good solution until KDE 4.5.