Design of Query Languages and User Interface



next up previous contents
Next: Utilities to Support Up: THE USER INTERFACE: Previous: Discussion of Text

Design of Query Languages and User Interface

Query composition is most efficient when the user can learn from examples. The interface should provide a large number of templates representative of typical queries in a specific domain and allow the user to instantiate, compose, and modify existing templates in constructing new queries. For textual query composition, the user should be allowed to browse through valid ``forms'', or templates, and ``fill in the blanks.'' Similarly, graphical templates are useful for the browsing phase. In a face recognition system, for instance, various face templates and large samples of eyes, noses, mouths, etc. should be provided to assist the user in constructing a model. Furthermore, graphic drawing, painting, and morphing tools should permit the user to fine tune existing models or construct generic models for search and retrieval.

Once a graphic query is constructed, the user must specify rules and constraints to be used in matching. Generic constraints might include nodal constraints, such as the shape and size of a certain feature, and topological constraints, such as adjacency and neighboring relations of features. Matching rules specify how these constraints are used and the order of their applications. Generic rules include conditional statements (e.g. if-then-else), loops (e.g. repeat, while), and productions. These rules constitute a visual grammar that can be used for syntactic pattern recognition. Again, the interface should allow the user to specify syntactic pattern recognition rules and visual grammars in a graphical manner. Hence, we intend to formulate a rich repertoire of rules and methods for formulating visual grammars to realize such a graphically-based interface to pictorial databases.

At an advanced level, we will develop languages that allow the user to specify queries by providing their own examples (Query By Examples). For the relational model, such QBE languages already exist ([55]). However, significant extensions are necessary for applications involving texts, images, and maps, etc. Two approaches will be taken. First, we will extend the relational QBE languages to more sophisticated models that may include nested structures and may be object-oriented. This task is relatively easy since the required data structures and operations are mostly known and well studied. Second, we are developing a QBE language for geographical databases that permits easy expression of queries for 1-dimensional (e.g., texts), 2-dimensional (e.g., maps, images) data. It is conceivable that the approach can be generalized to data with higher dimensions. The language combines the techniques from the relational QBE languages, object-orientation, and geographical databases. retrieved. As an example, the user might select two cities, connect them with a line and require that ''each point on the line is a point on some road whose speed limit is at least 25 m.p.h.''; this will display all possible routes from one city to the other along roads with the required minimal speed limit.

We will use a three-tier framework for the design of the Alexandria user interfaces. The three steps will be interleaved, but warrant separation because each step requires distinct qualifications and expertise from the designers. The first step entails the investigation of various formal systems with well-defined behavior and properties to determine how well they address the problem. This process will uncover the pertinent objects, operations and behavior required of the user interface. In order to formalize the objects and operations that a user will need, designers must understand the problem domain and have sufficient knowledge of and practice with the formalization tools (e.g., specification languages, algebras); we therefore refer to the designers in this stage as the domain experts.

The second step will investigate alternative interaction procedures that allow prospective users to perform the intended manipulations. The formal specifications produced in the first step will provide a consistent foundation from which various user interfaces can be developed according to different interaction techniques, such as command-line, windows, and icons. The specifications of objects and operations identify the core functionality necessary for all the various user interfaces. Therefore, the evaluation of the user interface can focus on the different interface techniques. During the second phase, designers must be proficient in cognitive analysis, psychology, human-computer interaction techniques, and graphics art. This is the role commonly performed by the user interface designer. This phase will thus focus on the translation of the domain experts' specifications into a particular interface environment; it further involves providing feedback to the domain experts so that the formal specifications can be modified and improved to correct problems and/or reflect changing requirements.

The third step is to implement the visualization- and interaction-designs on specific platforms using their operating systems and user-interface management systems, toolboxes, graphics libraries, etc. This phase of the user interface design requires extensive expertise in user-interface programming, graphics packages, and user- interface management systems. We call these experts the user-interface software engineers.



next up previous contents
Next: Utilities to Support Up: THE USER INTERFACE: Previous: Discussion of Text



Ron Dolin
Wed Dec 7 23:25:02 PST 1994