57

TheBlackCat wrote:There are two problems with that. One, it is not easily discoverable. How do you find out what the keyword are and what their syntax is without looking at the help file? Second, it requires memorizing the keywords, something I do not think we should expect ordinary users to do. Of course that could be an option for advanced users, and probably deserves a separate thread, but I think it is unrealistic for ordinary users.

One of the overriding goals of my series of dolphin ideas was to make things simple and easily discoverable by users. One of the main ways I thought to do that was avoiding anything that requires memorizing keyboard shortcuts, keywords to type in, or reading help files to find when there is an alternative solution that is small, noticeable, and intuitive to use. If the user doesn't know it exists, they aren't going to go looking for it in the help files, and expecting every user to read the entire documentation in order to learn that a feature even exists is unrealistic in my opinion. Your idea, although good for advanced users, amounts to a hidden feature that ordinary users will never see.

1) Nice question mark icon in the end of input field, or balloon tooltips would help to discover them

2) use aliases like type:video mime:video group:video should do the same

3) helper like http://img.photobucket.com/albums/v89/t ... r-menu.png could generate queries for users automatically, but advanced users still would be able to write them by hand.

4) Same syntax must be used in ALL KDE (or even Linux) apps like kmail, contacts, beagle, kopete, bookmarks, even klauncher etc.

If such syntax would became a ISO standard user will start to use it intuitively

I do like the idea of special filters, the current system is so limited

I would love some very easy feature:
Add an option to show all the files you not looked for.

When I am working with regex, there are many situtations where it is much easier to find a regex that matches the opposite. So just add a checkbox: "inverse search" and i would be happy.

I'm working on a GSoC project involving desktop search in Dolphin: please see the end of my blog post for my UI ideas.

I'd love to hear ideas from everybody here.

The first thing that hit me about this idea is that the use of a menu is inadequate for the complexity of the tasks you are aiming to perform. I'd much prefer if the "more" button popped a panel, possibly with different tabs, in order to handle all this stuff. You know the arrangement: the "more ^" button which changes to a "less v" button.

How, exactly, is it inadequate? And how would the tabs system you are proposing be better?

With menus I'd be worried about a couple of things:

1. having them close whenever I accidentally move the mouse off them then having to navigate back again
2. I think the final level menu will stay open while you tick multiple items but certainly if that behaviour ever changed it would be a pain
3. If you want to use this to construct a complex query with multiple parameters (spanning multiple menues) - eg. all odf files that have been edited since the start of the month - then the menues don't hold enough information about the query on screen for you to formulate it easily. I.e. they rely on the user's memory.

The "tabs" I mentioned... they don't have to be tabs. The main point is that options would be set via a panel rather than menues. I looked for a familiar example and found the print dialogue. This has a "Options" button which opens or closes the less used settings (grouped using tabs). However in in dolphon we would be expanding the panel at the bottom of the dolphin main window.

I don't think it really changes the idea you have presented in any significant way - just an alternative suggestion for the way the filter options would be presented.

Microsoft has got nicely done their search bar Windows 7 Search Bar, searching lighthouse and jellyfish

It is very easy just to enter search words, click wanted date, tags, rating etc. You can see right away the context like tag=searched_tag and then reuse those somewhere else.

It should be without tree menu and just simple dropdown box, with calender and other easier ways.

Same thing is with Spotlight on Mac OS X. You just need to enter wanted words and it will filter and understand what user want to search. Without need to press different buttons.

The searching should be very easy and intuitive. Example writing "lighthouse .jpg" should bring only .jpg files what has "lighthouse". "light .jpg" should bring all .jpg files what has "light" on it. Light.jpg, Lighthouse.jpg and Candel light.jpg files as well.

Other examples:
Light .jpg today = Search "Light", filetype JPEG and created today.
Light .jpg yesterday = Created yesterday
Light .jpg week = Created on this week
Light .jpg last week = Created on last week
Light .jpg Week 42 = Created on week 42
Light .jpg January = Created on January
Light .jpg Tag house = Tagged with "house"
Light Image today = Search all imagetypes created today
Light Video yesterday = search all videotypes created yesterday
Light Video Thomas = search all videotypes created/sended/received by/to Thomas

Other ways could be (more complex)
Light [jpg] [today]
Light [jpg] [week 58]
Light [video] [Thomas]
Light [Video] [5]
Light [Video] [5] [tag house]

The biggest problem on these can be the localizatio. It should be change all search words with wanted language. So it would make harder because some can be two words. But we could add gray text/selection boxes to searchbar where to select wanted tags, ratings and custom functions.

We do have semantik search engine, what does not mean that we should need to force user to type exactly the correct search info. The Nepomuk should take care of it.

So to find the wanted lighthouse.jpg what I created last week and I sended it to Thomas. I should just type: lighthouse image thomas last week or even "lighthouse image sended to thomas on last week"

It should be possible with Nepomuk to get files just by asking them. In other example:

Video edited last week and sended to KDE forums

Again problem is localization and different verbs and other adjectives.

andre_orwell wrote:1. having them close whenever I accidentally move the mouse off them then having to navigate back again

The multi-level menu was only one possibility, the individual buttons ideas would not have sub-menus.

andre_orwell wrote:2. I think the final level menu will stay open while you tick multiple items but certainly if that behaviour ever changed it would be a pain

Yes, but that is a hypothetical scenario that we have no reason to think will ever happen.

andre_orwell wrote:3. If you want to use this to construct a complex query with multiple parameters (spanning multiple menues) - eg. all odf files that have been edited since the start of the month - then the menues don't hold enough information about the query on screen for you to formulate it easily. I.e. they rely on the user's memory.

My idea already deals with this. Each search parameter is added to the search bar.

andre_orwell wrote:The "tabs" I mentioned... they don't have to be tabs. The main point is that options would be set via a panel rather than menues. I looked for a familiar example and found the print dialogue. This has a "Options" button which opens or closes the less used settings (grouped using tabs). However in in dolphon we would be expanding the panel at the bottom of the dolphin main window.

My idea isn't that different if you use the expanding buttons. You push one of the buttons, and its brings up that section. There is no menu. If you push that button again, it goes away. If you push a different button it switches to that one. Whether it goes away when you click elsewhere will depend on usability experts, I don't know enough to say. The difference is it doesn't take up as much space as an entire panel, it only takes up exactly as much space as needed for that specific parameter.