2007/2/19, Calum Benson <<a href="mailto:Calum.Benson@sun.com">Calum.Benson@sun.com</a>>:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Wed, 2007-02-14 at 14:29 +0100, Mikkel Kamstrup Erlandsen wrote:<br>> 2007/2/13, Calum Benson <<a href="mailto:Calum.Benson@sun.com">Calum.Benson@sun.com</a>>:<br>> On Mon, 2007-01-29 at 12:51 +0100, Mikkel Kamstrup Erlandsen
<br>> wrote:<br>> > 2007/1/29, Jean-Francois Dockes<br>> <<a href="mailto:jean-francois.dockes@wanadoo.fr">jean-francois.dockes@wanadoo.fr</a>>:<br>> > Mikkel Kamstrup Erlandsen writes:
<br>> > > Hi All,<br>> > ><br>> > > I put together a first take on formalizing an end<br>> user<br>> > search language.
<br>> > ><br>> > ><br>> <a href="http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage">http://wiki.freedesktop.org/wiki/WasabiUserSearchLanguage</a><br>> >
<br>> > - Which of OR and AND has priority ? (does (A AND B<br>> OR C) mean<br>> > ((A AND B) OR C) or (A AND (B OR C)) ?<br>> ><br>> > I guess it is standard that AND takes precedence over OR,
<br>> but maybe it<br>> > makes sense to reverse that in our case.<br>><br>> This is a perennial problem with designing boolean query UIs<br>> for average<br>> (
i.e. non-mathematically-trained) users-- they expect "and",<br>> "or" and<br>> "not" to mean the same as they do in everyday language, but<br>> often they<br>
> don't. E.g.:<br>><br>> - User asks for a list of "blue things and red things", and<br>> gets back a<br>> list of things that are both blue AND red (which in many
<br>> contexts is an<br>> empty list).<br>><br>> - User asks for a list of things that are "not blue or green",<br>> and gets<br>> back a list of things that are every colour except blue
<br>> (including<br>> green).<br>><br>> FWIW, this is why I personally prefer something like the eBay<br>> search<br>> "language" to Google's-- I always find it easier to remember
<br>> how to<br>> construct more complex queries, and they never involve typing<br>> "and" or<br>> "or" :) (But of course, I'm not really your "average user"
<br>> either.)<br>><br>><br>> I was not familiar with the eBay search language. I must say that I'm<br>> not really thrilled at they way they use braces - ie. they are not<br>> subexpressions. Also - you have to read the language spec to know what
<br>> they do.<br><br>Agreed; as I said, I'm certainly not an average user either.<br><br>That said, most "average users" are probably doing simple, one<br>word/phrase searches most of the time in any case. In which case, it
<br>may be acceptable to have them read instructions when they need to do<br>something more complex, provided those instructions are sufficiently<br>memorable that they don't have to read them again next time. I found
<br>this to be the case with eBay's, but I often have to refresh my memory<br>with Google's-- perhaps, admittedly, because Google is better at finding<br>things without complex queries in the first place, so the need to use
<br>them is much less frequent.<br><br>As others have said, though, it's pretty much vital to usability test<br>this sort of thing as soon as you can. Fortunately, command lines or<br>other text UIs are often a lot easier to test than GUIs, as you can
<br>often get by with just a pencil and paper.</blockquote><div><br>I don't think I'm the right guy to do usability testing. And I can pretty much guarantee that the specs wont be ready in 2007 if I have to pull it off alone.
<br><br>The current proposal is a synthesis of Apples spotlight language and Googles search language. The only usability study I know of is the one we did here at work pointing to the conclusions I outline in the specs. The biggest problem is that this study was in a library and on a web interface which might not represent desktop search very well.
<br><br>Anyway if anyone has time to pick this up (soonish! - like really really soonish), or know of existing usability tests please speak up.<br><br>Cheers,<br>Mikkel<br></div><br></div><br>