[Digikam-devel] Search UI

Mikolaj Machowski mikmach at wp.pl
Wed Feb 20 21:35:10 GMT 2008


Dnia Wednesday 20 of February 2008, Marcel Wiesweg napisaƂ:
> > > 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.
>
> (Which I usually dont like, but that's personal opinion)
>
> > 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).
>
> Yes it looks very simple, and is slick and fast if you know what you
> want. I like the language to describe the AND/OR grouping, and I like
> how concise the dialog is.
> There are some points I dont like:
> When you start is up, everything is disabled. You need to check a
> checkbox first to be able to enter data.

Well, I like it because it forces user to *think* about what is (s)he
going to do. I am working with people... hmm... cybernetically
challenged ;) . Generally there are two types of problems they have:

1. They are afraid of doing anything - simplified interface helps here.
2. They rush to do anything without thinking - restrictions like that
   are forcing to think; they provide clear order of battle with
   program.

> You dont see at first glance what you can do, it does not show you what
> it has to offer.
>
> > 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).
>
> What I like about the Google Advanced search is mostly the layout:
> Three columns, well aligned, a title on the left, a detailed label, then
> the data entry.
> Even the two combo boxes "Only/Don't" already disturb the layout in my
> eyes.

Google has practically infinite vertical space.

> > 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, ...)
>
> I have these grouping:
> - Filename, Album, Tags
> - Picture Properties (dates, rating, size, format,...)
> - Caption, comment, title (comment, author, headline, title)
> - Photograph information (make, model, aperture, ...)
> - Geographic position (Which I will not implement in the first version,
> but needs to be kept in mind.)
> - Copyright information (later)
> - other IPTC Core fields (later)

These are too much. It will give (at the beginning) 5 groups, what if
user wants to combine two sets of searching? It will give 10 groups in
one dialog.

Majority searches is really simple, grouping 2 or 3 options. With extensive
system it will give user dialog with 10-15 options and only 2-3 of them
will be used. 80-85% of space is wasted.

> > This would also correspond with data presentation in digiKam. But it
> > would also make complex searches interface *very* complex.
>
> The current paradigm is: No search field in the beginning; add one by
> one.
>
> The other end is: Show all fields at once.
>
> Solutions in between, of which I have thought, include:
>
> Show a well selected subsets of options, grouped as above, and allow to
> add more.
> Show the first two groups of options, and allow to unhide the other
> groups.

To Gilles: exclusion of even base wildcards makes search system
practically useless for languages with rich flexia(?) and declination
like all Slavic languages. Full PCRE would be overkill but this set:
"?.*" (or compatible) is a must.

m.




More information about the Digikam-devel mailing list