https://infovis-wiki.net/w/api.php?action=feedcontributions&feedformat=atom&user=AnfeInfoVis:Wiki - User contributions [en]2026-05-11T11:05:58ZUser contributionsMediaWiki 1.45.3https://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10406The InfoVis Toolkit2006-08-20T16:51:05Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/TableTimeSeries.png Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/GraphNodeLink.png Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was set to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type as columns and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single tubles or records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, realization of own complex [[Information Visualization|visualizations]] which require a lot of special functionality may be hard work and enforces developer to understand the internal structure of the toolkit itself. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure.png|400px]]<br />
<br />
The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are described with attributes. Each used attribute is associated with a certain ''Column'' of the ''Table''. Further, an ''ItemRenderer'' provides the painting routines of an item. After all items are layouted, the resulted shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no need to use this panel, also other targets like a ''BufferedImage'' or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the visual content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combine several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table''. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers like vectors or hashtables. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table.png|700px]]<br />
<br />
Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.<br />
<br />
As an array is indexed, the table itself has indexes too. The index is used to access the data records, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with the index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by layout algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when it is required. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on the visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that indicate the actual state of an item.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But, the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed. Nevertheless, many included examples are buggy or partially not runable anyway. When using a predefined sample, an exact testing is necessary.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10405The InfoVis Toolkit2006-08-20T16:31:15Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/TableTimeSeries.png Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://ivtk.sourceforge.net/GraphNodeLink.png Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was set to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type as columns and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single tubles or records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, realization of own complex [[Information Visualization|visualizations]] which require a lot of special functionality may be hard work and enforces developer to understand the internal structure of the toolkit itself. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure.png|400px]]<br />
<br />
The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of an item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table''. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table.png|700px]]<br />
<br />
Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.<br />
<br />
As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by layouting algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when needed. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that indicates the actual state of an tuple.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But, the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed. Nevertheless, many included examples are buggy or partially not runable anyway. When using a predefined sample, an exact testing is necessary.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10404Prefuse2006-08-20T12:48:36Z<p>Anfe: /* Conclusion */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://prefuse.org/gallery/fisheyemenu/ Fisheye Menu], [http://prefuse.org/gallery/radialgraphview/ Radial Graph], [http://prefuse.org/gallery/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even if the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual elements of the ''Visualization''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually by a user or automatically by the ''Visualization''. Once such a list is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to repaint themselves. <br />
<br />
The ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a separate coordinate system. View coordinates are described through an affine transformation matrix. Any navigation technique applied to the view only concerns the view coordinate system. The most important functionalities to work with this coordinate system are already predefined. Typically, users just have to apply whished techniques without considering technical details like the view coordinate system. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Databases. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data-type and table. That means, each row contains a data record, and each column contains values for a named data field with a specific data-type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table, also a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains the abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like colors, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Renderer'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionalities to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' disdinguishes automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be assigned to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argument for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization.] In CHI 2005, Human Factors in Computing Systems, 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java. Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10403Prefuse2006-08-20T12:47:23Z<p>Anfe: /* User Interactions */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://prefuse.org/gallery/fisheyemenu/ Fisheye Menu], [http://prefuse.org/gallery/radialgraphview/ Radial Graph], [http://prefuse.org/gallery/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even if the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual elements of the ''Visualization''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually by a user or automatically by the ''Visualization''. Once such a list is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to repaint themselves. <br />
<br />
The ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a separate coordinate system. View coordinates are described through an affine transformation matrix. Any navigation technique applied to the view only concerns the view coordinate system. The most important functionalities to work with this coordinate system are already predefined. Typically, users just have to apply whished techniques without considering technical details like the view coordinate system. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Databases. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data-type and table. That means, each row contains a data record, and each column contains values for a named data field with a specific data-type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table, also a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains the abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like colors, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Renderer'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionalities to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' disdinguishes automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be assigned to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization.] In CHI 2005, Human Factors in Computing Systems, 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java. Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10402Prefuse2006-08-20T12:44:17Z<p>Anfe: /* Package Structure */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://prefuse.org/gallery/fisheyemenu/ Fisheye Menu], [http://prefuse.org/gallery/radialgraphview/ Radial Graph], [http://prefuse.org/gallery/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even if the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual elements of the ''Visualization''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually by a user or automatically by the ''Visualization''. Once such a list is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to repaint themselves. <br />
<br />
The ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a separate coordinate system. View coordinates are described through an affine transformation matrix. Any navigation technique applied to the view only concerns the view coordinate system. The most important functionalities to work with this coordinate system are already predefined. Typically, users just have to apply whished techniques without considering technical details like the view coordinate system. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Databases. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data-type and table. That means, each row contains a data record, and each column contains values for a named data field with a specific data-type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table, also a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains the abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like colors, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Renderer'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionalities to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization.] In CHI 2005, Human Factors in Computing Systems, 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java. Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10401Prefuse2006-08-20T12:42:37Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://prefuse.org/gallery/fisheyemenu/ Fisheye Menu], [http://prefuse.org/gallery/radialgraphview/ Radial Graph], [http://prefuse.org/gallery/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even if the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual elements of the ''Visualization''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually by a user or automatically by the ''Visualization''. Once such a list is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to repaint themselves. <br />
<br />
The ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a separate coordinate system. View coordinates are described through an affine transformation matrix. Any navigation technique applied to the view only concerns the view coordinate system. The most important functionalities to work with this coordinate system are already predefined. Typically, users just have to apply whished techniques without considering technical details like the view coordinate system. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Databases. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data-type and table. That means, each row contains a data record, and each column contains values for a named data field with a specific data-type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table, also a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains the abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like colors, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Renderer'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization.] In CHI 2005, Human Factors in Computing Systems, 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java. Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Pan&diff=10389Pan2006-08-02T16:29:00Z<p>Anfe: </p>
<hr />
<div>Panning is an interaction technique that helps to navigate within a view. Instead of using a bounded view, an user interface that supports panning typically has no bounds. That means, it is possible to navigate in any direction without limitations given through bounds. Mostly, navigation with panning is realized by dragging the mouse above a view and the view goes along with the mouse movements.<br />
<br />
See also: [[Scroll]]<br />
[[Category: Glossary]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Monolithic_design&diff=10388Monolithic design2006-08-02T16:28:12Z<p>Anfe: </p>
<hr />
<div>Generally, a monolithic design is given when a software provides its functionality centralised in one or just a few classes. Such classes are very powerful and typically easy to apply.<br />
<br />
Such a design does not need a complex architecture with a deep class structure though inheritances. Developer typically will not have troubles to conceive the software as only a few elements must be studied in detail (exept the top-level class is very complex). Further, such an approach typically ensures fast results when applying the software. This is obtained as such implementations typically do not provide excessive functionality, instead, they are specialized on a limited count of features that may be applied easily. <br />
<br />
However, in case of providing a lot of functionality such an approach may lead to unclear or sleazy code as there is no clear separation to other areas of the software. Further, it is hard to manipulate or change existing code, also extensions may be hard to realize. So, developers are well advised to implement more flexible code when a certain dimension of functionality is reached.<br />
<br />
In visualization a software is called monolithic when abstract data, visual structures, and rendering routines are not separated explicity.<br />
<br />
See also: [[polylithic design]]<br />
[[Category: Glossary]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Polylithic_design&diff=10387Polylithic design2006-08-02T16:28:02Z<p>Anfe: </p>
<hr />
<div>Generally, a polylithic design is given when a software provides a high count of different classes. Each class provides only a few functionality. These separated classes which are consolidated through several programming techniques like inheritance or generic concepts. <br />
<br />
A lot of separations allow developers to change or manipulate existing functionality selectively. Furthermore, a high abstraction of objects forces developer to implement well thought components which may also work correct when other components have changed. Typically, this results a clear, flexible, and elaborate architecture. Further, to code of single classes is less complex.<br />
<br />
Nevertheless, the large count of objects may also lead to not considered mistakes and makes it harder to understand the software. Further, the separation between objects can exceed a normal dimension. In case of too many classes developers will have problems in conceiving the whole architecture. Especially generic concepts (e.g., reflection) must applied very carefully as external developers often have no insight in such concepts. <br />
<br />
In visualization, especially the separation between abstract data, visual structures, and rendering routines is defined as polylithic design.<br />
<br />
See also: [[monolithic design]]<br />
[[Category: Glossary]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Polylithic_design&diff=10381Polylithic design2006-07-31T09:49:55Z<p>Anfe: </p>
<hr />
<div>Generally, a polylithic design is given when a software provides a high count of different classes. Each class provides only a few functionality. These separated classes which are consolidated through several programming techniques like inheritance or generic concepts. <br />
<br />
A lot of separations allow developers to change or manipulate existing functionality selectively. Furthermore, a high abstraction of objects forces developer to implement well thought components which may also work correct when other components have changed. Typically, this results a clear, flexible, and elaborate architecture. Further, to code of single classes is less complex.<br />
<br />
Nevertheless, the large count of objects may also lead to not considered mistakes and makes it harder to understand the software. Further, the separation between objects can exceed a normal dimension. In case of too many classes developers will have problems in conceiving the whole architecture. Especially generic concepts (e.g., reflection) must applied very carefully as external developers often have no insight in such concepts. <br />
<br />
In visualization, especially the separation between abstract data, visual structures, and rendering routines is defined as polylithic design.</div>Anfehttps://infovis-wiki.net/w/index.php?title=Monolithic_design&diff=10380Monolithic design2006-07-31T09:40:44Z<p>Anfe: </p>
<hr />
<div>Generally, a monolithic design is given when a software provides its functionality centralised in one or just a few classes. Such classes are very powerful and typically easy to apply.<br />
<br />
Such a design does not need a complex architecture with a deep class structure though inheritances. Developer typically will not have troubles to conceive the software as only a few elements must be studied in detail (exept the top-level class is very complex). Further, such an approach typically ensures fast results when applying the software. This is obtained as such implementations typically do not provide excessive functionality, instead, they are specialized on a limited count of features that may be applied easily. <br />
<br />
However, in case of providing a lot of functionality such an approach may lead to unclear or sleazy code as there is no clear separation to other areas of the software. Further, it is hard to manipulate or change existing code, also extensions may be hard to realize. So, developers are well advised to implement more flexible code when a certain dimension of functionality is reached.<br />
<br />
In visualization a software is called monolithic when abstract data, visual structures, and rendering routines are not separated explicity.</div>Anfehttps://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10379The InfoVis Toolkit2006-07-31T09:28:11Z<p>Anfe: </p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://www.rsmas.miami.edu/environment/wx/time-series-cstars.pl Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://www-2.cs.cmu.edu/%7Esage/Papers/CHI90/DC.figure6.gif Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was paid to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type a column should map and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, the toolkit seems not be suitable to realize own complex [[Information Visualization|visualizations]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data sources. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure.png|400px]]<br />
<br />
The proper functionality of the toolkit is maintained by an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of an item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each Java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating mapped columns of the ''Table'', by manipulating ''Renderers'', or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table''. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table.png|700px]]<br />
<br />
Several ''Columns'' to map standard types like Strings or Integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. Therefore, a tuple in the table is composed of several differnt objects that may contain own data again.<br />
<br />
As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by layouting algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when needed. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' have changed, new ones were inserted, or existing ones were deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on visual attributes of the ''Visualization''. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, components to set filter expressions, or handler to select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
Note, that interactions in the '''InfoVis ToolKit''' may change columns in the underlying table. Further, the table is also used to store flags that indicates the actual state of an tuple.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But, the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed. Nevertheless, many included examples are buggy or partially not runable anyway. When using a predefined sample, an exact testing is necessary.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_structure.png&diff=10319File:Infovis toolkit structure.png2006-07-28T23:05:47Z<p>Anfe: /* Summary */</p>
<hr />
<div>== Summary ==<br />
The picture shows the internal structure of the InfoVis Toolkit.<br />
<br />
== Copyright status ==<br />
<br />
== Source ==<br />
[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_table.png&diff=10318File:Infovis toolkit table.png2006-07-28T23:05:30Z<p>Anfe: /* Summary */</p>
<hr />
<div>== Summary ==<br />
The picture shows the hierarchy of tables and columns in the InfoVis Toolkit.<br />
<br />
== Copyright status ==<br />
<br />
== Source ==<br />
[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_table.png&diff=10317File:Infovis toolkit table.png2006-07-28T23:05:06Z<p>Anfe: /* Source */</p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
<br />
== Source ==<br />
[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_structure.png&diff=10316File:Infovis toolkit structure.png2006-07-28T23:04:17Z<p>Anfe: /* Source */</p>
<hr />
<div>== Summary ==<br />
<br />
The picture shows the internal structure of the InfoVis Toolkit.<br />
<br />
== Copyright status ==<br />
<br />
== Source ==<br />
[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_structure.png&diff=10315File:Infovis toolkit structure.png2006-07-28T23:03:51Z<p>Anfe: </p>
<hr />
<div>== Summary ==<br />
<br />
The picture shows the internal structure of the InfoVis Toolkit.<br />
<br />
== Copyright status ==<br />
<br />
== Source ==</div>Anfehttps://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10314The InfoVis Toolkit2006-07-28T23:02:43Z<p>Anfe: </p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://www.rsmas.miami.edu/environment/wx/time-series-cstars.pl Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://www-2.cs.cmu.edu/%7Esage/Papers/CHI90/DC.figure6.gif Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was paid to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type a column should map and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, the toolkit seems not be suitable to realize own complex [[Information Visualization|visualization]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data records. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure.png|400px]]<br />
<br />
The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating visual attributes of the ''Visualization'', by manipulating ‘’Renderers’’, or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table'' and used to fill it or write its content back to the file system. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table.png|700px]]<br />
<br />
Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. <br />
<br />
Following this way, a table can contain each possible data. As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by lay outing algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when needed. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' are changed, new ones are inserted, or existing ones are deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on the visual attributes. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, set filter expressions to restrict the visual content, or select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10313The InfoVis Toolkit2006-07-28T23:02:19Z<p>Anfe: </p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://www.rsmas.miami.edu/environment/wx/time-series-cstars.pl Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://www-2.cs.cmu.edu/%7Esage/Papers/CHI90/DC.figure6.gif Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was paid to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type a column should map and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, the toolkit seems not be suitable to realize own complex [[Information Visualization|visualization]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data records. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure.png|600px]]<br />
<br />
The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating visual attributes of the ''Visualization'', by manipulating ‘’Renderers’’, or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table'' and used to fill it or write its content back to the file system. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table.png|600px]]<br />
<br />
Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. <br />
<br />
Following this way, a table can contain each possible data. As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by lay outing algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when needed. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' are changed, new ones are inserted, or existing ones are deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on the visual attributes. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, set filter expressions to restrict the visual content, or select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_table.png&diff=10312File:Infovis toolkit table.png2006-07-28T23:01:29Z<p>Anfe: </p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
<br />
== Source ==</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovis_toolkit_structure.png&diff=10311File:Infovis toolkit structure.png2006-07-28T23:00:01Z<p>Anfe: </p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
<br />
== Source ==</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Infovisstructure.png&diff=10310File:Infovisstructure.png2006-07-28T22:58:03Z<p>Anfe: </p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
<br />
== Source ==</div>Anfehttps://infovis-wiki.net/w/index.php?title=The_InfoVis_Toolkit&diff=10309The InfoVis Toolkit2006-07-28T22:57:10Z<p>Anfe: </p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jean-Daniel Fekete / University Paris-Sud<br /><br />
'''Project Webpage''': http://ivtk.sourceforge.net<br /><br />
'''Current Version''': 0.9 beta2, July 24, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
<br />
''' Base data structure''': table of columns; columns contain objects of equal type; trees and graphs are derived from tables<br /><br />
''' Included visualization techniques:''' [http://www.itl.nist.gov/div898/handbook/eda/section3/scatterp.htm Scatter Plot]<nowiki>; </nowiki>[http://www.rsmas.miami.edu/environment/wx/time-series-cstars.pl Time Series Plot]<nowiki>; </nowiki>[http://catt.bus.okstate.edu/jones98/parallel.html Parallel Coordinates]<nowiki>; </nowiki>[http://www-2.cs.cmu.edu/%7Esage/Papers/CHI90/DC.figure6.gif Node-Link Diagram]<nowiki>; </nowiki>[http://www.sims.berkeley.edu/courses/is247/s02/readings/barlow.pdf Icicle Tree]<nowiki>; </nowiki>[http://www.cs.umd.edu/hcil/treemap/ Treemap]<nowiki>; </nowiki>[http://en.wikipedia.org/wiki/Adjacency_matrix Adjacency Matrix ]<br /><br />
''' Supported File Formats''': CSV, XML, TQD, Newick, TM3, DOT, XML TreeML, XML GraphML<br /><br />
<br />
<br />
The '''InfoVis Toolkit''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of [[Information Visualization]]s which are based on a high amount of data. To provide a fast and efficient processing of these data, special attention was paid to the underlying data structure. As the internal structure of the '''InfoVis Toolkit''' considers the [[Visualization Pipeline]], a data table was chosen to store all information. A table allows representing nearly every kind of data. Also interrelations between records can be established by using parent and children columns. The '''InfoVis Toolkit''' supports a graph structure as well as a tree structure.<br />
<br />
Generally, the table was optimized regarding to memory footprint and data access speed. This was obtained by using arrays of the respective type a column should map and metadata which describes the column itself. In contrast to other implementations of tables (e.g., Java Swing Table) this approach provides a measurable advantage in memory usage and access performance. But, these performance enhancements are paid with less comfort in using the table and handling single records in it. <br />
<br />
The design of the '''InfoVis Toolkit''' can be seen as [[polylithic design|polylithic]]. Even though the [[Visualization Pipeline]] is considered internally, nevertheless, there are no clearly defined points in the logic where a user can place its own functionality (in contrast to other toolkits like [[prefuse]] for example). Applying own filters or rendering routines may enforce deep changes in the base functionality. Furthermore, the class hierarchy is very deep and complex. So, even small extensions of the predefined functionality may cause a lot of adaptation work in several classes. <br />
<br />
However, the toolkit seems not be suitable to realize own complex [[Information Visualization|visualization]] which requires a lot of special functionality. But, there are a lot of predefined visualization techniques that help to visualize data in a common way like scatter plots or treemaps. The toolkit provides a lot of examples that illustrate the appliance of such standard visualization techniques to own data records. <br />
<br />
=== Pros ===<br />
<br />
* low memory usage<br />
* fast data access, only a few typecasts are needed<br />
* metadata to describe columns and tables<br />
* internal pipeline approach<br />
* many visualization techniques included<br />
* several data reader for common formats included<br />
* algorithms for force-based physics simulation included<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* open source<br />
<br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* missing expected functionality (e.g., a row object in tables)<br />
* special requirements of visualization enforce a lot of adapting work<br />
* the design is hard to conceive, the logic not clear<br />
* no clear points defined to place own code<br />
* poor documentation<br />
* no user community <br />
* most examples are buggy (especially controls)<br />
<br />
=General Approach=<br />
<br />
An [[Information Visualization]] done with the '''InfoVis Toolkit''' is based on a table which stores the abstract data:<br />
<br />
[[Image:infovis_toolkit_structure|600px]]<br />
<br />
The proper functionality of the toolkit is combined in an object called ''Visualization''. This component is responsible for transforming the abstract data of the ''Table'' to visual analogues. The associations between abstract content and visual analogous are declared by visual attributes. These attributes can be associated with a certain ''Column'' of the ''Table''. Further, an associated ''ItemRenderer'' provides the painting routines of the item. After the items are layouted, the resulting shapes are stored in the ''ShapeColumn'' within the ''Visualization''.<br />
<br />
The view of a visualization done with the '''InfoVis Toolkit''' is the ''VisualizationPanel''. This graphical component can be embedded in each java Swing application. However, there is no force to use this panel, also other targets like an image or a standard ''JComponent'' can be taken to communicate the output to the user.<br />
<br />
Controlling of the visualization is done by manipulating visual attributes of the ''Visualization'', by manipulating ‘’Renderers’’, or by setting dynamic queries to filter the content. The toolkit has got a large set of interaction controls predefined. Most attention was set toward providing own panels which combines several interaction possibilities (e.g., color chooser, filter for all defined columns, etc.). Such control panels are typically organized in tab groups around the proper visualization. Further, the ''VisualizationPanel'' can be extended by control listener to handle mouse or keyboard events manually. If a certain item should handle such an event, the respective renderer must provide this functionality. <br />
<br />
==Readers and Writers==<br />
<br />
''Readers'' and ''Writers'' are associated with a ''Table'' and used to fill it or write its content back to the file system. The toolkit provides a lot of different readers for common file formats like XML or CSV. Predefined readers or writers already consider the internal structure of the associated file, so, XML files are stored in a tree, CSV in a table, etc. <br />
<br />
==Table==<br />
<br />
The ''Table'' is the base container for every kind of abstract data. In contrast to other implementations of tables, this table is not based on containers. Instead, it consists of several ''Columns'' which are technically arrays of the respective data type they should map. Additionally, each column is described with metadata: <br />
<br />
[[Image:infovis_toolkit_table|600px]]<br />
<br />
Several ''Columns'' to map standard types like strings or integers are already predefined. The ''ObjectColumn'' can store each thinkable Java Object. <br />
<br />
Following this way, a table can contain each possible data. As an array is indexed, the table itself has indexes too. The index is used to access a data tuple, further, relations as needed by ''Trees'' or ''Graphs'' are also established through indexes. A ''Column'' can have empty rows which is important in case of sparse data. <br />
<br />
A generally row object to fill or access data is missing, so, a data record can only be accessed by requesting the data of all columns with an index. Thus, especially when dealing with sparse data, special attention has to be paid toward filling the table.<br />
<br />
==Visualization==<br />
<br />
The ''Visualization'' is bound to the ''Table''. Semantic attributes which are defined in associated columns of the ''Table'' are transformed into visual attributes (e.g., color, label, etc.). Filtering of abstract content to visual attributes is managed by dynamic queries which are used to determine which data is visualized and which not.<br />
<br />
Most of the assignments attributes (like size, stroke width, etc.) are defined in own columns too. Locations of the items are typically calculated by lay outing algorithms. This can be done by the ''Visualization'' itself or an associated ''Layout'' object. Once, all visual attributes of an item are retrieved of the table or calculated by algorithms, they are stored in the internal ''ShapeColumn''. <br />
<br />
The ''ShapeColumn'' is only updated when needed. This happens on following events:<br />
<br />
* The ''Table'' has changed. The ''Visualization'' is notified whenever records of the ''Table'' are changed, new ones are inserted, or existing ones are deleted.<br />
* A user-interaction forces a new layout of the items. <br />
* A user-interaction changes the filtering process. <br />
<br />
Painting itself is done by ''Renderers''. Each ''Visualization'' has an associated ''Renderer'' which can consist of several other ''Renderers'' again. A ''Renderer'' provides the painting routines for an item which are based on the visual attributes. Further, a ''Renderer'' may also handle user interactions (e.g., clicking on an item).<br />
<br />
Before an item is actually painted, also other visualization techniques may influence the output. Examples for such techniques are fisheye views or dynamic labeling. <br />
<br />
==Components==<br />
<br />
In ''Components'' a large set of interaction components are concentrated. Predefined components are combined within own control panels and include sliders to change size or colors of items, set filter expressions to restrict the visual content, or select items. Such interactions are typically applied by using dynamic queries or changing visual attributes manually.<br />
<br />
==Image==<br />
<br />
The image is the visual output of the [[Information Visualization]]. In contrast to other toolkit, the ''InfoVis Toolkit'' does not demand a certain component to render its output. Painting is done by using the Java Graphics2D environment. Therefore, also a ''BufferedImage'' can be used for example. However, the default view is the ''VisualizationPanel'' and derivates of it. A ''VisualizationPanel'' is a ''JComponent'', therefore, the view also inherits the functionality of the Swing component. This component also supports events on the view that can be handled by the view itself or delegated to the respective ''Renderer'' or other event handler. <br />
<br />
The ''InfoVis Toolkit'' partially supports the Agile2D graphics framework which allows faster paintings of 2D graphics. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
; io<br />
: basic readers and writers. <br />
; metadata<br />
: several metadata categories.<br />
; panel<br />
: contains several "view" implementations and components that provides interaction possibilities.<br />
; visualization<br />
: this package contains several implementations of ''Visualizations'' and other basic classes like interfaces for layouts. Further, ''Renderer'' and other helper classes are included here. <br />
; column<br />
: provides the basic implementation of a ''Column'' and special derivates of it.<br />
; table<br />
: provides a set of classes related to visualization of tables.<br />
; tree<br />
: provides a set of classes related to visualization of trees.<br />
; graph<br />
: provides a set of classes related to visualization of graphs.<br />
; utils<br />
: contains several helper classes like comparators, etc <br /><br />
<br />
<br />
=Conclusion=<br />
<br />
The ''InfoVis Toolkit'' is a toolkit, which pays most attention toward saving resources. Even if there is a measurable advantage in comparison to other toolkits, there are other factors like usability or simplicity too that characterize a good toolkit. The toolkit is very hard to use, at least there is no underlying logic a developer can conceive quickly. But the toolkit provides a lot of examples for standard problems, like scatter plots, etc. These predefined applications are easy to use if no special demands of the [[Information Visualization]] are needed.<br />
<br />
= External links =<br />
*[http://ivtk.sourceforge.net The InfoVis Toolkit]<br />
*[http://www.cs.umd.edu/hcil/agile2d Agile2D]<br />
<br />
= References =<br />
*[Fekete, 2004] Jean-Daniel Fekete. [http://www.lri.fr/~fekete/ps/ivtk-04.pdf The InfoVis Toolkit]. Proceedings of the 10th IEEE Symposium on Information Visualization (InfoVis'04), Austin, TX, IEEE Press. pp. 17-24, Oct 2004.<br />
*[Fekete, 2003] Jean-Daniel Fekete. [http://www.inria.fr/rrrt/rr-4818.html The InfoVis Toolkit (Rapport de Recherche)] Research Report RR-4818, INRIA Futurs, May 2003.<br />
*[Fekete, 2004] Jean-Daniel Fekete, user manual. Retrieved at: July 06, 2006, http://ivtk.sourceforge.net/manual.html<br />
<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10308Prefuse2006-07-28T22:47:47Z<p>Anfe: </p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization.] In CHI 2005, Human Factors in Computing Systems, 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual. Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java. Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10132Prefuse2006-07-06T09:35:40Z<p>Anfe: /* User Interactions */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem''). <br />
<br />
A ''ControlListener'' may just perform simple tasks like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also tasks like loading new data or dragging items on the view may be handled. Therefore, a ''ControlListener'' may also start ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display''. Thus, it is able to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones.<br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10131Prefuse2006-07-06T09:32:49Z<p>Anfe: /* Coordinates in prefuse */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations.<br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10130Prefuse2006-07-06T09:31:34Z<p>Anfe: /* Package Structure */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. Default ''Nodes'' and ''Edges'' provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality to fulfil common requirements are provided by own components: <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render text items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to layout trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by predefined components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10129Prefuse2006-07-06T09:29:08Z<p>Anfe: /* View */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but the proper representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10128Prefuse2006-07-06T09:27:47Z<p>Anfe: /* Visual Abstraction */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may be distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity, it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10127Prefuse2006-07-06T09:05:58Z<p>Anfe: /* Data Table */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, own visual analogous are created. Visual attributes of them are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10126Prefuse2006-07-06T09:04:01Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10125Prefuse2006-07-06T09:03:37Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started manually or of the ''Visualization'' itself. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all belonging ''Displays'' of the ''Visualization'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint, it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
The ''Display'' also provides navigation techniques like [[zoom]]ing or [[pan]]ning which change the view. The view itself refers to a own coordinate system. View coordinates are described through an affine transformation matrix. The most important functionality to work with this coordinate system are already predefined. Typically, users just have to apply such techniques without considering technical details. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. A listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database or web content are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table of the ''Visualization''.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10124Prefuse2006-07-06T08:56:05Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are managed and executed by the ''Visualization'' too. Further, it refers to at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10123Prefuse2006-07-06T08:55:12Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting tree or graph structure must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10122Prefuse2006-07-06T08:53:32Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, all painting issues are completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10121Prefuse2006-07-06T08:52:14Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize interrelated information so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10113Prefuse2006-07-06T01:39:36Z<p>Anfe: /* Summary */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.org<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10112Prefuse2006-07-06T01:38:13Z<p>Anfe: /* Visual Abstaction */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstraction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10111Prefuse2006-07-06T01:38:04Z<p>Anfe: /* Visual Structures */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Abstaction==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object.<br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10110Prefuse2006-07-06T01:37:44Z<p>Anfe: /* Abstract Data */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Data Table==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10109Prefuse2006-07-06T01:37:26Z<p>Anfe: /* Raw Data */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Source Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table.<br />
<br />
==Abstract Data==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10108Prefuse2006-07-06T01:37:03Z<p>Anfe: /* Package Structure */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Raw Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table. <br />
<br />
==Abstract Data==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|600px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10107Prefuse2006-07-06T01:34:45Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif|600px]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Raw Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table. <br />
<br />
==Abstract Data==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|800px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10106Prefuse2006-07-06T01:34:29Z<p>Anfe: /* General Approach */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
[[Image:prefuse_visualization_pipeline.gif]]<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Raw Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table. <br />
<br />
==Abstract Data==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer.<br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|800px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Prefuse_visualization_pipeline.gif&diff=10105File:Prefuse visualization pipeline.gif2006-07-06T01:33:21Z<p>Anfe: /* Summary */</p>
<hr />
<div>== Summary ==<br />
The image shows the visualization pipeline used in prefuse.<br />
<br />
== Copyright status ==<br />
GNU Free Documentation License <br/><br />
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.<br/><br />
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA<br/><br />
Everyone is permitted to copy and distribute verbatim copies<br/><br />
of this license document, but changing it is not allowed.<br/><br />
<br />
== Source ==<br />
[Heer, 2006] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Prefuse_visualization_pipeline.gif&diff=10104File:Prefuse visualization pipeline.gif2006-07-06T01:32:46Z<p>Anfe: /* Copyright status */</p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
GNU Free Documentation License <br/><br />
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.<br/><br />
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA<br/><br />
Everyone is permitted to copy and distribute verbatim copies<br/><br />
of this license document, but changing it is not allowed.<br/><br />
<br />
== Source ==<br />
[Heer, 2006] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Prefuse_visualization_pipeline.gif&diff=10103File:Prefuse visualization pipeline.gif2006-07-06T01:32:18Z<p>Anfe: </p>
<hr />
<div>== Summary ==<br />
<br />
== Copyright status ==<br />
<br />
== Source ==<br />
[Heer, 2006] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Prefuse_package_guide.gif&diff=10102File:Prefuse package guide.gif2006-07-06T01:31:33Z<p>Anfe: /* Copyright status */</p>
<hr />
<div>== Summary ==<br />
The picture shows the most important packages of prefuse regarding to the Visualization Pipeline.<br />
== Copyright status ==<br />
GNU Free Documentation License <br/><br />
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.<br/><br />
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA<br/><br />
Everyone is permitted to copy and distribute verbatim copies<br/><br />
of this license document, but changing it is not allowed.<br/><br />
<br />
== Source ==<br />
[Heer, 2006] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org</div>Anfehttps://infovis-wiki.net/w/index.php?title=File:Prefuse_package_guide.gif&diff=10101File:Prefuse package guide.gif2006-07-06T01:30:57Z<p>Anfe: /* Copyright status */</p>
<hr />
<div>== Summary ==<br />
The picture shows the most important packages of prefuse regarding to the Visualization Pipeline.<br />
== Copyright status ==<br />
GNU Free Documentation License<br />
Copyright (C) 2000,2001,2002 Free Software Foundation, Inc.<br />
51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA<br />
Everyone is permitted to copy and distribute verbatim copies<br />
of this license document, but changing it is not allowed.<br />
<br />
== Source ==<br />
[Heer, 2006] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org</div>Anfehttps://infovis-wiki.net/w/index.php?title=Prefuse&diff=10100Prefuse2006-07-06T01:30:11Z<p>Anfe: /* Package Structure */</p>
<hr />
<div>= Summary =<br />
<br />
'''Author''': Jeffrey Heer / UC Berkeley<br /><br />
'''Project Webpage''': http://prefuse.sourceforge.net<br /><br />
'''Current Version''': beta, June 15, 2006<br /><br />
'''Requirements''': Java 1.4<br /><br />
'''Overview:''' using Java2D graphics library; pipeline architecture; animation and rendering support<br /><br /><br />
'''Base data structures''': Table, Graph, Tree<br /><br />
'''Included visualization techniques:''' [http://www.cs.umd.edu/hcil/fisheyemenu/ Fisheye Menu], [http://prefuse.sourceforge.net/demos-radial.html Radial Graph], [http://www.cs.umd.edu/hcil/treemap/ Treemap], [http://prefuse.sourceforge.net/demos-distortion.html F+C Distortion]<br /><br />
'''Supported File Formats''': XGMML (XML), TreeML (XML), tab-delimited text, HDir<br /><br /><br />
<br />
'''prefuse''' is an interactive graphical open source toolkit written in Java. It is thought to support the development of sophisticated, highly interactive, and flexible [[Information Visualization]]s. The architecture of '''prefuse''' considers the [[Visualization Pipeline]], a recommendation on how to implement a visualization. To provide flexibility, a [[polylithic design]] was chosen which enables developers to implement only needed functionality and customize these to meet the own requirements. But, in contrast to a [[monolithic design]], this design needs more time to conceive and influences the architecture of the own application heavily (which is not a disadvantage as '''prefuse''' is very elaborate). <br />
<br />
Typically, '''prefuse''' is designed to visualize information which is interrelated so it can be stored in a graph or tree structure, but, also not related data can be used which is stored within a data-table. Even though the structure is hierarchical, the resulting relations must not be considered in the proper graphical representation as layout algorithms are not restricted in any way. The painting of visual items is done by using a renderer which has access to the respective item itself and the Graphics2D context of the view. This approach enables to use the whole range of available painting methods of Java, therefore, the visual representation is completely independent of the toolkit itself.<br />
<br />
Besides providing a large set of predefined elements to visualize data, most attention was set toward usability of the visualization. This is obtained by applying several interaction techniques like tooltips or dragging visual elements. But also more sophisticated techniques like [[zoom]]ing, [[pan]]ning, or [[semantic zoom]]ing are supported or partially even provided by the toolkit itself. Further, '''prefuse''' clearly distinguishes between absolute and view coordinates. This separation helps users to place all visual elements in a logical way without consideration of later applied visualization techniques that changes the entire view. <br />
<br />
=== Pros ===<br />
<br />
* flexible<br />
* versatile pipeline approach<br />
* clear and well thought architecture<br />
* many layout and distortion algorithms included<br />
* algorithms for force-based physics simulation included<br />
* custom animations (smooth transitions)<br />
* color maps<br />
* query language to navigate within abstract data<br />
* demos and examples included<br />
* bounding management<br />
* open source<br />
* documentation of code and general guidance available<br />
* active developer community <br />
<br />
=== Cons ===<br />
<br />
* [[polylithic design]] takes up more time to conceive and see first results<br />
* special requirements of a visualization enforce a lot of adapting work<br />
<br />
=General Approach=<br />
<br />
Going along with the step-wise recommendation of the [[Visualization Pipeline]], a '''prefuse''' application consists of different states of data:<br />
<br />
'''prefuse''' uses a centralized object called ''Visualization'' (former ''ItemRegistry'') which maintains and manages the whole visualization. This object has to fulfil several tasks. It stores the abstract data as well as visual analogous of these in two different tables. All transformation routines like filtering or rendering are maintained and executed by the ''Visualization'' too. Further, it maintains at least one ''Display'', a graphical component which can represent visual data of '''prefuse'''. <br />
<br />
Transformation routines are defined as ''Actions'' which are combined in ''ActionLists''. An ''ActionList'' is an executable container which is started of the ''Visualization'' whenever necessary. Once it is started, all defined ''Actions'' are executed in the given sequence. Typically, the last called ''Action'' is the ''RepaintAction'' which forces all defined ''Displays'' to perform a repaint. <br />
<br />
A ''Display'' is the view of '''prefuse'''. It can be embedded in each Java Swing application. The main task of a ''Display'' is the painting of visual structures which are defined in the respective ''Visualization''. Whenever the ''Display'' performs a repaint it requests all visual items and checks all bounds of them (bounding management). If an item is within the own area the respective rendering mechanism is called. <br />
<br />
Another important task of the ''Display'' is the providing of navigation techniques like [[zoom]]ing or [[pan]]ning. The entire view is managed by an own view coordinate system which is described with an affine transformation matrix. The most important functionality to work with this coordinate system is already predefined. <br />
<br />
Furthermore, a ''Display'' also maintains a set of ''ControlListener'' which are used to process user interactions (mouse or keyboard events). Whenever such an event occurs the respective listener is called. This listener already differs on where the event happened (e.g., blank area or a certain item). Further, a ''ControlListener'' may also start an ''ActionList'' again.<br />
<br />
==Raw Data==<br />
<br />
Raw data is the base of the application. Typically, the source of raw data is a file, but also other sources like a database are thinkable. However, '''prefuse''' provides several file readers for different formats (CSV, Tab-Delimitated, etc.) that can be transformed into a data table. Further, some readers also support the reading of SQL-Database. If another source is needed, a reader can be written manually.<br />
<br />
Once the raw data is read, it is transformed into abstract data and stored within a data table. <br />
<br />
==Abstract Data==<br />
<br />
The data table which is used to store abstract data works with data types and a definition schema which maps relations between data type and table. That means, each row contains a data record, and each column contains data values for a named data field with a specific data type. Each record of the table is referred as a ''Tuple''. <br />
<br />
Furthermore, instead of the table itself, a graph or tree may be used to store interrelated data. Instead of ''Tuples'', records are referred as ''Nodes'' which are connected to others with ''Edges''. Additionally, a tree has one defined root ''Node''.<br />
<br />
Abstract data does not contain any visual information like assignment attributes or color settings. Instead, visual attributes are extracted out of the abstract data following a defined logic.<br />
<br />
==Visual Structures==<br />
<br />
Visual structures are created when filtering the data container which contains abstract data. In case of a visualization that displays all items from the beginning on, the filtering routine must only executed once at initializing time. If the visual content changes dynamically, the filtering is executed on certain user interactions by calling a defined filtering ''ActionList''. <br />
<br />
A visual structure is referred as ''VisualItem'' which may distinguished as ''VisualNode'', ''VisualEdge'', or an aggregated item which consists of several other items. However, as a ''VisualItem'' is extended of the respective abstract entity it has full access to all abstract information too. <br />
<br />
The filtering routine which transforms the abstract data to visual analogues typically consists of following ''Actions'':<br />
<br />
* '''Filter''': This ''Action'' is responsible to transform the abstract data of the backing table to visual analogues. If no special conditions are defined, the filter creates for each ''Tuple'' a visual instance and stores them in a second table. Additionally, a filter also performs a garbage collection and may set visibility attributes of the created items. <br />
* '''Layout''': A layout takes care about placing the ''VisualItems''. Several common algorithms for graphs or trees are already predefined (e.g., ''ForceDirectedLayout'' or ''RadialTreeLayout''). <br />
* '''Assignment''': Besides layouting, also other assignments may be performed during the filtering process. Such assignments directly changes visual attributes of ''VisualItems'' like color, sizes, fonts, etc.<br />
<br />
A visual structure may also contain a paint routine, but, as all painting jobs are initialized or performed by separated renderers, these issues may also be executed by the renderer itself or any other object. <br />
<br />
==View==<br />
<br />
Typically, the rendered visual structure is not stored, instead, they are re-rendered whenever needed. However, in case of very complex but constant visual representations it makes sense to hold items in an offscreen image. <br />
<br />
Each ''VisualItem'' has got one or more associated ''Renderers'' which are maintained by a factory of the ''Visualization''. A ''Render'' has to perform two tasks:<br />
<br />
* Providing a bounding box of the item. This box is used to determine if the item must actually be painted or if it would not be visible anyway. <br />
* Providing the painting routine of the item. Paintings may be executed by the ''Renderer'' itself or delegated to other objects which are accessible of the ''Renderer''. The painting routines are not restricted in any way, but they representation should not exceed the bounding box of the item. <br />
<br />
Rendering is always performed on a repaint of the ''Display''. A repaint can be requested by the ''Visualization'', on user interaction, and on events like resizing the component, getting the focus, or changing the coordinate system of the view. However, as repaints may occur very often, developers have to ascertain that rendering jobs can are performed fast, otherwise, the performance of the whole visualization would suffer. <br />
<br />
=Details=<br />
<br />
==Package Structure==<br />
<br />
Following picture shows the most important packages of '''prefuse''' regarding to the [[Visualization Pipeline]]:<br />
<br />
[[Image:prefuse_package_guide.gif|800px]]<br />
<br />
These packages also contain predefined components. A default nodes and edges provide standard functionality of abstract data, standard functionality is also available in visual analogous of them. A default filter transforms all defined abstract entities to visual ones. Further, also some special functionality for common requirements are provided by own components. <br />
<br />
* '''Renderers''': ''EdgeRenderer'' to render edges between graph or tree nodes, a ''LableRenderer'' to render test items, and a ''PolygoneRenderer'' to render geometrical items. <br />
* '''Layouts''': ''RandomLayout'', ''GridLayout'', and some more to place non related data, ''ForceDirectedLayout'', ''TreeLayout'', ''RadialTreeLayout'' and others to render trees and graphs.<br />
* '''Controls''': ''DragControl'', ''ZoomControl'', ''PanControl'', ''ToolTipControl'' and several others to react on user interactions. <br />
<br />
In simple visualizations the predefined functionality will meet most requirements. If special requirements are needed the default functionality supports a step-wise developing as results can be communicated by these components until the own functionality is implemented.<br />
<br />
==Coordinates in prefuse==<br />
<br />
'''prefuse''' works with two different coordinate systems. Absolute coordinates are device-independent logical coordinates. All visual attributes like positions or sizes are defined in absolute coordinates. In contrast, view coordinates are device-depended (screen). Transformations between absolute and view coordinates are done automatically by Java painting routines. View coordinates are influenced by the system and device driver (e.g., the absolute point (0,0) is the topmost left point of the actual graphical component which may be on any position at the screen). Further, view coordinates may also be manipulated manually by using an affine transformation matrix which applies linear transformations on absolute coordinates before device-dependent routines convert them to screen coordinates. <br />
<br />
A '''prefuse''' ''Display'' provides the most important manipulating methods of this matrix. [[Zoom]]ing, [[pan]]ning, and rotation of the whole view are only done by changing the view coordinates. So, as absolute coordinates are never concerned of such transformations and translations, a user must never consider the actual view in layout, assignment, or painting routines. <br />
<br />
There are several different ways on how to apply such transformations, additionally, the ''Display'' also supports animated transformations. <br />
<br />
==User Interactions==<br />
<br />
Mouse or keyboard events are treated by using ''ControlListener''. Whenever an event occurs which is handled by a ''ControlListener'', the ''Display'' delegates the event to the respective routine. A ''ControlListener'' differs automatically which visual element is concerned of the event (the view itself or a ''VisualItem'' on the view). <br />
<br />
A ''ControlListener'' may just perform simple task like changing the mouse cursor or editing the label of an item. But, in more sophisticated applications, also task like loading new data or dragging items on the view may also be handled. Therefore, a ''ControlListener'' may also work with ''ActionLists'' to execute such tasks. Further, a ''ControlListener'' has also access to the ''Display'' to call methods like zooming or panning. Typically, each ''ControlListener'' forces a repaint when its job is done. <br />
<br />
Most of standard functionality is already predefined in ''prefuse'' and the wanted listeners just have to be set to the ''Display''. However, the ''Display'' can handle a countless of different listener. Hence, typically only a few listeners must be defined manually as they can be mixed with default ones. <br />
<br />
=Conclusion=<br />
<br />
'''prefuse''' is a very powerful toolkit, providing a large set of components and methods a developer needs to build an [[Information Visualization]]. The [[polylithic design]] is not that easy to understand in the beginning of a development, but once conceived, a visualization is easy to realize even if really special demands have to be fulfilled. Furthermore, using Prefuse forces a clear and well designed architecture of own applications.<br />
<br />
'''prefuse''' was created with most attention paid to developers who will finally work with the toolkit. In an evaluation study this goal was approved too. In the meanwhile, there is also a not so small community using and upgrading the toolkit, which is an argue for its usability.<br />
<br />
= External links =<br />
*[http://prefuse.org prefuse Homepage]<br />
*[http://vw.indiana.edu/ivsi2004/jherr/index.html prefuse Position Paper]<br />
*[http://sourceforge.net/forum/forum.php?forum_id=343013 prefuse Help Forum]<br />
<br />
= References =<br />
*[Heer, 2004] Jeffrey Heer. [http://jheer.org/publications/2004-Heer-prefuse-Masters.pdf prefuse: a software framework for interactive information visualization]. Masters of Science, Computer Science Division, University of California, Berkeley, 2004.<br />
*[Heer, 2005] Jeffrey Heer, Stuart K. Card, and James A. Landay. [http://jheer.org/publications/2005-prefuse-CHI.pdf prefuse: a toolkit for interactive information visualization. In ''CHI 2005, Human Factors in Computing Systems''], 2005.<br />
*[Heer, 2006a] Jeffrey Heer, prefuse API documentation, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Heer, 2006b] Jeffrey Heer, prefuse manual, Retrieved at: July 06, 2006, http://prefuse.org<br />
*[Sun Microsystems, 2001] Sun Microsystems, Programmer’s Guide to the Java 2DTM API - Enhanced Graphics and Imaging for Java, Retrieved at: April 20, 2006, http://java.sun.com/j2se/1.4/pdf/j2d-book.pdf<br />
<br />
[[Category:Toolkits]]</div>Anfe