Show me your finest advanced search interfaces
September 14, 2015 11:50 AM Subscribe
I lead the development of an online bibliographic database for a government science agency. As we are planning next year's work, I'm looking for examples of advanced search interfaces that work well for both superusers and casual users.
I understand that the vast majority of users are only interested in the normal search box, but there is a pretty significant community of superusers (currently around 20%) who want to be able to access specific bits of the dataset, and we also have some fancy things in there like a geospatial search. Right now, it's just a big ol' html form, though a decent looking one with select2's etc. Links to relevant UX research papers/blog posts are welcome as well.
I understand that the vast majority of users are only interested in the normal search box, but there is a pretty significant community of superusers (currently around 20%) who want to be able to access specific bits of the dataset, and we also have some fancy things in there like a geospatial search. Right now, it's just a big ol' html form, though a decent looking one with select2's etc. Links to relevant UX research papers/blog posts are welcome as well.
I've never designed a search interface, but I often run up against usability issues in our own product, which is used to configure often-complex communications systems (also featuring complex form-like interactions).
These are a couple of things I've picked up along the way. I apologize in advance if these are considered elementary UI/UX concepts.
1. You should figure out if the simple vs. full-functionality version of your interface is used more, then make that the default. It's okay to hide complexity from casual users, but if 51% of your visitors have to click to get what they want, you risk annoying the majority of your audience.
2. Toggle push buttons are not my favorite UI element. Does the label on the button reflect its current state? Or does it reflect what will happen if I poke it?
3. If you have an A/B question to ask, I ask the user explicitly, then offer radio buttons with clear answers. One of our devs put in a checkbox with "Disable squelch tail" next to it. This is confusing, because you had to click the checkbox (make it "checked" or turn it "on") to actually turn *off* the little spurt of static at the end of a radio transmission. I had them change it to: "Do you want to hear squelch tail on this radio?" then "Yes" and "No" radio buttons. IMO that's easier for a user to understand & helps them avoid having to learn the interface (and its effects) through experimentation.
4. Pulldown selects hide information, and they require a user to click on them just so they can learn what their options are. That click and time is wasted if they really just want the default selection (which is the setting most of your users want, right?). If you have only a few options, you can get away with using radio buttons. Probably.
5. When you are displaying the search results, it's a nice touch to present the search form (in whatever state it was used right before they clicked) and the user's previous settings preconfigured somewhere on the screen. That way, if they have to tweak one setting, it's very simple to do vs. potentially having to tweak 5 out of 6 previously-changed settings to perform the search again with slightly different parameters.
That's all I can think of right now. Best of luck.
posted by xiix at 12:37 PM on September 14, 2015
These are a couple of things I've picked up along the way. I apologize in advance if these are considered elementary UI/UX concepts.
1. You should figure out if the simple vs. full-functionality version of your interface is used more, then make that the default. It's okay to hide complexity from casual users, but if 51% of your visitors have to click to get what they want, you risk annoying the majority of your audience.
2. Toggle push buttons are not my favorite UI element. Does the label on the button reflect its current state? Or does it reflect what will happen if I poke it?
3. If you have an A/B question to ask, I ask the user explicitly, then offer radio buttons with clear answers. One of our devs put in a checkbox with "Disable squelch tail" next to it. This is confusing, because you had to click the checkbox (make it "checked" or turn it "on") to actually turn *off* the little spurt of static at the end of a radio transmission. I had them change it to: "Do you want to hear squelch tail on this radio?" then "Yes" and "No" radio buttons. IMO that's easier for a user to understand & helps them avoid having to learn the interface (and its effects) through experimentation.
4. Pulldown selects hide information, and they require a user to click on them just so they can learn what their options are. That click and time is wasted if they really just want the default selection (which is the setting most of your users want, right?). If you have only a few options, you can get away with using radio buttons. Probably.
5. When you are displaying the search results, it's a nice touch to present the search form (in whatever state it was used right before they clicked) and the user's previous settings preconfigured somewhere on the screen. That way, if they have to tweak one setting, it's very simple to do vs. potentially having to tweak 5 out of 6 previously-changed settings to perform the search again with slightly different parameters.
That's all I can think of right now. Best of luck.
posted by xiix at 12:37 PM on September 14, 2015
One of the greatest power-user tricks you can do, if you do build an advanced search interface, is to have that interface translate the query into one that can be immediately typed into the "simple" search box when the search is run. For instance, if you have an advanced search that provides a date-range, you could have the query syntax be something like "keyword query +dates:[from]-[to]", or something similar. This can also open up possibilities for queries that are more capable than what your "advanced" search UI can generate.
posted by Aleyn at 1:34 PM on September 14, 2015 [3 favorites]
posted by Aleyn at 1:34 PM on September 14, 2015 [3 favorites]
I'm a casual programmer without any scientific knowledge, but I have made a couple of little programs that turned out somewhat successful and search has been part of some of those. I always want to make my interfaces stupid proof and advanced when needed, so here are just a couple of things I've tried that might be of interest to you.
- Provide the option to do a regular expression search. You can easily use something like pcre or boost to add the enormous power of regular expressions for those who need them.
- Predictive search with a database of words. I once built something similar for an educational university program and I kept adding successful search terms to the predictive database. This was appreciated by the students.
- Something I cooked up myself and wonder why it's not seen everywhere: distance searching. It's a really simple concept. Say you want to locate a paragraph and you know it has the words "Schopenhauer" and "Will". You can then query for both terms and their relative distance. As the user can specify a distance (in characters or words or what you may have), it eliminates unrelated paragraphs.
Good luck!
posted by hz37 at 2:41 PM on September 14, 2015 [1 favorite]
- Provide the option to do a regular expression search. You can easily use something like pcre or boost to add the enormous power of regular expressions for those who need them.
- Predictive search with a database of words. I once built something similar for an educational university program and I kept adding successful search terms to the predictive database. This was appreciated by the students.
- Something I cooked up myself and wonder why it's not seen everywhere: distance searching. It's a really simple concept. Say you want to locate a paragraph and you know it has the words "Schopenhauer" and "Will". You can then query for both terms and their relative distance. As the user can specify a distance (in characters or words or what you may have), it eliminates unrelated paragraphs.
Good luck!
posted by hz37 at 2:41 PM on September 14, 2015 [1 favorite]
Get a copy of Peter Morville's O'Reilly book Search Patterns. He's a UX/IA guy (literally wrote the book on IA) who's turned toward search in the past 5 years or so.
posted by ImproviseOrDie at 12:22 AM on September 15, 2015
posted by ImproviseOrDie at 12:22 AM on September 15, 2015
NIH reporter is a pretty serious search engine for grants etc. you may want to look there for inspiration.
posted by lalochezia at 9:25 AM on September 15, 2015
posted by lalochezia at 9:25 AM on September 15, 2015
This thread is closed to new comments.
1. Can you look at other databases? Ovid, JSTOR, different PUBMED interfaces? Also, Lexis-Nexis and WestLaw. Anything where you have researchers of various levels and librarians searching will be trying to solve the problems you're solving.
2. Highly, highly recommend that you test with representative users as you develop.
3. One thing we're looking at for a similar (not strictly search) is an advanced view vs. a simple view -- might be one idea to test.
posted by chesty_a_arthur at 11:57 AM on September 14, 2015