[web] Site search form usability
Sorry if the subject line isn't too useful.
I'm developing a web site based fundamentally around a search algorithm. The search page needs to be able to accommodate some averagely complex queries, which I will demonstrate with reference to AD+D statistics. [smile]
"find all characters with dexterity > 15"
"find all characters with strength > 16 OR constitution > 17"
"find all characters with (strength > 10 AND intelligence > 10) OR (wisdom > 15)"
"find all characters with strength > 10 AND (intelligence > 10 OR wisdom > 15)"
As you can see, this will map onto SQL simply enough, so the actual data retrieval is not a problem. What is a problem, is how to formulate a clean interface for this.
My first thought is to have 2 dropdowns, one for attribute (eg. strength, intelligence) and another for the required value. This works fine for example 1 above. Next to that would be a '+' button, which adds another 2 identical dropdowns below, to query a second attribute, with a button you can toggle from AND to OR and back again. That addresses example 2 above. However, examples 3 and 4 are more awkward - the AND operator would take precedence in the first and the OR operator takes precedence in the 2nd, yet my proposed UI has no good way of accommodating that.
My users are not going to be comfortable with entering a boolean search, no matter how simple it is. On the other hand though, users will perform very few searches and therefore it doesn't matter if it takes a little longer to formulate than a Google search does. However, it mustn't be intimidating or complex. Any ideas how I can comfortably represent all the above 4 examples visually? Wacky and off-the-wall suggestions welcomed, as long as they're practical - this isn't a formal business site by any means. I'm also happy to only target IE6 and Firefox 1.5 upwards, so assume javascript, CSS, and AJAX/JSON are all available.
How about a "Link Conditions" thingy like this:
When "Link" is clicked at Conj. A, C1 and C2 both have a border around it, now if "link" is clicked at Conj. B, there will be a border around (C1+C2) and (C3), maybe of a different color to differenciate between the two.
Of course, this will be difficult to turn into code, but seeing as you are the modding forums moderator, you could probably use a JS implementation of this. If not, I might give it a try later tonight, just let me know if you want me to give it a try.
Condition 1: [FIELD] [OPERATOR] [VALUE]Conjuction A: [AND|OR] [LINK|UNLINK]Condition 2: [FIELD] [OPERATOR] [VALUE]Conjuction B: [AND|OR] [LINK|UNLINK]Condition 3: [FIELD] [OPERATOR] [VALUE]When "Link" is clicked at Conj. A, C1 and C2 both have a border around it, now if "link" is clicked at Conj. B, there will be a border around (C1+C2) and (C3), maybe of a different color to differenciate between the two.
Of course, this will be difficult to turn into code, but seeing as you are the modding forums moderator, you could probably use a JS implementation of this. If not, I might give it a try later tonight, just let me know if you want me to give it a try.
The last two statements are basically two searches in one:
3. (S > 10 && I > 10) combined with (W > 15)
4. (S > 10 && I > 10) combined with (S > 10 && W > 15)
So, an alternative would be to let users search twice, and append results to previous results.
Alternately this can be done in the search menu by allowing not only additional requirements, but additional queries as well. Grouping them inside boxes is then essentially the same as using parenthesises in queries. So, a (+) button as well, and in each block, a + button. :)
3. (S > 10 && I > 10) combined with (W > 15)
4. (S > 10 && I > 10) combined with (S > 10 && W > 15)
So, an alternative would be to let users search twice, and append results to previous results.
Alternately this can be done in the search menu by allowing not only additional requirements, but additional queries as well. Grouping them inside boxes is then essentially the same as using parenthesises in queries. So, a (+) button as well, and in each block, a + button. :)
Is there a limit of three statements or is it unbounded? If you're limited to 3 statements you could visualy show grouping using checkboxes on the left side of the statements. The statements that have the checkbox checked would be considered grouped with parenthesis.
If you allow more then three statements per query it gets quite a bit more complicated because you could easily have nested statements which becomes quite difficult to group on. If you can provide some more information on that I'll try working up an example of what I mean.
If you allow more then three statements per query it gets quite a bit more complicated because you could easily have nested statements which becomes quite difficult to group on. If you can provide some more information on that I'll try working up an example of what I mean.
Another variation if you are not going to have nested lists more than a depth of 1, then you could conver it into 2 dimensions like so:
Where pressing [+] on the right of the line, would add another set of Field/Op/Value, with a conjuction, and clicking on [++] at the bottom would add another row.
Here, each row represents a condition in parenthesis. So you could have for your eg.4:
Condition 1: [FIELD] [OPERATOR] [VALUE] [AND|OR] [FIELD] [OPERATOR] [VALUE] [+]Conjuction: [AND|OR]Condition 2: [FIELD] [OPERATOR] [VALUE] [AND|OR] [FIELD] [OPERATOR] [VALUE] [+]Conjuction: [AND|OR]Condition 3: [FIELD] [OPERATOR] [VALUE] [AND|OR] [FIELD] [OPERATOR] [VALUE] [+] [++]Where pressing [+] on the right of the line, would add another set of Field/Op/Value, with a conjuction, and clicking on [++] at the bottom would add another row.
Here, each row represents a condition in parenthesis. So you could have for your eg.4:
Condition 1: [strength] [>] [10]Conjuction: [AND]Condition 2: [intelligence] [>] [10] [OR] [wisdom] [>] [15]
Hmm.
Verminox - An explicit 'link' option to set the precedence would work, but I don't think it would be intuitive to the users. Your second suggestion looks better though; I'll give it some thought.
Captain P - Yeah, I suppose there is always the way of reducing any set of AND and OR expressions into an ORed list of AND expressions, or vice versa. I would really prefer to be able to do it in one search, but an 'append results' options might not be a bad idea, thanks.
tstrimp - practically, I doubt they're going to want to supply more than 3 conditions to be ORed together, but each one could perhaps be up to 3 conditions ANDed together. However I'd rather not impose a hard limit if possible. The checkbox would work but, as with Verminox's link suggestion, I don't think it would be immediately obvious to users, who have no concept of grouping expressions or boolean logic. I don't expect the expression tree to be more than 2 operators deep - eg. (A and B) or (C and D), though I would like it to be arbitrarily wide.
Verminox - An explicit 'link' option to set the precedence would work, but I don't think it would be intuitive to the users. Your second suggestion looks better though; I'll give it some thought.
Captain P - Yeah, I suppose there is always the way of reducing any set of AND and OR expressions into an ORed list of AND expressions, or vice versa. I would really prefer to be able to do it in one search, but an 'append results' options might not be a bad idea, thanks.
tstrimp - practically, I doubt they're going to want to supply more than 3 conditions to be ORed together, but each one could perhaps be up to 3 conditions ANDed together. However I'd rather not impose a hard limit if possible. The checkbox would work but, as with Verminox's link suggestion, I don't think it would be immediately obvious to users, who have no concept of grouping expressions or boolean logic. I don't expect the expression tree to be more than 2 operators deep - eg. (A and B) or (C and D), though I would like it to be arbitrarily wide.
I would probably supply a form with 6 fields (one per attribute). Before each field is a drop-down: "ANY, <, >", and a numeric field. The six fields are tied with an AND clause. Next to the form is a javascript "more" button. Clicking it will create a new, identical form. The two forms are tied with an OR clause. More forms can be created this way. Normal disjonctive form theorem dictates that this is equivalent to arbitrary choices. So, for your examples:
"find all characters with dexterity > 15"
form1: DEX > 15
"find all characters with strength > 16 OR constitution > 17"
form1: STR > 16
form2: CON > 17
"find all characters with (strength > 10 AND intelligence > 10) OR (wisdom > 15)"
form1: STR > 10 INT > 10
form2: WIS > 15
"find all characters with strength > 10 AND (intelligence > 10 OR wisdom > 15)"
form1: STR > 10 INT > 10
form2: STR > 10 WIS > 15
"find all characters with dexterity > 15"
form1: DEX > 15
"find all characters with strength > 16 OR constitution > 17"
form1: STR > 16
form2: CON > 17
"find all characters with (strength > 10 AND intelligence > 10) OR (wisdom > 15)"
form1: STR > 10 INT > 10
form2: WIS > 15
"find all characters with strength > 10 AND (intelligence > 10 OR wisdom > 15)"
form1: STR > 10 INT > 10
form2: STR > 10 WIS > 15
Yeah, thinking about it, using disjunctive normal form works well both visually and theoretically. Each 'person specification' contains a number of ANDed conditions, and each search contains a number of person specifications, ORed together. (Which in practical terms will probably be done with a separate SQL query for each, with the results appended together.)
Thanks everybody, I'll give this a go. Any further thoughts or comments on layout, appearance, or ease of use welcomed.
Thanks everybody, I'll give this a go. Any further thoughts or comments on layout, appearance, or ease of use welcomed.
Perhaps you can draw some inspiration from bugzilla's search interface (link). Not the large top form, but the boolean charts the have at the bottom. I think that's a nice approach.
[Edited by - Sander on September 8, 2006 11:14:15 AM]
[Edited by - Sander on September 8, 2006 11:14:15 AM]
Yeah, that's conjunctive normal form, isn't it. I think disjunctive makes more sense for my application but the layout looks reasonable.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
