a graphical filter/flow representation of boolean queries ... · fying boolean queries. in an...

A Graphical Filter/Flow Representation of BooleanQueries: A Prototype Implementation and Evaluation

Degi Young and Ben Shneiderman*Human-Computer Interaction Laboratory & Department of Computer Science, A. V. Williams Building,University of Maryland, College Park, MD 20742-3255

One of the powerful applications of Booiean ex-pression is to allow users to extract relevantinformation from a database. Unfortunately, previousresearch has shown that users have difficulty speci-fying Boolean queries. In an attempt to overcomethis limitation, a graphical Filter/Flow representationof Boolean queries was designed to provide userswith an interface that visually conveys the meaning ofthe Booiean operators (AND, OR, and NOT). This wasaccomplished by impiementing a graphical interfaceprototype that uses the metaphor of water flowingthrough filters. Twenty subjects having no experiencewith Boolean logic participated in an experimentcomparing the Booiean operations represented in theFilter/Flow interface with a text-oniy SQL interface.The subjects independently performed five compre-hension tasks and five composition tasks in each ofthe interfaces. A significant difference (p < 0.05) inthe total number of correct queries in each of thecomprehension and composition tasks was foundfavoring Filter/Flow.

Introduction

Much research and experience with Boolean retrievalsystems indicates clearly and repeatedly that Booleansearch formulation syntax and retrieval techniques arenot very effective in search performance and not very us-able or efficient search methods for end users. (Hildreth,1989)

Many attempts have been made to overcome the"Boolean bottleneck" in the use of fourth generationlanguages. These attempts include a linear text such asthat used in Structured Query Language (SQL), tabularstructures such as those used in Query By Example(QBE) and various other graphical representations (Jarke& Vassiliou, 1986; Reisner, 1988). However, despite these

•To whom all correspondence should be addressed. Ben Shneidermanis also a member of Ihe Systems Research Center.

Received November 25. 1992; revised February 22, 1993; acceptedFebruary 22, 1993.

© 1993 John Wiley & Sons, Inc.

attempts, extracting information using a Boolean query isoften too abstract for novice users and problematic for manyexperienced users.

Literature Review

In order for users to form queries using the lineartext approach, they must be familiar with Boolean logic(i.e., the logical operator AND, which is the intersectionof two conditions; the logical operator OR, which is theunion of two conditions; and the logical operator NOT,which is the negation of a condition). Equipped with thisknowledge users can extract information simply by typingthe query. Indeed, in an experiment using both secretariesand college business administration students, the subjectspreferred SQL to QBE, because of its structural approachand because fewer steps have to be made when forming aquery on the computer (Boyle, Bury, & Evey, 1983).

The difficulty of using the linear text approach lies inattaining the knowledge to form the query. One of thereasons for this difficulty is that novice users use termsthat they are familiar with (indeed the terms and and orare used often in natural language); but these terms takeon different meanings when used to form a query. Thus,when constructing queries in SQL, users tend to makeerrors because they resort to their knowledge of English.This result was noted in experiments conducted by Greene,Devlin, Cannata, & Gomez (1989); Michard (1982); andBoyle et al. (1983). One of the common mistakes usersmade was to substitute the AND logical operator for the ORlogical operator when translating an English sentence to alinear text query. Reisner, Boyce, and Chamberlin (1975)further noted that the subjects would insert words from theEnglish sentence into the SEQUEL or SQUARE query inplace of the correct table name, column name, or data value.

Another requirement of SQL further complicates theformation of queries. In order for users to form complexqueries, they must be familiar with the rules of precedenceand the use of parentheses. Michard (1982), Greene et al.(1990), Boyle et al.(1983), and others have indicated thatnovice users have difficulty using parentheses, in particularnested parentheses. Greene et al. went further to note that

JOURNAL OF THE AMERICAN SOCIETY FOR INFORMATION SCIENCE. 44{6);327-339, 1993 CCC 0002-8231/93/060327-13

an increase in the complexity of a query should not mean anincrease in the difficulty of the method of specification.

The tabular representations of Boolean queries makesome attempts at either reducing the use of Boolean logic(QBE) or eliminating the use of Boolean logic (Truth-table Exemplar-Based Interface ITEBI]). Users can formsimple queries in QBE by placing either variables orconstants on various sections of the table. Initial studiesconducted by Thomas and Gould showed that subjects madeaccurate decisions about simple "AND/OR" constructionsand seldom used the wrong values when they translatedEnglish sentences to form queries in QBE. Follow-upstudies conducted by Greenblatt and Waxman (1978) notonly reaffirm these findings but go a step further to indicatethat QBE is a superior language to either SQL or thealgebraic language that they used, in terms of leamabilityand application ease. Unfortunately, when forming complexqueries in QBE, users must invoke a condition box andexpress the complex query as a Boolean expression. Thedisadvantage of using Boolean expressions, in particularparentheses, that existed in the linear text, still exists inQBE. Furthermore, as indicated by an experiment con-ducted by Boyle et al. (1983), subjects have difficultyknowing how and when to use the condition box.

TEBI was designed and developed by Greene and others.It is a tabular representation of a query language that isvoid of the logical operators, parentheses, or fixed syntax.In order to form a query in TEBI, users must be able torecognize, rather than generate, the form of the query thatthey are interested in. This method serves users who areunsure of the query that they want to form and have the timeto establish an interactive form of communication with thecomputer. However, if users know what query they want toform, and their difficulty lies only in expressing the query,then this form of representation may not be desirable.

The advantages of using a graphical interface are nu-merous. For example, u.sers tend to complete their tasksquickly and accurately, feel less frustrated, and show fewersigns of fatigue. Unfortunately, as mentioned by Lundh andRosengren (1990), there exists some difficulty in expressingBoolean expressions graphically.

An attempt was made by Michard (1982), who usedVenn diagrams to show the operations on sets. In thisinterface, each chosen attribute is represented by a circleand users form queries by pointing at the desired portionof the intersecting circles. A human factors comparisonwas done between a linear text language called "TEST"and his Graphical Query Language. He used 12 collegestudents who had experience with basic Boolean algebraand the use of Venn diagrams. In his study he found thatsubjects performed better when they used the GraphicalQuery Language interface.

A graphical Boolean interface based on the relativepositions of tiles within a block structure was developedby Anick et al. (1990). Their interface deals only withintersection and union operations—negation and clusteringare not addressed. Furthermore, the implied semantics of

horizontal and vertical relationships between the tiles issometimes confusing and ambiguous, making it difficult toform certain queries.

The Filter/Flow Interface

Filter/Flow was designed to present the Boolean op-erators using a metaphor that graphically conveys themeaning of the operators. This concept originated fromShneiderman (1991). Similar to TEBI, this interface isvoid of the logical operators, parentheses, or any formof fixed syntax. However, unlike TEBI, this interface canbe used to generate queries and is graphical. In order touse Michard's Graphical Query Language, users must befamiliar with Venn diagrams and the operations that theyrepresent. Filter/Flow provides a novel conceptual modelof queries and was designed to help users formulate andexpress queries.

Description of FilterIFlow

Initially, the screen contains two scrolling lists. Thedatabase list is placed on the extreme left-hand side ofthe screen and the result list is on the extreme right-handside. The database list consists of the tuples of the initialdatabase, while the result list consists of the tuples thatsatisfy the query formed.

At the top of the screen, arranged horizontally, arebuttons that are used to represent the attribute names. In thisinterface, they are LOCATION, MANAGER, SALARY,TITLE, and MORE. The MORE button is used to indicatethat additional attribute names may exist.

At the bottom of the screen are the action buttons of theFilter/T low interface; they are labeled as NEW QUERY,CLEAR FLOW, FLOW, and QUIT (Fig. 1).

Users form queries by clicking on the attribute namebuttons. This causes the attribute menus to be displayedon the screen. The attribute menus may be dragged andplaced at various positions on the screen. Users click onthe attribute value to select the appropriate values. Byselecting the FLOW action button, users may view thelogical representation of the query that they formed in theform of water (displayed in blue) flowing through filters.The NEW QUERY button clears all the attribute menusand the flow that are displayed on the screen. The CLEARFLQW button clears only the flow displayed on the screenand leaves the attribute menus intact. The QUIT buttonenables users to exit Filter/Flow.

The Filter/Flow Operators

INTERSECTION OPERATOR (AND): In order to spec-ify an intersection two or more conditions are needed.A condition is indicated by selecting an attribute menuand selecting an attribute value within that menu. Theseattribute menus must be in different columns and there mustbe a flow that passes through both of the menus.

328 JOURNAL OF THE AMERICAN SOCIETY FOR INFORMATION SCIENCE—July 1993

FILTER / FLOW INTERFACE

MANAGES SALAKT TITLE MoreRESULTINGEMPLOYEES

LOCATION X

AlabamaB ahamas

DCGeorgia >

CLEAR FLO W FLOW J

BarbaraCatherineDebraEdnaElizabethGraceJosepViirwLauraPatricia

Copynghi © 18S1 Humm • Computer Interaction Laboratory. Unj/ersity o< Maryland All Riglits Reseived

FIG. 1. Intersection operator. Find the employees who are located in California that earn exactly 50,000.

For example, in Figure 1, both of the attribute menusare on the same row but in different columns. Graphically,the attribute menus are filters that restrict the flow of water.As the stream of water passes through the first attribute itloses its volume; the width of the water flowing out of thefilter is less than the width of the water flowing into thefilter. This representation indicates that only the tuples thatsatisfy the specified condition were allowed to pass through.The tuples that result in the first condition are applied asinput to the second condition. From these tuples, only thetuples that satisfy the second condition are of interest. Theresult consists of the tuples that have satisfied both the firstcondition and the second condition. This process can beextended to multiple conditions.

UNION OPERATOR (OR): There are two ways ofspecifying a union operation. The first method is acrossattribute menus and can be used in all union specifications.The second method is within attribute menus and can onlybe used for two or more attribute values within the sameattribute menu.

(1) Across attribute menus—A union operation be-tween attribute menus can be specified by placingthe attribute menus on different rows and ensuringthat there is a parallel flow to both conditions(Fig. 2). The flow from the initial database enterseach attribute menu with the same width. Thisindicates that the same number of tuples enter

the attributes. As the water flows out of each ofthe attribute menus, the volume of the water hasdecreased. Similar to the intersection operator, thisprocess is used to indicate the relative number oftuples that have satisfied the condition. In this casethere is a direct flow to the result list. Thus, eachcondition has been satisfied independently.

(2) Within an attribute menu—A union can also bespecified by two or more attribute values withinthe same attribute menu (Fig. 3). This indicates thatthe filter allows two or more specifications to besatisfied, each independent of the other. A tuple can,therefore, satisfy any of the specified altematives inthe attribute menu.

NEGATION OPERATOR (NOT): Users can specifynegation by selecting an attribute menu and initially choos-ing the attribute value that they do not want to satisfy. The"X" located on the upper right-hand side of the attributemenu deselects the selected attribute values and selects allvalues that were not selected; tuples that did not satisfy theoriginal query will satisfy the negation query and vice versa(Fig. 4).

COMBINATIONS: A combination of the above opera-tors may be used to form a complex query (Fig. 5).

CLUSTERS: Users may form more complex queries byclustering attributes on a menu. This results in an attributemenu that graphically displays a reduced view of the section

JOURNAL OF THE AMERICAN SOCIETY FOR INFORMATION SCIENCE—July 1993 329


INITIAL

EMPLOTEES

AVelloAndreaBarbara

BettyCarolineCathenneCindy

Degi

Edna

EvahneFionaFredaGrace

HarmahHardeepHildaJanetJoarmaJosephmeJudyKirtyLaura

1Bi

"i

Q n i TCgp/rlgtii © 1331 Hwn^i Interaction Laboratory, Urwersity at Maryldrii] AH RigHs Reser/ed

FIG. 2. Across attribute menus—union operator. Find the employees who are either managed by Degi or are Drivers.

that was selected. In so doing the relative position of eachof the attribute menus in the cluster are maintained. Furlher-more, attribute menus within the cluster that are negated aredisplayed in black. Users may create labels for the attributemenu representing the cluster and use it in the same manneras any other attribute menu. Il is possible, for example, tonegate the clustered attribute menu. The query representedin Figure 6 is a cluster representation of the query inFigure 5. The icons within the attribute menu represent theunion between the accountants or engineers managed byElizabeth and the clerks who earn more than 30,000.

Conventions of the Interface

This interface is a prototype; it is not based on afunctioning relational database. However, we believe thatan interface based on the Filter/Flow model that supportsall the features of a relational database model can beimplemented. In the design of the Filter/Flow prototype,some restrictions were made on the database schema aswell as on the visual representation. In a commercialimplementation:

(1) The Filter/Fiow model would have to accommo-date joins between multiple relations. Our mockupis based on a one relation database. Several ap-

proaches have been demonslrated to work effec-tively (IBM's DIS, 1990; Clark & Wu, 1992).

(2) Extended filters could apply graphical techniqueslo specification of attribute values {sec section on"Graphical Filters to Extend Attributable Means"for suggestions). In our mockup, the retrieval oftuples are based on selections from scrolling menus.

(3) Operations such as transitive closures and aggregatefunctions should be addressed (Clark & Wu, 1992).

(4) Computation of values within an attribute menu orequality across menus should be addressed.

(5) The representation of the width of water flowingthrough the filters should be dependent on the valuesfrom the actual database. In our mockup, we useda heuristic to determine the width.

Clearly, these features would lead to a more completerepresentation of database queries. We believe that theselimitations did not interfere with our objectives whichwere to explore an altemative method of formingBoolean queries.

Experimental Evaluation

Previous researchers emphasized the goal of discover-ing what features facilitate the understanding of Booleanqueries. In order to collect this evidence, an experiment



IHITIAL

JEMPLOTEESLOCATION MANAGER SALARY TITLE More --•>

AkelloAndreaBarbaraBettyCarolineCdthermCindyDebraDegiEdithEdnaEhaabethEvalmeFionaFredaGrace

HannahHardeepHildaJanet

JoannaJojephmeJudyKatvLaura

RESULTING

EMPLOYEES

QUIT

AndreaBettyCarolineCmdyDegiEvalmeFiona

HannahJoannaNancy

NmaRachaeiReenaRudySamrrneSusetteTrishaValarie

Cop^nght © 1991 Hurnan • CwTtpuier Interactim LaboraloTy, Unwerjitv of Maryland AH Rights Reserved

FIG. 3. Within an attribute menu—union operator. Find the employees who are located in either the Bahamas or Georgia.

was run to compare the Boolean operators used in SQLwith the implemented version of Filter/Flow.

Hypothesis

The analogy present in the Filter/Flow interface is ex-pected to enable users to predict the outcome of a query.This is due to the fact that they can relate their prior knowl-edge of the domain (water flowing through the filter[s])to that of the target {operation of Boolean queries). It isconjectured that using a Filter/Flow interface would enableusers to interpret a query correctly with higher frequencythan they would if they were to read the same query in SQL.

SQL is a language equipped with definite syntax rules,such as in-order application of "AND" and "OR" and prefixorder application of "NOT." It also requires parentheses tospecify the order of operation. In addition there is oftenan inconsistency in the use of the natural language "and"and "or" and the logical AND and OR as discussed in theliterature review. Filter/Flow is a language that replacesa linear structure with a two-dimensional visual image.There is no referral to natural language words and usersdo not use parentheses. Furthermore, the visual feedbackshould facilitate an accurate formation of the query. It isconjectured that users should be able to form more accuratequeries using a Filter/Flow interface.

Subjects

Twenty subjects (10 male and 10 female) respondedto advertisements posted at the University of MarylandCollege Park campus. The requirements for the subjectswere that they had some experience using a mouse and verylittle or no programming language experience. In additionto this, subjects who had used Boolean logic in any of theircourse work were excluded. The ages of the subjects rangedfrom 18 to 40, the majority of the subjects being in theirearly twenties.

Method

The subjects used an AT&T computer with a 80386processor running at 25 megahertz with a 17-inch VGAmonitor. Both the SQL and Filter/Flow interfaces were cre-ated using ToolBook on the same computer, thus ensuringthe same rate of response.

The independent variable in this experiment is the typeof interface (Filter/Flow or SQL). Subjects performed twotypes of tasks (comprehension and composition). The de-pendent variables are the number of correct queries and thenumber of errors made in each task. Subjects were giventwo similar query sets for each interface. The order in whichthe subjects viewed the two query sets varied. The order



IVITIAL

EMPLOYEES

AlcelloAndrea

CarofineCdtheimeCindyDetrraDegiEdithEdna

EvahneFionaFredaGrace

HarmahHardeepHildaJanetJoannaJosephineJudyKatiLaura

RESULTIHG

EMPLOYEES

AndreaBabaraBettyCatherineCarohncCindyDebraDegiElisabethEvalineFionaGakanyaGraceHannahJoannaJosephmeLauraNancyNatalieNrnaPatnciaRachaelReenaRudySammieSijzetteTrishaValarie

! ; • : ) ;

