KDE SC 4.5 will be out soon and as mentioned in an earlier blog entry, for Dolphin this release has been used to do bugfixing, polishing and internal cleanups of the code. I'm quite happy with the result, however last week I decided to have some fun again and have started to improve the search interface of Dolphin (will be part of KDE SC 4.6).
History
Although it was already possible to search also for tags, ratings and other kind of data, it was nearly unfeasible for users to discover this functionality. In KDE SC 4.4 I tried to improve this by showing some search options as soon as the user clicks into the searchbox:
By clicking on the green (+)-button, it was possible to specify the searching in a very detailed manner:
Problem #1
When I started to write this (quite complex) user interface, Sebastian Trüg already told me about his concerns, that this kind of user interface might not be the best approach. Well, I still thought that I need to provide something for the users to allow them more specific searches; the feature freeze for 4.4 was near and so I finalized the implementation for this interface.
But Sebastian was right: It turned out, that nearly nobody uses this (+)-button at all. It just takes way too many clicks to specify a query. A better approach is something like Alessandro Sivieri implemented in his semantic browser: Just provide basic filters, that allow the user gradually to decrease the number of found files if necessary.
Problem #2
Another issue is the distinction between searching indexed files with Nepomuk by the searchbox...
... and searching non-indexed files with the KFind shortcut in Dolphin:
Most users out there don't care about whether a file is indexed or not, so I tried to solve those two problems during the last week.
Improvements
When pressing the Strg+F shortcut (I don't know yet, whether "Find" should be part of the default toolbar setup), Dolphin changes from:
to:
Not really revolutionary of course, but I like it that the breadcrumb gets replaced by the searchbox and hence no space is required anymore in the toolbar for the searchbox. The nice thing is that this searchbox integrates the KFind functionality and the Nepomuk searching in one interface. It is automatically detected internally, whether the current folder is indexed or not. Needless to say that for non-indexed folders it takes longer to query for e. g. all texts that have the word "test" inside, but it works. Also without Nepomuk it is of course not possible to query for files, that have a specific rating. But as soon as Nepomuk is available and the current folder is in the index, a filter-button is available on the right side. When pressing the filter-button, the searchbox gets extended:
The interface of those extensions is just a prototype currently, but the basic idea is similar to Alessandro Sivieri's semantic browser: Just allow the user with less clicks to minimize the search results after doing a search by activating a filter. E. g. pressing on the "Home" tag will limit the search result to files that have been tagged with "Home". Although this does not sound very different in the first sight, it is a huge difference when trying it out yourself.
For me personally the ability to search also on non-indexed folders is a big win: In my development environment I don't have indexed my sources, still I often require to grep for some strings in source files. So instead of using the terminal I now can use Dolphin for it :-)
26 comments:
Way cool, big improvement imho. For the rating I would use the normal rating widget, and I wonder how well the tags scale, but it looks like a great start.
finally, kfind integrated in dolphin :)
Nice idea, but what if:
1) User has more than 4 tags, as shown in the query window? How does the tag choose menu expand to show all tags?
2) User wants to search for files with specific time range?
Like July 4 2009 to January 27 2010.
@jos:
> For the rating I would use the
> normal rating widget...
Yes, this might be an option, but would allow only to filter for one value. But we have enough time to finetune this :-)
@warnec:
> User has more than 4 tags, as
> shown in the query window?
> How does the tag choose menu
> expand to show all tags?
It would just wrap at the right border and continue in the next lines. This has not been implemented yet, but will not be too tricky.
> User wants to search for
> files with specific time range?
You mean something like find file >= date-1 and <= date-2? This is not offered currently and I'm not sure whether this is really needed. But I agree that it is very tricky to find the line between a simple user interface without limiting the possibilities. I'll wait for the feedback of the users, but if in doubt I'll strive for the simple user interface this time.
If you wish to offer complexity, too, you could add the "+" of the previous interface on the bottom right side of the filtering widget, kind of like the filter button and have yet another set of options pop down for those who need things like date rage, etc.
It's a great improvement, by the way. :) Thank you for your efforts with Dolphin. It's really important to everyone using KDE.
Looking forward to 4.6 now. :P
"
It would just wrap at the right border and continue in the next lines.
"
Don't You think this would be hard to use? If I, say, have 40 tags and a single line can display 5-6 of them, I'd need to click a button to scroll right and see the next tags, and so on, and so on, until I finally find the one I look for.
(something like using Firefox with ~30 tabs on a netbook, frustrating)
Wouldn't it instead be better if the line would "extend" vertically so that it covers some part of the window below and displays a few rows of tags at once? (And then shrinks back to its place as soon as tag choice is finished) Is this doable? Do You undersatnd what I mean?
A bit off topic... Is it possible in Dolphin to have a quick scroll implemented? I mean that if I press K it would scroll to the first file starting with K.
The main problem what I currently find, is that Nepomuk (+ Strigi) still lacks the real time search function. No one can not wait hours that Strigi gets updated the index so just created file is there. Newly created documents need to be indexed right away when the file is saved to disk, and updated everytime the document is saved again. Without that, Nepomuk is useless.
Dolphin search bar is useless by few different reasons.
1) You can move the search bar where every you want, but the search filtering pop-ups all the times top of the breadcrumb. It should pop-up inside the file view, top or bottom of it. Like if the search bar is located bottom, it should come from bottom top of the search bar. Otherwise from top.
2) The pop-up is nice but it takes lots of space from more important feature, the search results. Especialy with smaller Dolphin sizes or small screensizes the search results comes very small and user has more difficulties to find anything.
3) The possibilities to narrow down the search results. This is something what was done well in Sembrowser. You have sidepanel for search filtering. You have calender view where you could select week, month, year, day, or select from-to -dates easily. Easy way to select what kind files you are searching (altought I think the "Documents" is just too wide definition. There should be "Document", "Presentation", "Spreadsheet" etc)
4) The function to narrow the search place. I do not care do I want to search from this location or this computer so much. Yes, it is nice to be able to narrow it down to current directory and it sub-directories. But more important is first to search from all metadata. (Or is Nepomuk so slow that it needs to be focused to smaller areas to get results faster?). Secondary options should be to search in current directory (+subs) or from remote place.
Integrating the KFind is actually littlebit weird, and I must say that this drives more collinsion with the filter function in Dolphin. That is so powerfull because you get results right away without waiting (like with Nepomuk) and it does not clutter the view.
The new UI does look promising but there is much polishing.
You could add a "Specify" button to date, a "More" button to the tags and only display the most used tags by default. Or use the tag cloud approach.
For the rating it might be possible to reduce the amount of space. If you want to limit your search for content with the rating 3 stars, mark the 3rd star. If you want to limit your search for files with ratings 3 and 5 stars mark star 3 and 5. Consistency with the rest of the environment might be a problem here. On the other hand, did you ever want to search for content which is either rated 3 or 5 but not 0,1,2,4 stars?
@warnec:
> Wouldn't it instead be better
> if the line would "extend"
> vertically...
That's what I meant with "wrap at the right border" :-) I never intended to introduce a scrolling.
Cool improvements!
Just an idea. I'm a fan of the goole approach. One line only and the possibility to define the search e.g.
> searchwords +date:>2010.07.01 +rating:3-5 -date:2010.07.15
A extended search could be reached with a button.
But perhaps that's to geeky.
@Gianvacca: When I got you right, this feature is implemented yet. Press K and the first filename with a K. Type KDE and it jumps to the first filename beginning with KDE. But you have to be very quick. Otherwise it will go from K to D to E beginning file.
"But you have to be very quick. Otherwise it will go from K to D to E beginning file."
Yeah, that has always been a bit of a problem. Not to draw any comparisons, your work on Dolphin is really great and I thank you for that, but the Nautilus way is more user-friendly, where you also get a visual feedback of what you've been typing. It would be really nice to have something along those lines implemented on Dolphin, too.
I posted some brainstorm ideas related to this a long time ago. They include some mockups about how this sort of thing could be implemented.
Special Filters:
http://forum.kde.org/brainstorm.php#idea38890_page1
Filter and Search Buttons:
http://forum.kde.org/brainstorm.php#idea38887_page1
What about sliders?
For example use slider (and label on the right explaining what this position means) to define date filer
Using some sort of log scale: 5 mins ago | 25 mins ago | 1 hour | 12 hours | 1 day | 3 days etc.
It would give more exact time frame to define at the same time simplifying the interface - only 2 elements would be visible - slider an label of current position.
----
As for more options, like define between filters, an right aligned "more" button could be used.
More button could not only add simple "between" stuff, but also display more important info, like bars chart of tag/time line usage in current directory, thus helping to more easily selecting right settings.
Just an idea (of course) why not construct the search terms like a sentence? Imagine the Dolphin addressbar filled with a query.
search [everywhere] for [anything] [containing] vacation [and] [created between] {6/5/10 and 7/5/10} [and] [tagged] {vegas}.
The [] operators would spawn suggestions; the {} would produce a list of tags or a calendar.
I think it would be really good, if the "Find" lineedit would be part of the default toolbar.
It looks very nice =)
Hi! I love the well thought out work you're doing on the search implementation. I feel like you're going in the right direction, it just needs to be consolidated a bit. Here's the link to the brainstorm and mockups I made to help with the design process. I would really like to know what you think! thanks
http://forum.kde.org/brainstorm.php#idea89276_page1
Awesome, I've been doing many searches today in Dolphin with the find utility... it is a pain to have to open a new window, refocus the pointer, etc etc. Can't wait to see this :)
This is very nice. My only nitpick is that the "filter" button was very hard for me to notice -- I had to look twice to find it even after you had explicitly mentioned that it was there (otherwise didn't see it at all).
"Yes, this might be an option, but would allow only to filter for one value"
i guess it's a question of whether there's the use case of "only items rated three stars, but not higher" or "show items of 1 or 4 stars only". if not, then wouldn't "3.5 stars" mean "anything with at least 3.5 stars"?
@toddrme2178 and Not: Thanks for your input at forum.kde.org. As mentioned the current filters are just a prototype and your ideas give some good hints how it could be done better.
@aseigo: Yes, I also doubt that there is a usecase like "show me only items with 2 and 4 stars". Like you said the interesting question is whether the user implies a >= if he selects e. g. 3 stars. I'll try to play with this and hope can come up with something simple...
@all: Thanks for your input! I could not reply to each statement, but I've of course read everything and will consider your input for future decisions.
I personally think you should keep it simple, if the user is in folder x, search for things on folder x, and show an option reading: search everywhere.
The rest of the options aren't going to be used much, you could just implement them as text operators.
If you really want to have a GUI for those options, just show a sidebar on the left side showing the options. Or may be you could temporally replace the places (or whatever) sidebar on the right, but this may (or may not) confuse users.
Don't take the search away from the window, since it has a critical impact on discoverability.
Hi! Nice concept. Wouldn't it be good if this functionality lived inside a panel that can be moved around by the user and placed on the left or right side of the browser. If it has a vertical orientation to begin with, I think it is easier from a GUI perspective for a user to have lines dynamically expand vertically. Personally, I dislike anything that pops up in the top region of the interface and pushes the content down as it expands (yeah Lastpass dialogs in FF, I am thinking of you!).
Great job!
A second comment. Recent versions of Amarok has an interesting method for organizing files where the user can either opt for a "basic" drag and drop method to arrange arbitrary directory structures and file names visually, or use an advanced mode to type the desired structure according to a simple grammar. Maybe this combinatio of modes could be of interest as well for search...
I have always wondered why so difficult key as : is used?
Lets separate the keywords with comma what is more natural and used widely in Unix world.
When typing to search box:
Document, created < 2 weeks, edited < 3 days, rating 3.
Well... maybe it is easier than using : everywhere what is un-natural mark for normal use.
Same way the UI should be so simple that it does not pop-up something what takes more space from the area where all results are shown.
Post a Comment