I am working on a complex genomic research software (yes, scientists are also humans and deserve human UX) and we are streamlining our search. It has quite a few self-exclusive filters, which we are aiming to address using Selection Dependent Inputs and Progressive disclosure inspired by this great article http://www.lukew.com/ff/entry.asp?764.

However we have multilevel branching logic for selection dependent inputs, that we think would be best to show to user progressively (i.e. we dont want to throw all the possible sub-options to the face of the user at once).

To demonstrate our design we unfortunately cannot disclose our real use cases, so for sake of an example lets assume we are doing an astronomical research software (disclaimer: I have little idea in astronomy), that allows searching for planets (which is very close in a way to what we are doing with our genomic research software).

Keeping in mind progressive disclosure and selection dependent inputs, we have came up with the following design:

Multi-level selection dependent inputs

Lets concentrate on the complex part of this search - Search in:. Here we actually have 3 levels of selection dependent inputs:

  1. Level 1: Choice of area unit - from Whole universe to single Planets
  2. Level 2: Subchoice of Galaxies and known Galaxy sets (that can contain e.g. 100 galaxies)
  3. Level 3: If Galaxies is selected, we can expand/narrow down the search in specified galaxies using Include radius... and Limit to approximity...

While user drills down from level 1 to level 3, vitality of the choice at the given level drops, we are visually changing how we show the choices. I.e. at level 3 the additional level 3 choice is moved to the right part of the screen, as it is not used frequently (most of the time galaxy/galaxy set is just fine). Clicking one of the links for level 3 choices gives somthing like this: Level 3 input added Now user can expand to look for planets not only in Milky Way but also in the nearby areas (e.g. some solar systems outside not strictly belonging to any galaxy)

Would that be appropriate strategy for designing the complex search to make sure users are not overwhelmed with the complex branching in the search and various additional filtering options for those subbranches?

  • I have updated the description to use more concrete example, representing the complexity of our real use-case. I have used an (fake) example of astronomical tool for planet search. Apr 4 '17 at 7:16
  • Will there always be three levels of filtering?
    – Sol
    Apr 4 '17 at 9:32
  • @Harshal Nope, e.g. Planets would contain just one searchable multi-select input. Apr 5 '17 at 13:49

Although it would be better to see sample values rather than dummy text in the wireframes, however, here are two suggestions depending upon the values/data that goes in the choices, and the user expectation -

1) Group the options 1-2-3 in an accordion styles menu. Something like this.

2) Alternatively, if the options are very limited against these choices, like three four, you could think of a nested dropdown of sorts. See image attached.

enter image description here

The important is to not overwhelm the user with an interface that has too much going on, and tried to show everything (related or not) upfront. You can think about taking him through the path that is most relevant to him/her and then supplementing the choices by a set of tags, as suggested by @uttham earlier, which serve as an indicator of the series of choices the user has made. (reference).

UPDATE (Apr 5 2017, Based on comments and more context)

Please find a quick design suggestion attached. As you already quoted Progressive Disclosure in your original question, this is aligned to the same principal. Generic users do not need all the choices laid out - and any fine tuning/detailed search is generally well accepted in an advanced search module. Also, you can try to be innovative and user friendly in designing the questions such that the user understands and inputs better. Note that using technology, you can make the system intelligent enought to understand what the user inputs. For example, as you see in the design, a choice of galaxy and galaxy set can be avoided - just by understanding the input user has given and mapping it to galaxy or a galaxy set name. Hope that helps!

enter image description here

UPDATE (Apr 6 2017, Based on comments and more context)

This comment keeps getting bigger!;)

Well, based on your comments - I have altered the solution a bit and this is the updated suggestion. Allows, user to use the accordion without necessarily selecting that section, and viewing the options. Using smart validation, and good tooltips - you can guide the user to fill in the needed values. If a section does not have extra choices (for e.g. solar system), then it does not necessarily expand. UI is just suggestive and a good one can certainly help a lot more.

enter image description here

  • Can you explain how 1) would be better than the radiobox approach in the mockup? Option 2) looks confusing - it does not immediately show that e.g. choices in Study Type were populated depending on selected choice in Search Terms. I am still not sure on how to make use of tags for the described problem, mockup would be great. Apr 3 '17 at 20:14
  • 1
    @MaximZavadskiy Could you possibly give some real life scenarios/examples to the choices? That will help to understand and comment better - and possibly do a quick mockup.
    – Amit Jain
    Apr 4 '17 at 5:00
  • updated - have fun with the planets :P Apr 4 '17 at 7:16
  • Thanks for wireframes - that is helpful now! I liked the idea of combining Galaxies+Galaxy sets into one input. But Advanced Search Options here seems wrong for me - when searching planets in Galaxies user must provide at least one galaxy/galaxy set, so its primary input when selecting Galaxies. Specify Radius looks nice and not very popping-out. How would you place it with *Limit to approximity to... filter, provided that they are self-exclusive? Apr 5 '17 at 14:00
  • @MaximZavadskiy Updated answer!
    – Amit Jain
    Apr 6 '17 at 9:19

everything is fine but in stage 3 you can improvise something like. giving tags directly in the input field rather than showing separately, which come over auto-complete. like

see the multiple -select feature in this page


and there should be provision to add custom tags by typing them.

  • Thx for the answer! Sorry, I don't see how tags related to my problem. Clicking filterin A or filtering B link in level 3 might append different inputs that might or might not use something like choosen.js library. Could you clarify your answer? Apr 3 '17 at 20:10

Your Answer

