top of page

Query builder

The Project

Medallia survey's are very long. One survey can have 80 pages, but this doesn't mean than when you take one of our surveys, that you will have to answer 80 pages. Survey takers will only answer questions that are relevant to their transaction and their experience. That is, from those 80 pages the survey taker will end up answering only 8 or 9 pages.

​

To achieve this, questions or pages have to have a query that sets what characteristics of a survey taker have to be true for this question or page to appear in the survey.

Background
Research Current Situation

Worked together with a researcher and we interviewed several users from Medallia's Managed Services and observed them through the process of setting up the queries for the sruvey

Findings

Users of our application have to create all logic queries by hand. There is no UI that will help the user to build a query. Currently queries are added by hand in a text field

​

  • Creating queries is vey time consuming, it takes a managed services person weeks of back and forward communication with our clients to agree in the queries that need to be added to the survey.

  • Users don't posses enough knowledge of Boolean Algebra to be able to create efficient queries. Clients send the queries in plain english to users, who then had to translate those queries into Boolean Algebra.

  • Difficult to test

  • Difficult to find the right ID's of questions 

  • Users didn't know when to use parenthesis or bolean rules in general

This is the actual condition written in the condition field in the image below

​

(q_ar_rz_business_use = 2 or (q_ar_rz_business_use = 1 and (e_ar_rz_survey_sample = 2 or ((((((((((q_ar_rz_iphone = 1 or q_ar_rz_iphone_5s = 1) or q_ar_rz_iphone_5c = 1) and q_ar_rz_imac = 2) and q_ar_rz_macmini = 2) and q_ar_rz_macpro = 2) and q_ar_rz_macbookpro = 2) and q_ar_rz_macbook_air = 2) and q_ar_rz_ipad = 2) and q_ar_rz_ipad_mini = 2) and q_ar_rz_ipad_air = 2))))

Project

Create a query builder that would allow the user to add queries to pages and questions in survey builder

The following tasks should be supported 

 

  • Create new condition

  • Boolean operators AND / OR

  • Group conditions ( )

  • Nested groups ( ( ) )

  • Boolean Expressions: AND / OR / single Boolean Factor

    • Boolean Factors:

      • Parenthesis (nesting allowed): ( <Boolean Expression> )

      • Relational Expression: <, <=, >, >=, =, != (not equal)

      • Not Expression: not <Boolean Factor>

      • Is Present: <Field> present

      • Is Missing: <Field> missing

      • At Most Expression: at most <number> of { <Boolean Factor>, ... }

      • At Least Expression: at least <number> of { <Boolean Factor>, ... }

      • Boolean: TRUE / FALSE

      • Javascript: SCRIPT( ... )

Explorations

The first large exploration we did was by having a long text field where you could build your query. To start, you searched for the value you wanted to compare and once you find the value a card open where you could set the first element of your query. then you joined that element with AND or OR, and started to search again, and so on. you could group elements by dragging one into another

Built in Place

Findings:

  • Users did not understand where to start

  • Users couldn't group elements

  • Did not scale for more complicated queries, It got really complicated really fast

  • In general users found it confuising 

Side Panel to Search for Elements

Then we went in a different direction, we used a two panel modal, left panel used to search for your elements and right panel to build your condition. The ANDs and ORs worked as a toggle, each element appear first as a card where you could set the value of the element, and to group elements, you selected the elements you wanted to group, and then click the GROUP button and the new group would appear on its own card, you could name groups to facilitate the understanding of your condition.

​

Findings:

This query builder actually worked quite well. The users understood what they were doing but there was some confusion when they started to build the query. The main findings were:
 

  • Improved comprehension and success with queries with this exploration

  • Users missed seeing the "Untitled Condition" and failed to name it

  • Participants were confused with the left panel 

  • Unclear interaction with "delete selected", "group selected", and check boxes

Our final design

We ended up doing a vertical tree-like structure where the groups were indented and there were clear Call To Actions to add elements. The elements were searched in place with a searchable dropdown. Each element was in its own row and at the left there were actions for that row (nest, add below or delete)

Validation Research

Users were presented with the following boolean and asked to build it using the survey builder prototype.

 

(m_duplicate_code is present AND m_last_submitted_page_name = Page 04c - Receipt Entry 3) OR (q_receipt_expired_yn=true AND m_last_submitted_page_name = Page 04c - Receipt Entry 3)

 

The prototype was click through with some things hard coded e.g. we did not include the field picker. When a user clicked on a field, we automatically filled it in with the correct field.

​

Findings:

  • All 3 users were able to figure out how the condition builder worked

  • All 3 users had no issues with the NOT button

  • All 3 users commented that is easier picking the values in the expression as they shown the only available values for the field

bottom of page