Core Evolution - Preview Refactoring
Yudi
Short description: Current API in the Preview module provides too many granular methods and classes. It also lacks abstraction to how users may extend the component. We approach this problem by following a generalized visualization design model: Raw Data -> Data Tables -> Visual Structures -> Views. The interface structure in the Preview module should indicate how the API should be used. In this work, we aim to bring modularity and extensibility in the new Preview module implementation.
A. Problem description
The current Preview API in the Gephi project lacks flexibility required for ready extension; has too much structure, given the content (confounding code maintenance); and is hard to incorporate for use in other Gephi modules. In particular, the current design emphasizes performance over flexibility, whereas the inverse should be the case for Preview.
The general visualization toolkit infovis reference model for visualization is as follows:
Raw Data -> Data Tables -> Visual Structures -> Views. This model has been successfully adopted for other popular visualization applications, such as Prefuse (with which the applicant has conducted significant work). It is my understanding that the target implementation of Gephi Preview module is similar to this common visualization model.
My experience in the design of visualization tools (most notably, graph-based information visualization in Prefuse), and exposure another graph visualization framework (GUESS), combined with my strong background in software engineering and human-computer interaction, provides a solid foundation for completing this work. The focus on refactoring in this task draws on my SE background in refactoring medium-scale projects, particularly with respect to searation of concerns, identification of appropriate abstracts and modularity mechanisms, and the implementation of advanced concepts such as dynamic structures, property, and serialization. My HCI background will facilitate the identification of potential use cases, and the development and evaluation of solutions that support these use cases both for developers and users.
B. Implementation plan
The proposed implementation has three major components: Managing and developing the portions of the software responsible for processing raw data (including data support for building the components of the visualization), creating properties hooks for managing a wide variety of local or global characteristics, and the creation of clear interfaces for rendering the combination of the two previous components (with some possible extensions, discussed below). A more detailed implementation description follows:
1. In the first step of this work, I propose to develop and clean up the code for processing the raw data to be visualized. In many cases, these data will be classic graph objects (node, edge, etc.) from the Gephi graph, but there is some suggestion that a more flexible implementation is required. Part of this step will be determining what those further requirements might be and implementing them appropriately. The primary component in this step will be the builders, responsible for reading data stored in objects and translating it into data tables, and in turn supported by various type and data structures. This stage also involves the creation of an infrastructure to support the programmatic creation of visual items corresponding to data elements. I anticipate that this will significantly improve the flexibility and extendability of the current system.
2. Properties describe the structural components of visual items, most of which are expected to share common characteristics such as colors, borders, opacity, distortion, and enabling. Other kinds of visual items have more specific properties, such as convex-hull, which uses polygons to specify smoothness. Properties can also express environmental or global qualities, such as resolution or anti-aliasing. My proposed second implementation stage will involve the creation of properties hooks into existing visual items and a management system for changing properties, removing properties, and adding new ones. Specifically, the implementation will apply the operator pattern. Such mechanism contain a series of composable operations, which allow us to deconstruct visualization tasks into operators that can be configured at runtime. A single Operation object will have a reference to the visualization instance, as well as an run() method which perform specified operation to the visualization. The OperationSeq class is a composite of the Operations which applies the operations to specified groups.
1. In the first step of this work, I propose to develop and clean up the code for processing the raw data to be visualized. In many cases, these data will be classic graph objects (node, edge, etc.) from the Gephi graph, but there is some suggestion that a more flexible implementation is required. Part of this step will be determining what those further requirements might be and implementing them appropriately. The primary component in this step will be the builders, responsible for reading data stored in objects and translating it into data tables, and in turn supported by various type and data structures. This stage also involves the creation of an infrastructure to support the programmatic creation of visual items corresponding to data elements. I anticipate that this will significantly improve the flexibility and extendability of the current system.
2. Properties describe the structural components of visual items, most of which are expected to share common characteristics such as colors, borders, opacity, distortion, and enabling. Other kinds of visual items have more specific properties, such as convex-hull, which uses polygons to specify smoothness. Properties can also express environmental or global qualities, such as resolution or anti-aliasing. My proposed second implementation stage will involve the creation of properties hooks into existing visual items and a management system for changing properties, removing properties, and adding new ones. Specifically, the implementation will apply the operator pattern. Such mechanism contain a series of composable operations, which allow us to deconstruct visualization tasks into operators that can be configured at runtime. A single Operation object will have a reference to the visualization instance, as well as an run() method which perform specified operation to the visualization. The OperationSeq class is a composite of the Operations which applies the operations to specified groups.
C. Deliverables
- A working Preview plug-in module that can be easily extended and used
- A new API specification for Preview module
- A new Composable Property Hooks (Embedded in Preview)
- Color, Opacity Ops
- EdgeBundling Ops
- A new Processing Renderer
- ShapeRenderer
- PictureRenderer
- PolygonRenderer (Convex Hull)
- LabelRenderer
- EdgeRenderer
- A new exporter-adapter to export visualization to static form (PDF, PNG) from Processing.
- Proper documentation and tests for the above-mentioned components
D. TimeLine
Before April 20
- Familiarize myself with the previous implementation of the Preview Module
- Study project code style, specification, project configuration, and past use of Bazaar with respect to branching and merging, such that I am ready to contribute code to Gephi in Launchpad.
- Tool Setup, including Netbeans and Bazaar for Gephi contribution.
April 20 - May 23 (Before Official Coding start)
- Analyze current code base, identify and coordinate the details of code updates. Undertake small projects to verify theoretical assumptions.
- At this point I anticipate that I should have a thorough understanding of the problem and potential strategy for the solution. If not, this time will be spent securing that understanding and plan for a solution.
May 23 - June 18 (Official coding period starts)
- Define and layout the Preview API; have a working builder/item/renderer to allow users to try out the new API.
- Based on the current Preview UI, create a low fidelity prototype of the Preview UI using a third party drawing tool
June 18 - July 5
- Get feedback on the development on the API to this point and make improvements
- Core implementation for Renderer, Builder, and properties
JULY 6th MID TERM EVALUATION
July 6 - July 15
- Get feedback from community, improve code quality, bug fixes
July 15 - July 25
- Tests and bug fixes
July 25 - July 31
- Documentation