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 extensible. 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) http://kubasik.net/blog/2008/02/03/beagle_mockup.png 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 http://kubasik.net/blog
Attachment:
NautliusSearch.png
Description: PNG image
Attachment:
beagle_mockup.svg
Description: image/svg
