Improved Find Panel

1

Haiku’s queries, while lightning fast, are a bit too complicated to use with the Find panel. You have to navigate through too many drop-down menus when all you want to do is quickly find a file of a specific type.
Here is a suggestion how this could be improved. Excuse the imperfect mockups, I’m sure the real thing would be much more pleasing to the eye… :slight_smile:

Instead of tuning all search parameters in the Find panel and be surprised what turns up in the result window, then go back to refine/rinse/repeat, I’d like to see instant results while typing the search strings. So, it’s more like narrowing down a search by more and more filtering.

Quick Icon BarQuick Icon BarTo speed up everyday searches, there’s an icon bar at the top where a user can drag&drop his most often used query templates. These templates only consist of the filetype and the layout of the attribute columns which will determine which attributes can be searched.

Query FiletypeQuery FiletypeIf you don't already have it in your quick icon bar, you choose the filetype and the partition to search. There are also the expandable options from the current Find panel for temporary queries and in/exclunding the trash. It should be possible to search through a whole supertype, like audio/*, video/* or image/*, because a user normally doesn't know/care what exact type the music/video/image is. You can drag the icon into the quick bar. If it gets too crowded up there, they can gradually shrink from 64px. If a dragged filetype already exists up there, its setting (attribute layout) is updated. Query StringsQuery StringsWhen your filetype is set, you have an empty file list below with the attribute layout typical (or saved with the quick icon bar) for that filetype. You can add/remove columns via right-click etc. as usual. Now you begin typing in the textbox above the attribute-column you'd like to search. After, say, 3 letters the query gets updated live and the file list fills with results. You can change the criteria with a drop-down menu above every textbox according to the type of attribute: contains/contains not, is/is not, begins/ends, larger/smaller, before/after... etc.

The different attributes are always AND linked, as this to me makes sense in real life: You search for an artist AND an album, but I can’t think of a real use for looking for one OR the other.

More Query StringsMore Query StringsHowever, if you need to search for more than one string within an attribute, you can click on the "+" button and add another search box for the column. Here you can choose between an AND/OR link with another drop-down menu. Removing a search box is done with its "-".

Here’s the whole panel:

Next Generation Find PanelNext Generation Find Panel So, a quick query would now go like this, for example: * ALT+F * Click music-icon * Click into artist search box * Enter "Breeders" (which I promplty forgot in all the mockup images...)

Opinions?
Thanks!

BTW: There’s also a thread on the dev mailing list for discussion.

Regards,
Humdinger

PS: I would’ve preferred not to use thumbnails for the mockups, but after taking about 10 minutes just to upload 5 images I’m at the end of my tether…

2

I like it very much! It even brings some features to the surface, like the attribute layout which depends on the file type, which have been quite hidden before. Maybe the file type not only determines the attribute layout, but also which of the attributes get text fields by default.

3

If the user creates two templates for searching the same MIME type - say, a general MP3 search and a search for “Breeders” songs, - how will he differ them on the Quick Icon Bar?

Maybe, there should be a description field somewhere near the Quick Icon Bar? This field will include a description of the query when user puts the cursor over the corresponding icon. (A ToolTip would be even better, but AFAIK there’s no ToolTips in Haiku right now).

4

I’d say every searchable attribute gets a text field. IIRC that’s not necessarily dependant on the attribute being indexed, right?

5

The quick icon bar is really only for the general filetypes a user regularly searches. Those are not saved queries with their specific search strings.

There are in fact tooltips since a few days, thanks to Axel. Of course, the quick tool bar can be further improved (context menu, icon size, tooltips, maybe an additional button to open the saved query folder etc.). All the details will be worked out should anyone feel like implementing it all.

6

Icon bar with recent/saved queries menus
Here’s the icon bar with two additional drop-down menus.
“Recent Queries” has a menu with the 10/20/30(?) most recent queries. Queries started on the same day could be grouped with a seperator.

“Saved Queries” has a menu of all user-saved queries without a “temporary” flag. The bottom entry is “Open Query Folder” and opens ~/queries/ when you want to delete or otherwise edit your queries.

The icons themselves don’t have to be 64px. We could have a right-click context menu offering different sizes and other options like icon+text or text-only.

7

The filetype and location selection could be better:
Maybe something like this:

