Re: beagle-search: Showing the top 2 of 3 total matches

["Joe Shaw" <joe ximian com>]

Hi,

On 3/30/07, Johann Petrak <johann petrak chello at> wrote:
> And why does it first show "showing all 0 matches" or sometimes
> "showing all n matches" only to replace this with a much higher
> match count a bit later? This is a) wrong and b) confusing as hell.

The results come back asynchronously, so that you can see *some*
results right away, even if they're not all of them.  This is a
constant tradeoff in computing: for a fundamentally slow operation
(like searching thousands of documents, browsing a web page, or
navigating to an enormous directory with the file manager), do you
show incomplete results first and fill them in to give the user some
feedback, or do you wait until everything is in?  Generally, you show
the user what you can.

As for the count, the idea is that it's the total number of documents
which match your search, similar to how Google says:

   Results 1 - 10 of about 304,000,000 for dog

It gives a clue that if you're looking for a very specific document,
you need to refine your search terms further.  (Also, like Google,
Beagle doesn't return every single matching document if there are more
than a few hundred.  Try viewing all 304 million matches for "dog" in
Google.  You can't.)

But anyway, as Felix mentioned there seems to be a bug in getting the
exact document count, especially if beagle-search doesn't know how to
display a certain document.

> Also, I hate the way how the search results are shown in the
> beagle-search GUI.

Tell us how you really feel. ;)

> Why can't I configure this to show me a proper list instead of
> this clumsy, hard-to-use multi-column, multi page view?

Our usability tests indicated that this setup has a nice balance: it
allows you to see more results for a given type (say, music) without
losing the top matching results of other types.  But I do agree that
the layout can be confusing and needs a fair amount of work.  A list
might be a good thing to add.

> The list could then contain, depending on what the user wants,
> more or less information (arranged in columns with matching documents
> in rows) and allow re-sorting in the standard way
> by clicking on the column headers, as one is used to from
> countless other apps.

With such disparate types of data, I'm not sure how well this would
work.  The only things common among all search results are that they
have a type (document, email, music, etc.) and that they have a
timestamp associated with them.  Forcing the different elements into a
column won't work, and you'll invariably spend a lot of time
customizing those columns depending on the search.

I *do* think that a Spotlight-like flat list is a good idea, though,
and we should look into adding it.

Joe