The beginnings of an advanced query UI

So, I think we all agree that while the system of text-based keywords
for advanced queries can be extremely powerful, the issue of
discoverability makes them more of a stepping stone to a graphical
system. Now, the current beagle-search UI isn't exactly spacious, and
we already have issues with cluttered results, so its obvious (to me)
that anything me plan on doing is gonna take some planning, or a major
examination of beagle-search. (as this would be the second large
pending change for beagle-search).

Anyways, I can't say I have any answers, but I figured that a few
mockup's wouldn't go amiss and  we could come up with a plan.

So, most people use specialty searches as filters on primary queries.
I'm looking for an e-mail about spring break, I got too many back, so
I narrow it down to this  year. While there are certainly cool
possibilities when data is approached from the other direction, thats
beyond this scope IMOH. It's with this filtering concept in mind that
I endorse what nautilus search has done for its basic interface. And
while we need to make some more specific decisions, I think its very

The problem is, large queries (say 5 or 6 qualifiers) would more of
less fill the entire interface, especially at full size, so instead of
fighting that, I vote we simply make our search interface 3 phase. I
now it loses some 'coolness' but I think the sheer sense it makes can
overcome that, most people like simplicity.

So, this new interface starts like the basic nautilus one (just with
lots more dropdown options (once we have the property names finalized
of course). Then the user punches query, we are taken to what we see
now, but with a few small additions.
1) The presence of a Back-Forward arrow combination
2) A '+' button to add more filters next to the query bar.
3) Like the web interface, we allow the user to click on any property
of any result, and add that to the filter stack.

Now the second 2 additions are pretty cut and dried, but the first
bullet seems a little out of place I know, I'm proposing that instead
of displaying every filter the user has added over the process of
refining down there results, we just keep that information in a stack,
and allow the user to navigate much the same way they might a large
Google search. (I got this idea while watching a friend try to find us
a restaurant on Google, he rarely realized what information Google
Maps was adding to his search bar, just the results, then the back
arrow, and more clicking) This allows for a very natural navigation of
information, descending into smaller result sets, then backing back
out to larger ones to try a different subset.

As soon as I thought of this I got concerned that we might force a
_lot_ of unnecessary button pressing when crafting the initial set,
but I think that 90% of those use cases are made irrelevant by using
the traditional interface when crafting the initial query. In this
type setting, instead of requiring the problematic timespan (we don't
handle a mail with significantly different sent and received times
etc) by allowing people to specify the only parameter that matters for
them. There are dozens of smaller UI things we need to decide like how
to indicate before or after when someone clicks on a date on a tile.
How do we help users keep track of there place in the 'stack' , I'm
thinking some sort of breadcrumbs, with abbreviated representations of
each filter/query part, but making that coherent is tough. Since I
know this is tough to follow in words, I've attempted a diagram in
stetic/inkscape/gimp Its nothing like what I think it would really
look like, but I hope it conveys the idea.

(the bitmap is probably way to big for the list, so here)

Anyways, feel free to dismiss, to heckle, to praise, Just trying to
think of a way to be something more than just searching text.... ;)

Kevin Kubasik

Attachment: NautliusSearch.png
Description: PNG image

Attachment: beagle_mockup.svg
Description: image/svg

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]