Search UI

[Marcel Wiesweg]

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.
- usability: at first use, interface may need 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.
- for advanced users, there must be all possibilities of constructing complex
queries: allow to combine several such groups of search options (even
building subgroups?)

There are no screenshots yet (and not much code).
I would like to know how much you like the
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

(I sent the previous mail before it was finished, here is the rest)

> There are no screenshots yet (and not much code).
> I would like to know how much you like the
I would like to know your opinions on the search interface, both for your
requirements as advanced users, and what would be best for the average user.

Btw, if you have a particularly spectacularly complex search created, I would
be interested in the search url for testing. You get it if you open your db
file with the sqlite3 tool and execute
SELECT url FROM Searches WHERE name='<name of search>';

Marcel
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

> > 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.
You dont see at first glance what you can do, it does not show you what it has
to offer.

> > 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.

I am not planning a crowded dialog with a huge number of checkbox, labels and
combo boxes all around the place. That looks really intimidating.

>
> 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.

>
> 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)

>
> 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.

>
> 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.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

2008/2/7, Marcel Wiesweg <[hidden email]>:

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 also,

- same interface : users are not lost.
- Code already ported. Gui code tested. interraction with KIO-slave need to be re-tested indeep...
 

and these problems:
- discoverability: imagine a combo box with 45 entries.
- usability: at first use, interface may need learning

Agree... there are already few B.K.O entries about this subject.
 

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

This already exist as well with Quick search. Of course code need to be improved to include complex queries " à la google"...

But please, please, do not make a regular expression interface... You know already my viewpoint about...

For standard users, this gives a well-known kind of interface, shows the
options that we offer.
- for advanced users, there must be all possibilities of constructing complex
queries: allow to combine several such groups of search options (even
building subgroups?)

This is my recommendations :

- In a first time, port the current code to check if your new Search backend work fine. This include Quick and Advanced search.
- In a second time, improve the quick search tools to include complex queries.
- In 3th time, Look if new google like Search tool can be a good remplacement of Advanced Search tool.

Marcel, you have forget an important point about searches : the dedicaced user friendly tools :

- 1/ GPS location search using marble (this is the next one my my list).
- 2/ Duplicate images search using haar fingerprint.
- 3/ Fuzzy search images using haar fingerprint (like imgseek)

Others viewpoints are welcome of course form this room...

Best

Gilles Caulier

 

There are no screenshots yet (and not much code).
I would like to know how much you like the
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

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.

_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel