Browse Prior Art Database

Method of Implicit Specification of Operators and Syntax to Simplify the Creation of Complex Boolean Expressions Disclosure Number: IPCOM000012863D
Original Publication Date: 2003-Jun-04
Included in the Prior Art Database: 2003-Jun-04
Document File: 4 page(s) / 44K

Publishing Venue



This publication discusses a user interface method that allows the creation of simple or complex boolean expressions without requiring the user to explicitly type text-based statements with AND and OR operators, special keywords, paired parentheticals, or comma delimiters. This method has been implemented in IBM WebSphere Everyplace Access (WEA) software as part of Everyplace Synchronization Server (ESS), a component of which provides filtering capabilities for client-server synchronization of mail, contacts, tasks, events, and memos. Prior to the implementation of the user interface described herein, the user created these filters by writing boolean expressions. This technique was shown to be extremely error-prone in user interface evaluations, with very few users demonstrating success in creating even a simple filter. Using the technique of this publication, filters were correctly created at a success rate near 100 per cent.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 4

  Method of Implicit Specification of Operators and Syntax to Simplify the Creation of Complex Boolean Expressions

  This user interface method allows a user to configure all the possible combinations for an ESS filter without relying on the explicit creation of boolean expressions as text. Historically, the creation of even relatively simple filters in this manner was found to be error-prone. For example, to filter unread email from two users, Bill and Sarah, the boolean expression would be: AND(read=f, OR(from=Bill, from=Sarah)). Most users would have typed AND(read=f, from=Bill, from=Sarah), because receiving unread mail from both Bill and Sarah is the desired goal. Obviously, there cannot be two senders of an email, but that is the way that the incorrect boolean statement would have been interpreted by ESS. Adding an additional requirement to this filter increases the expression immensely. For example, if a user wants to filter unread email from two users named Bill and Sarah and also wants high priority email from anyone, then the boolean expression becomes: OR(AND(read=f, OR(from=Bill, from=Sarah)), priority=high). These common filters become a very complex boolean expression that most users would have extreme difficulty creating.

The fundamental art in this publication is that OR operators are created separately and differently from AND operators. Consequently, there are two user interface panels required to create filters. The first panel allows the user to view or edit a list of filters and to create a filter to add to this list. All filters that appear in this list are additive. That is, these filters behave as though an OR operator exists between each of them. For example, to filter unread email from Bill and Sarah and high priority email, the user creates two different filters. These two filters, shown in Figure 1, are listed on this first panel and can be edited by clicking on the filter name.


Page 2 of 4

Figure 1. User interface panel listing filters created for email. Filters that appear in this panel behave as though a boolean OR operator exists between them.

When the user edits or creates a new filter, the second panel is presented. In this second panel, shown in both Figures 2 and 3, the user is given numerous options with which to specify the filter. The filter that is created...