:i:i:i:i{|i

i'iii!

d1Copyright © 1931 Human - Comprrter Interaction Laboratory, Unr/ersity d Maryland AH Rights Reserved

FIG. 4. Negation operator. Find the employees who are not located in Hawaii.

in which the subjects viewed the two interfaces was alsoalternated. During the experiment resuits were not shownin either Filter/Fiow or SQL.

Training

A 15-20-minute training period was given for eachinterface. In the first five minutes the subjects were givenspecific tasks to perform on the computer, thus enablingthe subjects to become familiar with the medium that theywere about to use. For example, in SQL subjects wereasked to type in statements and, in Filter/Flow, subjectswere asked to use the mouse to select and drag boxes onthe screen. The remaining 10-15 minutes of the trainingperiod were spent going over the operations of Booleanlogic. The subjects were given two sheets of paper: aquestion sheet consisting of five queries, and an employeedata sheet. The first query consisted of a simple extraction,the second query introduced the concept of the intersectionoperator, the third query introduced the union operator, thefourth query introduced the negation operator coupled withthe intersection operator (in the case of SQL, parentheseswere introduced in this question), and finally the fifth queryconsisted of all the above operators.

The experimenter formed and interactively interpretedthe first four questions and asked the subjects to form andinterpret the final question. Since the final question con-tained all the Boolean operators, it served as an indicationas to whether or not the subjects had a basic understandingof the material presented. Subjects were free to ask anyquestions throughout the training period.

Tasks

The first task was Query Comprehension. In this task,subjects were given an employee database. The employeedatabase indicates the location, salary, title, and managerof 30 employees. The experimenter either typed in orconstructed a query (depending on the interface used) andthe subjects were required to indicate on a sheet of paperthe results of the query. In order to do this task, subjectsmust be familiar with the connotation of the operators usedin the query.

The second task was Query Composition. In this task,the subjects were given an English sentence and they had toform a query using either the SQL or Filter/Flow interface.The query was written on a piece of paper allowing thesubjects to refer to the query at any time. When usingSQL, subjects were provded with the stem of the query and

332 JOURNAL OF THE AMERICAN SOCIEP/ FOR INFORMATION SCIENCE —July 1993

INITIALEMPL07EES

Andrew

BettyCarolrneCdtherme

DebraDegiEfith

ElisabethEvaltneFiona

GraceGakonyaHannahHardeepHilda.Imet.loarnnaJosepbine

Lamra

QPIT I


LOCATION M&HAGEB S&LART TITLE More -->BESDLTINGEMPLOYEES

CLEAR FLO W FLOW

CarohneCindyFionaGakonyaTrisha

©lSSlHuman- Computer Irrteracticm Laboratory. Unrversity d Maryland. AH Rights Reseived

FIG. 5. Example of a complex query. Find the accountants or engineers from Georgia who are managed by Elizabeth, or the clerks fromGeorgia who make more than 30.000.

were asked to type in the "WHERE" condition. This taskis usually difficult, because it entails creating an expressionthat represents the query. Two examples of the compositionqueries that were asked are given below:

(1) I'd like to find the employees who are managedby Nancy. Please ensure that these employees don'tearn exactly 50,000 but they are lawyers.

(2) Nancy, with Degi's help, wrote a paper about Al-abama women in history. Degi talks to all heremployees about this paper. Nancy gave a seminarabout this paper to her employees who are fromAlabama. Nancy felt that this paper would be ofinterest to the historians she employs so she toldthem, too. Could you list all tbe people who haveheard about this paper?

The subjects always performed the comprehension task(consisting of five queries) followed by the compositiontask (consisting of five queries) using one of the designatedinterfaces and one of the designated query sets. Aftercompletion of the last composition query, subjects wereasked whether they wanted a break or not. If so, a five-minute break was taken. After that the subjects repeatedthe two tasks using the alternate interface and the alternatequery set.

After completion of all the tasks, subjects were askedfor their opinion of the two interfaces and the reasons fortheir preferences.

Experimental Results

Scoring. The total number of correct queries made byeach subject was collected and errors were noted. A 2 X 2ANOVA was done to compare the scores obtained in theFilter/Flow with that obtained in SQL and study the ordereffect. The null hypothesis was that there is no differencebetween the two interfaces.

Comprehension task: If the subject did not write downthe correct list of tuples then the answer was considered tobe wrong. The number of correct answers for each querywith each interface was noted (Table 2). The types of errorsmade were of interest; thus, the incorrect result lists wereexamined. A break down of the types of errors was notedfor each question (Table 4).

The Boolean errors were of special interest, so thenumber of Boolean errors was noted (Table 3). The Booleanerrors included:

(1) Interpreting the logical operators incorrectly, forexample, interpreting the union for an intersectionor the intersection for the union operation.

JOURNAL OF THE AMERICAN SOCIETY FOR INFORMATION SOIENOE—July 1993 333


INITIALEMPLOYEES

LOCATION MANAGER SALARY TITLE Une -> RESULTINGEMPLOYEES

AVelloAndreaBarbaraBettyCarolineCathermeCmdyDebraDegi

Edna

Evalme

FredaGrace

HannahHardeepHildaJanetJoaonaJosephineJydyKatyLauraLidvaLisa

QUIT

Alabama

1 Batiamas1 CaMcrma

|DC

Njx

Jn

• D

CarohneCmdyFionaGaVonyaTnsha

CLEAR F L O W ! FLOW

Copvriqbi © 1991 Human • Ccmipuier Irrteracticm Labcrraioi-y. Ufn>/er5ity of Maryland AH Rights

FIG. 6. Clustered attribute menu. Find the accountants or engineers from Georgia who are managed by Elizabeth, or the clerks fromGeorgia who make more than 30,000.

(2) Ignoring the order of precedence.

Composition task: In general syntactical errors were notcounted as wrong answers. For example, a missing quoteor a misspelled attribute name or value were consideredaccepted when the subject used SQL. There was an errorcheck procedure in Filter/Flow which would indicate thatthe flow was incorrectly specified, so the subjects hada chance to change this when they were forming theirquery. Since this was not the case in SQL, subjects werenot penalized for those types of errors. It is, of course,conceivable that a program could be implemented to cotrectsyntactical errors in SQL (Welty, 1985).

Every error made was counted. Thus, if a subject re-peated a mistake, that error was counted the number oftimes it was repeated. For example, in SQL, if the querycalled for an "A OR B OR C" structure and the subjectwrote "A AND B AND C," then two errors were made andthe error type was AND instead of OR (Table 5).

In noting the Boolean errors (Table 7), the definition ofthe Boolean errors had to be redefined. In this case theBoolean errors consisted of:

(1) Typing "AND" instead of "OR" or typing "OR"instead of "AND" in SQL. Placing the attributemenus on the same row instead of different rows or

placing the attribute menus on different rows insteadof the same row in Filter/Flow.

(2) Placing the parentheses in the wrong place or omit-ting the parentheses in SOL. Placing an attributemenu in the same column instead of the precedingcolumn in Filter/Flow.

(3) Forgetting to apply the negation as a preorder spec-ification SQL, or forgetting to specify the negationfilter.

Statistical Results. Comprehension task: There was asignificant difference in the number of correct answers forthis task favoring Filter/Flow [F(l, 18) = 12.9; p < 0.05J(Table 1).

Fewer Boolean errors were made in Filter/Flow thanwere made in SQL. The total nutnber of errors made inFilter/Flow was 12, of which nine were Boolean errors.In SQL, 28 errors were made, of which 25 were Booleanerrors (Tables 2 and 3).

TABLE 1.queries for

Filter/Flow

4.3 (0.87)

Means and standard deviationscomprehension task.

SQL

3.5 (0.95)

of number

F

12.9

of correct

P

0.02


TABLE 2. Number of correct queries in comprehension tasks.

Correct Queries

Query Filter/Flow SQL Query Expression

1 202 193 174 195 13

2018161412

Number of - .Correct QuaHes

86420

20 A n B n c16 (A U B) n C3 AU Bn C

19 A U -(B U C)14 ((A n B n-(C u D)) u (E n -F ) ) n G

1—••••••••••J—^MJ

••••••1—HJ

1•1—JHLJ

••••••

1—WMJ

•••••1—^B-.

Query 1 Query 2 Query 3 Query 4 Query 5

D Filler/Flow • SQL

The most common error occurred m the third question,where five subjects wrote the wrong answer in Filter/Flow,and 17 subjects wrote the wrong answer in SQL (Table 3).The main type of error for this question was that subjectsdid not use the rules of precedence to evaluate the results.Seventeen subjects did not use the rules of precedence inSQL, while only four subjects did not use the rules ofprecedence in Filter/Flow (Table 4).

The most incorrect answers per query in Filter/Flowwere in the fifth query (seven incorrect answers), wherethree subjects inverted the negation operation (i.e., allowing

tuples to go through rather than restricting them) (Tables 2and 4). Six incorrect answers were found in the fifth queryin SQL. Nine errors were made in the fifth query in SQL,and four of those nine errors were made when subjectsmisinterpreted the order of the parentheses (Tables 2 and4). Four Boolean errors were found in the fifth query inFilter/Flow and five Boolean errors were found in the fifthquery in SQL (Table 3).

Composition task: There was a significant differencebetween the number of correct queries in SQL and Fil-ter/Flow, favoring Filter/Flow [F(l, 18) = 65.8; p < 0.05](Table 5).

The number of correct queries was greater for everyquery in Filter/Flow than it was in SQL (Table 6).

Subjects made the most Boolean errors in the fifth query.Thirty-five enors were made in SQL and only seven errorswere made in Filter/Flow. Subjects made the least numberof Boolean errors in the first query in FiUer/FIow and theleast number of Boolean errors in the second query in SQL(Table 7).

The most frequent error type was the use of parentheses.A total of 50 parentheses errors were made in SQL, whileonly two errors were made in specifying the order of theattribute menus in Filter/Flow (Table 8). The most frequenterror made in Filter/Flow was the placement of attributeson the same row as opposed to different rows; the errorwas made nine times. However, this was less than thenumber of times the comparable error was made in SQL.In this case, the AND Boolean operator was used insteadof the OR operator; this error occurred 22 times (Table 8).Another rather frequent error type which occurred in SQLwas that subjects did not specify the attribute name. Thisoccurred 24 times. One subject did not negate an attributemenu in Filter/Flow, while four subjects used the negation

TABLE 3. Boolean errors in comprehension task.

Query

Number of Boolean Errors

Filter/Flow SQL Query Expression

02

1715

A n Bn c(A U B) n CA u B n c

A U -(B U C)({A n B n-<c u D)) u (E n -F) ) n G

Number orBoolean Errors

in Queries

Query 1 Query 2 Query 3 Query 4 Query 5

riltw/Flow SQL


TABLE 4. Comprehension error types.

Type of Error Interface Query 1 Query 2 Query 3 Query 4 Query 5 Total

Did not use rules of precedenceDid not use rules of precedenceAttribute menu on same row instead of on a different rowUsed logical "AND" instead of logical "OR"•Not applicableOrder of parenthesesInverted nieaning of negation operationApplied negation to one condition instad of two conditionsMisread sheetMisread sheetOther errorsOlher errors

Filter/FlowSQL

Fitter/FlowSQL

Filter/FlowSQL

Filter/FlowSQL

Filter/FlowSQL

Filter/FlowSQL

00000000000

n

000200001000

417

1000000000

000000111001

000004311331

417

1204423332

as a binary operator (applying to two operands) ratherthan a unary operator (applying to one operand) in SQL.There were nine unidentified errors in SQL, these errorswere unique to the individual subject. For example, somesubjects introduced terms that are not used in the SQL. Onesubject in Filter/Flow tried to use the within attribute menuspecification incorrectly when specifying a union (Table 8).

Subjective Satisfaction

At the end of the experiment, one subject told his friend:"It's fun man, go for it." That, coupled with the fact thatonly two subjects wanted to take a break after the firstinterface, showed some indication that the subjects enjoyedthe experiment in general. When asked to compare thetwo interfaces, all 20 subjects claimed that Filter/Flow waseasier to use than SQL. Indeed, when subjects attemptedthe training task in Filter/Flow, comments included "thisis fun" and "this is groovy." In SQL, when some of thesubjects were told that they would have to type, they madeapologetic claims about not being great typists.

When asked which interface they preferred, a few ofthe subjects looked as if this was a rather stupid questionand stated that it was Filter/Flow, of course. In fact, somesubjects did not need any prompting. After completing theFilter/Flow interface and in the middle of the SQL task, onesubject stated that she could see why SQL was left untilthe end, it was much harder. Another subject said that usingSQL reminded him of using the IBM where everything hasto be typed in, but when he used Filter/Flow it was likeusing the Mac where one can use the mouse to get a result.When forming a complex query in SQL, one of the pilotsubjects stated: "Gosh, I'm lost in bracket city." Overallthis subject felt more confident when she used Filter/Flow

TABLE 5. Means and standard deviations of number of correctqueries in composition task.

because she had visual feedback; when she used SQL shewas not sure that what she had done was correct.

A few subjects felt that SQL challenged them and wastherefore fun to use. In comparison to SQL they expressedthe opinion that Filter/Flow was definitely easier to use andrecommended it as a training tool. One subject stated thathe preferred the visual feedback and it was "neat" to watchthe water flow. In one extreme case, a subject started withFilter/Flow and, as he was doing the tasks, he seemed veryenthusiastic about the tasks, with an occasional smile assoon as he completed a query. He then switched to SQL andhalfway through the task, he asked what the operation ofthe "OR" was. He was then told that no further explanationscould be given because he had finished the trial task and hadstarted the experimental task. As he continued the tasks hebegan to show his displeasure by swearing. Gone was theoccasional smile and in its place was an occasional shrug ofacceptance. It was almost as if he was saying, "I don't know

TABLE 6. Correct queries in composition task.

Filter/Flow SQL

4.2 (0.98) 1.9 (L37) 65.8 0.00

Query

12345


Filter/Flow

2019151514

1816

12Number of ,„

Correct Queries

6420

••J H

Query 1

SQL

716484 A

1

u

L••••

—^UQiiei7 2

Query

'V n (Bi uA U

(A U(A n (B

n (B n (c

•1—HILJ

Expression

B2B)B)UU

.

11

U B3 U B4)

n-cn -cC)) U DD) U (E n F)

