Fil Salustri's Design Site

Site Tools


Information Visualization

How can information be displayed to communicate most effectively and efficiently?

General points

  • “The messy, networked nature of that exploration [of conceptual designs] is probably best supported by a diagrammatic representation.” Diagrams can be especially useful in pre-geometric concept visualization, and can improve creativity and innovation. [AEO11]
  • “…revealing these discrepancies in graphic form leads to helpful debate not just about alternative strategies, but about schisms between various subgroups of the management team, and between managers and directors.” [FH92]
  • It has been shown through experiment that at least for sparse graphs, node-link diagrams are easier to read and understand than matrices [KEC06].
    • Problems with the generic type of experiments done, however:
      • No larger framework of diagrammatic reasoning is assumed.
      • Experience with the information represented visually impacts understandability significantly. This means that (a) there's a steep learning curve for diagrams and (b) there will be initial resistance to their use as other visualizations may seem better at first.
      • A number of the tasks that formed the experiments could be easily automated either with matrices or diagrams. It is therefore not clear if the benefits as described can be realized in real-life situations.
      • It would be interesting to consider what real-life tasks might be tested for.

[FH92] notes the importance of visualizations, even though the work was done in 1992.

Kinds of visualizations

In mechanical design, CAD is the principal form of visualising products. However, in stages of the design process preceding the establishment of geometry (e.g. concept design, systems design, etc.) there is no method, technique, or tool to capture and represent visually the information that is used to drive the design forward. This is in opposition to other disciplines, such as architecture and electrical engineering, where the notion of a product architecture is fundamental to the early design stages. Indeed, in these other disciplines there are many tools to represent architectures visually.

Visual (non-textual) representations of information can be extremely dense and communicate tremendous amounts of information easily and quickly.

Can a visual, diagrammatic form of information representation be developed for mechanical design? I believe the answer is 'yes', and am pursuing various projects to prove this hypothesis and develop the necessary methods and tools.

Design schematics: This is the overarching goal: a diagrammatic language able to represent all non-geometric information about products, and with supporting tools to facilitate the process of design in the pre-geometry stages.

Visual wikis: A visual wiki combines visualization with conventional text-based wikis.

Design Structure Graphs: The design structure matrix (DSM) is a very useful tool in product development. I believe it could be even more useful if a DSM were represented as a graph rather than a matrix. A design structure graph (DSG) is a diagrammatic rendering of a DSM. Our hypothesis is that a DSG more easily and quickly communicates important information about a design task to a human designer than a DSM.

Chapin Charts: Chapin charts were once proposed as an alternative to flowcharts. I believe the reason chapin charts never caught on is that they are hard to draw by hand; and at the time they were invented, there were no computer tools to create diagrams. These days, however, almost anything is possible. Furthermore, chapin charts don't only work for software, but, as with flowcharts, they can be applied in any procedural setting.

Functional Analysis Diagrams: Developed by Aurisicchio et all ([AEO11]), these are based on concept maps with specific rules added to capture diagrammatically aspects of design function modelling. In these, nodes represent components (internal, external/environmental, and sub-components), and functions represent functions.

Radar plots: These are two-dimensional plots with multiple axes arranged in a polar geometry about an origin. The variables are typically orthogonal, but the rendering doesn't not maintain orthogonality in rendering. This essentially lets one plot data in greater than 2D on a 2D plot. Connecting the points on each variable axes for a set of data can be useful to show biases, priorities, or implicit weights of the values.

Simple causal relationship diagrams (or means-ends diagrams), precursors to causal loop diagrams, were identified as far back as 1992 as beneficial. They were described thus: “Factors with many ‘out’ arrows are the givens in this generalized map; those with arrows both ‘in’ and ‘out’ denote means; while those with many ‘in’ arrows mark important ends.”

Other packages and systems


Topicscape is a 3d concept mapping tool. Nathan Eng sums up this commercial package as follows:

The parts that raise flags:

  • Looks like a planar map rendered with a 3D texture
  • Eliminates relation by geometric connection (line) in favour of relationships by proximity, which gets confusing
  • the example looks hierarchic, don't know if you could to a cycle or mind-map with this.
  • UI has text entry off to the side while occluding part of the map.
  • Space efficiency: I have a feeling this could be rendered in 1/4 the space on a normal cmap with better structure.
  • no room for longer labels

Parts that look like good ideas:

  • Multiple parallel entry (parse one string with '|' dividers into multiple nodes at the same level) Little script tricks in the text entry could make for neat shortcuts.
  • Drag and drop folders
  • Looks a bit closer to a ZUI, lots of zooming and panning, even in the “topic centre” table entry. but a lack of rotation and other real 3d manipulations imply it's not really 3D

General Notes

  • Content of concept maps may have some rules for layout worth absorbing.
  • Cmaptools & Scaffolding: an article about cmaptools and possible additions, including scaffolding, which is defined as providing context-sensitive guidance on how to carry out “discourses” and put together content (but not just help on the software interface itself).
  • Aurisicchio, Bracewell, and Wallace. 2003. A design data model to support rationale capture and functional synthesis. ASME 2003 DETC, paper DTM-48672.
  • Kirkpatrick. 1959. Techniques for evaluating training programs. ASTD, 13(11):3-9.

Other Graphics Packages

Other ideas


[AEO11]., [AEO11]. M. Aurisicchio, N.L. Eng, J.C. Ortiz, P.N.R. Childs, and R.H. Bracewell. 2011. On the function of products. Intl Conf on Engineering Design. The Design Society. (link)
[FH92]., [FH92]. C.M. Fiol and A.S. Huff. 1992. Maps for managers: Where are we? Where do we go from here? J Mgmt Studies 29(3):267-285. (link)
[KEC06]. R. Keller, C.M. Eckert, and P.J. Clarkson. 2006. Matrices or node-link diagrams: which visual representation is better for visualising connectivity models? Information Visualization 5:62-76. (link)
[MZ96]. E. Motta and Z. Zdrahal 1996. Parametric design problem solving. Proc 10th Knowledge Acquisition Workshop, Banff, Canada (link)
[ACC00]. A. Aoussat, H. Christofol and M. Le Coq 2000. The new product design - a transverse approach. J. Eng. Design, 11(4):399-417.
research/information_visualization.txt · Last modified: 2020.03.12 13:30 (external edit)