Interests and Objectives
My research interests primarily concern the relationship between technology and creativity: how technology can support creative activities and how it evolves to provide new creative opportunities. Exploring these issues has led me to pursue a wide-ranging path of inquiry, calling on computer science, architecture, design theory and philosophy. Ultimately, these studies converged on an interest in the emergence and evolution of creative instruments, e.g., design methods, tools and techniques, in particular, diagrammatic techniques. As I continue on this path of inquiry, I hope to uncover how such techniques support innovation within and across domains.
Methods, Tools & Techniques
Throughout my graduate studies, I have concentrated on the interplay between three fundamental kinds of instruments that support creative activities: methods, abstract procedures that characterize a process; tools, material devices used to execute a process; and techniques, material procedures that describe how one uses a tool within a method. All three instruments are necessary; however, techniques are especially important since they govern the relationship between the abstract and the material. Like methods, techniques are abstract and procedural in form; yet, they are also innately material in that they describe the application of a tool. In spite of their importance, techniques are rarely examined as entities onto themselves. Indeed, the difficulty of characterizing techniques succinctly is an essential justification for practical, laboratory- and studio-based education. Thus, studying the emergence and evolution of techniques presents an exceptional opportunity to build an imminently useful body of knowledge.
Diagrammatic Techniques
I have directed much of my attention toward diagrammatic techniques or diagrams, the class of techniques that give material form to abstract entities or phenomena. My view of diagrams differs from the more common view in two significant respects: • Whereas diagrams are often regarded as reductive representations, I prefer to think of them as alternative manifestations or proxies. That is, I see a diagram as the substance on which one operates rather than a representation of some other substance. • Whereas diagrams are typically regarded as innately visual devices, I hold that they emerge from any sensible configuration. By allowing people to describe and operate upon abstract entities in material ways, diagrammatic techniques offer means of thinking and working that might otherwise be difficult, if not impossible.
The fault tree technique, most commonly used in systems engineering, is one example.
Briefly, this technique helps one to identify possible causes of a major fault within a
complex system, be they technical, environmental or social. (Vesely et al. 2002) One produces
a fault tree by identifying a high-level fault and inductively identifying the lower
faults and conditions that contributed to higher ones. All faults are displayed as a
hierarchy with logic gates that describe the relationship between faults.
The fault tree technique is diagrammatic in that it gives material form to an abstract idea, viz., the causality between faults in a system rendered on screen or on paper. Moreover, it is an active contributor to the user’s process. The technique inhabits the user’s procedural memory and expands their working memory, helping the user to reason about faults and presenting opportunities for reflection in action.
Other features of the fault tree technique are worth noting. • It is independent of the tool used to create it. One could create a fault tree by hand, with an illustration tool, with a diagramming tool or with a tool specifically created for making fault trees. The appropriateness of any one tool depends on the user’s specific needs. • Likewise, the technique is independent of the method used to identify faults within a system. What constitutes a fault and what constitutes causality is specific to the user’s objective and perspective on the subject. • The fault tree technique evolved from a similar technique in a different domain, logic circuit design, and similar techniques have evolved in other domains, e.g., decision support systems in business. • Although the fault tree is a primarily visual technique, one does not need to look far to find diagrammatic techniques that engage other senses. Drills and live simulations also help engineers to find faults within a complex system, only they do so with vision, sound and motion.
Objectives
Major foci of my graduate work thus far have been • how techniques emerge and evolve to meet changing technological and methodological needs • how this evolution feeds back into the development of new tools and methods • how individuals acquire techniques, as students and as professionals and • how particular combinations of tools and techniques can support creative activities. Although I initially focused on research techniques in architecture and urban design education, I found that a broad approach, tracing the use of techniques across disciplines, offers richer opportunities for study. Moving forward, I intend to investigate the use of diagrammatic techniques to facilitate learning, discovery and communication in a variety of settings, in particular those involving interdisciplinary research and education.
The ultimate outcome for this work would be a theory of evolution for techniques and tools. Over time, techniques evolve to serve other needs. A user’s task may change; they may find an easier or more efficient techniques to implement a task; or they may discover that a technique found in another domain serves a purpose in their own. Understanding how techniques emerge and evolve would help to create devices that readily adapt to new patterns of use within a domain or similar patterns of use other domains.
References
G Deleuze, F Bacon. 1981 [2003]. "Chapter 11: The Diagram." Francis Bacon: The Logic of Sensation. DW Smith, transl. Minneapolis: U Minnesota Press. 81-90.
W Vesely, et al. 2003. Fault Tree Handbook with Aerospace Applications. Version 1.1. Washington: NASA. Online at http://www.hq.nasa.gov/office/codeq/doctree/fthb.pdf.
Casey R Hickerson
14 December 2008