[Digikam-devel] Search UI

[Mikolaj Machowski]

Dnia Friday 08 of February 2008, Marcel Wiesweg napisał:
> Hi all,
>
> in 0.10, we have now a working search backend, now it's time to look at
> the frontend.
> Currently we have the Advanced Search Dialog. This allows to construct a
> list of search criteria, linked with AND or Or and possibly grouped (one
> level deep as far as I see). There are 11 different search fields (album
> name, rating, tag etc.)
> For 0.10, the database stores much more information. We can easily come
> to more than 40 possible search fields. Some of these fields can be
> useful to the user - if he knows about their existence.
>
> So with the current interface we have these advantages:
> - flexibility creating the search rules
> - good overview
>
> and these problems:
> - discoverability: imagine a combo box with 45 entries.

Why not? Big combo boxes are routinely used on the web eg to
select country or language in many forms.

I like  interface for creation of smart playlists in Amarok. In fact
this is slightly refined version of current advanced search dialog in
digiKam (sorry, looks like my current build of digiKam is broken so
cannot draw precise comparison). The only real drawback is lack of
choosing AND, OR, NOT in Amarok version. Amarok has 23 items in
combobox. It looks very simple but allows for quite complex searches
(playlists are basically searches).

> - usability: at first use, interface may need learning

All interfaces require learning.

> My thoughts currently go into these directions:
> - present all useful search options at one glance, in the style of web
> search engines' advanced search page
> For standard users, this gives a well-known kind of interface, shows the
> options that we offer.

Standard users will use this really rarely and one page with multiple
options can be quite intimidating. 

Believe me, I know. In work we have custom database application. Queries
tool is awful.  Developer thought it will be convenient to provide as
far as possible options on one page to make searches. Only after I came
to work in this department and show how this work they started to use it
- still very reluctantly and use only small subset of options.

Also advanced search in browsers is very verbose and take much space.
Fitting this into 800x600 dialog required by KDE HIG will be hard.

Note also that eg Google advanced search isn't really powerful. I can
search for site in particular language (English) but only in one of two
languages (Polish or English).

Returning to length of comboboxes. To make them shorter you could split
searching in three major areas:

- File properties (filename, ...)
- Photography properties (aperture, shutter speed, ISO, ...)
- Metadata properties (tags, caption, date, ...)

This would also correspond with data presentation in digiKam. But it
would also make complex searches interface *very* complex.

I would really recommend looking at Amarok dialog and playing with it.

> - for advanced users, there must be all possibilities of constructing
> complex queries: allow to combine several such groups of search options
> (even building subgroups?)

Well, IMO for advanced users best tool would be some kind of query
dialect (a la Google) in searches "command line" with parenthesis and
keywords like AND, OR, NOT.

m.