111 •

1 tQuery 3 Query 4 Querc 5

D Filter/Flow • SQL

336 JOURNAL OF THE AMERICAN SOCIETY FOR INFORMATION SCIENCE —July 1993

TABLE 7. Boolean errors in composition queries.

Query

12345


Filter/Flow

01547

SQL

104

231435

A r

A n

Query

"1 (Bl UA U

(A U

(An(B(B n {c

Expression

B2 U B3 UD1 1 1 ^^

B) n -<:i U Q) U D• U D) U (E

B4)

riF)

3 5 T

M

25

Nunbcr of 20Boolean Erron

in Queries 15

IS

5

0Query 1 Query 2 Query 3 Quay 4 Query 5

Filter/Flow SQL

if this is correct or not but this task has to be performed soI'm just going to do it." As he was reaching the end of theSQL task it dawned on him that if he used the concept ofFilter/Flow he might be able to form better queries. So hestarted drawing the structural flow on a piece of paper andturned around and said "I'm using the Flow thing to figurethis thing out." He decided to use the knowledge he hadattained from Filter/Flow to structure his answers in SQL.

DISCUSSION OF RESULTS

Comprehension Results

There were more correct answers in the comprehensiontask (160 out of 200) compared with the composition task(122 out of 200). When comprehending relatively simplequeries such as the first query, which consisted of threeconjunctions, subjects had little difficulty in either of the

two interfaces. Furthermore, subjects were able to solvequeries whose structure was similar to queries that theywere shown in the training session. However, when subjectswere given a unique query (i.e., a query whose form theyhad not seen before) they were able to solve the querymore accurately in Filter/Flow than in SQL. When usingSQL, subjects often failed to apply the rules of precedence;they would evaluate the queries on a left-to-right basis.Filter/Flow encourages this process; the flow is from left toright and the subjects evaluate the information from left toright and this representation results in the correct answer.

When interpreting complex queries, the major errormade by SQL users was the incorrect interpretation of theorder of parentheses. Some subjects did not know whichof the parenthesized expressions to solve first, especiallywhen the parentheses were nested.

Composition Results

Our findings suggest that one of the simpler structures toform in both interfaces was the combination of three inter-section operators and a negation of one of the terms. Thiscoincides with Michard's finding that the AND operator isthe easiest operator to use (Michard, 1982). In some caseswhile using SQL, subjects would place the two conditionsnext to each other, assuming that if they were together itmeant that these conditions were automatically intersected.

Subjects had little difficulty using the "within an" at-tribute representation of the union operator in Filter/Flow.However, they did have difficulty in forming a unionbetween several attribute values within an attribute in SQL.They made several attempts to shorten the specification ofthe query, including: not specifying the attribute names (orin one case using a different attribute name); not using theOR operator between the values; and using commas to listall the values.

The correct use of parentheses is essential if userswant to change the rules of precedence that apply to theBoolean operators. Users must be able to use parentheseseffectively if they want to express complex queries. Themajor error made with the SQL interface was the improper

TABLE 8. Composition error types.

of Error Interface Query 1 Query 2 Query 3 Query 4 Query 5 Total

Precedence of Filter/FlowMissing parentheses or parentheses in the wrong placeAttribute menu on same row instead of on a different rowUsed logical "AND" instead of logical "QR"Attribute menu on diflFerent rows instead of the same rowUsed logical "OR" instead of logical "AND"Did not negate attribute menusDid not use negation as a unary operatorMissing attribute menuDid not specify attribute labelUsed within specification of the union operator instead of betweenQther errors

Filter/FlowSQL

Filter/FlowSQL

Filter/FiowSQL

Filter/FlowSQL

Filter/FlowSQL

Filter/FlowSQL

060301000901

030010010002

2122712101203

072711001401

0225911032912

2509

2645144

2419


use of parentheses. In some cases, subjects would notuse parentheses; logical operators with a higher orderprecedence were thus bound together when the subjectsexpected the logical operators of lower order precedence tobe bound together. In the Filter/Flow experiment, subjectswere able to form complex queries easily by placingattribute menus in the preceding column and indicatingthe flow appropriately. Using Filter/Flow, the majority ofthe subjects were able to form queries that were twoparentheses levels deep but were unable to do so in SQL.

Errors made in SQL seem to indicate that if the subjectsare not sure how to express themselves, they will try torelate SOL to an English construct. This was evident bythe Booiean operators and by the syntax that they used. Forexample, in the first composition query, the subjects useda comma to indicate that they wanted to take the unionof the attribute values. Another common error was the useof "AND" instead of "OR" which coincides with previousstudies (Boyle et al., 1983; Reisner, 1988).

Subjective Satisfaction

There is good evidence that the subjects preferred usingFilter/Flow to SQL. They may have felt more confidentwith their answers, because they had a more effective visualfeedback to indicate when they were on the right track.The Filter/Flow representation appears to have helped thesenovices by providing a means to explore.

Experimental Limitations

The Filter/Flow interface is an implemented prototypethat was used to explore some of the issues that affect therepresentation of Boolean queries. Thus, in the evaluationof the Filter/Flow model some limitations and conventionswere made. For example, the experiment conducted wasbased on the comparison of specific Booiean queries in theFilter/Flow model with the SQL model. This experimentconcentrated on novice users performing two specific tasktypes (comprehension and composition) on a particularsingle relation database (i.e., the employee database basedon the attributes: title, manager, salary, and location).Further studies are warranted with alternative tasks, moreexperienced users, and different databases.

Future Research Directions

Interface Implementation

Our prototype for a Filter/Flow interface was static; thatis, the width of the flow was reduced by a fixed amount ateach attribute menu. In other words, to indicate intersection,the width was reduced a certain amount; while to indicatea convergence between two resulting operations, the widthof the largest operation was used as the resulting width. Adesign that is consistent with the data evaluated would vary

the width of the flow, dependent on the number of tuplesthat satisfy the query.

The graphical representation of the union between at-tribute menus was an inverted "L" structure. A betterrepresentation would have been a diagonal block or roundedcorners going from the initial attribute menu to the resultingattribute menus.

We conjecture that if the inversion of the values selectedwithin the attribute menu were blue (the same color as thewater fiow) instead of black, fewer subjects would havebeen confused about whether or not tuples were allowed topass through. Furthermore, in this prototype, the resultinglist of tuples is not shown.

Graphical Filters to Extend Attribute Menus. Therepresentation of the attribute menus in this interface wasbased on a scrolling list of menu items. More effectiveforms of representation for different values exist (Weiland& Shneiderman, 1993).

Specification of numerical values: When specifying nu-merical values, users may want to specify a range of valuesrather than an exact value; using sliders as a representationof a filter may be more suitable than a scrolling list. Usersmay specif a lower bound by placing the right arrowmarker on the designated value. Similarly, a left arrowmarker may be used to specify a higher bound (Fig. 7).Alternatively, users may want to specify computations ofvalues within an filter.

ScholarshipsInterestsTuitionSize ^Gender fT

OSpori3 0 Needs-b&sedSiWork-Study

Chicagor Pittsburgh *

ndi anapo 1 i s, Uashi ng ton" ^ ^

\ P ' >?

iNeu York

'Philadelphia

FIG 7. Mockup of a Filter/Flow boolean query. Find ((Interests =English or Literature or Journalism) AND ((Tuition greater thanor equal to $2200 or les.-i than or equal to $4500) OR ((Tuitiongreater than or equal to S5I00) AND (Scholarships are available byWork-Study or Assistantship)))) combined with map output to show theresult (Dartmouth, Grinnell, and the Univ. of Maryland).

338 JOURNAL OF THE AMERICAN SOCtETY FOR INFORMATION SCIENCE—July 1993

Specification of nonnumerical values: Check boxes orradio buttons may be used to specify a limited amount offixed values. For example, there are only a limited numberof options in the Scholarship attribute (Fig. 7), and theseare easily displayed as radio buttons. An alternative methodof specification may allow users to type in the appropriatevalue after receiving a prompt. For example, in the Interestsmenus, users can type in their interests (Fig. 7).

Specification of values within a geographical region:Users may select a specific map region with a mouse ortouch screen. Altematively, multiple regions may be chosenby specifying the appropriate areas.

Display of results on a geographic region: Figure 7shows how it might be applied to help students choosingcolleges. Users can select from the set of attributes and getan appropriate filter widget (type-in for interest areas, slid-ers for cost, and buttons for scholarships), which is placedon the screen with flow lines showing ANDs (sequentialflow) and ORs (parallel flows). The X in each filter widgetcould be selected to negate the filter values.

Experimental Design

It would have been interesting to spend additional timeon the more complex queries. Unfortunately, in order to getthe subjects to the level in which they could form complexqueries, they had to be guided through the simpler queriesfirst. A more thorough study of more complex queries mayresult in showing just how much the subjects understoodthe Filter/Flow interface.

The complexity of queries did not reach a level wheresubjects were forced to use the implemented clustering. Itmight be interesting to see whether the use of clusteringleads to better organization in the formation of queries withmore experienced users.

Acknowledgments

We appreciate the financial support of General Elec-tric Information Services and express our thanks to ourproofreaders: Dave Turo, Catherine Plaisant, Andy Sears,Dave Carr, Scott Gilkeson, Richard Chimera, and RichardPotter.

References

Anick, P.G., Brennan, J, D., Flynn, R, A,, Hanssen, D. R., Alvey, B.,Robbins, J, (1990), A direct manipulation interface for Booleaninformation retrieval via natural language query. Proceedings oftheACMSIGIR Conference 1990, 135-150,

Boyle, J,, Bury, K,, & Evey, R. (1983). Two studies evaluating learn-ing and use of QBE and SQL. In Proceedings of the Human FactorsSociety 27th Annual Meeting, (pp. 663-667). Santa Monica, CA:Human Factors Society,

Bury, K,, & Boyle, J. (1982). An on-line experimental comparisonof two simulated record selection languages. In Proceedings ofthe Human Factors Society 26th Annual Meeting, (pp. 74-78).Santa Monica, CA: Human Factors Society,

Clark, G.J., & Wu, C.T. (1992). DFQL: Dataflow Query Languagefor Relational Databases, Naval Postgraduate School, Departmentof Computer Science, Monterey, CA.

Greene, S., Devlin, S., Cannata, P., & Gomez. L, (1990). No IFs,ANDs, or ORs: A study of database querying. InternationalJournalMan-Machine Studies. 32, 303-326.

Greenblatt, D., & Waxman, J. (1978). A study of three database querylanguages. In B. Shneiderman (Ed.), Databases: improving usabilityand responsiveness. New York: Academic Press.

Hildreth, C. (1989). Intelligent interfaces and retrieval methods forsubject search in bibliographic retrieval systems. Library of Con-gress, Washington, DC,

IBM Data Interpretation System (DIS) user's guide, (1990), WhitePlains, NY: IBM.

Jarke, M,, & Vassiliou, Y, (1986). A framework for choosing adatabase query language. Computing Surveys, 17, 313-340.

Lundh, J., & Rosengren, P. (1990). Hybris—An ER-hased graphicalquery toot with an integrated data dictionary. Kista, Sweden: SISU,Swedish Institute for Systems Development.

Michard, A. (1982). A new database query language for non-professional users: Design principles and ergonomic evaluation.Behaviour & Information Technology, 13, 279-288.

Reisner, P., Boyce, R., & Chamberlin, D. (1975). Human factors eval-uation of two database query languages—square and sequel, ^ o -tional Computer Conference. Anaheim, CA: AFIPS, pp. 447-452.

Reisner, P. (1988). Query languages. In Helander, M. (Ed,), Hand-book of human-computer interaction, (pp. 257-280). Amsterdam:Elsevier/North-Holland.

Shneiderman. B. (1991). Visual user interfaces for information ex-ploration. In Proceedings of the 54th Anntml Meeting of the Ameri-can Society for Information Science, (pp. 379-384). Medford, NJ:Leamed Information Inc.

Thomas, J.. & Gould, J. (1975), A psychological study of query byexample. National Computer Conference, Anaheim, CA: AFIPS,44, pp. 439-445,

Weiland, W. & Shneiderman, B. (1993), A graphical query inter-face based on aggregation/generalization hierarchies. InformationSystems (to appear, 1993).


a graphical filter/flow representation of boolean queries ... · fying boolean queries. in an...

Documents