| |
|
|
Status Report for Advanced User InterfacesMichael ShilmanHeloise Hwawen Hse Morley Mao ObjectiveThe goal of the Interact project is to provide tools and technology to facilitate rich information visualization, high-bandwidth human-computer interaction, and effective collaboration. User interfaces represent a bottleneck in current design systems: designers are faced with larger collections of data than ever before, more levels of abstraction, and significant collaboration challenges, yet little research has been done to deal with these problems. Drawing from the fields of information visualization, data mining, distributed systems, and virtual reality, we hope to set new paradigms for design management, navigation, and manipulation, and ultimately enhance the productivity of design engineers.Our goals for the previous quarter were to build applications on top of our core graph display API. This included visualizations of graph algorithms, hierarchical structures, and aspects of Java code development. These applications were recently demonstrated at the 1997 Design Automation Conference. In the development process, much of our exploratory prototype work has been generalized and folded back into a core API. An innovative and valuable result of this work is a powerful filter-based technique for the user to configure views on the data. Over the next quarter we will package the graph code into a complete API and release it as a visualization tool. We plan to add many features, including a standardized architecture for processes that modify the graph, more sophisticated filter functionality, and some support for graph layout. Detailed Description, Progress and StatusOur summer focus is graph display. Over the last quarter we have developed a robust infrastructure for displaying graphs of arbitrary domains and a flexible mechanism for conveying domain properties via filters. This technique scales to all sorts of problems in the CAD/CASE domains, and the package design will make it easy for users in all fields to visualize quantities and semantically-rich relationships in their problem domains. Our hope is that given the right interaction techniques and design decisions, this package can become a de facto standard for graph visualization, though there are several other existing packages which have a head start on us. The background of the graph package development is described in two documents:Filter-Based ArchitectureThe key feature of our package is its domain independence, the ability to intelligently display semantic information from any type of graph. We have devised a simple and modular means to utilize its display features through a Filter-based architecture (described below), in which Filters map domain-specific information from an application onto domain-independent "display axes" provided by our library, such as node position, size, shape, color, motion, transparency, etc. In this way we are able to enforce strong policy on top of flexible mechanism, making the package considerably easier to leverage without sacrificing any of the underlying flexibility. Many additional benefits (such as automatic creation of dialog boxes for Filter configuration, and a very clean and consistent user interface) are possible through this architecture.
In addition, the use of Filters provides the user with a much better interface to specify his view of a data set. In a space with many data axes and many display axes, a clean interface for setting up the display by layering filters allows the user to specify his view by parameterizing several operators on the scene, as opposed to a monolithic dialog box which details all of the display options. Layout FiltersLayout filters are filters which modify the positions of the nodes in the graph. While this is a simple part of the underlying graph API, the way in which to reveal this functionality to an individual application, let alone the user, is much less clear. For example, auto-layout of a graph by trying to minimize the number of edge crossings is a common way to improve the display of graphs and would make a nice filter to place on a graph. Yet a custom layout which provides a particularly meaningful positioning to display semantic properties of a graph partitioning algorithm is not necessarily something that the user would want to deal with; this might be written in a more application-integrated manner.Dynamic, Graphical Filter SpecificationFilters are currently written in C++ by deriving from a base class "Filter" which knows about the domain data and the display variables. Eventually, a more general form of filter construction will be possible in which the user is presented with a listing of all the available data types from the set he is viewing and all of the possible display options and can quickly choose a mapping that suits his needs. In addition he will be able to save and compose filters to make more sophisticated "views." Allowing the user to specify filters quickly and dynamically will result in better, more appropriate visualizations.To this end, we have embedded a Scheme interpreter in our library which allows for interpreted, scripted filters (a large improvement over compiled), and will greatly simplify the implementation of the graphical specification process. We are currently working towards an API in which adding functions to the interpreter is simple or even transparent to a user who is extending our library. Data VisualizationWe realize that although display of connected graphs and entity-relationship diagrams is semantically rich enough to cover a variety of applications, users may also wish to display raw data associated with any particular node or the whole system. For example a scatter plot, line graph, or bar chart might be more appropriate than a modification of the node color or shape. Thus we are also working on a "data visualization" extension (as opposed to "information visualization"), which will allow the users to specify display of charts via a consistent Filter-based interface.Active ProcessesActive processes are algorithms, tools, or other users who modify the data and therefore indirectly cause the view to change. . We have implemented several animations in application-specific ways, but a general solution is still in the works. A near-term goal is to provide high-level support for arbitrary animation of the graph. With the right design, this will significantly simplify the animation process for developers using the library.Driving ProblemsDriving problems demonstrate the usefulness of the library and help us validate our system architecture and test our implementation. The following driving problems are underway or have already been completed:
Future Plans and Projected MilestonesOver the next quarter we plan to focus on graph visualization, with the target of a library release at the end of summer. The steps toward this release include:
|