Search For:
[-][ ] Audio (if checked will search any Audio filetype and will hide the below filetype fields)
_[X] Filetype: [MP3 Audio ][V] (when checked adds another Filetype below)
_[X] Filetype: [Windows WAV ][V]
_[ ] Filetype: [ ][V]
[][X] Video (this is checked and cannot be expanded. Will search all video filetypes)
[+][ ] Images
[+][ ] Documents
[+][ ] Mail
[-][ ] Other
_[X] Filetype: [CFG configuration][V]
_[ ] Filetype: [ ][V]

Search In:
[-][ ] Local drives (if checked selects the below checkboxes)
_[ ] Disk 1
_[ ] Disk 2
[-][ ] Removable drives (if checked selects the below checkboxes)
_[ ] USB stick
_[ ] DVD
[-][ ] Locations
_[ ] /
_[ ] /home
_[ ] Desktop
_[X] Location: [ /home/music/ ][…] (when checked adds another location below)
_[X] Location: [ /home/video/ ][…]
_[ ] Location: [ ][…]
[ ] Trash

And you may add this option for the attributes:
[X]Match any attribute

And some buttons:
[Reset] [Save Querry] [Load Querry]

BTW, I would love to have natural language queries. Something similar to Wolfram Alpha

8

[quote=geleto]The filetype and location selection could be better:
Maybe something like this:[/quote]

That’s a good idea in general. I see a problem, however, what attribute columns to display for the file list. For example, Audio and Image usually just share the general file attributes (name, size, modified etc.).
Revert then automatically to a general file attribute layout?

Are combinations of attribute searches really a common usage pattern, or wouldn’t you opt for a general file search in that case in the first place?

This makes a lot more sense. What would be needed (and also in other places, like the context menu on attribute columns for choosing the attribute layout), is a way to check more than one box at once without closing the menu. That would be convenient for any menu, actually. Maybe with a right-click on a menu item?

[quote]And you may add this option for the attributes:
Match any attribute[/quote]

Another good idea. Axel mentioned a similar thing on the mailing list. Normally that would be done with radio buttons, but I can’t see a nice design for that.
So, a checkbox with a textbox for the search string that will simultaneously deactivate the per-attribute textboxes.

[quote]And some buttons:
[Reset] [Save Querry] [Load Querry][/quote]

I’d prefer to have these in a File menu. We must try to keep the Find panel as compact and simple as possible.

That’s probably a more fundamental change to the query/parsing system. This thread deals solely with a refined Find panel. Maybe you’ll open a new thread for this idea.

9

[quote=Humdinger]That’s a good idea in general. I see a problem, however, what attribute columns to display for the file list. For example, Audio and Image usually just share the general file attributes (name, size, modified etc.).
Revert then automatically to a general file attribute layout?[/quote]

Maybe if “Match any attribute” is checked - show all merged attributes with empty values where they don’t apply.
If it’s not checked - show the general file attributes.

Or just use radio choice - where only one item can be selected.

You can search for audio/video clips from the same artist, but in most cases such queries will be needed with the general file attributes.

[quote=Humdinger]Search In:
This makes a lot more sense. What would be needed (and also in other places, like the context menu on attribute columns for choosing the attribute layout), is a way to check more than one box at once without closing the menu. That would be convenient for any menu, actually. Maybe with a right-click on a menu item?[/quote]

I was thinking of something similar to a file/folder selection panel - with a checkbox on the left of each item and expandable/collapsable folders.

10

We begin to touch on some peculiarities and shortcomings of Haiku’s index/query system. The attributes that are commonly associated with certain filetypes, like AUDIO:artist for MP3s, are not restricted to these filetypes.
You can just as easily add this attribute to a JPG, for example. Just show the Artist attribute in a folder of MP3s and copy a JPG into it. Now you can happily fill that AUDIO:artist attribute of that image and it will be found in a query (if you don’t restrict the filetype to TYPE:audio).

That’s not bad either, but it is odd to have a AUDIO attribute with a non-audio file. All the more since when you move that image into another folder, where there are no MP3s, you have no way to show the Artist attribute, since the available attributes are tracked with the filetype…

Even having multiple type attributes (e.g. AUDIO|VIDEO:playingtime) wouldn’t be a solution for every case.

Until these issues are solved (after R1 no doubt), we have to be careful not to overthink the Find panel. I’d go for a simpler solution that fits the usage in most situations.
Maybe we have to abandon the thought of combining the search of multiple filetypes aside from general file searches (name, size, modified…). You could still do several parallel queries.