Current Application of Graphical Program

Current application of graphical programming
in the design phase of a BIM project:

Development opportunities and future scenarios with 'Dynamo'
VOGT
THOMAS MICHAEL
W14008230
08 January 2016
MSc Building Design Management and BIM

UNIVERSITY OF NORTHUMBRIA
AT NEWCASTLE
FACULTY OF ENGINEERING & ENVIRONMENT
Current application of graphical programming

in the design phase of a BIM project:
Development opportunities and future scenarios with 'Dynamo'
A DISSERTATION SUBMITTED IN PARTIAL

FULFILMENT OF THE REQUIREMENTS FOR THE
DEGREE OF
MSc Building Design Management and BIM
Thomas Michael Vogt
January 2016
All rights reserved – no part of this publication may be reproduced without the prior permission of the author.
DECLARATION FORM
I declare the following:
1. That the material contained in my dissertation/thesis is the end result of my

own work and that due acknowledgement has been given in the bibliography
and references to ALL sources, be they printed, electronic or personal, using
the Northumbria Harvard referencing system.
2. The word count of my dissertation/thesis is 19090 words.
3. That unless my dissertation/thesis has been confirmed as confidential, I agree

to an entire electronic copy or sections of my dissertation/thesis being placed
on the eLearning portal and shared hard drive, if deemed appropriate, to allow
future students and staff the opportunity to see examples of past students’
dissertations/theses.
4. I agree to my dissertation/thesis being submitted to a plagiarism detection

service where it will be stored in a database and compared against work
submitted from this or any other programme within Northumbria University
and from other UK, EU and international institutions using the service.
In the event of the service detecting a high degree of similarity between the
content of my dissertation/thesis and the documents contained within the
database, this will be reported back to my supervisor and examiners, who may
decide to undertake further investigation that may ultimately lead to
disciplinary action (according to ARNA), should instances of plagiarism be
detected.
5. I have read the Northumbria University policy statements on Ethics in

Research and Consultancy and confirm that ethical issues have been
considered, evaluated and appropriately addressed during my research and
during the production of my dissertation/thesis.
6. I agree to the module tutor and/or programme leader nominating my

dissertation/thesis on my behalf for appropriate academic/research awards,
such as the CIOB, RICS and APM annual master’s dissertation awards.
Signed: ................................................
Date: ....................................................
Please remember to sign this declaration and include it before submitting your
dissertation/thesis for binding. This declaration form should be placed in each
Wiro bound copy after the title page.
“The result is complex without being complicated.”
(Shane Burger)
ii
ACKNOWLEDGEMENTS
I am very thankful to my supervisor, Dr Claudio BENGHI, whose advice,

encouragement and support helped me to achieve my objective and aims. I think we
share similar opinions about the construction industry and his understanding of
programming helped me to formulate this research topic.
I like to thank all survey participants, everyone who have supported me somehow,
my family and all who have helped to spread the survey. Especially I want to thank
Harriet Latimer with her eyes for every detail – an outstanding classmate and an
always helpful friend. I hope we will meet soon again on events! I was absorbed by
the thesis for several months and I hope everyone will forgive me for not attending
your party. I am already looking forward to dive deeper into programming and BIM
at my future position in Stuttgart. If you are interested in Dynamo, Revit or BIM –
don’t hesitate to contact me: t.vogt.84@gmail.com or on LinkedIn or just say ‘hello’
on events!
iii
TABLE OF CONTENTS
Acknowledgements ..................................................................................... ii
List of Illustrations ...................................................................................... vi
List of Tables ................................................................................................ x
Preface ......................................................................................................... xi
List of Abbreviations ................................................................................. xii
Abstract ..................................................................................................... xiii
1 Introduction ..................................................................................... 1
1.1 Background ................................................................................................... 1
1.2 Rationale of the study .................................................................................... 2
1.3 Research aim and questions .......................................................................... 3
1.4 Research objectives ....................................................................................... 4
1.5 Scope of research ........................................................................................... 5
1.6 Research method ........................................................................................... 6
1.7 Limitations..................................................................................................... 7
1.8 Dissertation structure ..................................................................................... 8
2 Fundamentals of graphical programming .................................... 9

2.1 The current BIM design data authoring process and its limitations .............. 9
2.2 Multi-Criteria Design Optimisation ............................................................ 13
2.3 Algorithms ................................................................................................... 13
2.4 Textual programming and advanced scripting ............................................ 15
2.5 History of graphical programming .............................................................. 15
2.6 Graphical programming principles .............................................................. 18
2.7 From graphical programming to BIM 2.0 ................................................... 24
2.8 Summary ..................................................................................................... 26
3 Graphical programming with Dynamo ........................................ 27

3.1 Developer principles and value goals .......................................................... 29
3.2 Dynamo overview ....................................................................................... 31
3.3 Technology implementation ........................................................................ 34
3.3.1 Computational design: Analysis and optimisation .................................. 34
3.3.2 Model management and quality assurance.............................................. 35
3.3.3 Integration of external software and hardware ........................................ 37
3.4 Technological challenges ............................................................................ 38
3.5 Advantages and areas for improvements ..................................................... 38
3.6 Future of Dynamo ....................................................................................... 40
3.7 Summary ..................................................................................................... 42
iv
4 Research method .......................................................................... 44

4.1 Collecting data through a web-based survey ............................................... 44
4.2 Strategy of data collection ........................................................................... 45
4.3 Analysing survey data ................................................................................. 46
5 Survey Results and Data Analysis .............................................. 47

5.1 Introduction ................................................................................................. 47
5.2 General participant characteristics .............................................................. 48
5.3 Textual programming skills......................................................................... 48
5.4 Revit macro usage ....................................................................................... 49
5.5 Dynamo skills .............................................................................................. 53
5.6 Tasks and problems solved with Dynamo ................................................... 58
5.7 Effects of applying Dynamo ........................................................................ 59
5.8 Dynamo dissemination ................................................................................ 61
5.9 Dynamo node development ......................................................................... 65
5.10 Publishing of Dynamo nodes ...................................................................... 67
5.11 Commercial node-packages......................................................................... 70
5.12 Dynamo platform development ................................................................... 73
5.13 Future success of Dynamo .......................................................................... 74
5.14 Software skills of the participants ............................................................... 76
6 Discussion..................................................................................... 77
7 Conclusion .................................................................................... 82
APPENDICES.............................................................................................. 85
A Appendix ....................................................................................... 85
A.1 Survey participant introductions ................................................................. 85
A.2 Survey questions and data distribution ........................................................ 86
A.2.1 Question 1 ............................................................................................... 86
A.2.2 Question 2 ............................................................................................... 87
A.2.3 Question 3 ............................................................................................... 89
A.2.4 Question 4 ............................................................................................... 90
A.2.5 Question 5 ............................................................................................... 91
A.2.6 Question 6 ............................................................................................... 92
A.2.7 Question 7 ............................................................................................... 93
A.2.8 Question 8 ............................................................................................... 94
A.2.9 Question 9 ............................................................................................... 95
A.2.10 Question 10 ............................................................................................. 96
A.2.11 Question 11 ............................................................................................. 98
A.2.12 Question 12 ........................................................................................... 102
A.2.13 Question 13 ........................................................................................... 105
A.2.14 Question 14 ........................................................................................... 106
v
A.2.15 Question 15 ........................................................................................... 107

A.2.16 Question 16 ........................................................................................... 108
A.2.17 Question 17 ........................................................................................... 109
A.2.18 Question 18 ........................................................................................... 110
A.2.19 Question 19 ........................................................................................... 111
A.2.20 Question 20 ........................................................................................... 112
A.2.21 Question 21 ........................................................................................... 113
A.2.22 Question 22 ........................................................................................... 115
A.2.23 Question 24 ........................................................................................... 116
A.2.24 Question 25 ........................................................................................... 117
References................................................................................................ 119
Bibliography ............................................................................................. 127

vi
LIST OF ILLUSTRATIONS
Figure 2.1: Design optimisation (Aish et al., 2012, p. 4) .......................................... 11

Figure 2.2: Visualized Excel dependencies between cells (Kumar, 2013) ................ 17
Figure 2.3: Graphical representation and pseudocode of an if-statement (Ritter,
Preidel and Singer, 2015, p. 2) ................................................................ 19
Figure 2.4: “Schematic representation of a black-box and a white-box” node (Preidel
and Borrmann, 2015)............................................................................... 21
Figure 2.5: (a) Plug-Ins structure (left), (b) the integrated structure of graphical
programming (mid) (Davis and Peters, 2013, p. 127) and (c) the bi-
directional connection to more than one application (right) ................... 21
Figure 3.1: Relationship of Dynamo to other applications (inspired by Sgambelluri,
2015h)...................................................................................................... 28
Figure 3.2: Problem solving workflow with Dynamo (Guerra, 2014) ...................... 28
Figure 3.3: Dynamo user interface ............................................................................ 31
Figure 3.4: Node description ..................................................................................... 32
Figure 3.5: Dynamo Groups to modularize collection of nodes (Keough, 2015) ..... 33
Figure 3.6: Dynamo Package Manager (http://dynamopackages.com) ..................... 33
Figure 3.7: Acoustic ray tracing with Dynamo (Vannini, 2015) ............................... 35
Figure 3.8: Visualizing of data and colourized geometry (Keough, 2015) ............... 36
Figure 3.9: Visualized load calculations (CORE studio, no date) ............................. 36
Figure 5.1: Distribution of textual programming skills ............................................. 49
Figure 5.2: Usage of Revit Macros ............................................................................ 50
Figure 5.3: Participants’ textual programming skills who have used Revit macros
successfully ............................................................................................. 51
Figure 5.4: Comparison of textual programming skills between all participants
(dashed bars) and participants who have used Revit macros successfully
(grey bars) ............................................................................................... 52
Figure 5.5: Textual programming skills of participants who wanted but were not able
to use Revit Macros ................................................................................. 52
Figure 5.6: Dynamo skills of all participants ............................................................. 53
Figure 5.7: Participants’ Dynamo skills who have used Revit macros successfully . 54
Figure 5.8: Are textual programming skills important to use Dynamo successfully?
................................................................................................................. 55
vii
................................................................................................................. 55
Figure 5.10: Are textual programming skills important to use Dynamo successfully? .
.......................................................................................................... 56
Figure 5.11: Motivation to learn textual programming by using graphical
programming ........................................................................................... 57
Figure 5.12: Textual programming skills are important to use Dynamo successfully:
Agreements.............................................................................................. 61
Figure 5.13: Percentages of designers who should be able to create and adjust
Dynamo definitions ................................................................................. 62
Figure 5.14: Percentages of designers who should be able to use existing Dynamo
definitions ................................................................................................ 62
Figure 5.15: Development of Dynamo nodes ............................................................ 65
Figure 5.16: Textual programming skills of all participants (dashed) in comparison
with participants who have developed Dynamo nodes before (grey) and
the ratio between them ............................................................................ 66
Figure 5.17: Are the developed Dynamo nodes published ? ..................................... 67
Figure 5.18: Is a node-package store beneficial to the Dynamo community? ........... 70
Figure 5.19: Contribution to the development of Dynamo on GitHub ...................... 74
Figure A.1: Survey flyer: Participant information ..................................................... 85
Figure A.2: Participant introduction and survey Question 1...................................... 86
Figure A.3: Survey question 2 ................................................................................... 87
Figure A.4: Question 2 distribution: Office percent of cases..................................... 88
Figure A.6: Survey data question 3: Role distribution of the participants ................. 89
Figure A.8: Answer distribution of textual programming skills ................................ 90
Figure A.10: Age distribution of the participants .................................................. 91
Figure A.11: Survey question 6 ................................................................................. 92
Figure A.12: Revit Skills of the participants ......................................................... 92
Figure A.14: Usage of Revit Macros ..................................................................... 93
viii
Figure A.16: Average usage hours of graphical programming per week .............. 94
Figure A.18: Dynamo skills of all participants ...................................................... 95
Figure A.19: Survey question 10 ............................................................................... 96
Figure A.20: Are textual programming skills important to use Dynamo successfully?
.. 97
Figure A.21: Survey question 11 ............................................................................... 98
Figure A.22: Survey question 12 ............................................................................. 102
Figure A.24: Percentages of designers in the office who are able to create Dynamo
definitions .............................................................................................. 105
Figure A.26: Percentages of designers who should be able to create and adjust
Dynamo definitions ............................................................................... 106
Figure A.28: Percentages of designers who should be able to use existing Dynamo
definitions .............................................................................................. 107
Figure A.30: Development of Dynamo nodes ......................................................... 108
Figure A.32: Are the developed Dynamo nodes published ?................................... 109
Figure A.34: Motivation to learn textual programming by using graphical
programming ......................................................................................... 110
Figure A.36: Contribution to the development of Dynamo on GitHub ................... 111
Figure A.38: Reasons for companies not to share custom nodes with the community .
113
Figure A.40: Possible motivations for developers to share nodes with the community
114
Figure A.42: Is a node-package store beneficial to the Dynamo community? ........ 115
ix

x
LIST OF TABLES
Table 3.1: Selection of existing software connections to Dynamo .......................... 37

Table 5.1: Cross tabulation of Revit skills and usage of Revit Macros ................... 50
Table 5.2: Motivation to learn textual programming as a function of the textual
programming skills .................................................................................. 58
Table 5.3: Most frequently solved problems with Dynamo ..................................... 58
Table 5.3: Agreement distribution about statements on effects of applying Dynamo
................................................................................................................. 60
Table 5.4: Percentages of designers who should be able to create and adjust
Dynamo definitions in comparison with the Dynamo skills ................... 63
Table 5.5: Percentages of designers who should be able to use existing Dynamo
definitions in comparison with the Dynamo skills .................................. 64
Table 5.6: Possible reasons for companies not to share custom nodes with the
community............................................................................................... 69
Table 5.7: Possible motivations for developers to share nodes with the community
................................................................................................................. 70
Table 5.8: Future success factors for Dynamo ......................................................... 75
Table 5.9: Software skills distribution...................................................................... 76
Table A.1: Question 2 statistics: Office type frequencies ......................................... 87
Table A.2: Revit Skills of the participants ................................................................ 92
Table A.3: Agreement distribution about statements on effects of applying Dynamo
................................................................................................................. 97
Table A.4: Most frequently solved problems with Dynamo ..................................... 98
Table A.4: Possible reasons for companies not to share custom nodes with the
community............................................................................................. 112
Table A.5: Possible motivations for developers to share nodes with the community
............................................................................................................... 114
Table A.7: Software skills distribution.................................................................... 117
xi
PREFACE
Some years ago, when I came in contact with Revit for the first time at the University
of Leeds at my Erasmus year, I was fascinated by the software. In Stuttgart
(Germany) the university was still teaching hand sketching and AutoCAD and they
never mentioned something like BIM or model-based design. A classmate in Leeds
was researching for his bachelor thesis about BIM and he has explained me the
basics of BIM and the possibilities. So the first step after coming back from Leeds
was to find someone who has experience with BIM and Revit. There was one office
in Stuttgart, an Autodesk partner with proven experience at Revit and BIM:
HAFNER’S BÜRO and my future mentor Ralf Schmitz – an early adopter and a
consulting office for Revit and BIM implementation. Still be a student at the
University of Applied Science Stuttgart I have worked there part-time, to search for
an interesting bachelor thesis topic, to learn Revit in more detail, to read books and
magazines about Revit and BIM stuff. Thus I discovered the company FARO and its
laser scanner Focus 3D. They have their headquarters not far away from Stuttgart
and I asked them for supporting my work with a laser scanner – at these days it was a
new way of working, especially with the combination with Revit. After I have
successfully finished my bachelor degree I have worked about one year for ‘Boll und
Partner’ a structural engineering office in Stuttgart. They got already outstanding
experience with Revit and SOFiSTiK. And one of the directors got some
programming skills and used it to automate some steps. For me it was fascinating and
at the same time I have discovered the visual programming tool Dynamo. The
community was still very small but I saw the potential of using it without having
serious troubles without textual programming skills. I was attending several events in
Europe and met other Dynamo enthusiasts. Today Dynamo is on a good way to
becoming a mainstream tool. So the research topic for my master thesis was obvious
– Graphical programming with Dynamo. How is it used? Who can learn it? What is
the opinion of others?
As you will see in my research it is a helpful tool for nearly everyone working with
Revit. But there is a limitation at some point and you have to go the extra mile and
learn how to program to solve all problems out there. Thus I will start in 2016 to
extend my skills with textual programming and I hope to be able then to extend
Dynamo and can be a part of the developer team.
xii
LIST OF ABBREVIATIONS
AEC Architectural, Engineering and Construction

API Application programming interface
BIM Building Information Modelling
CAD Computer Aided Design
CAM Computer Aided Manufacturing
DLL Dynamic Link Library
FFI Foreign Function Interface
GP Graphical Programming
GPL Graphical Programming Language
IDE Integrated Development Environment
LSI Latent Semantic Indexing
TPL Textual Programming Language
VBA Visual Basic for Applications
VP Visual Programming
VPL Visual Programming Language
xiii
ABSTRACT
In the last decade the design process in the AEC industry was strongly influenced by
new tools, which are based on the method Building Information Modelling.
Shortcomings like the lack of suitable computational approaches available for
designers and engineers were identified. Several textual programming approaches for
automating tasks have failed due to various reasons. The success of Grasshopper has
highlighted the demand for tools, which can be used by non-programmers but still
have the ability to create algorithms for multi-criteria design optimisations. Several
software manufacturers have started to offer graphical programming tools in the last
years. Thus the promising graphical programming tool ‘Dynamo’ and its usage have
been studied in detail. Therefore a survey about Dynamo was conducted and
evaluated and compared with the findings from existing literature. The research
presents technical details about the software and possible future developments. The
results show a clear acceptance by non-programmers and also areas for
improvement. Overall Dynamo has proven to be a suitable approach for the BIM
design workflow by reducing labour time, better quality assurance, and by supporting
interoperability of software.
Keywords: Building Information Modelling (BIM); BIM Management; BIM

Workflow; Parametric Design; Algorithm-aided Design; Visual Programming;
Graphical Programming; Dynamo; DynamoBIM; Computational Design.
CHAPTER 1
1 INTRODUCTION
1.1 Background
The emergence of Building Information Modelling (BIM) and its latest development
to become a mainstream method for designing and analysing the lifecycle of the built
environment has consequences on how to handle and use the increasing amount of
data effectively. With BIM enabled tools all data has a direct or indirect relationship
to each other by creating a database which represents a digital copy of a project. The
database can be visually represented as a digital model and it has also intelligence
and properties embedded in its objects. Despite all that, the design process with BIM
tools is still a widely manual process. To some degree parametrical intelligence and
dependencies are embedded in the objects. But artificial intelligence spanning the
whole model by using algorithms is rarely integrated in this workflow. The high
expectations by clients, the complexity of given sites and conditions, and the
pressure to optimize the design workflow has resulted in new data management and
data manipulation tools. These are graphical programming tools. They use the
intelligence and flexibility of textual programming languages and embed its
functionalities into graphical nodes which can be visually connected to each other.
Thus non-programmers are not confronted with abstract syntaxes and receive instant
visual feedback of their actions.
Graphical programming is used since the early days of programming to simplify the
understanding by using a visual representation of logical connections and its results.
It is also known as visual programming, but this term has equivocal meanings and to
prevent misunderstandings former term is used.
Several graphical programming tools for design have emerged over the last years and
nearly every BIM enabled design tool has today its counterpart for graphical
programming. In this research project the focus is on the graphical programming tool
Dynamo.
Dynamo has been originally developed as a data manipulation tool for Autodesk
Revit. But the open-source strategy and the demand by users has led to many
additional software connections.
1. Introduction 2
1.2 Rationale of the study
The literature about Dynamo is very limited. There are only papers that cover
Dynamo rudimentarily and internet resource like blogs from the Dynamo
community. So it will be a valuable resource for companies and BIM Users.
Companies are always looking for possibilities to simplify, optimize and improve
their processes. They want to reduce especially labour-intensive tasks. The results of
the research shall reveal the potential of Dynamo to help companies and employees
improving their BIM workflows.
Innovators do already understand Dynamo and use it in practice. The study shall give
the early adopters and the early majority in the Architectural, Engineering and
Construction (AEC) industry an overview about the possibilities and areas of
applications. With the results of the research they can assess, if there are areas that
suit to their BIM workflow and how they can improve their BIM workflow to be
more efficient.
During a conversation with BIM Consultants a question has arisen, if visual

programming is necessary for a good design and how many employees should have
the skills to use graphical programming software like Dynamo. To answer the
questions of how and why graphical programming is maybe useful to a design
workflow of a project a research about this topic is conducted. Therefore the
characteristics of graphical programming are investigated. Additionally users who
use already the visual programming tool Dynamo in their BIM workflow are
analysed.
1. Introduction 3
1.3 Research aim and questions
Aim of the study
This research intends to study applications and possibilities of Dynamo and how to
improve with Dynamo specific BIM workflows.
Research questions
To ensure that the aim is met, the following questions are to be investigated:
 How effective is the usage of graphical programming in a BIM project to

solve specific problems and what are the reasons?
 To what extent is graphical programming effective at helping to improve the

BIM workflow?
 Can a BIM workflow improved with graphical programming?
 What are the barriers to use graphical programming (Dynamo)?
 What are the key factors for successful graphical programming software?
 What types of employees are using graphical programming (Dynamo) already

and how often?
 What are common day-to-day tasks for graphical programming (Dynamo)?
 Which types of projects are suitable for graphical programming (Dynamo)

and what are the reasons?
 How can the economic value of graphical programming (Dynamo) be

measured?
 Who and how much percent of a design team should be able to use graphical
programming (Dynamo)?
 What implications/effects have the use of graphical programming (Dynamo)

on the employees regarding outcome, job satisfaction and job performance (at
the learning phase and later at the usage phase)?
1. Introduction 4
1.4 Research objectives
To ensure that the aim is met, the following objectives need to be investigated:
 Investigate literature and documentation about the computational

design/algorithms-aided design and Dynamo to understand the principles of
graphical programming, the software Dynamo and describe the interface and
main software functions.
 Gather information how companies already use the software to improve their
BIM workflow
 Test the hypotheses ‘The application of Dynamo improves specific BIM

workflows’ with the results of the quantitative questionnaire
 Retesting selected application areas mentioned by the participants (AEC

companies/offices) to evaluate the personal findings (how and why Dynamo
improves a BIM workflow) with the results of the questionnaires and
interviews.
 Investigate the cause and effect of using graphical programming in a BIM

workflow.
1. Introduction 5
1.5 Scope of research
The scope of this research is to investigate how the design phase of BIM project can
be affected by the usage of the graphical programming tool Dynamo. The research
investigates the current application opportunities of Dynamo and how and why it can
be integrated into a BIM workflow. The research is broken into four stages:
A literature study about graphical programming, a review study of graphical
programming with Dynamo, a survey about Dynamo and its results, and a discussion
of the findings in relation to the literature.
In the first and second stage a literature study is conducted to get an understanding
about graphical programming, the software Dynamo and its possibilities. This
includes software tutorials and reading of blog posts as well, because an initial
research has indicated that there are only very few scientific papers about Dynamo
available.
In the third stage a structured questionnaire with qualitative and quantitative

questions is conducted to get primary data of how and why Dynamo is applied. The
primary evidence is gathered from BIM users which apply Dynamo in their BIM
workflows; this can be, for example, BIM Managers, BIM Coordinators, BIM
Modellers or Revit Technicians. The quantitative questionnaire data is used to get a
broad view of the Dynamo users and to create sub-samples of interest to find patterns
and correlations in the data.
In the last stage the primary data from questionnaire and the secondary data from the
literature study are discussed to identify typical scenarios and patterns in which
Dynamo is applied. In the conclusion all findings are assembled and the propositions
or hypotheses produced can serve as a basis for further research.
1. Introduction 6
1.6 Research method
There are two major philosophical schools of thought – positivism and post-
positivism (interpretivism). This research uses interpretivism to compare the effects
of cause of interest relative to other conditions (with Dynamo and without Dynamo).
It is an inductive research because it begins with specific observations and measures
to detect patterns and regularities, formulate some tentative hypotheses that can be
explored, and finally end up developing some general conclusions or theories
(Trochim, 2006a). “Inductive reasoning […] is more open-ended and exploratory,
especially at the beginning” (Trochim, 2006a).
“Epistemology is the philosophy of knowledge or of how we come to know”
(Trochim, 2006b). A positivist view needs a truth (internal validity) to understand the
world, but to measure thoughts of how and why (Trochim, 2006b), a post-positivism
approach is used in this research. Critical realism recognises “that all observation is
fallible and has error and that all theory is revisable” (Trochim, 2006b). Because
everyone constructs a view of ‘the world’ based on their perceptions (different
background / discipline) a constructivist view is used. Objectivity cannot be achieved
because every individual observation is biased. To approach objectivity different
perspectives are researched (Trochim, 2006b).
The research in construction and especially in BIM is relatively ‘nascent’ in maturity.
Edmondson and McManus (2007, p. 1160) propose in a table for a nascent state of
prior theory and research open-ended inquiry about a phenomenon of interest. Thus
this research uses quantitative and qualitative data in the questionnaire. The goal of
the data analysis is to identify a pattern and to provide a suggestive theory as an
invitation for further work on the issue (Edmondson and McManus, 2007, p. 1160).
Fellows and Liu (2015) distinct pure research and applied research. They argue “pure
research is undertaken to develop scientific knowledge, to contribute to the body of
theory which exists – to aid the search for the ‘truth’”(Fellows and Liu, 2015, p. 8).
Further they argue applied research seeks to address issues of applications to help
solve a practical problem.
Thus the proposed overall methodology is not strictly an action research approach,
because investigated “open ended problem” (Fellows and Liu, 2015, p. 8) scenarios
are based on results of the questionnaires.
In this case of action research the interest of knowledge generation is practical
interest.
1. Introduction 7
It “refers to an orientation toward gaining understanding through interpretation. The

researcher engaged in the pursuit of practical interest employs interpretive
methodologies – primarily hermeneutic interpretation – in an effort to provide
understanding of a given situation” (Herr and Anderson, 2005, p. 27).
“As triangulated studies employ two or more research techniques, qualitative and
quantitative approaches may be employed to reduce or eliminate disadvantages of
each individual approach while gaining the advantages of each, and of the
combination – a multi-dimensional view of the subject, gained through synergy”
(Fellows and Liu, 2015, p. 29).
Thus the quantitative data gives information about a large sample of Dynamo users
and it easier due to the high fragmentation of the AEC industry to identify a pattern.
The qualitative data uses methods of field research.
Field research “aims to produce factual descriptions based on face-to-face knowledge
of individuals in their natural settings. […] This method is commonly used for
providing an in-depth description of procedures, beliefs and knowledge […] for
exploring the reasons for certain behaviours including the opinions of respondents
about particular issues” (Ebrahim and Sullivan, 1995, p. 196).
The literature research, the process of software understanding and the questionnaire
will have also some elements of an exploratory research. Exploratory research “tends
to tackle new problems on which little or no previous research has been done”
(Brown, 2006, p. 45).
Social exploratory research "seeks to find out how people get along in the setting
under question, what meanings they give to their actions, and what issues concern
them. The goal is to learn 'what is going on here?' and to investigate social
phenomena without explicit expectations." (Schutt, 2006)
1.7 Limitations
 Limitation is maybe the unwillingness of the participants to share their

knowledge.
 The author has no control about the honesty and accuracy of the participants’
responses.
1. Introduction 8
 The reliability of the study is potentially limited by a relatively low sample

size. Maybe not every discipline is represented by participants.
 It is likely that only participants from very innovative companies answer the
questionnaire, because BIM is still a very new method and applied BIM
combined visual programming is very rare.
 The reader should be familiar with the general background of BIM and Revit.
 The functions of Dynamo and the possible combinations of functions cannot

all be covered.
 The focus researcher is not programming new scripts or nodes. Instead the
available nodes are used to show possible solutions. Due to the large number
of nodes, most of the nodes cannot be covered in detail.
1.8 Dissertation structure
The dissertation is structured into seven main chapters and the appendix:
In in the first chapter the work is introduced with reasons, aim, research questions,
scope and suitable methods of the research. The second and third chapter are based
on literature, practical experience with graphical programming and opinions by
experts. The second chapter evaluates the fundamentals of graphical programming
and looks back into the history of graphical programming to the integration of
graphical programming into BIM. The third chapter has the focus on the graphical
programming tool Dynamo. It is discussed how it works, what is possible with
Dynamo, technological challenges and a future outlook. The fourth chapter justifies
the research method and explains the survey setup. In the fifth chapter important
survey results are presented and discussed. The data analysis and the discussion are
based on many graphs and tables. Chapter six compares the research findings to the
existing literature and in chapter seven the research conclusion is presented.
2. Fundamentals of graphical programming 9
2 FUNDAMENTALS OF GRAPHICAL PROGRAMMING
In this chapter available literature is analysed and relevant topics are discussed: the
current BIM design data authoring process, its limitations, and ways to overcome
them (chapter 2.1); how multi-criteria design optimisation (chapter 2.2) can be
automated with algorithms (chapter 2.3). Subsequently the discussion continues with
the technical solution by using programming and advanced scripting (chapter 2.4)
and how the usage of programming can be simplified by graphical programming
(chapter 2.6). As a practical example of graphical programming in the context of
BIM, the software Dynamo is introduced and evaluated in chapter 3.
2.1 The current BIM design data authoring process

and its limitations
Coenders (2010, p. 1113) argues that current state of practice is far from the ‘BIM
vision’, because “current software applications are too simplistic” and “only support
limited complexity in objects and geometry”. The “lack of use and availability of
suitable computational approaches in the design process” (Coenders, 2010, p. 1113)
and the lack of interoperability between software leads to information loss. As
intelligent, parametric objects “are saved as generic 3D geometry to be processed by
Computer Aided Manufacturing (CAM)”, all intelligence is lost and “changes to the
parametric design cannot directly propagate to the CAM environment” (Braumann
and Brell-Cokcan, 2014, p. 101)
The foundations to be able to use computational approaches are available, but are not
used properly. Prototyping comes often with manual “problem-solving through trial
and error” (Braumann and Brell-Cokcan, 2014, p. 101) and experience instead of
using intelligent algorithms based on data and facts. The typical properties of digital
models are defined in the literature as data-rich, object-oriented, intelligent,
parametric, digital, shared knowledge resource, whole life-cycle. In addition the user
has the ability to “insert, extract, update, or modify information” (‘National Building
Information Modeling Standard’, 2010, p. 21). “Today, a significant part of the
technical feedback in the construction industry is generated by software” (Braumann
and Brell-Cokcan, 2014, p. 101). The software is capable of “calculating a building’s

performance and even evaluating if a building confirms to zoning and construction
laws” (Braumann and Brell-Cokcan, 2014, p. 101). But the current BIM software
tools are applied widely as data storage during the design process and the design
process itself is still mainly a “manual modelling approach” (Coenders, 2010, p.
1113). The problem of the actual “situation is that designers do not take advantage of
the computational power of the computer” (Terzidis, 2006a, p. xi).
It is important to understand “the distinction between computation and

computerisation” (Menges and Ahlquist, 2011, p. 10). Computation is about “rule-
based intelligence”, simulations (Terzidis, 2006a, p. xi) and iterations. Computation
aims at extending the human intellect with rationalization, reasoning, logic,
algorithm, and estimation (Terzidis, 2006a, p. xi). In contrast, computerisation
“involves the digitization of entities or processes that are” already conceptualized,
“preconceived, predetermined, and well defined” in the designer’s mind (Terzidis,
2006a, p. xi). In a workflow of computerisation, the generation, manipulation,
organisation, and storage of data is mostly done in a manual and sometimes in a
semi-automated process by the designer.
There are no suitable tools to access and handle the data in an intelligent way. No
one can assure the veracity of the vast amount of collected data. The challenge is to
connect data with design standards, the real world conditions, and beyond. The
current BIM tools focus mainly on data storage and have difficulties to deal with
design changes in a mature level of design (Coenders, 2010, p. 1122).
Add-ons and specialized analysis software “often reflect the assumptions of the […]
creator and may be restricted by these assumptions, while at the same time such
generality may not be matched to the specific design problem being tackled” (Aish et
al., 2012, p. 3). But “rather than fully automating the design process, approaches are
required that allow quick and intuitive changes of key parameters” (Braumann and
Brell-Cokcan, 2014, p. 101)
“The rising problem of increased complexity, […] amount of information in building

design” (Coenders, 2010, p. 1119) and fast iteration cycles of design need a strategy
to enhance the control of an engineer. ‘Rule-processing’ is such a strategy to create
optimized design solutions or to validate current design conditions in accordance to

standards and physical limits. With real-time feedback in form of success, failure, or
efficiency presented on dashboard view, the user quickly gets indication of important
aspects and its feasibility (Coenders, 2010, p. 1118).
The goal should be to combine “generative mechanisms and analytical/evaluative

mechanisms into a connected iterative process” (Aish et al., 2012, p. 4). The vast
amount of possible combinations necessitates a method which automates this process
(Figure 2.1). This is achieved by defining rules to assess combinations against each
other, and with “mechanisms to automatically generate new […] configurations”
(Aish et al., 2012, p. 4). “Digital Scripting allows the manipulations of parameters of
the design based on the results of analytical evaluation of the model during the
development of the design itself and thereby changes the nature of the design
process” (Kensek and Noble, 2014, p. 87).
Figure 2.1: Design optimisation (Aish et al., 2012, p. 4)
Lopez has investigated several textual and visual programming languages for
generative design. His conclusion leads to “a great need for a modern programming
environment for” generative design, because the “most used tools” available in 2012
were “unsuitable choices” (Lopes, 2012, p. 69). Lopez suggested four necessary
properties of a programming language:
 be pedagogic
 provide domain-specific features

 provide multiple programming languages
 provide [connection to] multiple CAD applications
As well as design principles to overcome identified problems (Lopes, 2012, p. 69):
 portability
 parametric elements
 functional operations
 dimension independent operations
 algebra of sets
 algebraic equivalences
 traceability
 immediate feedback
Until today this can be achieved not sufficiently with advanced scripting or textual
programming techniques (chapter 2.4). And particularly the average software user
has no skills in textual programming to create such an iterative process. Thus these
scripting techniques are “(a) only applicable for use on well-defined problems in
complex large scale projects (b) are not sufficiently general reusable (c) require
considerable insight on the part of the users and (d) are therefore not practical for the
use by non-experts” (Aish et al., 2012, p. 3). The focus of a designer moves in the
future from modelling, analysing and evaluating to a “strategic role of ‘controlling’”
(Aish et al., 2012, p. 5) functions, rules and variables (Figure 2.1).
A simulation and analysis of one single case is not enough, instead “statistical
methods, adaptive modelling, machine learning and pattern recognition algorithms
for identifying persistent structures in models (Hanna et al., 2010, p. 1). Instead a
generative way of design with many differing simulations is needed “for re-
evaluation of constraints and a ‘geometry building’ process” (Fischer et al., 2012, p.
541).
Google has shown recently interest in the building industry (Deutsch, 2014, no page),
as they get their strength from the collected data. The well-known strategy of google
is to use data to make profit. Flux, a software manufacturer financed among others
by Google, has plans to automate the design process and “shorten the time from the
start of planning to market by 30-60%” (Deutsch, 2014, no page). And the designers
should be interested to use the available data to design better as well.
2.2 Multi-Criteria Design Optimisation
To effectively satisfy the expected performance of a building, “multiple potentially

conflicting performance criteria” (Aish et al., 2012, p. 1) need to be considered.
“Complex multi-variable equations results that can be solved computationally
through adjustment and iteration […] allows the designer to see, understand, and
select from a wide range of potential options“ (Kensek and Noble, 2014, p. 87).
Therefor interactions between these subsystems need to be considered and trade-off’s
need to be made (Aish et al., 2012, p. 3).
Human abilities are limited in comparing a vast amount of possible options with
overlooking many criteria and parameters. Human decisions are based on experience.
This can be observed at traditional buildings and typical houses for specific areas,
which have all similar appearance, functionality and materials. Especially modern
buildings with many special requirements are difficult to optimize without advanced
decision techniques. Manual algorithm techniques are limited, and thus
computational techniques with software using algorithms are essential to include all
criteria.
2.3 Algorithms
Both, Computational design and generative design are based on algorithms. And
there are various definitions of the term ‘algorithm’ and some of them suitable to the
topic under discussion are listed below:
“An algorithm is a finite sequence of explicit, elementary instructions

described in an exact, complete yet general manner” (Menges and
Ahlquist, 2011, p. 11).
“An algorithm is a procedure for addressing a problem in a finite

number of steps using logical if-then-else operations” (Terzidis, 2006a,
p. xii).
“An algorithm is a finite set of instructions that aim to fulfil a clearly

defined purpose in a finite number of steps. An algorithm takes one value
or a set of values as input, executes a series of computational steps that
transform the input, and finally produces one value or a set of values as
output” (Dino, 2012, p. 210).
“Informally, an algorithm is any well-defined computational procedure

that takes some value, or set of values, as input and produces some value,
or set of values, as output. An algorithm is thus a sequence of
computational steps that transform the input into the output”. […] “We
can also view an algorithm as a tool for solving a well-specified
computational problem. The statement of the problem specifies in
general terms the desired input/output relationship. The algorithm
describes a specific computational procedure for achieving that
input/output relationship” (Cormen, 2009, p. 5).
Furthermore Dino has stated 4 elements of an algorithmic generative process (Dino,

2012, p. 209):
1. Start Conditions and parameters (input)
2. Generative mechanisms (rules, algorithms etc.)
3. The act of generation of the variants (output)
4. Decision to stop the iteration and selection of the best variant
Algorithms have the ability to solve computational problems like sorting and
searching, data structure operations, combinatorial problems, numerical problems,
and computational geometry. But the quality of the final result depends on the
designer’s coding, interpretation and manipulation skills. Even with powerful
computers of today, a poor defined algorithm will produce poor or erroneous results.
A well-defined algorithm, with the support of multicore computers, will solve the
problem faster, more efficiently and produce the correct answer (Cormen, 2009, pp.
10–11).
2.4 Textual programming and advanced scripting
To create an algorithm, the actions have to be defined with a computer readable

programming language and have to be compiled into an executable program.
Embedded are instructions on how to react to specific conditions. Compared to
human iterative improvement cycles, the instructions included in an algorithm can be
executed much faster without the risk of human errors. “The use of parametric
scripting in combination with analytical results from digital simulation tools
broadens the designer’s power considerably” (Kensek and Noble, 2014, p. 87). Thus
it is possible to test many variations to find an optimized and efficient solution. “By
creating a script that controls and manipulates the characteristics of the design, the
designer […] embeds the characteristics of the design intent within the solution
itself” (Kensek and Noble, 2014, p. 87).
The difficulty and hurdle for designers is the abstract way of writing the textual code
and to know and understand the language specific syntax. Therefore the designers
have to familiarize with a complete new field of knowledge. Efforts by software
manufacturers to encourage designers to use algorithms into their daily work by
using textual languages have been available for several years. For example the Macro
Manager or the RevitPythonShell extension for Revit: both of them are textual
programming interfaces to automate tasks in Revit. To use these tools, designers
have to know they exist and have to be interested in coding, which most designers
won’t be; therefore narrowing the field of users.
2.5 History of graphical programming
One of the earliest graphical programming languages is maybe the ‘Graphical

Program Editor’ designed in 1966 by William Sutherland (Sutherland, 1966). He was
influenced by his brother, Ivan Sutherland, who wrote the ‘Sketchpad’ in 1963. The
Sketchpad has influenced the human-computer interaction (Sutherland, 1964) and
Smiths computer program Pygmalion (Smith, 1977) which coined the term ‘icon’,
making it clearer that graphical images could portray a programming language
(Blackwell and Rodden, 2003). “For example, in the late ‘70s, logic design systems
were made available in a [Latent Semantic Indexing ] (LSI) CAD environment”, but
this kind of system “is highly application-specific and its generality is limited” and
the “development of general-purpose visual programming languages/systems has
been carried out since the middle ‘80s” (Hirakawa and Ichikawa, 1992, p. 538).
The first attempts were targeting to completely avoid text, because “the one-
dimensional, textual, and static representation” was seen as main reason for
frustration and difficulties (Glinert and Tanimoto, 1984, p. 7; Schiffer, 1996, p. 7).
Schiffer claims such attempts as impractical, because graphical components need to
have a meaningful label and notes to explain important program parts (Schiffer,
1996, p. 7). Shu (1988, p. 9) defined visual programming as “the use of meaningful
graphic representations in the process of programming”. Hirakawa and Ichikawa
(1992, p. 538) have a similar point of view by defining visual programming as “the
activity of making programs through spatial manipulation of visual elements, that is,
a language which is inself visual”. According to Menzies (1998, p. 2) a visual
programming system “is a computer system whose execution can be specified
without scripting”, and according to Menzies a pure Visual Programming (VP)
system must “satisfy two criteria”: “The system must execute” […] and the
“specifications of the program must be modifiable within the system’s visual
environment […]”, otherwise the system is called “visually supported” (Menzies,
1998, p. 2). In contrast, today there too many functions necessary to cover all needs.
Some types of elements can be graphically distinguished by colour or form but the
use of unique textual identifiers is inevitable.
Myers (1990, p. 1) notes that “the success of spreadsheets can be partially attributed
to the ability of users to write programs”. The created dependencies between the cells
using formulas can be interpreted as parametric behaviour. A visualization of these
dependencies reveals the similarities to modern graphical programming interfaces
(Figure 2.2).
Figure 2.2: Visualized Excel dependencies between cells (Kumar, 2013)
Due to a steep decline in computing costs and an increase in wages (Shu, 1988, p. 5)
it is valuable to have office staff with expert domain knowledge and additionally
with skills to create algorithms. Thus it is possible to minimize manual tasks and
automate workflows without “depending on programmers as middlemen to develop
their applications” (Shu, 1988, p. 6). With graphical programming the pool of
programmers can be extended to such individuals who have expert domain
knowledge but limited software engineering knowledge (Murray and McDaid, 1993;
Hayden, 1995).
The increase in popularity of graphical programming in many different software
types like music, video, media, and geometry editors laid the groundwork for modern
graphical programming environments. A online compilation of software using visual
programming is presented by Eric Hosick (Hosick, 2014) and some types are
presented below (not a definitive list):
 Music production software (e.g. Pure Data Max, Reaktor, …)
 Material editors (e.g. 3DS Max, Maya, Blender, Shake, Fusion, …)
 Game engines (e.g. Unreal Engine, Unity, …)
 Game editors (e.g. Minecraft, …)
 Video editors (e.g. vvvv, …)

 Teaching (e.g. Scratch, …)
 Geometry editors (GenerativeComponents, Grasshopper, Dynamo…)
Geometry editors like Grasshopper can be seen as the precursor in manipulating two-
dimensional (2D) and three-dimensional (3D) geometry in the AEC industry. Until a
few years ago, the focus was on algorithmic and generative approaches to describe a
shape and its manipulation by rules and constraints (Leitão and Santos, 2011, p. 549).
The development of Computers, BIM tools and BIM processes, using data rich
digital models with embedded realistic properties as parameters, required an
approach to use the embedded data. The attempt to give the average designer a
textual scripting interface (Chapter 2.4) to use the embedded data in an automated
way was not adopted by the majority than initially anticipated. Thus BIM authoring
tools try to connect today to various graphical programming tools (Grasshopper,
Dynamo, Marionette etc.).
The developmental history of graphical programming shows that graphical

programming gain acceptance by professional programmers until today only for
schematic design of software components and its interrelationships. Leitão and
Santos (2011, p. 549) argue that “when the complexity of the design problem
increases,” textual programming languages “can be more productive than” visual
programming languages. Their statement is maybe acceptable for specific complex
scenarios; but in recent years there is a clear trend and increasing demand by the
average AEC designers to use additional graphical programming interfaces to solve
design problems with algorithms. So far this was mainly accomplished by using
abstract programming and scripting methods (Chapter 2.4).
2.6 Graphical programming principles
Graphical programming or also termed as visual programming uses the concept of

textual programming, but simplifies the abstractness by replacing textual code
snippets with graphical components. “In the conventional sense, […] [graphical
programming] languages also have well defined syntax and semantics” (Hayden,
1995), but presented in a more convenient and less abstract form for non-
programmers.
The graphical code snippets are in themselves normally without syntax errors and are
visually presented as graphical nodes. The nodes can have inlets, outlets, input fields,
sliders, buttons etc. Memorable graphical interfaces like buttons, sliders, switches
and visual display units are recognized by the users from the real world. The optical
impact, intuitive handling, low risk of errors, the direct feedback and the ability of an
easy manipulation increase to motivation of the user (Schiffer, 1996, p. 17). “At any
time and degree of completion […], the user is able to understand inspect every
single processing step” (Preidel and Borrmann, 2015, p. 4).
The usage of the visual components with embedded and pretested code prevents
typical misspelling of traditional programming code writing. The textual code used at
traditional programming is hence mainly hidden behind the graphical components
(Figure 2.3). With this flexible approach it is not necessary anymore to memorize “a
[abstract] syntax or an API” (Babic, 2012, no page) to create algorithms. Thus the
main sources of errors in graphical algorithms are logical mistakes (Vollenweider,
2013, no page). And if “errors are identified in the processing chain, the system can
be adjusted very quickly and simply according to the user’s requirements” (Preidel
and Borrmann, 2015, p. 4). A characteristic feature of graphical programming is the
combination of nodes (graphical program modules) to create new functionalities
suitable to the desired task.
Figure 2.3: Graphical representation and pseudocode of an if-statement

(Ritter, Preidel and Singer, 2015, p. 2)
A node itself has limited functionality to be able to act for different purposes, but it
has enough flexibility to avoid unnecessary node combinations. All nodes can be
individually adjusted. The semi-abstract appearance of nodes and the graphical aids
like buttons, sliders, mathematical expressions, icons, and state of the node by
colour, help to understand the logic of an algorithm. Labels with class and function
or pictogram can help to interpret the nodes (Ritter, Preidel and Singer, 2015, p. 3).
Pictograms use less space and support the interpretation of the logic. But the great
amount of pictograms and the little difference between the functionality cannot be
interpreted intuitively (Ritter, Preidel and Singer, 2015, p. 3).
For advanced users it is still possible to extend the graphical nodes with scripting
languages by using special ‘code-block nodes’ with an embedded text editor
interface. Zhang et al. (2001) have already 1999 registered a patent for such a
functionality. The ability to change between scripting and visual programming
language, mapping one into another, helps to develop “the capacity for understanding
abstract concepts, which is extremely important in architectural design education”
(Celani and Vaz, 2012, p. 136). Babic calls this an “hybrid approach” (Babic, 2012).
The code block node can be used as a replacement for nodes, just to be faster, or to
solve special tasks in which existing nodes are not sufficient or non-existent. Celani
and Vaz point out that “even when a code window is used, it is constrained to a
specific point, so bugs can be easily located” (Celani and Vaz, 2012, p. 128). Schiffer
notes (1996, p. 8), that not everything is visually representable or efficient; for
example mathematically formulas are more precise and manageable in a textual
form.
Once a textual code block is created, it can be converted to a graphical node with the
same functionality (not every graphical programming environment supports this
function). The reusability of created code blocks leads to a higher efficiency and less
syntax errors. There are two different access types of nodes: white-box nodes and
black-box nodes (Figure 2.4). The textual code and the logic in white-box nodes is
accessible and modifiable, whereas the textual code in black-box nodes is compiled
and therefor hidden, nevertheless the node is still fully functional. According to
Green and Petre (1996, p. 136) “novices need ‘progressive evaluation’, an
environment where it is easy to check a program fragment before adding to it”, thus
black-box nodes are contra productive for understanding the logic. Preidel and
Bormann (2015) identified the lack of transparency by using black-box nodes,
because the correctness of the created routines are not verifiable. In contrast to these
opinions and the missing transparency of black-box nodes can be an advantage for
companies, as they are able to hide and protect the intelligence of their created
algorithms against competitors.
Figure 2.4: “Schematic representation of a black-box and a white-box” node (Preidel and Borrmann,
2015)
In the last decade it was common to install plug-ins to extend the functionality of the
core application. Plug-ins are using the Application Programming Interface (API)
from the core application, but they are usually not able to interact between each other
(Figure 2.5a). In contrast to the isolated and more or less inflexible extensions, a
graphical programming environment is hosting the functionality of add-ins within the
nodes (Figure 2.5b). The nodes can “communicate with one another” (Davis and
Peters, 2013, p. 127) and an accessible programming interface allows additional
connection to further core applications with an API (Figure 2.5c). API commands
can be used to create bi-directional connections. For example data is extracted from a
BIM authoring tool and with the help of suitable nodes a bi-directional link to
Microsoft Excel is established. After the manipulation of the data in Excel and with
help of the nodes, the data can be transferred back into the BIM authoring tool.
Therefore recreation or loss of information is prevented and automated iterative
algorithms can be used to optimize solutions.
Figure 2.5: (a) Plug-Ins structure (left), (b) the integrated structure of graphical programming (mid)
(Davis and Peters, 2013, p. 127) and (c) the bi-directional connection to more than one
application (right)
Graphical programming can be compared with component based software

development. Components can be created with traditional programming or via
combining existing nodes to a custom node.
Several advantages and disadvantages of graphical programming have been

identified:
Advantages:
 Picturesque relation to reality (Schiffer, 1996, p. 1)
 Large motivation and learning potential (Schiffer, 1996, p. 1)
 Mitigation of syntactical structures and emphasis on sematic relationships

(Schiffer, 1996, p. 1)
 “trial-and-error process becomes much faster” (Braumann and Brell-Cokcan,

2014, p. 101)
 Using graphical “programming tools, architects and designers are now able to
create their own virtual simulation environments, where they can change key
parameters with the push of a slider and observe the results on their designs
in real time” (Braumann and Brell-Cokcan, 2014, p. 101)
 “constant feedback that supports the designer’s decision-making” (Braumann

and Brell-Cokcan, 2014, p. 101)
 “it is not necessary to compile code, but changes to the parametric definition
are reflected instantly in the viewport, allowing the designer to deduct an
immediate relationship between cause and effect” (Braumann and Brell-
Cokcan, 2014, p. 101).
 Graphical programming environments can be used “not only for rapidly

generating design iterations, but also for integrating custom simulation
functions that graphically support their decision making” (Braumann and
Brell-Cokcan, 2014, p. 101).
 Graphical programming environments like Grasshopper or Dynamo offer all

typical core functionalities and an “accessible approach to programming”
(Braumann and Brell-Cokcan, 2014, p. 102). Thus it is “not necessary to
develop a full interface” (Braumann and Brell-Cokcan, 2014, p. 102). Instead

the user can focus on the development of the necessary additional
functionality.
 Graphical “programming allows the designer to work in a near-real-time

environment, fluently linking design with simulation” (Braumann and Brell-
Cokcan, 2014, p. 108).
 The “characteristic of visual programming avoids the barrier to entry

commonly found in trying to learn a new language, even a spoken one, as
well as foregrounds the interface, which for designers locates Grasshopper [or
Dynamo] within more familiar territory” (Mode Lab, 2015b)
 “there are fewer syntactic planning goals to be met, such as paired delimiters,
discontinuous constructs, separators, or initializations of variables; higher-
level operators reduce the need for awkward combinations of primitives; and
the order of activity is freer, so that programmers can proceed as seems best
in putting the pieces of a program together” (Green and Petre, 1996, p. 166)
Disadvantages:
 Missing standards (Schiffer, 1996, p. 1)
 Slight illustration density (Schiffer, 1996, p. 1)
 High resistance to modifications (Schiffer, 1996, p. 1)
 Difficult formalizability (Schiffer, 1996, p. 1)
 Limited abstract ability (Schiffer, 1996, p. 1)
 Compared to textual programming code, a complex graphical algorithm

requires a lot of space for the same amount of information
 Limited possibility to structuring leads to bad scalability of graphical

algorithms (Schiffer, 1996, p. 20)
Proponents of graphical programming argue to change with graphical programming

the emphasis of software development to the users (Schiffer, 1996, p. 1). There is a
need to evaluate how this speculation applies for example to existing software plug-
ins with the arising of graphical programming in the BIM environment.
2.7 From graphical programming to BIM 2.0
‘BIM 1.0’ tools are characterized by parametric objects, which “have their own [but
limited] intelligent behaviour and are configured by setting the property values of all
exposed parameters” (Boeykens, 2012). The designer creates, places and modifies
more or less manually objects and applies numeric information to it. “What is mostly
missing is overall control on the project level, e.g. where a single parameter can steer
the generation of many derived objects” (Boeykens, 2012). As by-products of ‘BIM
1.0’ “cost estimating, structural calculations, and energy analysis” were generated
(Kensek and Noble, 2014, p. 82). They were “early indicators of the potential for
analysis and simulation that more developed implementations of BIM-based process
might make possible “ (Kensek and Noble, 2014, p. 82). “Traditionally
interoperability [between applications] is thought about as transfer of static design
information. New visual programming tools will create possibilities for a more
associative kind of collaboration across modelling platforms” (Fralick, no date). The
process of designing by using text based programming or graphical programming is
also known as computational design. “Computation is the procedure of calculating,
i.e. determining something by mathematical or logical methods […]. It is about
rationalization, reasoning, logic, algorithm, deduction, induction, extrapolation,
exploration, and estimation” (Terzidis, 2006b, XI).
“With the huge amounts of data that are currently being generated inside […]
models, access to read and write this data remains difficult to those without
traditional programming skills” (Thornton Tomasetti, no date). In the context of
BIM, a visual programming script uses the information of a model, its objects and
other external sources to generate with computational algorithms new information.
Bernstein and Jezyk describe computational scripts as one part of “three related
evolutionary characteristics” of “BIM 2.0” (Kensek and Noble, 2014, p. 83). The
scripts can use the data to “generate new design solutions” and “analysis, evaluate
and optimize selected design decisions related to both the form and performance of a
building”(Kensek and Noble, 2014, p. 85).
Compared to BIM 1.0 “implicit design objectives are made explicit by the objective
function of declaring a design goal that is represented by a script” (Kensek and
Noble, 2014, p. 89). The design feedback loop “between ideation and understanding”
makes iteration much more rapid and insightful (Kensek and Noble, 2014, p. 89).
Similar to the transition from 2D CAD to BIM, working with visual programming
and data “will require new attitudes, workflows, and expertise in a tradition that has
struggles with change” (Deutsch, 2015, p. 108). To take the use of “current
technology tools to the next level” “it is not enough anymore to learn existing tools”
(Deutsch, 2015, pp. 108, 111). Instead “design and construction professionals need to
feel comfortable either shaping existing tools to fit their needs, or otherwise creating
their own tools” (Deutsch, 2015, p. 111).
Nowadays the most famous graphical programming environment in the AEC

industry is Grasshopper for Rhino. Rhino has strong geometry capabilities (e.g. Non-
uniform rational B-splines) and Grasshopper has a mature library of hundreds of
nodes with unique functions. However, Rhino has it limits because it does not
support a fully BIM concept with intelligent objects and “it is not directly
interoperable with BIM software” (Kensek, 2014, p. 3). Nevertheless it is used a lot
and the competitor Autodesk has realized that there is a strong need for more
intelligent customisation with graphical programming.
“The basic thesis was we should be able to teach Revit to do

computational design in the same way that Grasshopper can drive
Rhino.”
- Matt Jezyk, Product Line Manager at Autodesk (Kron, 2014)
The complete new visual programming software called Dynamo, invented privately
by Ian Keough as an open source project. Autodesk recognized growth of the
Dynamo community and the sophisticated complicated needs of large projects (Jezyk
and Izzi, no date) and decided to contribute to the effort with a professional team to
accelerate the development process. “The people are using currently multiple tools,
[…] which is the state of the industry. But one thing that is really hard to do, to pull
all that information together. And the needs about pulling information back and forth
are not really met by one tool” (Jezyk and Izzi, no date). Autodesk’s competitor
Graphisoft has recently announced a partnership with McNeels Rhino to have for
ArchiCAD similar computational design functions available (Graphisoft, 2015).
According to Shu (1988, p. 139), modern graphical programming languages like
Dynamo or Grasshopper, can be classified as high-level languages, because the
language “requires fewer but larger steps with less detail from the user” and they are
widely applicable as they can “manage multitasking operations”.
Some graphical programming interfaces can be used in AEC (not a definitive list):
 Generative Components
 Grasshopper (Connection to Rhino and ArchiCAD)
 Hypergraph (Maya)
 Dynamo (Connection to Revit, Navisworks, Excel, Grasshopper, OSM,

Tableau, …)
 Marionette (Connection to VectorWorks)
 Flux (Connection to Revit, Grasshopper, Excel)
2.8 Summary
In the second chapter various relevant literatures have been discussed and evaluated.
The findings present BIM as a good foundation for computational design. However,
today there are too many manual steps and decisions in the workflows. An intelligent
and automated approach is rarely applied, as extensive programming skills are
necessary. Without spending a lot of extra work, the existing analyse tools can
influence each other only through a limited and restricted data exchange procedure,
which is mostly one-directional. As a consequence the results of the analyses are
based in parts on assumptions and rough standard values and not on real and exact
data.
The iterative cycles are executed manually, which, due to the complexity of the
projects, leads to weak results. Nevertheless, to give average designers and engineers
the possibility to use algorithms and iterative workflows, graphical programming
turned out as a helpful tool. To understand the principals of graphical programming,
3. Graphical programming with Dynamo 27
first the functionality of algorithms, textual programming, and scripting were

explained and discussed in the previous chapters.
When looking at the history of graphical programming, it became clearer as to why

and how it could be useful within the AEC industry. Important properties and
workflows of modern graphical programming languages used in the AEC industry as
well as advantages and disadvantages are discussed and explained, whereby the
advantages outweigh for the desired tasks. A comparison to other methods using the
API, like add-ons, are discussed and evaluated.
At the end of chapter 2, the term ‘BIM 2.0’ is explained and why graphical
programming is a suitable tool to extend the intelligent behaviour of ‘BIM 1.0’. To
achieve this goal hurdles, limitations, and necessitates are discussed. Up to this point
the basics of graphical programming are covered. In the following chapter the
promising graphical programming language and tool ‘Dynamo’ is discussed,
explained, and evaluated in more detail.
3 GRAPHICAL PROGRAMMING WITH DYNAMO
Dynamo is a free, easily available, open source program that uses graphical
programming (Sgambelluri, 2015f) and “its look and feel is influenced by a number
visual programming interface that have come before” (Kensek, 2014, p. 3). “At its
core, Dynamo is built to be deployed to any application, and to create new
opportunities for cross-platform and cross-discipline collaboration” (Fralick, no
date). Dynamo is a standalone program, but the free version uses the geometry kernel
from Revit to illustrate geometry. Dynamo is based on DesignScript, which “is
extensible and using the Foreign Function Interface (FFI)” (Aish et al., 2012, p. 11).
Thus “classes in external [Dynamic Link Libraries] (DLL) can be exposed as
DesignScript Classes” (Aish et al., 2012, p. 11). “As a parametric modelling engine,
[…] it is designed to extend Revit’s […] capabilities by adding a level of
associativity” (Kensek, 2014, p. 3). Primarily Dynamo accomplish two tasks: it
“creates its own geometry with parametric relationships” and it “reads and writes to
and from external databases” (Sgambelluri, 2015f). Thus “it is a perfect fit to interact
with Revit because” simply put Revit is “a database with parametric geometry”
(Sgambelluri, 2015f). In this case, “Dynamo reads and writes back data to and from
the Revit database via the Revit API” (Sgambelluri, 2015f) (Figure 3.1).
Figure 3.1: Relationship of Dynamo to other applications (inspired by Sgambelluri, 2015h)
“The data could be just about anything, parameter values, family geometry, family
placement” (Sgambelluri, 2015f). The elements created with Dynamo are editable in
Revit and the parameters can still be adjusted manually (Akos, 2014). The links to
the created objects are maintained (Fralick, no date) and the Dynamo file can be re-
run and update those exact same elements (Akos, 2014). A typical problem solving
workflow with Dynamo is illustrated in Figure 3.2.
Figure 3.2: Problem solving workflow with Dynamo (Guerra, 2014)

3.1 Developer principles and value goals
The developer team of Dynamo follows some principals (Keough, 2015) to create
maximum value for the users. Most of the principals are realized already and are still
further optimized:
1. The user should be able to share their tools easily and be able to use, extend
or update tools created by others
2. Not everything should be embedded in a graph. Enhanced intelligence needs

a separate platform that can be used by designers with scripting skills and by
programmers as well.
3. Every user who contributes to a building should be able to get the concept
and basic functions of Dynamo
4. Users should be able to easily organize and refactor their graphs
5. Users should be able to analyse in real-time with their design. Getting

Architects, Engineers and Analysts to work at the same model at the same
time, so analysis can be conducted in real-time in the actual design stage.
Within a Revit family it was always possible to create formula with some limitations.
But with the availability of visual programming in BIM, parameters of different
objects can be set in a relation to each other and extended with complex algorithms.
With Dynamo it is possible to automate time and labour intensive tasks. “A designers
speed of production should increase with Dynamo in their workflow and they should
be able to explore more options and more options integrated with performance
criteria such as solar load, view corridors, or visual patterning” (Akos, 2014, no
page). The increasing data amount in digital building models can be used more
effectively. The result is an increased accuracy and a better productivity. Thus the
decisions can be based now on measureable results the risks are reduced. The visual
programming interface makes it easier for designers to enter the world of
programming. Earlier attempts to push the non-programmers to use the API of Revit
with text based programming interfaces were not very successful. Analysis can now
be integrated into the design process instead of outsourcing to consultants. The
cumbersome and time-consuming adjustment cycle of transferring information back
and forth and the analysis and implementation of the delivered report results is
dropped.
Dynamo can be applied in various ways; for instance, it can be used with a close
connection to Autodesk software, for example, ‘Revit’ but it can be used to connect
software and hardware, which provides an API as well. “Dynamo is, quite literally,
what you make it” (Mode Lab, 2015a). The open-source concept of Dynamo enables
users to create custom nodes and to create new functionalities, which can be shared
with the Dynamo community. Due to the free available source code, it can be
implemented into other applications and can be customized for special needs or
projects. This is especially important for the heterogeneous AEC industry, where a
large variety of applications are used. But it is also possible and has been already
done, to adapt Dynamo to other industry software, like Inventor or Illustrator, among
others (chapter 3.3.3).
3.2 Dynamo overview
The user interface of Dynamo is very simple (Figure 3.3). A typical menu bar at the
top, on the left side the search bar and the node library. The main window is called
workspace or canvas. Here are the nodes and wires placed to create a visual program.
At the bottom the script can be executed. This can be done manually or
automatically. The direction of the execution is typically from left to right. Inactive
nodes are grey, active and well-connected nodes are orange and error states are
indicated with a red node. After a successful execution a preview is displayed in the
background.
Figure 3.3: Dynamo user interface
A Pull down menu F Node collection

B Search bar G Preview of the generated geometry
C Node library H Node
D Comment box I Workspace / Canvas
E Wire J Program execution bar
The nodes are objects, which can be placed in the workspace (Figure 3.4). They
represent Revit elements or math functions or anything else what can be created and
accessed with texted based programming code and an API. Nodes have input ports
(on the left side) and/or output ports (on the right side) with different types. Each
port type expects a certain type of data. The ports can be connected together with
wires to create relationships and to establish a program flow. There are lots of
different types of nodes, but this cannot be covered in this context.
Figure 3.4: Node description
Groups exist to organize nodes into a logical collection of nodes (Figure 3.5). They
can be converted into custom nodes. In traditional text based programming this is
known as modularisation.
Figure 3.5: Dynamo Groups to modularize collection of nodes (Keough, 2015)
Most graphs can be built with the available core nodes; but it is sometimes quicker,
and more elegant to use a shared solution, known as Custom Nodes. Custom Nodes
can be shared with the community within the package manager (Figure 3.6) or it can
be stored and shared locally. A package needs to be downloaded and installed before
it can be used.
Figure 3.6: Dynamo Package Manager (http://dynamopackages.com)

3.3 Technology implementation
Due to the flexible structure of Dynamo, the field of application is very large.
Optimisation and analysis, management of data and the connection or use of other
applications and hardware are the main usage categories of Dynamo. In addition,
Dynamo has a rapid development cycle with regular new functionalities in the daily
builds.
3.3.1 Computational design: Analysis and optimisation

In parametric models relationships with limited intelligence are generated between
driven objects and drivers. For example kinetic façade panels can react to a sun path
in the model. A computational design approach extends these relationships with
defined constraints, analysis and an iterative approach to generate optimized design
solutions. Computational design has also generative abilities and can be used already
at the conceptual design phase. It bridges the gap between the architectural work and
engineering work and the early conceptual design becomes a part of the digital
building model. With an iterative workflow by using algorithms, the major decisions
are made very early, based on the given constraints and inputs. As indicated by the
‘MacLeamy Curve’, the shift of effort towards an earlier design stage can save a lot
of money. As all constraints are implemented in an algorithm many alternative
design options can be compared very quickly. A computational design approach with
Dynamo can deal with ‘wicked problems’ by using several optimization types:
 Energy performance optimisation (Kensek and Noble, 2014, p. 87)
 Daylight analysis (Daylight Analysis for Dynamo, no date)
 Acoustic optimisation (Figure 3.7) (Vannini, 2015)
 Structural optimisation (Vermeulen, 2015)
This is achieved by integrating analysis nodes into the iterative design process.
Figure 3.7: Acoustic ray tracing with Dynamo (Vannini, 2015)
3.3.2 Model management and quality assurance

The integration of visual programming into BIM tools like Revit gives new
possibilities for creating, managing and checking of the digital model. The flexible
workflow with dynamo and the access to Revit functions via the API can replace
commercial add-ons and even extend their functionality in some cases. A
inconclusive list of tasks that can be done with Dynamo:
 Creation of plans (Sobon, 2014a) and placement of views on plans (Sobon,

2014d)
 Rule based creation of annotations (Sobon, 2014b)
 Level creations (Sgambelluri, 2015c) e.g. for a skyscraper
 Extracting the worksharing status of a Revit file (central, local, or not

workshared) (Sgambelluri, 2015e)
 Alignment and measurement of scope boxes (Sgambelluri, 2013)
 Readout, sort, process und write data information from and into the digital
model and to other applications (Sgambelluri, 2015d) (Sgambelluri, 2015b) E.g.
Coordinates from piles or other objects
 Management of lists (Sgambelluri, 2015a), nested lists (Sgambelluri, 2015g),

mathematical operations
 Management of family types (Sobon, 2014c)
 Validation of model standards and quality assurance (Dieckmann and Russell,

2014)
 2D graphs of information out of the model (Morin, 2015)
 Colourizing: Analyse visually geometry (Figure 3.8) and embedded data (Figure
3.9) (CORE studio, no date). “Information displayed with the design mode itself,
[…] guides the designer in choosing an optimal solution” (Kensek and Noble,
2014, p. 87).
Figure 3.8: Visualizing of data and colourized geometry (Keough, 2015)
Figure 3.9: Visualized load calculations (CORE studio, no date)

3.3.3 Integration of external software and hardware

“Connecting the digital world to our built environment can be an exciting way to
develop new ideas and better understand our surroundings. With the advent of
inexpensive programmable devices like the Arduino this is easier than ever”
(Thornton Tomasetti, no date). With Dynamo it is possible to create a connection to
Kinect (Keough, 2011) or Arduino and to access sensor data (Jezyk, 2013).
Computer-controlled fabrication of objects in the model with the connection of
industrial robots (McCrone, 2014) to Dynamo are steps towards an completed life
cycle process and to mass customization. The software list with connections to
Dynamo is steadily growing. A list of actual efforts to implement external software
into Dynamo to extend the interoperability:
Table 3.1: Selection of existing software connections to Dynamo

Software Implementatio Additional information
n Name
3DS Max Maxymo http://www.scriptspot.com/3ds-
max/scripts/maxymo-server
Rhino Mantis Shrimp https://github.com/ksobon/MantisShrimp
and Rhynamo https://bitbucket.org/caseinc/rhynamo
Solibri Anvil http://collectivebim.com/dynamo-solibri-using-
ifc-via-anvil-xbim/
SAP2000 Dynamo SAP https://github.com/tt-acm/DynamoSAP
Robot Dynamo for https://beta.autodesk.com/callout/
Structural Robot ?callid=70F56BD3926A4A459FC552121CE042E
Analysis 3
Inventor DynamoInventor https://github.com/frankfralick/DynamoInventor
Navisworks Dynaworks https://github.com/Gytaco/DynaWorks
Tableau Dynableau http://blog.kylemorin.co/2015/03/dynableau-
dynamo-tableau/
MS Excel
SQL Slingshot http://www.theprovingground.org/2014/11/slingsh
ot-for-dynamo-update.html
Illustrator https://github.com/elayabharath/Dynamo-Addons
Maya DynaMaya http://dynamaya.cerver.org/
3.4 Technological challenges
There is a big difference between implementing typical design software and

programming within an office; visual programming has still the logic of traditional
programming. Not every designer is comfortable with the computer and maybe
understands even less about the concept of programming. At the moment it is not
obvious if it makes sense to teach every designer or only a selected group of people
in Dynamo. A growing community and its blogs by community members are very
helpful in learning Dynamo. A second obstacle is maybe the massive collection of
nodes and wires used for more complex tasks. Without a good documentation, the
generated code becomes difficult to handle. And by using analysis algorithms and
iterations a high-end setup is necessary to run the created program quickly. A
solution for this could be the execution of Dynamo in the cloud (SaaS) similar to the
cloud-based software Flux.
The fast development of Dynamo makes it is difficult to hold created custom nodes
and tutorials up to date. This leads to frustration for new and less advanced users.
3.5 Advantages and areas for improvements
The literature research and personal observations leads to a not definitive list of
advantages and areas for improvements of visual programming with Dynamo.
Advantages:
 The basics are simple to understand
 All necessary core nodes and the interface are already available and can be
extended with little effort.
 Different textual programming languages (TPL) can be used to create

geometry, to access API within nodes or to create custom code block nodes
for an algorithm extension. The most common languages in the Dynamo
environment are Python, Design Script, and C#. With the usage of Python
and Design Script an interim stage of compiling the code is not necessary and
it can be used in the native environment of Dynamo. In contrast C# is more
abstract and has to be compiled with an IDE, but it has been used a lot by
Revit and Dynamo software developers.
 The underlying concept of programming with its abstractions can be explored

and learned by non-programmers. The reuse and investigation of available
and well-structured node-combination examples, leads to an interest of
learning the more advanced usage and maybe textual programming as well.
 Custom nodes made by programmers with non-standard functionalities can be

used by non-programmers more easily than a macro add-in.
 “users of different skill levels can use the tool to be productive at their own
paces” (Kirschner, 2015, p. 42)
Areas for improvement:
 The geometric library is only available with a Revit license or with the
commercial version ‘Autodesk Dynamo Studio’
 An unstructured placement without nesting of node-groups creates a

devastating spaghetti-effect with the wires criss-cross one above the other
(Schiffer, 1996, p. 10). The positive effects of the visual code representation
are in this case lost.
 It takes a lot of time to understand and apply available functionality of all

available nodes. Additionally node specific tutorials and discussions are very
rare and difficult to find in the forum.
 All nodes have a very similar visual appearance: Thus the user and its human
brain have difficulties to create “mental images” (Anderson, 2010, p. 92) of
the different node types. The logic of a large collection of different nodes
with the same visual appearance cannot be analysed quickly. At the moment
the only way to create a mental image of the overall logic is the textual
information embedded in the nodes or to create colourized groups. The fast
identification of node types can be achieved by using the ability of pattern
recognition (Anderson, 2010, p. 42). To enable the full potential of visual
programming the human brain needs support in form of colour, sizes, shapes
and spatial structure (Anderson, 2010, p. 105) of nodes.
 For larger applications the canvas can become messy very fast. Similar to
textual programming code, it is important to follow placement rules, to use
regularly comments about the intended functions and to structure logical parts
together.
 Collaborative development of nodes, node specific discussions and version

control, which is a standard functionality in environments like GitHub for
textual programming projects, is still a missing function for developers and
users of graphical programs and nodes.
 “Programs must currently execute inside of Dynamo and cannot at this time,
be compiled to external applications” (Kirschner, 2015, p. 41).
 “The granularity is quite low, as the functional nature of the program means
that nodes aggregate their outputs from multiple evaluations into a list of
results. Thus selecting a node will highlight everything, and inspecting in
more detail is difficult and requires writing more code so the user can then
select those sub nodes, which will have less output values” (Kirschner, 2015,
p. 41)
 “[…] visualization of lists is quite limited […] [because] it is handled with a

simple nested tree viewer […] and does not work well enough when
inspecting data that is commonly made up of geometries and complex data
structures” (Kirschner, 2015, p. 41)
 Recursive functions realised with nodes are not self-explanatory, because

custom nodes have to be nested inside of themselves
3.6 Future of Dynamo
The fast growing Dynamo community and the increasing effort by Autodesk to push
the development lets expect a bright future. In addition the increasing adoption rate
of BIM will increase further the need for a tool that serves as a bridge between
applications. Boyer (no date) has started the effort to port Dynamo to Linux. This is
the first step to run Dynamo in the cloud, similar to the software Flux, which “will
free designers from the computation constraints of a desktop computer, making it
possible to perform simultaneous development of the design in parallel with the
resulting analysis of implications, essentially in real time as ideas are developed”

(Kensek and Noble, 2014, p. 90). Other hot topics for integration are point clouds,
rooms and spaces, control of many adaptive components and a node to code
mechanism, which allows a translation of nodes into text based code. Recently
Autodesk has announced to involve an additional developer team to implement more
Revit specific functionality into Dynamo (Kron, 2015).
A not yet implemented, but patented idea, is to compile “the enhanced computational
logic [created with Dynamo] into the family definition such that the enhanced
computational logic is embed at an object level” to “automatically executing”
without further use of the Dynamo interface (Jezyk et al., 2015). This is also known
as ‘Project Honeycomb’ introduced by Autodesk.
It is convincible, that Dynamo will be enhanced to act as a 5D BIM query language

for IFC files (Wülfing, Windisch and Scherer, 2014) or native files/objects.
Therefore the implementation of ‘time’ is important, which is present for example in
Hypergraph (Autodesk Maya).
Other hot topics under development are graphical improvements (e.g. nodes, wires,
user interface), informational improvements (e.g. tooltips, documentation, action
impacts), and functional improvements (i.e. nodes) to identify source of errors, state
of the node, suggestions for inputs/outputs, and a more robust and more intelligent
behaviour to unexpected user inputs.
The increasing availability of visual programming tools for BIM tools, requires name
standards for core functionalities which are present in every visual programming
environment. Furthermore, a node dictionary based on a database would be helpful
for users switching between different visual programming tools. This dictionary can
be embedded in the library search to find nodes with same functionality but a
different name.
Boshernitsan and Downes (2004, p. 23) speculated in 1997 that there would be
increasing attention in 3D visual programming languages. But even with the already
improved computer performance and other anticipated advantages. Some examples
for 3D graphical programming environments are ‘Pupi’ (Prună, 2015) and ‘XYZ’
(Kirschner, 2015).
3.7 Summary
The third chapter has introduced the graphical programming tool ‘Dynamo’ in detail.
The available academic literature was analysed and therefor evaluated together with
personal knowledge and internet resources. Several areas of application are
introduced and technical details are presented. The research about Dynamo made the
flexibility of Dynamo transparent: Various textual programming languages can be
used to extend Dynamo. The relationship in Dynamo between geometry,
parametrical behaviour, database connectivity, and typical workflow are explained
and illustrated. The motives by the developers and their principles they follow to
create value for the users are evaluated. The development strategy has made bi-
directional connections to various other programs possible. Especially the connection
to Autodesk Revit is discussed in greater detail and the management, optimisation,
and checking process of a Revit model are discussed. In addition to the long list of
advantages, upcoming technological challenges and areas of improvements have
been identified. Discussions on conferences with experts and the deep dive into the
world of graphical programming literature led to a prediction for technological future
scenarios of Dynamo.
The presented topics are based on a technical nature and present mostly facts and
combinations of findings by single persons. Some of the stated research questions are
discussed already. So far this is a very good foundation to continue the research with
a survey to answer unresolved questions which are covered so far only by
assumptions and speculative opinions.
Visual programming and technical questions about Dynamo are covered so far, but
how does graphical programming (in this case Dynamo) affect the method of
operation of users with BIM? There are many questions which are so far not
answered:
 Who is using Dynamo already and what are the reasons to use it?
 Which skills and abilities are necessary or helpful to use Dynamo properly?
 Where can users see advantages compared to textual programming and

scripting?
 What tasks are particularly suitable for Dynamo?
 Is the implementation of Dynamo economically reasonable?
 How many employees should know how to use Dynamo or know how to
extend its capabilities?
 Is it sufficient to use existing Dynamo nodes or at what point is it useful to

participate as developer?
 What are the advantages of in-house development and how can someone
achieve competitive advantage by doing this?
 Are the users willing to pay for the added value by Dynamo or special custom
nodes?
 The open source concept of Dynamo: How are the attitudes and mind-sets?
Who supports the open source concept? What need to be changed?
 How can the common development effort be strengthened?
 What are the hurdles for a fast a broad usage of Dynamo?

CHAPTER 4
4 RESEARCH METHOD
The literature review is the foundation for the researcher to reveal research gaps of
graphical programming (Dynamo) in the context of BIM and to create appropriate
survey and interview questions. The reader will get also a foundation to be able to
understand the aim and the research questions.
Single opinions to technical questions about Dynamo are already available by early
adopters and experienced Dynamo users via conference discussions, interviews,
literature, websites, blogs etc. These available sources and the authors’ knowledge
about the software were used in the second and third chapter for the literature review
to get a basic understanding about the theoretical background of visual programming
and software understanding. Thus the further research should focus primarily on all
types of Dynamo users to create a wide spread collection of opinions within a
structured format. To get as many completed questionnaires as possible it is essential
to keep the necessary answer time for the survey low. To achieve this goal, all open
ended questions were not mandatory. The combination of quantitative and qualitative
survey questions were chosen to be able to compare subsamples and on the other
hand to get unexpected answers. The identification of subsamples with similar
opinions or correlations between subsamples is an important part of the analysis.
Depending on the success of the survey analysis, optional interviews were taken into
account, to answer unresolved questions.
4.1 Collecting data through a web-based survey
The initial data collection takes the form of a structured questionnaire. To collect the
data, the online survey tool ‘limesurvey’ is used with quantitative and qualitative
questions. The participants were chosen randomly in online forum, social networks
and on Dynamo websites without asking specific people. The first aim of the
questionnaire is to identify use cases of ‘how’ Dynamo is professionally used. The
second aim is to identify the distribution of participant types (disciplines) with
appropriate knowledge and experience with Dynamo and BIM. The third aim of the
4. Research method 45
questionnaire is to get the perceived advantages and barriers for the usage of
Dynamo.
However, to ensure the validity of the questionnaire an initial test with 1-2
participants and feedback discussion was conducted before the official start. To find
participants, the author has spread the survey on LinkedIn in a Dynamo group, on
GitHub, twitter and via the Dynamo community website. The amount of questions is
kept to a minimum to ensure as much completed questionnaires as possible. To be
able to contact the participants, the questionnaire is formally not anonymous because
the IP address is logged and browser cookies prevent repeated participation. But it
will initially clarified, that the findings and cases used in the dissertation are
anonymised.
One of the reasons to create a survey was to get an actual opinion of the graphical
programming and BIM community. Another reason was to close the research gaps
identified in the literature review. To goal was to create new insights with the
evaluation of the web-based survey, to reveal dependencies, and to generalize some
findings.
A sample web-based survey is appropriate for the research, because (Rea and Parker,
2014, p. 28):
 Adequate secondary data is not available.
 There is a desire to generalize findings from a small subpopulation to a larger

population.
 The target respondent population is accessible.
 The data to be obtained are of a personal, self-reported nature.
4.2 Strategy of data collection
In the pre-test the questionnaire was checked for clarity, comprehensiveness and
acceptability (Rea and Parker, 2014, p. 38). According to Flick the participants
should be “concerned and experienced with the issue under study” (Flick, 2007, p.
29) and this is achieved to ask for participation in Dynamo related communities,
forums, websites etc.
4. Research method 46
One claim of this study is to develop a grounded theory which applies to the specific
field of Building Information Modelling. Flick terms this as a “substantive theory”
(Flick, 2007, p. 42). The aim is to find an internal generalizability, which "refers to
the generalizability of a conclusion within the setting or group studied" (Maxwell,
2005, p. 115). The quality of the survey is mainly assured through standardization of
the research design, “to control as many influences […] as possible” (Flick, 2007, p.
42).
4.3 Analysing survey data
To analyse the collected data, all answers were imported into SPSS. Most of the
closed-ended questions were already pre-coded. Some from the open-ended
questions were categorized to create statistics, sub-samples and tests. All
uncompleted surveys were not included in the data analysis. To create correlations
between sub-samples additional variables were created. After cleaning up the forms
the pre-coding from the tool ‘limesurvey’ was optimized. Nearly all graphs and
tables were adjusted to a suitable format and then saved in the syntax editor, to run
the tests again with all samples after the survey has ended. Most of the created tables
were transferred to Excel. Thus it was possible to use colours to reveal patterns in the
data.
Question 23 got an error because of an incorrect array type. Thus this question was
removed from the survey. The survey data can be found on the CD. All questions and
simple statistics is listed in Appendix A. The statistical tests with SPSS was difficult,
because the sample of 70 and the even smaller sub-samples with many categories
with less than 5 answers were not statistical significant. Thus only a tendency or a
descriptive statistics or vague correlations among variables were possible.
CHAPTER 5
5 SURVEY RESULTS AND DATA ANALYSIS
During the 20th November and the 3rd December 2015 a survey was conducted. The
main topic of the survey was about Dynamo - a graphical programming software. To
reach out to potential participants, the flyer and links to the survey were distributed
in LinkedIn Groups, on twitter and in online forums. The strategy not to push
specific persons to answer the survey and instead of asking in a more general public
way was quite successful: 145 participants have started to answer the survey, 73 of
them have completed the survey and 70 of the cases were valid. The 3 invalid cases
have not been accepted as the research participant have not followed instructions or
have answered questions are obviously not serious. Thus these 3 invalid cases are not
included in the analysis. Two control questions about Revit Skills and Dynamo Skills
were asked 2 times, at the first quarter and at the end of the survey. 17 of 70 valid
cases exposed a discrepancy of maximum one skill category. All control
discrepancies are negligible because the differences are small and have occurred
between the skill categories ‘intermediate’ to ‘guru’. Most of the participants with
discrepancies assessed their skills at the beginning lower than at the end of the
survey. The reason for this can be the visible comparison with other similar software,
which has maybe influenced their ratings.
5.1 Introduction
The descriptive statistics of all closed and some open questions are presented in
Appendix A.2. The detailed data analysis in the following chapters uses the
descriptive statistics to point out interesting findings and particularities of specific
samples. With cross tabulation analysis the results of participants with specific
characteristics are analysed. Due to the small number of cases, especially with even
smaller sub-samples, the statistical significance was never attained. Thus all
observed effects and conclusions should be seen as a reflection or a tendency of the
sample which cannot be transferred with a statistical significance to the whole
population.
5. Survey Results and Data Analysis 48
5.2 General participant characteristics
Most of the questions were presented in a categorical form with given answers to
choose from. If appropriate the given answers were sorted in a logical way. An
additional input field was given to cover unexpected answers. Most of the ‘other’
answers were re-coded in the analysis phase into existing categories. The last
question reveals that nearly all participants have used Dynamo before (A.2.24 -
Question 25). Thus the survey results represent to some extent the population of
Dynamo users. The most frequent office type comprises architecture (60%), followed
by BIM consulting (41.4%) and structural engineering (30%) (A.2.2 - Question 2).
The given distribution of office types has similarities with the adoption rate of BIM
in combination with the usage rate of Autodesk Revit by disciplines. All of the top 5
office types are working typically with digital models and this enables them to use
Dynamo in some way.
Most participants’ roles at work are directly related to BIM management and
coordination: 28.6% are BIM Managers, 20% BIM Technicians and 21.4% have
architecture related roles at work (A.2.3 - Question 3). The year of birth was recoded
into age groups with 5 year steps (A.2.5 - Question 5). The participant distribution
indicates a peak at the age 25-29 with a declining amount the older the participants
are. The reason for this can be attributed to the conducted participant search, which
was focused on social media networks, it can be an indicator of available time of the
participants groups or older people are not so much receptive to new technologies
like Dynamo and BIM. Nearly 92% of the participants have an advanced to guru skill
in Autodesk Revit (A.2.6 - Question 6). This can be expected, because Dynamo is
strongly associated with Revit and to apply Dynamo effectively the basic functions
of Revit have to be known well.
5.3 Textual programming skills
The answer distribution of the question about the level of the general textual
programming skills (Figure 5.1) of Dynamo users is interesting but not surprising. As
already mentioned in chapter 3, it is possible to use Dynamo solely as a graphical
programming tool or in combination with textual programming. But to reveal
characteristics of specific sub-samples of questions regarding the usage of ‘Revit
Macros’ and the importance of textual programming to use Dynamo successfully a

more detailed analysis is conducted.
Figure 5.1: Distribution of textual programming skills
5.4 Revit macro usage
The macro functionality for Revit was first introduced in ‘Revit 2009’and is designed
to save time by automating repetitive tasks (Autodesk, 2008, p. 1549). A macro can
use Revit API commands and can be executed in Revit without an additional
installation process. It was introduced by Autodesk as “the next evolution of Visual
Basic for Applications (VBA)” (Autodesk, 2008, p. 1549). The advantages of the
macro functionalities in Revit are covered by Dynamo as well: 98.6% of the survey
participants agree to the statement that Dynamo can automate repetitive tasks (A.2.10
- Question 10). To consider the research questions from chapter 1.3, e.g. how
effective a graphical programming tool like Dynamo is compared to other
automation methods, the usage of Revit macros is evaluated and compared with
Dynamo. Figure 5.2 reveals that only 31.4% of the Dynamo users have used the
Revit macro functionality successfully and 20% have tried to use or create a macro,
but they were not successful. A resulting question is: why are some of the Dynamo
users able to use macros successfully and some not? Therefore a more detailed data
analysis was examined.
Figure 5.2: Usage of Revit Macros
To show the dependencies between Revit skills and the usage of Revit Macros a
cross tabulation was created. Table 5.1 shows clearly that many advanced to guru
Revit users, have not used the Revit macro function before or they were not able to
do it successfully. A bit strange is that one guru Revit user does not know what a
Revit Macro is, but this can be attributed to the self-assessment of the skills.
Table 5.1: Cross tabulation of Revit skills and usage of Revit Macros
Have you used the Macro function in Autodesk
Revit before?
Not
I don't know
sucessfully, Total
what a
but I have
Yes No 'Autodesk
tried to
Revit Macro'
create/use a
is
Macro.
beginner 0 1 0 0 1
What level
is your intermediate 1 2 1 1 5
skill in advanced 2 10 4 2 18
Autodesk expert 10 14 2 1 27
Revit?
guru 9 2 7 1 19
Total 22 29 14 5 70
Why is a large part of the guru Revit users not able to use macros successfully? Even
though an automation of repetitive tasks was always demanded by the Revit users to
save time in the design stage, why is the overall ability to use macros very low?
In the following procedure 22 cases that have used Revit macros successfully are
investigated, to see on which level their programming and Dynamo skills are (Figure
5.3).
Figure 5.3: Participants’ textual programming skills who have used Revit macros successfully
This distribution in Figure 5.3 is compared with the general textual programming
skills of all participants (Figure 5.4). The graph shows that the ratio between these
two groups increases continuously with better textual programming skills:
0/9 (≙0%) no experience

5/30 (≙16.7%) beginner
4/11 (≙36.4%) intermediate
9/15 (≙64.3%) advanced
3/4 (≙75%) expert
1/1 (≙100%) guru
Figure 5.4: Comparison of textual programming skills between all participants (dashed bars) and
participants who have used Revit macros successfully (grey bars)
Even if this is not a statistically significant finding, it shows a clear tendency that the
skill level of textual programming correlates with the chance to use successful Revit
macros. But to have advanced textual programming skills is not a guarantee to use
macros successful as well. There are some participants with advanced to expert skills
in textual programming who have tried to, but were not able to use Revit Macros
successfully (Figure 5.5).
Figure 5.5: Textual programming skills of participants who wanted but were not able to use Revit
Macros
Thus, Revit users without programming skills need another suitable method to
automate repetitive tasks. This new method is the graphical programming tool
Dynamo, introduced in chapter 3.
5.5 Dynamo skills
Dynamo is still in a beta stage and such type of software in combination with BIM is
still a quite new way of managing data. Thus the distribution of Dynamo skills by the
participants shows a declining curve the higher the skill level is:
Figure 5.6: Dynamo skills of all participants
Figure 5.7 shows the Dynamo skill distribution of participants who have used Revit
Macros successfully. Beginners are hardly evident and it can be argued that a higher
Dynamo skill level is easier to reach for people who are already able to create and
use Revit macros.
Figure 5.7: Participants’ Dynamo skills who have used Revit macros successfully
Dynamo is a hybrid graphical programming tool. So it is an interesting question, if it

is necessary to be able to program (textual) to apply successfully.
In Figure 5.8 the sub-sample with none or little textual programming skills and none
to intermediate Dynamo skills were asked for their opinion if textual programming
skills are important to use Dynamo successfully. As can be seen in the graph not all
of them agree with this statement. The ‘agree group’ was maybe not able to solve
their problems. But the agreement can have various reasons. The basic and common
problems are covered by Dynamo nodes, but to solve a special problem it is
necessary to know a large library of nodes or to have textual programming skills to
bridge the missing nodes. Another reason could be the large amount of nodes and as
a beginner it is difficult to find the right node to create a working algorithm.
Thus it is interesting to modify the sub-sample and select participants with non to
little textual programming experience, but with advanced to guru Dynamo skills.
These properties got only 6 of 70 participants and the result is still mixed (Figure
5.9). It can be assumed that these users know a lot of nodes and have enough
experience with the graphical system. And still 2 of 6 users say textual programming
is important to solve problems with Dynamo. But there are some experienced
Dynamo users who could solve their problems without textual programming skills.
The conclusion could be: It is nice to have textual programming skills, but to a
specific degree problems can be solved without textual programming skills.
Participants with advanced to guru textual programming skills with non to

intermediate Dynamo skills perceive it is important to have textual programming
skills (Figure 5.10). Being such type of Dynamo user and encountering a problematic
case during the creation of the definition, it is probably easier and faster to use a
textual programming node, instead of searching the Dynamo library for a suitable
graphical node, thus they perceive textual programming as important to solve a
problem.
The analysis of the different sub-samples indicates that both programmers and non-
programmers are able to work with the Dynamo platform successfully. The question
how effective the two different working styles are, is still to answer. The motivation
by many Dynamo users to learn textual programming caused by the usage of a
graphical programming (Figure 5.11) can be an indication that the use of textual
programming has some benefits.
Figure 5.11: Motivation to learn textual programming by using graphical programming
However, we have seen that over 70% of participants get motivated by graphical
programming to dive deeper into textual programming (Figure 5.11), but why do
some disagree with this statement? A reason could be the already existing textual
programming skills. But Table 5.2 shows that this assumption cannot be the reason.
Only 3 of 11 participants (dashed blue) who have disagreed with the statement have
advanced to expert textual programming skills. Thus it can be argued that the
remaining 8 participants (dashed green) have other reasons to be not motivated to
dive deeper into textual programming. A further research of these 8 cases has not
discovered any common characteristics (e.g. age).
Table 5.2: Motivation to learn textual programming as a function of the textual programming
skills
Graphical programming What level is your general textual programming skills?
has motivated me to dive
Total
deeper into textural no exp. beginner intermediate advanced expert guru
programming
Count 2 10 4 6 2 0 24
Agree
strongly % of textual
22,2% 33,3% 36,4% 40% 50% 0% 34,3%
progr. skills
Count 5 11 4 5 0 1 26
Agree
somewhat % of textual 55,6% 36,7% 36,4% 33,3% 0% 100% 37,1%
progr. skills
Neither Count 1 2 0 2 0 0 5
agree nor % of textual
disagree progr. skills 11,1% 6,7% 0% 13,3% 0% 0% 7,1%
Count 0 4 1 1 0 0 6
Disagree
somewhat % of textual 0% 13,3% 9,1% 6,7% 0% 0% 8,6%
progr. skills
Count 0 2 1 1 1 0 5
Disagree
strongly % of textual 0% 6,7% 9,1% 6,7% 25% 0% 7,1%
progr. skills
Count 1 1 1 0 1 0 4
No
opinion % of textual
11,1% 3,3% 9,1% 0% 25% 0% 5,7%
progr. skills
Count 9 30 11 15 4 1 70
Total % of textual
100% 100% 100% 100% 100% 100% 100%
progr. skills
5.6 Tasks and problems solved with Dynamo
The flexibility of Dynamo supports a wide range of functionality. And on events

mostly the complex and rare applications of Dynamo are demonstrated. Thus it is
interesting to get data about the most frequently tasks and problems solved by the
users.
Table 5.3: Most frequently solved problems with Dynamo

N Problems / tasks
22 Extracting data / data transfer / interoperability between software
21 Automating repetitive tasks
21 Model management / data management
19 Data manipulation
10 Geometry creation
8 Quality assurance / quality checks
5 Conceptual design
4 Object and family creation
3 Revision / index management

3 Quantity take-offs
2 Documentation
2 Finding / filter elements
2 Clash report creation with colourisation
2 Topography manipulation
2 Structural design
1 Data mining
1 Recesses
1 Energy analysis
In the subsequent question, the participants were asked which special tasks or
problems they have solved with Dynamo. Many of them are similar to the entries in
list above, but some outstanding and interesting tasks are:
 Code checking
 Erection sequencing
 Tessellations
 Automatically documenting created custom nodes
 Acoustic optimisations
 Node to identify who created objects
The complete list of answers can be found in Appendix A.2.11 and A.2.12. The lists
are helpful to get inspiration how Dynamo can be used.
5.7 Effects of applying Dynamo
To get a clear result, the ordinal scale of five agreement levels was recoded into
‘agree’, ‘disagree’ and ‘no opinion & undecided’ (Table 5.4). For the assessment of
the statement, the agreement and disagreement percentage is decisive. Nearly all
statements have a strong tendency to ‘agree’ with one exception: The statement
‘Textual programming skills are important to use Dynamo successfully’. A high
agreement ratio (agreements minus disagreements) above 0.75 is assessed as true. All
other statements have to be examined in more detail.
Table 5.4: Agreement distribution about statements on effects of applying Dynamo

Valid cases N= 69
Agreement
Opinion no opinion &
Effects of applying Dynamo Disagree Agree ratio
available undecided
N Percent N Percent N Percent N Percent Percent
With Dynamo repetitive tasks
68 98,6% 1 1,4% 0 0,0% 68 98,6% 0,99
can be automated
The utilization of Dynamo
64 92,8% 5 7,2% 2 2,9% 62 89,9% 0,87
reduces labour time
Better control on available data 58 84,1% 11 15,9% 1 1,4% 57 82,6% 0,81
Bi-directional data transfer
between software is improved 59 85,5% 10 14,5% 3 4,3% 56 81,2% 0,77
with Dynamo
Transfer of data between
software gets easier with 56 81,2% 13 18,8% 4 5,8% 52 75,4% 0,70
Dynamo
The iteration / optimisation
process and its results can be
54 78,3% 15 21,7% 5 7,2% 49 71,0% 0,64
presented clearly and
understandable
Iteration workflows are well
56 81,2% 13 18,8% 6 8,7% 50 72,5% 0,64
supported by Dynamo
Design outcome has with
43 62,3% 26 37,7% 4 5,8% 39 56,5% 0,51
Dynamo a better quality
Textual programming skills are
important to use Dynamo 58 84,1% 11 15,9% 14 20,3% 44 63,8% 0,43
successfully
The most controversial statement about the importance of textual programming skills
with 20.3% of disagreement votes, is investigated in more detail. Therefore the cases
who disagreed are divided into their Dynamo skills (Figure 5.12) and the ratios are
calculated:
33% of beginners disagree

22% of intermediate disagree
13% of advanced disagree
16% of experts disagree
100% of gurus disagree
It is not possible to calculate convincing ratios and the chi-square test is of course not
successful as well, because the sub-samples are too small.
Figure 5.12: Textual programming skills are important to use Dynamo successfully: Agreements
5.8 Dynamo dissemination
The actual ratio of people who can create Dynamo definitions in the office is as
expected still quite low (A.2.13). The majority of 68.6% participants has answered
that only 1 to 10% of their designers in the office are able to create Dynamo
definitions.
A logical consequence is to ask them what percentage they prefer to able to create
and adjust Dynamo definitions from an economic point of view (Figure 5.13). The
answers are widely spread across the scale. More than 15% of the participants can
see so much value in creating Dynamo definitions to vote for the maximum
percentage. But a majority thinks that it is enough to have only a lower portion of
designers who are able to create Dynamo definitions. A minority sees not enough
value to have such kind of designers.
Figure 5.13: Percentages of designers who should be able to create and adjust Dynamo
definitions
It is possible to prepare a library with Dynamo definitions for regular tasks. So how
many designers in an office should be able to apply already existing nodes from an
economic point of view? Figure 5.14 illustrates that 31.4% thinks all designers
should be able to use Dynamo definitions and more than 68% believe that at least the
half of the designers should be able to use Dynamo definitions.
Figure 5.14: Percentages of designers who should be able to use existing Dynamo definitions
There are some cases with extreme answers. To evaluate the experience of the cases
in Figure 5.13 and Figure 5.14the corresponding Dynamo skills are listed in two
cross tables below. Table 5.5 indicates, that the extreme cases with the answer of 0%
(of designer) can be neglected, because two of these participants have no experience
and one has only intermediate experience. The most votes of advanced to expert
users are in the range between 1 to 30% and the remaining participants of this skill
level and two guru Dynamo users think a higher percentage is economically
beneficial. A correlation with the Dynamo skills cannot be identified.
Table 5.5: Percentages of designers who should be able to create and adjust Dynamo definitions in
comparison with the Dynamo skills
What level is your skill in Dynamo?
percentage
no Total
of designer beginner intermediate advanced expert guru
experience
Count 2 0 1 0 0 0 3
0%
% of skill 100% 0,0% 5,0% 0,0% 0,0% 0,0% 4,3%
Count 0 6 6 0 3 0 15
1% to 10%
% of skill 0,0% 26,1% 30,0% 0,0% 42,9% 0,0% 21,4%
Count 0 4 3 3 1 0 11
11% to 20%
% of skill 0,0% 17,4% 15,0% 18,8% 14,3% 0,0% 15,7%
Count 0 5 1 4 2 0 12
21% to 30%
% of skill 0,0% 21,7% 5,0% 25,0% 28,6% 0,0% 17,1%
Count 0 1 2 2 0 0 5
31% to 40%
% of skill 0,0% 4,3% 10,0% 12,5% 0,0% 0,0% 7,1%
Count 0 1 3 1 0 1 6
41% to 50%
% of skill 0,0% 4,3% 15,0% 6,3% 0,0% 50,0% 8,6%
Count 0 2 1 1 0 0 4
51% to 60%
% of skill 0,0% 8,7% 5,0% 6,3% 0,0% 0,0% 5,7%
Count 0 0 0 0 0 1 1
61% to 70%
% of skill 0,0% 0,0% 0,0% 0,0% 0,0% 50,0% 1,4%
Count 0 1 0 1 0 0 2
71% to 80%
% of skill 0,0% 4,3% 0,0% 6,3% 0,0% 0,0% 2,9%
Count 0 3 3 4 1 0 11
91% to 100%
% of skill 0,0% 13,0% 15,0% 25,0% 14,3% 0,0% 15,7%
Count 2 23 20 16 7 2 70
Total
% of skill 100,0% 100,0% 100,0% 100,0% 100,0% 100,0% 100,0%
Table 5.6 indicates nothing unexpected. There is a general tendency of all skill levels
to a higher percentage with a peak at 91 to 100%. But to identify a clear pattern a
larger sample is necessary and the Dynamo skills should be verified with a Dynamo
quiz.
Table 5.6: Percentages of designers who should be able to use existing Dynamo definitions in
comparison with the Dynamo skills
What level is your skill in Dynamo?
Percentage
no Total
of designer beginner intermediate advanced expert guru
experience
Count 1 1 1 0 0 0 3
0%
% of skill 50,0% 4,3% 5,0% 0,0% 0,0% 0,0% 4,3%
Count 0 1 4 0 0 0 5
1% to 10%
% of skill 0,0% 4,3% 20,0% 0,0% 0,0% 0,0% 7,1%
Count 1 0 1 0 1 0 3
11% to 20%
% of skill 50,0% 0,0% 5,0% 0,0% 14,3% 0,0% 4,3%
Count 0 3 1 1 2 0 7
21% to 30%
% of skill 0,0% 13,0% 5,0% 6,3% 28,6% 0,0% 10,0%
Count 0 1 1 1 0 0 3
31% to 40%
% of skill 0,0% 4,3% 5,0% 6,3% 0,0% 0,0% 4,3%
Count 0 0 1 0 0 0 1
41% to 50%
% of skill 0,0% 0,0% 5,0% 0,0% 0,0% 0,0% 1,4%
Count 0 4 0 2 2 0 8
51% to 60%
% of skill 0,0% 17,4% 0,0% 12,5% 28,6% 0,0% 11,4%
Count 0 0 2 1 1 0 4
61% to 70%
% of skill 0,0% 0,0% 10,0% 6,3% 14,3% 0,0% 5,7%
Count 0 4 3 3 0 0 10
71% to 80%
% of skill 0,0% 17,4% 15,0% 18,8% 0,0% 0,0% 14,3%
Count 0 2 1 1 0 0 4
81% to 90%
% of skill 0,0% 8,7% 5,0% 6,3% 0,0% 0,0% 5,7%
91% to Count 0 7 5 7 1 2 22
100% % of skill 0,0% 30,4% 25,0% 43,8% 14,3% 100% 31,4%
Count 2 23 20 16 7 2 70
% of skill 100% 100% 100% 100% 100% 100% 100%
5.9 Dynamo node development
58.6% of all participants have already developed Dynamo nodes (Figure 5.15). A
further research of this sub-sample reveals that it is possible without textual
programming skills to develop a new Dynamo node.
Figure 5.15: Development of Dynamo nodes
The reason for this is there are several ways to create a new node: A graphical
method with combining existing nodes or method by usage of textual programming
code. The ratio (red) in Figure 5.16 shows a correlation between the general textual
programming skills of all participants and the general textual programming skills of
the participants who have developed a Dynamo node. The better the textual
programming skills the higher is the likelihood to be a node developer.
Figure 5.16: Textual programming skills of all participants (dashed) in comparison with
participants who have developed Dynamo nodes before (grey) and the ratio between
them
5.10 Publishing of Dynamo nodes
All participants who have developed Dynamo nodes were asked if their company
publish the nodes to the community or not and the reason for their decision:
Figure 5.17: Are the developed Dynamo nodes published ?
With the wisdom of hindsight the questions should be stated more clearly and it
should be asked for publishing the nodes to the whole Dynamo community in the
package manager to prevent misunderstandings.
This question reveals that a majority of the companies do not share their developed
nodes or only a minority of the nodes. In an additional comment box the participants
could give reasons for the companies’ behaviour. All comments by the participants
were analysed and every group is presented with corresponding arguments:
Group A – All nodes are published

This group of participants share their work to learn from each other. Thus all get
faster to a higher skill level.
Group B – Most nodes are published

There are different reasons for not sharing some of the developed nodes. The
majority has some nodes developed which are too specific to share, depending on a
special family or on special parameters. Some nodes are still under development and
not mature enough to share. And one participant mentions it took a lot of time to
create it and it is therefore too valuable to share. One participant mentions he have
just reworked already existing nodes.
Conclusion of these statements:

There should be a release portal for beta nodes to improve the quality, to get
feedback about the usefulness, to discuss node specific problems and to suggest node
improvements. It should be possible to share nodes together with corresponding
families, special parameters, instructions and release versions.
Group C – A minority of the nodes are published

Similar to group B most participants have developed many project specific nodes and
they cannot see a demand by the community or it is not worthy to invest the extra
time to distribute it. The developed basic nodes are similar to existing nodes and thus
not shared with the community.
Group D – None of the nodes are published

Some cases of this group have developed node prototypes, but they doubt about the
quality of their nodes and the maturity of Dynamo. Some of them can see negative
marketing effects by publishing nodes with some possible errors. Some of them get
not the time or clearance by the management for publishing not nodes. And some are
developing nodes for clients or for company internal usage only to have a
competitive advantage.
This was the opinion by the node developers themselves but what are possible
reasons for a company not to share their developed nodes and how can they be
motivated to publish the nodes for free? To push every participant into such a
situation, a fictional statement (which is likely to be true) is presented to the
participants: ‘Some companies don’t share developed custom nodes with the
community. What do you think are the reasons?’ All answers are recoded into similar
opinions and are presented in Table 5.7.
Table 5.7: Possible reasons for companies not to share custom nodes with the community
Responses Percent of
Reasons not to publish Dynamo nodes
N Percent Cases
Competitive advantage 31 31,6% 44,3%
No opinion / I don't know 13 13,3% 18,6%
There is no economic benefit to share nodes 12 12,2% 17,1%
Attitude and mentality of people to share things 11 11,2% 15,7%
Intellectual property and Copyrights 10 10,2% 14,3%
Nodes are too (project) specific are only useful
7 7,1% 10,0%
with companys Revit parameters
Liability & legal issues 6 6,1% 8,6%
Reluctance to provide support, extra work for
4 4,1% 5,7%
publishing
NDA agreements, company policies prohibit
3 3,1% 4,3%
sharing
The strength of open source concept and sharing
1 1,0% 1,4%
is not understood
Total 98 100,0% 140,0%
As we have seen in Figure A.17 and Table 5.7, there is a reluctance to share custom
nodes with the community. The detailed analysis shows that it can be attributed to
various reasons. To expedite the development and the availability of a broad
functionality it is essential to motivate all developers and companies to publish their
custom nodes and relevant documentation. As a consequence the question ‘How can
developers and companies be motivated to publish their nodes for free?’ is stated.
This question was several times mentioned as difficult to answer and as a result the
majority has no suggestion provided and all other answers are widely spread.
Therefore it should be seen as a collection of ideas instead of ranking about the
effectiveness. All answers are recoded into multiple response variables and the data
is presented in Table 5.8 and Figure A.40. The controversial suggestion of economic
incentives was expected by the author and thus the subsequent question about
commercial node-packages was stated and will be analysed in chapter 5.11.
Table 5.8: Possible motivations for developers to share nodes with the community
Possible motivation to publish nodes for free
N Percent Cases
No opinion / I don't know / no appropriate answer 36 44,4% 52,2%
Acknowledgement / reputation / advertisment opportunity 13 16,0% 18,8%
Economic incentives 8 9,9% 11,6%
Not possible 4 4,9% 5,8%
Not necessary / there is already enough motivation 4 4,9% 5,8%
Explain benefits and reasons to share 4 4,9% 5,8%
Give them sth. in return for doing so 3 3,7% 4,3%
Premium support by software manufacturer 2 2,5% 2,9%
Discount on licences 2 2,5% 2,9%
Patents 1 1,2% 1,4%
Hackathons 1 1,2% 1,4%
A quality improvment system to test and improve the
1 1,2% 1,4%
published nodes
More control over published work 1 1,2% 1,4%
Easier and more transparent publishing process 1 1,2% 1,4%
Total 81 100,0% 117,4%
5.11 Commercial node-packages
Following questions was stated: ‘Do you think a node-package store (to sell custom
nodes) would be beneficial to the Dynamo community?’
Figure 5.18: Is a node-package store beneficial to the Dynamo community?

This is as expected a controversial topic because many Dynamo users like the open-
source concept to use all nodes for free and be able to extend its functionality with
improvements and enhancements. To learn by study the textual programming code
helps developers to develop other nodes faster and with better quality. Bugs and
errors can be solved together as a community. There are many developers who like
the concept of sharing their work for free – but of course there are other groups of
developers: Some offices or companies employ a development team to creating
highly complex Dynamo nodes. And another potential developer group are
specialized software companies with developers. They are hired by clients and offer
services like task specific nodes to extend their capabilities. Both of them spend
money to get a competitive advantage.
The difficult task is how to preserve the open-source concept of sharing, learning and
helping – and at the same time how to give professional developers or principals a
reason to share or a compensation for their invested time and money.
27.9% of the participants have voted in favour and 41.2% against the commercial
node-package store. Many of them have stated requirements and suggestion how this
has to be done. All answers have been analysed, sorted, and extended into three
different proposals:
Option A: Possibility to charge a fee for professional highly complex nodes
 Details:
Only highly complex error free nodes which have passed a quality check are
able to be charged. Similar to Google Play Store, there should be a commercial
node version with full functionalities and a free version with limited
functionalities or adverts (see option B below). A specific percentage of the
revenue should be transferred into a community foundation to support the
development of free nodes
 Potential negative effects:
 Former free nodes are converted into commercial nodes

 Textual programming code is not accessible (black-box nodes) to learn new

methods and to reuse it
 A custom-node which includes the commercial node is depended on the

availability of the licence
 Potential positive effects:
 Developers can finance the development efforts
 Developers can spend more time for support and documentation
 They are encouraged to develop further nodes
 The global view on possibilities with Dynamo, even if it is commercial, will

attract more users
Option B: Possibility to include advertisements into the node
 Details:
After the quality check of the submitted node (similar to the Autodesk add-in
store), the developers can place adverts by themselves (for example job
advertisements, company logo, or service offers) into the nodes or they can
activate an advertising system. By tracking the usage of the node the revenue is
calculated and the developer gets a monetary compensation. The advertising
space is sold in a commercial e-store.
 The Dynamo canvas gets confusing
 Very specific and complex nodes are not used often to generate enough
advertising revenues to compensate the effort by the developers
 Nodes are still available for free
 Companies can create an additional revenue, especially if the nodes are used
regularly
Option C: Nodes can be shared only for free

 Details:
Instead of a commercial node-package store, a platform is provided to share,
discuss, and explain nodes. Advertisements can be placed on each node page to
generate some compensation. Node specific problems can be discussed and
solved without disappearing in the Dynamo forum.
 It is likely that high quality and complex nodes will be used only internally
and are not available to the community. Instead every big company develop
their own nodes without sharing the effort.
 It is likely that one or several commercial stores will be created by someone

else without any control or regulations by the community
 Nodes are still available for free
 Nodes can still be used to new custom-nodes by combining them
 The quality gets improved by node specific discussions
 The collaborative nature of open-source is not endangered
 Adverts can be placed on the platform as well
5.12 Dynamo platform development
As stated in chapter 5.9 more than 58% of the survey participants have already
developed a node for Dynamo. But the analysis of the question about the
contribution to GitHub to help developing the Dynamo software itself is
disappointing. Figure 5.19 shows that only five participants have contributed as an
active developer.
Figure 5.19: Contribution to the development of Dynamo on GitHub
Of course many users have not the skill and experience in software development. But
there are also some users who have an account and like to help but don’t know how
to use GitHub for example to report bugs. And eight participants do not contribute
because they have not enough time to do it. Another fact is that Autodesk develops
and discuss Dynamo in their internal and non-public meetings. Maybe Autodesk
should make monthly open developer meetings to discuss with the external developer
community what are they working on and where someone could possibly assist them.
It would be interesting for non-programmers as well and could form a stronger
Dynamo developer community, because they can interact with professional
developers.
5.13 Future success of Dynamo
The analysis of the survey so far shows that Dynamo has the right to exist. But there
are some critical bottlenecks that limit the potential of Dynamo. To reveal the
limiting factors the question ‘What factors are important to make Dynamo more
successful?’ was stated in the survey.
Table 5.9: Future success factors for Dynamo

N Factor
17 Documentation / examples (for daily & basic tasks) / tutorials
11 Stability
9 More connections to other software
8 Improved performance & computation time
7 Easier interface / more intelligent behaviour of nodes / user friendliness
5 Improved community integration/participation
4 Yearly builds / less versions / no rework of existing definitions after updates
3 More high quality nodes for complicated tasks
3 More Revit MEP functions
3 Extended integration of Revit functions as nodes
1 Free standalone Dynamo
1 Overhaul of the Revit geometry kernel
1 Ability to quickly remove / add Revit elements
1 Improved integration/support for 3rd party developers
1 Upgraded forum functionality
1 Capability to use Revit type parameters
1 Improved debugging process
1 Improved process and more options to select Revit elements (e.g. Filter)
1 Improved tool tips of nodes / node specific documentation and discussions
Node name dictionary and an international standard for names of node types.
1
The dictionary should be optional to be included in the node search
1 Multiplatform support
1 Password protection for nodes
5.14 Software skills of the participants

Table 5.10: Software skills distribution
I don't
inter- beginner
70 know the no exp. beginner adv. expert guru
mediate to guru
software
0 0 1 5 18 26 20 70
Revit
0% 0% 1% 7% 26% 37% 29% 100%
0 2 20 18 19 8 3 68
Dynamo
0% 3% 29% 26% 27% 11% 4% 97%
2 11 22 22 9 3 1 57
SketchUp
3% 16% 31% 31% 13% 4% 1% 81%
4 23 17 15 4 5 2 43
Rhino 3D
6% 33% 24% 21% 6% 7% 3% 61%
6 30 13 9 4 6 2 34
Grasshopper
9% 43% 19% 13% 6% 9% 3% 49%
12 33 15 7 3 1 0 26
ArchiCAD
17% 47% 21% 10% 4% 1% 0% 37%
14 33 11 8 1 1 2 23
MicroStation
20% 47% 16% 11% 1% 1% 3% 33%
Generative 23 32 7 6 1 0 1 15
Components 33% 46% 10% 9% 1% 0% 1% 21%
23 36 6 5 0 0 0 11
Vectorworks
33% 51% 9% 7% 0% 0% 0% 16%
27 33 8 2 0 0 0 10
Flux.io
39% 47% 11% 3% 0% 0% 0% 14%
33 35 2 0 0 0 0 2
Marionette
47% 50% 3% 0% 0% 0% 0% 3%
The result of this question represents the software knowledge of people who are
interested in Dynamo. A survey with a focus on Grasshopper or other graphical
programming tools would show different results for Rhino, Revit and Dynamo etc. of
course.
CHAPTER 6
6 DISCUSSION
BIM enabled design tools and the current BIM based design process are criticized in
the literature as too simplistic, with limited complexity, lack of computational
approaches and missing interoperability between software. Design tools are blamed
to focus on data storage instead of using, manipulating and creating data in an
intelligent way. Problems are solved through trial and error procedures and mainly a
manual modelling approach is applied.
This research investigates if these problems can be solved or at least be improved by

using the graphical programming tool ‘Dynamo’. Therefore the findings of the
conducted research are discussed and evaluated with regard to existing literature. The
research questions in chapter 1.3 are used as guideline to describe the patterns,
principles and relationships of the findings.
To what extent is graphical programming effective at helping to improve

the BIM workflow?
The research reveals that graphical programming can be an effective computational

approach in the design process of BIM and the graphical programming tools
(especially Flux and Dynamo) help to bridge the lack of interoperability between
software (chapter 5.6 & 5.7). The available nodes and custom-nodes shared by the
community have embedded functionality which can be used by all designers without
using textual programming (chapter 5.5). Thus once nodes are created and studied,
they can be easily used without having knowledge of the embedded (API) methods.
How effective is the usage of graphical programming in a BIM project to

solve specific problems and what are the reasons?
The open-source concept of Dynamo enables companies to use the existing code
base to develop and enhance their BIM workflow (chapter 5.6). Companies and their
developers have started to develop an in-house collection of nodes to get a
6. Discussion 78
competitive advantage. Some developers share their nodes and workflows with the
community because they like the community spirit to learn from each other. But
there is still reluctance by a majority of the developers / companies to share their
nodes and workflows (chapter 5.10). Especially complex and valuable nodes are less
likely shared with the community due to preserve a competitive advantage, no
compensation, or increased effort for support and documentation.
How can the economic value of graphical programming (Dynamo) be

measured? Who and how much percent of a design team should be able
to use graphical programming (Dynamo)?
Graphical Programming with Dynamo is suitable for non-programmers as well as for

programmers and its passage is fluent. It is likely that Dynamo users get more
interest to dive deeper into textual programming (Figure 5.11), because the entry
point into graphical programming is low and the free choice of using code-blocks
creates no pressure on the users. Thus the ratio of designer with textual programming
skills will increase over time as well. This helps companies to prepare their
employees for a time with increased demand for data-driven design (Deutsch, 2015).
The findings reveal that textual programming skills are still useful to use Dynamo in
all situations successfully. The usage of the hybrid programming approach leads to
more flexibility and missing nodes can be bridged with code-blocks.
Especially for complex problems, textual programming is still in demand. And once
the Dynamo definition is created and well documented by more experiences users, it
can be shared with colleagues and be reused by all designers. Thus not all employees
need to be an expert in how to create Dynamo definitions. According to the survey
result, 1-30% of designer should have advanced skills in creating and adjusting
Dynamo definitions and the majority of designers should at least be able to use
existing definitions.
By solving more tasks with algorithms the labour time is reduced and thus economic
value is created. It is hard to define an exact measure for value, but the research
indicates fewer errors and reduced labour time for the same amount of work.
6. Discussion 79
Can a BIM workflow improved with graphical programming?
The research reveals that automation of tasks with textual programming (e.g. Revit
Macros or add-ins) is more difficult to apply or create than graphical programming
with Dynamo. With Dynamo it is now possible for an average designer to apply the
computational power of the computer in various situations. Especially tedious tasks
can be automated with Dynamo and labour time is reduced. With Dynamo it is easier
to create a rule-driven testing process to check for errors or deviations. If the early
design is created with algorithms in Dynamo, changes of parameters can be
evaluated quickly and intuitive.
What are the barriers to use graphical programming (Dynamo)?
Some barriers are encountered at all new technologies: There is a reluctance to invest
time to learn an additional tool. The benefit of applying algorithms is still often
neglected. Small design offices have no programmers in their team, thus the
designers think they have not suitable skills to create algorithms. Some have
answered in the survey that there is a lack of documentation / tutorials for daily tasks
solvable with Dynamo. Stability and performance issues, and too frequent releases of
new versions resulting in a failure of existing definitions.
What are the key factors for successful graphical programming software
in the context of BIM?
In chapter 2.1 Lopes suggest several key factors for a programming language. All
these properties are valuable, but in contrast to Lopes’ findings in 2012, Dynamo is
supporting all principles (some of them only to a limited degree). But to have a
programming language suitable for improving BIM process, the list should be
extended with following principles:
 Provide connections to multiple BIM authoring tools
 Provide ability to bake created intelligence into 3D geometry (native file formats
& IFC)
6. Discussion 80
 Provide ability to execute defined algorithms independently from single user

activity (i.e. cloud-based)
 Open-source access
What types of employees are using graphical programming (Dynamo)

already and how often?
Most frequently Dynamo is used by BIM Managers, BIM Technicians, and

architecture related staff (chapter 5.2). Young professionals are using graphical
programming more often than the older generations and most of the Dynamo users
have strong Revit skills. The general programming skills are spread across all skill
categories, but with a peak of beginners and a minority of experts. The average usage
of graphical programming is about eight hours per week (Appendix Figure A.16).
Only a minority of designers are at the moment able to create Dynamo definitions,
but there is a tendency and wish to increate this ratio (chapter Figure 5.8).
What are common day-to-day tasks for graphical programming (Dynamo)?
At the moment Dynamo is mostly used for extracting, transfer, manipulation,

management, and quality assurance of existing data (chapter 5.6). Generative design
is only represented by the categories ‘geometry creation’ and ’conceptual design’.
Thus it can be argued that Dynamos’ generative design functionalities are only
existent in a limited form. External research tools (e.g. Project Akaba) and also
Grasshopper have already more advanced functionalities for generative design and
the developer should link to these functionalities to develop similar and later on more
advanced functionalities for generative design.
Which types of projects are suitable for graphical programming

(Dynamo) and what are the reasons?
Large projects can benefit a lot, because specific tasks have to be done many times or
are so valuable that an optimized design can save much money. Thus the time to
create a working algorithm is amortizing soon. But small projects are also suitable,
6. Discussion 81
because normally the tasks are repeated with each project. At the moment building
construction projects are most common, because of the strong connection to Revit.
But other software connections are developed as well and thus civil engineering and
other types of projects are getting more common in the future.
What implications/effects have the use of graphical programming

(Dynamo) on the employees regarding outcome, job satisfaction and job
performance (at the learning phase and later at the usage phase)?
Manual and often repeated tasks are perceived as boring and as a waste of skills. And
if there are no interns who can do these boring tasks, an employee with high wages is
bound to such work. By using graphical programming, designers have more time for
application of skills and can concentrate on optimizing the design and apply their
domain knowledge more effectively.
CHAPTER 7
7 CONCLUSION
The literature research about graphical programming clearly shows that the goals at
the beginning of the first graphical programming tools until today are similar: They
are supposed to simply workflows. In the last decade the design process in the AEC
industry was strongly influenced by new tools, which are based on BIM.
Shortcomings like the lack of suitable computational approaches available for
designers and engineers were identified. The success of Grasshopper has highlighted
the demand for tools, which can be used by non-programmers but still have the
ability to create algorithms for multi-criteria design optimisations. Advanced
scripting with textual programming is not an option for the average designer. Thus
the outstanding graphical programming tool ‘Dynamo’ and its usage have been
studied in detail.
The initial intended research was founded on a tri-angulated method, by the use
practical experience with Dynamo, a literature research, a survey and interviews. But
the survey which used a mixed research approach of quantitative and qualitative
questions, have resulted in very many and rich answers. Thus the intended follow up
interviews were not conducted.
The practical usage of Dynamo, discussions and presentations on several Dynamo

related events, and the available literature have revealed strong advantages of
Dynamo, but also technological challenges and areas for improvement:
The concept of graphical programming is for non-programmers very simple to grasp.
But the large amount of nodes and the hidden functionality requires a good
documentation and time to learn the principles. The direct feedback of actions and
the graphical representation helps to understand the generated algorithms. The reuse
and exploration of existing definitions supports the learning process.
A strong technical advantage is the interoperability of Dynamo (and Flux). Thus

different programs can be connected to each other by using nodes. Compared to the
commonly used add-ins, by embedding the same functionality into nodes, the data
can be bi-directionally processed and the user is much more flexible. Developers can
A. Appendix 83
use the open-source access to create additional connections. Shu (1988, p. 136) has
“classified visual languages into three categories: (1) languages for processing visual
information, (2) languages for supporting visual interaction, and (3) languages for
programming with visual expressions”. However, in modern visual programming
environments like Dynamo all the three categories are included. In addition such an
environment comprises several graphical programming languages, textual scripting
languages, and compiled textual components. Thus the author suggests for such
developer environments to use the name ‘multi-dimensional programming language’.
In the conducted survey 70 participants have answered quantitative and qualitative

questions about Dynamo and its usage. The results are not statistical significant, thus
the results and findings should be seen as a tendency.
Most participants have BIM related roles at work with advanced Revit skills. To use
Dynamo textual programming skills are not necessary. But the findings indicate it is
still important to use Dynamo successfully. In comparison to task automation with
textual programming interface like Revit Macros, Dynamo is applied more
successfully – even participants with textual programming skills were more
successful with Dynamo. It is perceived, that graphical programming motivates the
users to dive deeper into textual programming.
At the moment Dynamo is mostly used for extracting, transfer, manipulation,

management, and quality assurance of existing data. Confirmed positive effects of
applying Dynamo are the automation repetitive tasks, the reduction of labour time,
better control on available data and the bi-directional transfer between software is
improved. Iteration functionality, the need of textual programming, and generative
design is not fully confirmed by the participants.
A majority believes that 1-30% of the designers in an office should be able to create
and adjust Dynamo definitions. But in contrast, 51-100% of the designers in an office
should be able to use existing definitions.
Many participants have developed nodes for Dynamo, but there is still a strong
reluctance to share nodes with the community. Only 30% actively share their
developments with the community. The main reasons for not sharing nodes are to
gain a competitive advantage, no economic benefit, and the attitude of people. To
A. Appendix 84
change this situation possible motivational factors are acknowledgment / reputation /

advertisement opportunity, economic incentives, explanation of the benefits to share.
The authors’ suggestion to provide a commercial node store was controversial,
because some participants see the open-source concept in danger – but others believe
a commercial store can help developers to invest more time on complex nodes, on its
documentation and support.
The Dynamo platform itself is developed mainly by Autodesk employees. Only 7%

of the participants have contributed to the development on GitHub. Of course many
designers have not the skills to develop software, but development efforts by
Autodesk developed as top secret projects. By an more open development, the author
believes, that more developers are attracted to support the Dynamo development.
For the future success of Dynamo the documentation, the stability, the performance
and further software integrations are important.
Some interesting topics for future research are:
 How can the intelligence of a created algorithm be transferred into 3D

geometry? What are the consequences for the BIM design process?
 What are the advantages / disadvantages of a cloud-based graphical

programming tool?
 How can the creation process of a Dynamo definition be automated?

85
APPENDICES
A APPENDIX
A.1 Survey participant introductions
Every participant was informed on the first survey page about the reasons, the
research framework, the expected length of the survey, and about the personal data
security.
The Information Flyer is available in full size on the following file path on the CD:
CD\Survey\Survey_participant_instructions.pdf
Figure A.1: Survey flyer: Participant information

A. Appendix 86
A.2 Survey questions and data distribution
A.2.1 Question 1
Figure A.2: Participant introduction and survey Question 1

A. Appendix 87
A.2.2 Question 2
Figure A.3: Survey question 2
Table A.1: Question 2 statistics: Office type frequencies

Office type
N Percent Cases
Architecture 42 24,1% 60,0%
BIM Consulting 29 16,7% 41,4%
Structural Engineering 21 12,1% 30,0%
Civil Engineering 11 6,3% 15,7%
Construction 11 6,3% 15,7%
Visualisation 11 6,3% 15,7%
Project Management 10 5,7% 14,3%
Electrical Engineering 8 4,6% 11,4%
Mechanical Engineering 7 4,0% 10,0%
University 6 3,4% 8,6%
General (multi-discipline) 6 3,4% 8,6%
Software Developer 4 2,3% 5,7%
Quantity Surveying 4 2,3% 5,7%
Fabrication 3 1,7% 4,3%
Operation and Maintanance 1 0,6% 1,4%
Total 174 100,0% 248,6%

A. Appendix 88
Figure A.4: Question 2 distribution: Office percent of cases

A. Appendix 89
A.2.3 Question 3
Figure A.6: Survey data question 3: Role distribution of the participants

A. Appendix 90
A.2.4 Question 4
Figure A.8: Answer distribution of textual programming skills

A. Appendix 91
A.2.5 Question 5
Figure A.10: Age distribution of the participants

A. Appendix 92
A.2.6 Question 6
Table A.2: Revit Skills of the participants

Revit Skills Count Valid N %
I don't know the software 0 0,0%

no experience 0 0,0%
beginner 1 1,4%
intermediate 5 7,1%
advanced 18 25,7%
expert 27 38,6%
guru 19 27,1%
Total 70 100,0%
Figure A.12: Revit Skills of the participants

A. Appendix 93
A.2.7 Question 7
Figure A.14: Usage of Revit Macros

A. Appendix 94
A.2.8 Question 8
Figure A.16: Average usage hours of graphical programming per week

A. Appendix 95
A.2.9 Question 9
Figure A.18: Dynamo skills of all participants

A. Appendix 96
A.2.10 Question 10

A. Appendix 97
Figure A.20: Are textual programming skills important to use Dynamo successfully?
Table A.3: Agreement distribution about statements on effects of applying Dynamo

Valid cases N= 69
Agreement
Opinion no opinion & ratio
Effects of applying Dynamo Disagree Agree
available undecided
N Percent N Percent N Percent N Percent Percent
With Dynamo repetitive tasks
68 98,60% 1 1,40% 0 0,00% 68 98,60% 0,99
can be automated
The utilization of Dynamo
64 92,80% 5 7,20% 2 2,90% 62 89,90% 0,87
reduces labour time
Better control on available
58 84,10% 11 15,90% 1 1,40% 57 82,60% 0,81
data
Bi-directional data transfer
between software is improved 59 85,50% 10 14,50% 3 4,30% 56 81,20% 0,77
with Dynamo
Transfer of data between
software gets easier with 56 81,20% 13 18,80% 4 5,80% 52 75,40% 0,7
Dynamo
The iteration / optimisation
process and its results can
54 78,30% 15 21,70% 5 7,20% 49 71,00% 0,64
be presented clearly and
understandable
Iteration workflows are well
56 81,20% 13 18,80% 6 8,70% 50 72,50% 0,64
supported by Dynamo
Design outcome has with
43 62,30% 26 37,70% 4 5,80% 39 56,50% 0,51
Dynamo a better quality
Textual programming skills

are important to use Dynamo 58 84,10% 11 15,90% 14 20,30% 44 63,80% 0,43
successfully
A. Appendix 98
A.2.11 Question 11
Table A.4: Most frequently solved problems with Dynamo

N Problems / tasks
22 Extracting data / data transfer / interoperability between software
21 Automating repetitive tasks
21 Model management / data management
19 Data manipulation
10 Geometry creation
8 Quality assurance / quality checks
5 Conceptual design
4 Object and family creation
3 Revision / index management
3 Quantity take-offs
2 Documentation
2 Finding / filter elements
2 Clash report creation with colourisation
2 Topography manipulation
2 Structural design
1 Data mining
1 Recesses
1 Energy analysis
Raw data:
 Design intent finds expression in code in the very early stages of the
conceptual design process.
 Documentation and workflow optimisation
 Automating repetitive tasks, reducing button clicks
 Data input i.e. Door fire rating, ironmongery, etc.
 QA/QC and Data management

A. Appendix 99
 Not many, Grasshopper is superior. Dynamo seems to be an easy way into

Revit API for Revit model management
 Data transfer, automated object generation, geometry generation
 Conceptual design of spatial light structures
 Data transfer, model management and parametric design
 Repetitive task automation, data interoperability for schedules
 Repetitive tasks, parameter change, finding elements and changing properties,

extracting data
 ID/Running index management
 Data exchange between software parametric structures
 Data Extraction, File Management - removing CAD import data, pushing

parameters
 Manipulating parameters
 Data management, generation of families and complex geometry.
 Data mining
 I find it most useful as a way to quickly verify that I have populated

parameter data that will be used for tagging, scheduling, etc. For example,
colour code elements based on the presence or absence of specific data
 Model quality control and task automation
 All kind of Information Management (2 ways), task automation,

quantification, visual clash report (colour), Design automation
 Sheets, views, parameters, data extraction, recesses, generation models based

in certain prerequisites
 Automation of repetitive tasks (mark numbers, room numbers etc.), geometry

creation - housing Adaptive Components back into Revit through a fully
flexible 'rig' in Dynamo Colouration 'visual checks' in 3D views
A. Appendix 100
 Repetitive task solutions, program to excel to dynamo to Revit for concept

design
 Design forms
 Mostly automation tasks. To date, I've used Dynamo to:
- Create dynamic links between unconnected objects, such as Spaces,

HVAC Zones, Mechanical Equipment and Communication Devices
(Thermostats). I accomplish this with spreadsheets linked to the Dynamo
script.
- Generate revision narrative document in Excel that lists the comment

parameter data for all revision clouds, sorted by date.
- Force the electrical load classification parameter for all mechanical

equipment to match the mark parameter, which automates the task of
manually filling out the equipment name in electrical panel schedules.
 Automation
 Auto data input (parameter); add shared parameter; auto join / unjoin and cut;
auto create wall / floor / pipe / tree etc. by CAD
 Clash analysis with Dynaworks; parametric design; model maintenance; data

manipulation
 Everything from geometry creation to cross-platform data manipulation
 Excluding triviality or overly involved processes that should by right already

be easier
 Mostly data-related problems: sorting, filtering elements by parameter data in

more complex ways than a traditional Revit schedule would, extracting data
based on elements' position in space or related to one another, automating
documentation-related tasks
 Primary for topography purposes
 Automating tasks; extracting meaningful data; check / verify
 Data sorting manipulation and collection

A. Appendix 101
 Geometry; energy analysis; task Automation
 Design
 Automation; filling gaps from OOTB features
 Practical Dynamo: renumbering, scheduling, auditing, solving warnings,

deleting duplicates, filling shared parameter values.
 Dynamo data transfer to Revit
 repetitive tasks; linking Revit to excel
 Complex geometry, import from other software, task automation,
 Transfer information, complex design
 Solving interoperability with non-Revit users: importing and exporting from

and to Excel
 Repetitive design elements on facades, bi-directional excel workflow
 Structural design
 Revit DB information processing, geometry evaluation and analysis, custom

quantity take-off, optimization of redundant tasks
 Grasshopper - Revit Interoperability
 Creating new elements in Revit at intersections of existing elements.

Gathering mass data from Revit's database
 Repeating works in Revit
 Data / parameter manipulation
 Model quality assurance: Managing naming and parameter values in Revit.
 Automating Repetition
 Bi-directions data transfer with Excel and Revit
 Structural design
 Repetitive tasks, topography following hardscape

A. Appendix 102
 Combination of Parameters; calculations; quality checks
A.2.12 Question 12
Answers:
 Architectural design schemes that are developed purely with code (Design
Script) using data relevant to the site, without any preconceived ideas.
 Too many to name but most are centred around automating documentation
tasks
 Automation of code analysis in Revit with Dynamo.
 Erection sequencing - special phasing (more than exist / new / temp /

demolished) generates 3D views for every sequence in the same orientation,
etc. colour coding based on sequence and intended use.
 Automatic creation of families from Dynamo geometry, extraction of all

kinds of data from Revit models.
 Pattern repetitions, tessellations
 Model auditing and a fairly advanced sheet creation script within built
checkers
 Making sheets automatic, schematic block diagram in drafting view. Export

sheets lists and import them with engineer information. Parameter mapping
for the offsets.
 Geometric form, complex data processing / restructuring
 Sheet creation, parameters, find elements, quality checks

A. Appendix 103
 exchange data with structural analysis tools
 Pushing type name information to type mark, removing CAD import junk
 Extracting information from large projects with multiple linked files per
model, consistency testing / clash testing, parameter manipulation
 Revit geometry to Robot via Dynamo – MS Excel – grasshopper
 Created formwork models and got their take-offs
 Batch update drawing title block information. Batch transfer of design

information into model.
 Automatically documenting my custom nodes
 Creating custom bill of quantities, create grids from CAD, list and rename
levels based on Excel, push information from Excel to Revit
 Sheet, View management, Recesses,
 Allowing previously untouchable parameters (i.e. greyed out) to parse their

data to a new shared parameter. For example area of filled regions. You can
then schedule / tag it.
 Place every family types of a specific family on a view; place a family in its
destination room; delete imported line styles; place survey point in Revit;
view and sheet creation
 Complex model workflow
 Read and Write Parameter by Excel, batch add shared parameter to families,
Control the filter visibility / colour / pattern, topography manipulation, place
family be point
 Acoustic optimisations
 Extract spatial coordinates of building geometry and write them to a

schedule, apply different facade panel types or parameter values according to
an Excel spreadsheet, perform zoning area calculation
 Data sorting
A. Appendix 104
 Automated Space Layout
 Forms
 Get clashes from Navisworks to Revit, get data from links
 Automating tasks
 Populate automatically a Revit model by an Excel spreadsheet
 Importing a boat shape form Rhino
 Facade design, structure design, transfer information
 Communication with no Revit users involving them into data base

information
 Structural design, project option generation
 data transfers, parametric studies
 Direct connection between Grasshopper geometric model and Revit's IFC

properties
 We use it to speed modelling and drafting tasks.
 Door schedule, room schedule, Rhino geometry transmit
 Wall finish area calculations, sheet and view creation, geometry creation and
manipulation, parameter editing
 Node to identify who created objects.
 Randomization of Facades
 Modelling complex structures

A. Appendix 105
A.2.13 Question 13
Figure A.24: Percentages of designers in the office who are able to create Dynamo definitions
A. Appendix 106
A.2.14 Question 14
Figure A.26: Percentages of designers who should be able to create and adjust Dynamo
definitions
A. Appendix 107
A.2.15 Question 15
Figure A.28: Percentages of designers who should be able to use existing Dynamo definitions
A. Appendix 108
A.2.16 Question 16
Figure A.30: Development of Dynamo nodes

A. Appendix 109
A.2.17 Question 17
Figure A.32: Are the developed Dynamo nodes published ?

A. Appendix 110
A.2.18 Question 18
Figure A.34: Motivation to learn textual programming by using graphical programming

A. Appendix 111
A.2.19 Question 19
Figure A.36: Contribution to the development of Dynamo on GitHub

A. Appendix 112
A.2.20 Question 20
Table A.5: Possible reasons for companies not to share custom nodes with the community
Reasons not to publish Dynamo nodes
N Percent Cases
Competitive advantage 31 31,6% 44,3%
No opinion / I don't know 13 13,3% 18,6%
There is no economic benefit to share nodes 12 12,2% 17,1%
Attitude and mentality of people to share things 11 11,2% 15,7%
Intellectual property and Copyrights 10 10,2% 14,3%
Nodes are too (project) specific are only useful
7 7,1% 10,0%
with companys Revit parameters
Liability & legal issues 6 6,1% 8,6%
Reluctance to provide support, extra work for
4 4,1% 5,7%
publishing
NDA agreements, company policies prohibit
3 3,1% 4,3%
sharing
The strength of open source concept and sharing
1 1,0% 1,4%
is not understood
Total 98 100,0% 140,0%
A. Appendix 113
Figure A.38: Reasons for companies not to share custom nodes with the community
A.2.21 Question 21

A. Appendix 114
Table A.6: Possible motivations for developers to share nodes with the community
Possible motivation to publish nodes for free
N Percent Cases
No opinion / I don't know / no appropriate answer 36 44,4% 52,2%
Acknowledgement / reputation / advertisment
13 16,0% 18,8%
opportunity
Economical incentives 8 9,9% 11,6%
Not possible 4 4,9% 5,8%
Not necessary / there is already enough motivation 4 4,9% 5,8%
Explain benefits and reasons to share 4 4,9% 5,8%

Give them sth. in return for doing so 3 3,7% 4,3%
Premium support by software manufacturer 2 2,5% 2,9%
Discount on licences 2 2,5% 2,9%
Patents 1 1,2% 1,4%
Hackathons 1 1,2% 1,4%
A quality improvment system to test and improve
1 1,2% 1,4%
the published nodes
More control over published work 1 1,2% 1,4%
Easier and more transparent publishing process 1 1,2% 1,4%
Total 81 100,0% 117,4%
Figure A.40: Possible motivations for developers to share nodes with the community
A. Appendix 115
A.2.22 Question 22
Figure A.42: Is a node-package store beneficial to the Dynamo community?
Survey question 23 was deleted shortly after the start of the survey due to a logical
error.
A. Appendix 116
A.2.23 Question 24

A. Appendix 117
A.2.24 Question 25
Table A.7: Software skills distribution

I don't
inter- beginner
70 know the no exp. beginner adv. expert guru
mediate to guru
software
0 0 1 5 18 26 20 70
Revit
0% 0% 1% 7% 26% 37% 29% 100%
0 2 20 18 19 8 3 68
Dynamo
0% 3% 29% 26% 27% 11% 4% 97%
2 11 22 22 9 3 1 57
SketchUp
3% 16% 31% 31% 13% 4% 1% 81%
4 23 17 15 4 5 2 43
Rhino 3D
6% 33% 24% 21% 6% 7% 3% 61%
6 30 13 9 4 6 2 34
Grasshopper
9% 43% 19% 13% 6% 9% 3% 49%
12 33 15 7 3 1 0 26
ArchiCAD
17% 47% 21% 10% 4% 1% 0% 37%
14 33 11 8 1 1 2 23
MicroStation
20% 47% 16% 11% 1% 1% 3% 33%
Generative 23 32 7 6 1 0 1 15
Components 33% 46% 10% 9% 1% 0% 1% 21%
23 36 6 5 0 0 0 11
Vectorworks
33% 51% 9% 7% 0% 0% 0% 16%
27 33 8 2 0 0 0 10
Flux.io
39% 47% 11% 3% 0% 0% 0% 14%
33 35 2 0 0 0 0 2
Marionette
47% 50% 3% 0% 0% 0% 0% 3%
A. Appendix 118
119
REFERENCES
Aish, R., Fisher, A., Joyce, S. and Marsh, A. (2012) ‘Progress towards Multi-Criteria
Design Optimisation using DesignScript with SMART Form, Robot Structural
analysis and Ecotect building performance analysis’, in. ACADIA. Available at:
http://companyshed.com/downloads/documents/2012_ACADIA.pdf (Accessed: 1
March 2015).
Akos, G. (2014) ‘Mode Lab Education | Two answers for “Why Dynamo”?’, Mode
Lab, 26 March. Available at: http://modelab.is/education/two-answers-for-why-
dynamo/ (Accessed: 16 May 2015).
Anderson, J. R. (2010) Cognitive psychology and its implications. 7th ed. New York:
Worth Publishers.
Autodesk (ed.) (2008) ‘Revit MEP 2009 User’s Guide’. Available at:
http://revit.downloads.autodesk.com/download/RME2009/Documents/ENU/HelpME
PENU.pdf (Accessed: 12 November 2015).
Babic, D. (2012) Visual programming and why it sucks, Davor Babic. Available at:
http://blog.davor.se/blog/2012/09/09/Visual-programming/ (Accessed: 2 September
2015).
Blackwell, A. and Rodden, K. (2003) ‘Preface to “Sketchpad: A man-machine

graphical communication system”’, IE Sutherland, Sketchpad: A man-machine
graphical communication system, pp. 3–5.
Boeykens, S. (2012) ‘Bridging building information modeling and parametric

design’, eWork and eBusiness in Architecture, Engineering and Construction:
ECPPM 2012, p. 453.
Boshernitsan, M. and Downes, M. S. (2004) Visual programming languages: A

survey. Citeseer. Available at:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.73.2491&rep=rep1&type=
pdf (Accessed: 15 July 2015).
Boyer, P. (no date) Dynamo on Linux, Mac, Github. Available at:

https://github.com/DynamoDS/Dynamo/wiki/Dynamo-on-Linux,-Mac (Accessed: 17
May 2015).
Braumann, J. and Brell-Cokcan, S. (2014) ‘Visual robot programming: linking

design, simulation, and fabrication’, in Proceedings of the Symposium on Simulation
for Architecture & Urban Design. Tampa, Florida: Society for Computer Simulation
International, pp. 1–8.
Brown, R. B. (2006) Doing your dissertation in business and management. 1st ed.
Thousand Oaks, CA: Sage Publications (Sage study skills).
A. Appendix 120
Celani, G. and Vaz, C. E. V. (2012) ‘CAD scripting and visual programming

languages for implementing computational design concepts: A comparison from a
pedagogical point of view’, International Journal of Architectural Computing, 10(1),
pp. 121–138.
Coenders, J. L. (2010) ‘Parametric and associative design as a strategy for conceptual

design and delivery to BIM’, in Symposium of the International Association for Shell
and Spatial Structures (50th. 2009. Valencia). Evolution and Trends in Design,
Analysis and Construction of Shell and Spatial Structures: Proceedings. Editorial
Universitat Politècnica de València. Available at:
http://riunet.upv.es/handle/10251/6981 (Accessed: 1 March 2015).
CORE studio (no date) ‘Visualizing Loads and Capacity with Dynamo’, CORE
studio Thornton Tomasetti. Available at:
http://core.thorntontomasetti.com/visualizing-loads-and-capacity-with-dynamo/
(Accessed: 17 May 2015).
Cormen, T. H. (ed.) (2009) Introduction to algorithms. 3rd ed. Cambridge, Mass:

MIT Press.
Davis, D. and Peters, B. (2013) ‘Design Ecosystems: Customising the Architectural

Design Environment with Software Plug-ins’, Architectural Design, 83(2), pp. 124–
131.
Daylight Analysis for Dynamo (no date) Dynaom Wiki. Available at:
https://github.com/DynamoDS/Dynamo/wiki/Daylight-Analysis-for-Dynamo
Deutsch, R. (2014) ‘Google’s BIM-busting App for Design and Construction’, BIM
+ Integrated Design, 24 October. Available at:
http://bimandintegrateddesign.com/2014/10/24/googles-bim-busting-app-for-design-
and-construction/ (Accessed: 15 August 2015).
Deutsch, R. (2015) Data-driven design and construction: 25 strategies for capturing,

analyzing and applying building data. Hoboken: John Wiley & Sons Inc.
Dieckmann, A. and Russell, P. (2014) ‘The Truth Is In The Model by Andreas

Dieckmann on Prezi’. eCAADe 2014, Newcastle upon Tyne. Available at:
https://prezi.com/kaagf4w6iq-d/the-truth-is-in-the-model/ (Accessed: 7 May 2015).
Dino, İ. G. (2012) ‘Creative design exploration by parametric generative systems in

architecture’, METU Journal of Faculty of Architecture, 29(1), pp. 207–224.
Ebrahim, G. . and Sullivan, K. . (1995) Mother and child health: research methods.
London: Book-Aid.
Edmondson, A. C. and McManus, S. E. (2007) ‘Methodological fit in management

field research’, Academy of management review, 32(4), pp. 1246–1264.
Fellows, R. and Liu, A. (2015) Research methods for construction. Third edition.
Chichester, West Sussex, United Kingdom ; Malden, MA, USA: John Wiley and
Sons, Inc.
A. Appendix 121
Fischer, T., De Biswas, K., Ham, J. J., Naka, R. and Huang, W. X. (2012)
‘Parametric and Generative methods with BuildinG information modellinG’.
Available at:
http://cumincad.architexturez.net/system/files/pdf/caadria2012_089.content.pdf
(Accessed: 1 March 2015).
Flick, U. (2007) Designing qualitative research. Thousand Oaks, CA: Sage

Publications (The sage qualitative reasearch kit).
Fralick, F. (no date) Design to Fabrication Workflows and Visual Programming,

BIM Forum. Available at: https://bimforum.org/presentations-computation/
Glinert and Tanimoto (1984) ‘Pict: An Interactive Graphical Programming

Environment’, Computer, 17(11), pp. 7–25. doi: 10.1109/MC.1984.1658997.
Graphisoft (2015) Rhino - ARCHICAD Connection. Available at:

http://www.graphisoft.com/downloads/addons/interoperability/rhino.html (Accessed:
16 May 2015).
Green, T. R. G. and Petre, M. (1996) ‘Usability analysis of visual programming

environments: a “cognitive dimensions” framework’, Journal of Visual Languages &
Computing, 7(2), pp. 131–174.
Guerra, E. (2014) BIM - One Version of the Truth. Dynamo: Visual Programming for
Revit/Vasari. Available at: https://www.youtube.com/watch?v=xm26L0P2MPE.
Hanna, S., Hesselgren, L., Gonzalez, V. and Vargas, I. (2010) ‘Beyond simulation:
designing for uncertainty and robust solutions’, in Proceedings of the 2010 Spring
Simulation Multiconference. Society for Computer Simulation International, p. 182.
Available at: http://dl.acm.org/citation.cfm?id=1878727 (Accessed: 18 August
2015).
Hayden, M. K. (1995) ‘An experimental investigation of visual enhancements for

programming environments’.
Herr, K. and Anderson, G. L. (2005) The action research dissertation: a guide for
students and faculty. Thousand Oaks, Calif: SAGE Publications.
Hirakawa, M. and Ichikawa, T. (1992) ‘Advances in visual programming’, in

Systems Integration, 1992. ICSI’92., Proceedings of the Second International
Conference on. IEEE, pp. 538–543. Available at:
http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=217309 (Accessed: 13 August
2015).
Hosick, E. (2014) Visual Programming Languages - Snapshots, Interface Vision.

Available at: http://blog.interfacevision.com/design/design-visual-progarmming-
languages-snapshots/ (Accessed: 25 December 2015).
Jezyk, M. (2013) Revit Dynamo Visual Programming connected to Arduino,

Youtube. Available at: https://www.youtube.com/watch?v=VidwY8Ki4ZQ
A. Appendix 122
Jezyk, M. D., Lipkin, L., Elliott, S. J. and Boyer, P. B. (2015) ‘Computational design
method and interface’. Available at:
http://www.google.com/patents/US20150095881.
Jezyk, M. and Izzi, A. (no date) What’s New for Dynamo. Available at:
http://inthefold.autodesk.com/in_the_fold/2015/05/autodesk-launches-dynamo-
studio-and-formit-360-pro-at-aia.html (Accessed: 16 May 2015).
Kensek, K. M. (2014) ‘Integration of Environmental Sensors with BIM: case studies

using Arduino, Dynamo, and the Revit API’, Informes de la Construcción, 66(536),
p. e044. doi: 10.3989/ic.13.151.
Kensek, K. M. and Noble, D. (eds) (2014) Building information modeling: BIM in

current and future practice. Hoboken, New Jersey: Wiley.
Keough, I. (2011) Kinect + Dynamo, Youtube. Available at:

https://www.youtube.com/watch?v=rA8jTNiWxPo (Accessed: 17 May 2015).
Keough, I. (2015) Dynamo Now, Dynamo Next. Available at: http://www.case-

inc.com/blog/dynamo-now-dynamo-next (Accessed: 16 May 2015).
Kirschner, M. J. (2015) Visual programming in three dimensions: visual

representations of computational mental models. Massachusetts Institute of
Technology. Available at: http://dspace.mit.edu/handle/1721.1/99246 (Accessed: 26
December 2015).
Kron, Z. (2014) Q&A about Dynamo, DynamoBIM. Available at:

http://dynamobim.com/qa-about-dynamo/ (Accessed: 22 April 2015).
Kron, Z. (2015) What is Autodesk Dynamo Studio? Available at:

http://dynamobim.com/what-is-autodesk-dynamo-studio/ (Accessed: 17 May 2015).
Kumar, V. (2013) ‘Excel Tip: Options using INQUIRE’, Vinod Kumar (Blog home),
6 November. Available at: http://blogs.extremeexperts.com/tag/excel/page/6/
(Accessed: 25 December 2015).
Leitão, A. and Santos, L. (2011) ‘Programming Languages for Generative design’, in

Respecting Fragile Places: 29th eCAADe Conference Proceedings. eCAADe,
Ljubljana, Slovenia: University of Ljubljana. Faculty of Architecture (eCAADe:
Conferences), p. 980. Available at:
http://cumincad.architexturez.net/system/files/pdf/ecaade2011_118.content.pdf
(Accessed: 14 September 2015).
Lopes, J. (2012) Modern Programming for Generative Design. Available at:

https://fenix.tecnico.ulisboa.pt/downloadFile/395144311914/dissertacao.pdf
Maxwell, J. A. (2005) Qualitative research design: an interactive approach. 2nd ed.

Thousand Oaks, CA: Sage Publications (Applied social research methods series, no.
41).
A. Appendix 123
McCrone, C. (2014) ‘Dynamobotics @ 2014 AEC Hackathon’, DynamoBIM, 29

May. Available at: http://dynamobim.com/dynarobo/ (Accessed: 17 May 2015).
Menges, A. and Ahlquist, S. (2011) Computational design thinking. Chichester:

Wiley (AD Reader).
Menzies, T. (1998) ‘Evaluation issues for visual programming languages’, Handbook

of Software Engineering and Knowledge Engineering, 2, pp. 93–101.
Mode Lab (2015a) The Dynamo Primer. Available at:

http://dynamoprimer.com/01_Introduction/1-2_what_is_dynamo.html (Accessed: 10
August 2015).
Mode Lab (2015b) The Grasshopper Primer 3.2. Available at:

http://grasshopperprimer.com.
Morin, K. (2015) ‘DynaBleau: Dynamo + Tableau’, Kylemorin, 12 March. Available

at: http://blog.kylemorin.co/2015/03/dynableau-dynamo-tableau/ (Accessed: 17 May
2015).
Murray, B. S. and McDaid, E. (1993) ‘Visualizing and representing knowledge for

the end user: a review’, International journal of man-machine studies, 38(1), pp. 23–
49.
Myers, B. A. (1990) ‘Taxonomies of visual programming and program

visualization’, Journal of Visual Languages & Computing, 1(1), pp. 97–123.
‘National Building Information Modeling Standard’ (2010).

BuildingSMARTalliance. Available at: http://www.wbdg.org/pdfs/NBIMSv1_p1.pdf
(Accessed: 15 August 2015).
Preidel, C. and Borrmann, A. (2015) ‘Automated Code Compliance Checking Based

on a Visual Language and Building Information Modeling’, in Proceedings of the
32nd ISARC 2015. 32nd ISARC 2015, Oulu, Finland. Available at:
http://www.cms.bgu.tum.de/publications/2015_Preidel_ISARC.pdf (Accessed: 19
August 2015).
Prună, M. (2015) PUPI - Parametric Universal Programming Interface, Parametric

Universal Programming InterfaceTM Visual Programming Applications Toolkit.
Available at: http://pupi.co/ (Accessed: 26 December 2015).
Rea, L. M. and Parker, R. A. (2014) Designing and conducting survey research: a

comprehensive guide. Fourth edition. San Francisco, CA: Jossey-Bass, a Wiley
brand.
Ritter, F., Preidel, C. and Singer, D. (2015) ‘Visuelle Programmiersprachen im

Bauwesen - Stand der Technik und aktuelle Entwicklungen’, in Proceedings of the
27th Forum Bauinformatik. 27th Forum Bauinformatik, Aachen, Germany. Available
at: http://www.cms.bgu.tum.de/publications/2015_Ritter_FBI.pdf (Accessed: 19
August 2015).
A. Appendix 124
Schiffer, S. (1996) ‘Visuelle Programmierung-Potential und Grenzen’, in GI

Jahrestagung, pp. 267–286. Available at: http://www.schiffer.at/publications/se-96-
19/se-96-19.htm (Accessed: 12 August 2015).
Schutt, R. K. (2006) Investigating the social world: the process and practice of
research. Thousand Oaks, Calif.; London: Pine Forge Press ; SAGE Publications.
Sgambelluri, M. (2013) ‘Learn How to Align and Measure a Scope Box in Revit
without the API’, Simply Complex, 23 August. Available at:
http://therevitcomplex.blogspot.co.uk/2013/08/learn-how-to-align-and-measure-
scope.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015a) ‘Ever wanted to extract an item from a list in DynamoBIM?

Don’t use the “GetItemAtIndex” Node Use Design Script!’, Simply Complex, 6
March. Available at: http://therevitcomplex.blogspot.co.uk/2015/03/ever-wanted-to-
extract-item-from-list.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015b) ‘Get the Area of a Ramp From Revit Using DynamoBIM’,
Simply Complex, 3 May. Available at:
http://therevitcomplex.blogspot.co.uk/2015/05/get-area-of-ramp-from-revit-
using.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015c) ‘How to create levels in Revit using DynamoBIM’, Simply

Complex, 1 April. Available at: http://therevitcomplex.blogspot.co.uk/2015/04/how-
to-create-levels-in-revit-using.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015d) ‘How to Get The Revit Version and Build Number Using
DynamoBIM.’, Simply Complex, 4 November. Available at:
http://therevitcomplex.blogspot.co.uk/2015/04/how-to-get-revit-version-and-
build.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015e) ‘How to Get the Worksharing Status of a Revit File

(Central, Local, or Not Workshared) Using DymamoBIM’, Simply Complex, 16
April. Available at: http://therevitcomplex.blogspot.co.uk/2015/04/how-to-get-
worksharing-status-of-revit.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015f) ‘Simply Complex: WHAT IS DYNAMO?’, Simply

Complex, 30 January. Available at:
http://therevitcomplex.blogspot.co.uk/2015/01/what-is-dynamo.html (Accessed: 16
May 2015).
Sgambelluri, M. (2015g) ‘Want to create a list or nested list in DynamoBIM? Use

Design Script’, Simply Complex, 11 March. Available at:
http://therevitcomplex.blogspot.co.uk/2015/03/want-to-create-list-or-nested-list-
in.html (Accessed: 17 May 2015).
Sgambelluri, M. (2015h) ‘whatisdynamo.png (PNG Image, 1600 × 1140 pixels)’,

Simply Complex, 30 January. Available at: http://4.bp.blogspot.com/-
bpJqAhYNxWs/U3Tfr1tVYJI/AAAAAAAAAe8/xiKu1AQtqss/s1600/whatisdynam
o.png (Accessed: 16 May 2015).
Shu, N. C. (1988) Visual programming. New York: Van Nostrand Reinhold.

A. Appendix 125
Smith, D. C. (1977) Pygmalion: A computer program to model and stimulate

creative thought. Birkhauser.
Sobon, K. K. (2014a) ‘create placeholder sheets using excel with dynamo v.1.5’,
Archi Lab, 13 October. Available at: http://archi-lab.net/create-placeholder-sheets-
using-excel-with-dynamo-v-1-5/ (Accessed: 17 May 2015).
Sobon, K. K. (2014b) ‘element tagging with dynamo’, Archi Lab, 18 July. Available
at: http://archi-lab.net/element-tagging-with-dynamo/ (Accessed: 17 May 2015).
Sobon, K. K. (2014c) ‘managing family types with dynamo’, Archi Lab, 30 June.
Available at: http://archi-lab.net/managing-family-types-with-dynamo/ (Accessed: 17
May 2015).
Sobon, K. K. (2014d) ‘view organization management with dynamo’, Archi Lab, 11

May. Available at: http://archi-lab.net/view-organization-management-with-dynamo/
Sutherland, I. E. (1964) ‘Sketch pad a man-machine graphical communication

system’, in Proceedings of the SHARE design automation workshop. ACM, pp.
6.329–6.346.
Sutherland, W. R. (1966) ON-LINE GRAPHICAL SPECIFICATION OF

COMPUTER PROCEDURES. DTIC Document.
Terzidis, K. (2006a) Algorithmic architecture. 1st ed. Amsterdam ; Boston:

Architectural Press.
Terzidis, K. (2006b) Algorithmic architecture. Routledge.
Thornton Tomasetti (no date) Workshops | CORE studio. Available at:

http://core.thorntontomasetti.com/workshops/ (Accessed: 16 May 2015).
Trochim, W. M. (2006a) The Research Methods Knowledge Base, 2nd Edition, The
Research Methods Knowledge Base, 2nd Edition. Available at:
http://www.socialresearchmethods.net/kb/dedind.php (Accessed: 26 May 2015).
Trochim, W. M. (2006b) The Research Methods Knowledge Base, 2nd Edition, The
Research Methods Knowledge Base, 2nd Edition. Available at:
http://www.socialresearchmethods.net/kb/philosophy.php (Accessed: 26 May 2015).
Vannini, A. (2015) ‘Acoustamo Released!’, andreaarch, 15 February. Available at:

https://andreaarch.wordpress.com/2015/02/15/acoustamo-released/ (Accessed: 17
May 2015).
Vermeulen, D. (2015) ‘Dynam(o)ite your Design for Engineers’, Revit beyond BIM,
5 April. Available at: https://revitbeyondbim.wordpress.com/2015/05/04/dynamoite-
your-design-for-engineers-part-5/ (Accessed: 17 May 2015).
Vollenweider, M. (2013) Visuelle Programmiersprachen?, TechBlog. Available at:

https://martinvollenweider.wordpress.com/2013/04/21/visuelle-
programmiersprachen/ (Accessed: 13 August 2015).
A. Appendix 126
Wülfing, A., Windisch, R. and Scherer, R. J. (2014) ‘A visual BIM query language’,
eWork and eBusiness in Architecture, Engineering and Construction: ECPPM 2014,
p. 157.
Zhang, R., Dye, R., McKaskle, G. and Cifra, C. (2001) ‘Code node for a graphical
programming system which invokes execution of textual code’. Available at:
http://www.google.com/patents/US6282699 (Accessed: 12 August 2015).
127
BIBLIOGRAPHY
Revit Dynamo Visual Programming connected to Arduino - YouTube (no date).

Available at: https://www.youtube.com/watch?v=VidwY8Ki4ZQ (Accessed: 16 May
2015).
‘547048dd0cf216f8cfa9ecdf.pdf’ (no date). Available at:

http://www.researchgate.net/profile/Rafael_Roa_Hernandez/publication/268551658_
El_diseo_paramtrico_aplicado_a_las_soluciones_y_detalles_constructivos/links/547
048dd0cf216f8cfa9ecdf.pdf (Accessed: 1 March 2015).
‘ACADIA2011_robarch.pdf’ (no date). Available at:

http://www.robotsinarchitecture.org/wp-
content/uploads/2012/04/ACADIA2011_robarch.pdf (Accessed: 13 August 2015).
‘ADSK_Education_Dynamo_case_study.pdf’ (no date). Available at: http://static-

dc.autodesk.net/content/dam/autodesk/www/industries/education/docs/ADSK_Educa
tion_Dynamo_case_study.pdf (Accessed: 13 August 2015).
Ahmad, R. (1999) ‘Visual languages: A new way of programming’, Malaysian

Journal of Computer Science, 12(1), pp. 76–81.
Aish, R. and Woodbury, R. (2005) ‘Multi-level interaction in parametric design’, in

Smart Graphics. Springer, pp. 151–162. Available at:
http://link.springer.com/10.1007/11536482_13 (Accessed: 16 September 2015).
Aksamija, A., AP BD, L., Mario Guttman, A. I. A., Rangarajan, H. P. and Meador,
T. (no date) ‘PARAMETRIC CONTROL OF BIM ELEMENTS FOR
SUSTAINABLE DESIGN IN’.
Asl, M. R., Bergin, M., Menter, A. and Yan, W. (2014) ‘BIM-based Parametric
Building Energy Performance Multi-Objective Optimization’.
Asl, M. R., Stoupine, A., Zarrinmehr, S. and Yan, W. (2015) ‘Optimo: A BIM-based
Multi-Objective Optimization Tool Utilizing Visual Programming for High
Performance Building Design’, in Proceedings of the Conference of Education and
Research in Computer Aided Architectural Design in Europe (eCAADe), pp. 673–
682. Available at:
https://www.researchgate.net/profile/Mohammad_Rahmani_Asl/publication/283351
762_Optimo_A_BIM-based_Multi-
Objective_Optimization_Tool_Utilizing_Visual_Programming_for_High_Performan
ce_Building_Design/links/5636806508aeb786b703f21d.pdf (Accessed: 26
December 2015).
Attia, S., Hamdy, M., O’Brien, W. and Carlucci, S. (2013) ‘Assessing gaps and
needs for integrating building performance optimization tools in net zero energy
buildings design’, Energy and Buildings, 60, pp. 110–124. doi:
10.1016/j.enbuild.2013.01.016.
A. Appendix 128
Autodesk University (2009) Robert Aish: Design Computation. Available at:

https://www.youtube.com/watch?v=_mPag-y_SG0 (Accessed: 6 September 2015).
Averbukh, V. and Bakhterev, M. (2013) ‘The analysis of visual parallel

programming languages’, Advances in Computer Science: an International Journal,
2(3), pp. 126–131.
Azhar, S., Khalfan, M. and Maqsood, T. (2012) ‘Building information modelling

(BIM): now and beyond’, Australasian Journal of Construction Economics and
Building, 12(4), pp. 15–28.
Bentrad, S., Meslati, D. and others (2011) ‘Visual Programming and Program
Visualization–Towards an Ideal Visual Software Engineering System’, IJIT-ACEEE
International Journal on Information Technology, 1(3), pp. 56–62.
‘BIMcraft -5D-BIM für das Handwerk’ (no date). Available at:

http://www.aufitgebaut.de/fileadmin/media/Projektwebsites/Auf-IT-
gebaut_ALT/2._Preis_BauBW_Braun.pdf (Accessed: 19 August 2015).
Blackwell, A. F., Whitley, K. N., Good, J. and Petre, M. (2001) ‘Cognitive factors in
programming with diagrams’, Artificial Intelligence Review, 15(1-2), pp. 95–114.
Blackwell, A. and Rodden, K. (2003) ‘Preface to “Sketchpad: A man-machine

graphical communication system”’, IE Sutherland, Sketchpad: A man-machine
graphical communication system, pp. 3–5.
Blockly | Google Developers (no date). Available at:

https://developers.google.com/blockly/ (Accessed: 13 August 2015).
Boeykens, S. and NEuCKERmANS, Her. (2009) ‘Visual Programming in

Architecture: Should Architects Be Trained As Programmers?’, Proceedings of
CAAD-Futures 2009 CD-Rom. Available at:
http://cumincad.architexturez.net/system/files/pdf/cf2009_poster_41.content.pdf
Bradner, E., Iorio, F. and Davis, M. (2014) ‘Parameters tell the design story: ideation
and abstraction in design optimization’, in Proceedings of the Symposium on
Simulation for Architecture & Urban Design. Society for Computer Simulation
International, p. 26. Available at: http://dl.acm.org/citation.cfm?id=2664349
Breslav, S., Goldstein, R., Doherty, B., Rumery, D. and Khan, A. (2013) ‘Simulating
the sensing of building occupancy’, in Proceedings of the Symposium on Simulation
for Architecture & Urban Design. Society for Computer Simulation International, p.
15. Available at: http://dl.acm.org/citation.cfm?id=2500019 (Accessed: 1 March
2015).
Breslav, S., Goldstein, R., Tessier, A. and Khan, A. (2014) ‘Towards visualization of
simulated occupants and their interactions with buildings at multiple time scales’, in
Proceedings of the Symposium on Simulation for Architecture & Urban Design.
Society for Computer Simulation International, p. 5. Available at:
http://dl.acm.org/citation.cfm?id=2664328 (Accessed: 1 March 2015).
A. Appendix 129
Büdding, H. (2007) ‘Einführung in visuelle Programmiersprachen und Mobile

Endgeräte.’, in INFOS, pp. 327–328. Available at:
http://cs.emis.de/LNI/Proceedings/Proceedings112/gi-proc-112-032.pdf (Accessed:
12 August 2015).
Burger, S. M. (no date) ‘Natural and Intuitive’, words & images. Available at:
http://shaneburger.com/2011/08/designing-design/ (Accessed: 25 September 2015).
Burnett, M. M. (1999) ‘Visual Programming’. Available at:

ftp://ftp.cs.orst.edu/pub/burnett/whatIsVP.pdf (Accessed: 12 August 2015).
Burnett, M. M. and Baker, M. J. (1994) ‘A classification system for visual

programming languages’, Journal of Visual Languages & Computing, 5(3), pp. 287–
300.
Catarci, T. and Santucci, G. (1995) ‘Are visual query languages easier to use than
traditional ones? An experimental proof’, in BCS HCI, pp. 323–338. Available at:
https://books.google.com/books?hl=en&lr=&id=OlZONLkAtVMC&oi=fnd&pg=PA
323&dq=%22the+effectiveness+of+various+query+styles+and+interfaces+have+bee
n+conducted+in%22+%22developing+a+task+for+users+to%22+%22in+the+query
+system+under+study.+In+query+writing,+the+question+is:+%E2%80%9CGiven+a
%22+&ots=cK6M3w97rI&sig=RJb85zCX0beFKtpMFteoXMqXoow (Accessed: 19
August 2015).
CELANI, M. G. C. (2009) ‘Teaching CAD programming to architecture students’,

Gestão & Tecnologia de Projetos, 3(2), pp. 1–23.
Chang, S.-K. (1987) ‘Visual languages: A tutorial and survey’, in Visualization in

Programming. Springer, pp. 1–23. Available at:
http://link.springer.com/content/pdf/10.1007/3-540-18507-0_1.pdf (Accessed: 26
December 2015).
Chang, S.-K. K., Glinert, E., Bonar, J. G., Graf, M. and Berztiss, A. T. (1990)
Principles of visual programming systems. Prentice Hall Professional Technical
Reference.
Chronis, A., Tsigkari, M., Giouvanos, E., Aish, F. and Zaki, A. A. (2012)
‘Performance driven design and simulation interfaces: a multi-objective parametric
optimization process’, in Proceedings of the 2012 Symposium on Simulation for
Architecture and Urban Design. Society for Computer Simulation International, p.
14.
Cormen, T. H. (ed.) (2009) Introduction to algorithms. 3rd ed. Cambridge, Mass:

MIT Press.
Daum, S. and Borrmann, A. (2013) ‘Checking spatio-semantic consistency of

building information models by means of a query language’, in Proc. of the Intl
Conference on Construction Applications of Virtual Reality.
Daum, S. and Borrmann, A. (no date) ‘Simplifying the Analysis of Building

Information Models Using’. Available at:
http://www.cms.bgu.tum.de/publications/2015_Daum_EGICE.pdf (Accessed: 19
A. Appendix 130
August 2015).
Davis, D. (no date) PhD Thesis –Modelled on Software Engineering: Flexible

Parametric Models in the Practice of Architecture. Available at:
http://www.danieldavis.com/thesis/ (Accessed: 2 May 2015).
DynamoDS/Dynamo (2015) GitHub. Available at:

https://github.com/DynamoDS/Dynamo (Accessed: 22 April 2015).
‘dynamo presentaion en.pdf’ (no date). Available at:

http://www.nti.dk/media/1693990/dynamo%20presentaion%20en.pdf (Accessed: 13
August 2015).
Dynamo: The Secret to Working Smarter and Making Your Life Easier | ArchDaily
(no date). Available at: http://www.archdaily.com/773079/dynamo-the-secret-to-
working-smarter-and-making-your-life-easier (Accessed: 4 September 2015).
EMADALQATTAN Parametric Modeling: Yas Viceroy (BIM): Detailing (no date).

Available at: http://eqpmd.blogspot.co.uk/2015/04/yas-viceroy-bim-detailing.html
Emanuele Naboni, A. M., Korolija, I. and Zhang, Y. (no date) ‘COMPARISON OF

CONVENTIONAL, PARAMETRIC AND EVOLUTIONARY OPTIMIZATION
APPROACHES FOR THE ARCHITECTURAL DESIGN OF NEARLY ZERO
ENERGY BUILDINGS’. Available at:
http://www.e3lab.org/upl/website/publication11111/IBPSA13.pdf (Accessed: 1
March 2015).
European Conference on Product and Process Modelling, Mahdavi, A., Martens, B.

and Scherer, R. J. (2015) Ework and ebusiness in architecture, engineering and
construction: proceedings of the 10th European Conference on Product and Process
Modelling (ECPPM 2014), Vienna Austria, 17-19 September 2014. Available at:
http://dx.doi.org/10.1201/b17396 (Accessed: 1 March 2015).
ExcelPrecedents-5.png (PNG Image, 1767 × 1080 pixels) (no date). Available at:
http://i0.wp.com/www.extremeexperts.com/blogimages/ExcelPrecedents-5.png
(Accessed: 25 December 2015).
Fun with Dynamo for BPA - Automatic shading design - Building Performance
Analysis (no date). Available at: http://autodesk.typepad.com/bpa/2013/08/more-fun-
with-dynamo-for-bpa-automatic-shading-design.html (Accessed: 16 May 2015).
Gertz, M. W. and Khosla, P. (1994) ‘Visual Programming and Program Visualization

Techniques for Port-Based Objects’. Available at: http://repository.cmu.edu/isr/586/
(Accessed: 5 September 2015).
Goldstein, R., Breslav, S. and Khan, A. (no date) ‘Towards Voxel-Based Algorithms
for Building Performance Simulation’. Available at:
http://www.autodeskresearch.com/pdf/Goldstein__Towards_Voxel_Building_Simula
tion__2014-02-28_1020.pdf (Accessed: 1 March 2015).
‘Graphical programming system and method for enabling a person to learn text-
A. Appendix 131
based programming’ (no date). Available at:

http://www.google.com/patents/US5760788 (Accessed: 12 August 2015).
Green, T. (no date) ‘Visual Programming’. Available at:

http://homepages.mcs.vuw.ac.nz/~db/references/visual-programming.pdf (Accessed:
5 September 2015).
Gürsel, I. (2010) CLIP: computational support for lifecycle integral building

performance assessment. [S.l.]: [s.n.].
Hall, T. W., Jabi, W., Passerini, K., Borcea, C. and Jones, Q. (2008) ‘An Interactive
Poster System to Solicit Casual Design Feedback’, in Proceedings of the 28 th
Conference ACADIA, pp. 438–447. Available at:
http://wjabi.net/portfolio/Papers/2008acadia.pdf (Accessed: 1 March 2015).
Hanna, S. (2011) ‘The inverted genotype and its implications for the flexibility of
architectural models’, The Journal of Space Syntax, 2(2), pp. 247–272.
Holzer, D. (2011) ‘BIM’s seven deadly sins’, International Journal of Architectural

Computing, 9(4), pp. 463–480.
Hubers, H. J., Turrin, M., Erbas, I. and Chatzikonstantinou, I. (2014) ‘pCOLAD:

online sharing of parameters for collaborative architectural design’, in Proceedings
of the 32nd eCAADe Conference, Newcastle upon Tyne (England), 10-12 Sept. 2014.
eCAADe. Available at: http://repository.tudelft.nl/view/ir/uuid:4ec3dd17-232d-
414d-a065-d15461719acc/ (Accessed: 1 March 2015).
Hubers, J. C. (2010) ‘Collaborative parametric BIM’, in proceedings of the 5th

ASCAAD conference 2010. Available at:
http://cumincad.architexturez.net/system/files/pdf/ascaad2010_127.content.pdf
Hu, C.-H. and Wang, F.-J. (1998) ‘Constructing an integrated visual programming
environment’, SOFTWARE-PRACTICE & EXPERIENCE, 28(7), pp. 773–798.
‘IntelliMCI7.pdf’ (no date). Available at: https://ki.informatik.uni-

wuerzburg.de/teach/ss-2003/ichi/IntelliMCI7.pdf (Accessed: 12 August 2015).
Jabi, W. (2014) ‘Parametric spatial models for energy analysis in the early design
stages’, in Proceedings of the Symposium on Simulation for Architecture & Urban
Design. Society for Computer Simulation International, p. 16. Available at:
Jacobson, I., Griss, M. and Jonsson, P. (1997) Software reuse: architecture process
and organization for business success. New York, NY : Harlow, England ; Reading,
MA: ACM Press ; Addison Wesley Longman.
Johnsson, M. and Örmo, A. (2002) ‘Visual Programming’.
Johnston, W. M., Hanna, J. R. and Millar, R. J. (2004) ‘Advances in dataflow

programming languages’, ACM Computing Surveys (CSUR), 36(1), pp. 1–34.
A. Appendix 132
Journal of Visual Languages and Computing - Elsevier (no date). Available at:
http://www.journals.elsevier.com/journal-of-visual-languages-and-computing
Keltsch, C. (2014) Ein visuelles Programmiersystem zur Modellierung deskriptiver

Untersuchungen in der Datenanalyse. diplom.de.
Kensek, K. (2015) ‘BIM Guidelines Inform Facilities Management Databases: A

Case Study over Time’, Buildings, 5(3), pp. 899–916. doi:
10.3390/buildings5030899.
Kensek, K. M. (2014) ‘Integration of Environmental Sensors with BIM: case studies

using Arduino, Dynamo, and the Revit API’, Informes de la Construcción, 66(536),
p. e044. doi: 10.3989/ic.13.151.
Kensek, K. M. (no date) ‘PRACTICAL BIM 2012: Management, Implementation

Coordination and Evaluation’. Available at:
http://www.researchgate.net/profile/Simone_Garagnani/publication/236866132_BIM
_TOOLS_AND_DESIGN_INTENT_Limitations_and_Opportunities/links/00463519
b53bb7897e000000.pdf (Accessed: 1 March 2015).
Kicinger, R., Arciszewski, T. and De Jong, K. (2005) ‘Evolutionary computation and

structural design: A survey of the state-of-the-art’, Computers & Structures, 83(23),
pp. 1943–1978.
Kiper, J. D., Howard, E. and Ames, C. (1997) ‘Criteria for evaluation of visual
programming languages’, Journal of Visual Languages & Computing, 8(2), pp. 175–
192.
KNIME | Open for Innovation (no date). Available at: http://www.knime.org/

Kolarevic, B. and Malkawi, A. (eds) (2005) Performative architecture: beyond

instrumentality. New York: Spon Press.
Kontos, G. (2008) ‘Cognitive dimensions usability assessment of textual and visual

VHDL environments’. Available at: https://ritdml.rit.edu/handle/1850/5490
Langenhan, C., Ha\s s, S., Weber, M., Petzold, F., Liwicki, M. and Dengel, A. (2011)
‘Investigating research strategies for accessing knowledge stored in semantic
models’, eCAADe, Ljubljana. Available at:
http://cumincad.architexturez.net/system/files/pdf/ecaade2011_014.content.pdf
Larsen, N. M. (2012) Generative algorithmic techniques for architectural design.

Institut 1/Institut for ArkitekturDepartment 1/Department of Architecture. Available
at: http://forskningsbasen.deff.dk/Share.external?sp=Sc5c42051-49f6-4a59-b11d-
bf2a9a559396&sp=Sark (Accessed: 9 September 2015).
Lee, P. A. and Webber, J. (2003) ‘Taxonomy for Visual Parallel Programming

Language’, TECHNICAL REPORT SERIES-UNIVERSITY OF NEWCASTLE UPON
A. Appendix 133
TYNE COMPUTING SCIENCE. Available at:

http://www.cs.newcastle.ac.uk/publications/trs/papers/793.pdf (Accessed: 5
September 2015).
Leitão, A., Cabecinhas, F. and Martins, S. (2010) ‘Revisiting the Architecture

Curriculum’, in ECAADe 2010 Conference: Future Cities: Proceedings of the 28th
Conference on Education in Computer Aided Architectural Design in Europe, Verlag
der Fachvereine Hochschulverlag AG an der ETH Zurich, Zurich, Switzerland, pp.
81–88. Available at:
http://books.google.com/books?hl=en&lr=&id=KTKFJK6DrEoC&oi=fnd&pg=PA8
1&dq=%22drawing/designing+tools+very%22+%22that+Architecture+practice+evo
lved+to+use%22+%222002).+Other+important+features+are%22+%22took+courses
+in+programming+think+that+it+is%22+%22creating+an+impedance+mismatch%2
2+&ots=YuoHGPC-tr&sig=wkWC7pChHSLMmEF4PTDav8xnW-g (Accessed: 2
May 2015).
Liao, A. (no date) The 21st-Century Skill Set for Architects, Architect. Available at:
http://www.architectmagazine.com/practice/the-21st-century-skill-set-for-
architects_o (Accessed: 6 September 2015).
Maing, M. and Vargas, R. (no date) ‘Digital Fabrication Processes of Mass

Customized Building Facades in Global’, in. Available at:
http://cumincad.architexturez.net/system/files/pdf/sigradi2013_364.content.pdf
Maloney, J., Resnick, M., Rusk, N., Silverman, B. and Eastmond, E. (2010) ‘The
Scratch Programming Language and Environment’, ACM Transactions on
Computing Education, 10(4), pp. 1–15. doi: 10.1145/1868358.1868363.
Management and Innovation for a Sustainable Built Environment (2011)

Management and innovation for a sustainable built environment CIB International
Conference of WO55, WO65, WO89, W112, TG76, TG78, TG81. Delft: University of
Technology. Available at: http://www.misbe2011.nl/proceedings.htm (Accessed: 1
March 2015).
Marriott, K. and Meyer, B. (2012) Visual language theory. Springer Science &
Business Media. Available at:
https://books.google.de/books?id=FsXcBwAAQBAJ&pg=PP7&dq=Visual+Languag
e+Theory++von+Kim+Marriott,Bernd+Meyer&hl=de&sa=X&ved=0CCEQ6AEwA
GoVChMIi5as5YzexgIVcCPbCh1iUAVy#v=onepage&q=Visual%20Language%20
Theory%20%20von%20Kim%20Marriott%2CBernd%20Meyer&f=false.
Menzies, T. (1996) ‘Visual Programming, Knowledge Engineering, and Software

Engineering.’, in SEKE. Citeseer, pp. 506–513.
Merkel, P. (no date) ‘Visual Programming im Ueberblick’.
Mirtschin, J. (2011) ‘Engaging generative BIM workflows’, Geometry Gym website.

Available at:
http://rhino4you.com/1/upload/engaging_generative_bim_workflows_submit.pdf
A. Appendix 134
Möbius, F. (1996) Visuelle Programmierung von Industrierobotern: ein Beitrag zur

bedienergerechten Gestaltung von Programmiersystemen. VDI-Verlag.
Nathan Miller (2015) ‘Should Architects Learn to Code?’, PROVING GROUND, 3

September. Available at: http://provingground.io/2015/09/03/should-architects-learn-
to-code/ (Accessed: 5 September 2015).
Navarro-Prieto, R. and CañAs, J. J. (2001a) ‘Are visual programming languages

better? The role of imagery in program comprehension’, International Journal of
Human-Computer Studies, 54(6), pp. 799–829. doi: 10.1006/ijhc.2000.0465.
Navarro-Prieto, R. and CañAs, J. J. (2001b) ‘Are visual programming languages

better? The role of imagery in program comprehension’, International Journal of
Human-Computer Studies, 54(6), pp. 799–829. doi: 10.1006/ijhc.2000.0465.
Nickerson, J. V. (1994) Visual programming. New York University.
Nickerson, J. V. (1994) ‘Visual programming: Limits of graphic representation’, in

Visual Languages, 1994. Proceedings., IEEE Symposium on. IEEE, pp. 178–179.
Available at: http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=363624
Ning, G. (2012) Computational Design Methods and Technologies: Applications in

CAD, CAM and CAE Education: Applications in CAD, CAM and CAE Education.
IGI Global.
Ogueta, C. S. (2012) ‘User Innovation in Digital Design and Construction:

Dialectical Relations between Standard BIM Tools and Specific User Requirements’.
Available at: http://hdl.handle.net/1721.1/72975.
Ogueta, C. S. (2013) ‘Innovación por el Usuario en la Construcción y el Diseño

Digital: La Relación Entre Herramientas BIM Standard y Requerimientos
Específicos de los Usuarios’, in. Editora Edgard Blücher, pp. 274–278. doi:
10.5151/despro-sigradi2013-0051.
Ormerod, T. (1990) ‘Human cognition and programming’, Hoc et al, 307, pp. 63–82.
Pane, J. F., Ratanamahatana, C. ‘Ann’ and Myers, B. A. (2001) ‘Studying the

language and structure in non-programmers’ solutions to programming problems’,
International Journal of Human-Computer Studies, 54(2), pp. 237–264. doi:
10.1006/ijhc.2000.0410.
Parametric design procedure: an approach to ‘Generative-form’ and exploring the

design instances in architecture (no date). Available at:
http://s3.amazonaws.com/academia.edu.documents/12631236/Hardi_Barznji-
libre.pdf?AWSAccessKeyId=AKIAJ56TQJRTWSMTNPEA&Expires=1425224725
&Signature=tmHTMlwFBoOsdbgQWp871948H8w%3D (Accessed: 1 March 2015).
Petre, M. (1995) ‘Why looking isn’t always seeing: readership skills and graphical
programming’, Communications of the ACM, 38(6), pp. 33–44.
Petre, M. and Blackwell, A. F. (1999) ‘Mental imagery in program design and visual
A. Appendix 135
programming’, International Journal of Human-Computer Studies, 51(1), pp. 7–30.
Plank, M. (2008) Visuelle komponentenbasierte Spieleentwicklung. Fachhochschule

Hagenberg. Available at: http://theses.fh-hagenberg.at/system/files/pdf/Plank08.pdf
PlayMaker - Visual Scripting for Unity3D (no date). Available at:

http://www.hutonggames.com/ (Accessed: 2 September 2015).
Preidel, C. (2014) Code Compliance Checking - Entwicklung einer Methode zur

automatisierten Konformitätsüberprüfung au f Basis einer graphischen Sprache und
Building Information Modeling. Technische Universität München. Available at:
http://www.cms.bgu.tum.de/publications/theses/Preidel_2014_Daum.pdf (Accessed:
13 August 2015).
Price, B. A., Baecker, R. M. and Small, I. S. (1993) ‘A principled taxonomy of

software visualization’, Journal of Visual Languages & Computing, 4(3), pp. 211–
266.
Primary Benefits of BIM - Shoegnome (no date). Available at:

http://www.shoegnome.com/2013/02/05/primary-benefits-of-bim/ (Accessed: 1
March 2015).
Raeder (1985) ‘A Survey of Current Graphical Programming Techniques’,

Computer, 18(8), pp. 11–25. doi: 10.1109/MC.1985.1662971.
Ritter, F., Schubert, G., Geyer, P., Borrmann, A. and Petzold, F. (no date) ‘Design
Decision Support–Real-time Energy Simulation in the Early Design Stages’, in
Computing in Civil and Building Engineering (2014). ASCE, pp. 2023–2031.
Available at: http://ascelibrary.org/doi/abs/10.1061/9780784413616.251 (Accessed:
19 August 2015).
Saleh, M. M. I. M. (no date) Using the Tools of Parametric Urbanism. Faculty of

Engineering, Alexandria University. Available at:
http://www.academia.edu/download/31100099/Master_Thesis_-
_Mohamed_M._Saleh.pdf (Accessed: 1 March 2015).
Sambs, J. (2008) Visuelle Programmierung. na. Available at: http://theses.fh-

hagenberg.at/system/files/pdf/Sambs08.pdf (Accessed: 12 August 2015).
Schiffer, S. (1998) Visuelle Programmierung: Grundlagen und

Einsatzmöglichkeiten. Addison-Wesley München.
Schmidt, C. (2006) Generierung von Struktureditoren für anspruchsvolle visuelle

Sprachen.
Senske, N. (2014) ‘Building a Computational Culture: a pedagogical study of a

computer programming requirement’, in ARCC Conference Repository. Available at:
http://www.arcc-journal.org/index.php/repository/article/view/188 (Accessed: 2 May
2015).
Seward, D. and Zied, K. (2004) ‘Graphical Programming and the Development of

A. Appendix 136
Construction Robots’, Computer-Aided Civil and Infrastructure Engineering, 19(1),

pp. 64–80. doi: 10.1111/j.1467-8667.2004.00338.x.
Shajahan, A. (no date) ‘Building Information Modeling (BIM): Parametric BIM

through Visual Programming’. Available at:
http://amreenshajahan.blogspot.de/2015/04/normal-0-false-false-false-en-us-ja-
x.html (Accessed: 13 August 2015).
Shu, N. C. (1986) ‘Visual programming languages: A perspective and a dimensional

analysis’, in Visual Languages. Springer, pp. 11–34. doi: 10.1007/978-1-4613-1805-
7_2 ·.
Shu, N. C. (1989) ‘Visual programming: perspectives and approaches’, IBM Systems

Journal, 28(4), p. 525.
Singer, D. (no date) ‘Entwicklung eines Prototyps für den Einsatz von Knowledge-
based Engineering in frühen Phasen des Brückenentwurfs’. Available at:
http://www.cms.bgu.tum.de/publications/theses/singer_2014_amann.pdf (Accessed:
19 August 2015).
slate material editor - Design Corps Design Corps (no date). Available at:
http://www.design-corps.co.uk/tag/slate-material-editor/ (Accessed: 6 September
2015).
Srinivasan, R., Kibert, C., Thakur, S., Ahmed, I., Fishwick, P., Ezzell, Z. and
Lakshmanan, J. (2012) ‘Preliminary research in dynamic-BIM (D-BIM) workbench
development’, in Proceedings of the Winter Simulation Conference. Winter
Simulation Conference, p. 53. Available at:
Staepels, L., Verbeeck, G., Roels, S., Van Gelder, L. and Bauwens, G. (2013)
‘Evaluation of indoor climate in low energy houses’, in Proceedings of the
Symposium on Simulation for Architecture & Urban Design. Society for Computer
Simulation International, p. 8. Available at:
Stavric, M. and Marina, O. (2011) ‘Parametric modeling for advanced architecture’,

International journal of applied mathematics and informatics, 5(1), pp. 9–16.
Sternberg, R. J., Sternberg, K. and Mio, J. S. (2012) Cognitive psychology. 6th ed.
Belmont, CA: Wadsworth/Cengage Learning.
Systematic Software Reuse: Architecture, Process and Organization are Crucial (no
date). Available at: http://martin.griss.com/pubs/fusion1.htm (Accessed: 12 August
2015).
Thomas, M., Fachtagung Informatik und Schule and Gesellschaft für Informatik
(eds) (2011) Informatik in Bildung und Beruf: 14. GI-Fachtagung ‘Informatik und
Schule - INFOS 2011’, 12. - 15. September 2011 an der Westfälischen Wilhelms-
Universität Münster. Bonn: Ges. für Informatik (GI-edition Proceedings, 189).
Thornton Tomasetti (2015) Introducing In-House BIM Workflow Apps | CORE

A. Appendix 137
studio. Available at: http://core.thorntontomasetti.com/introducing-in-house-bim-

workflow-apps/ (Accessed: 16 May 2015).
Tjan, B. S., Breslow, L., Dogru, S., Rajan, V., Rieck, K., Slagle, J. R. and Poliac, M.
O. (1993) ‘A data-flow graphical user interface for querying a scientific database’,
in. IEEE Comput. Soc. Press, pp. 49–54. doi: 10.1109/VL.1993.269578.
Visual Programming Languages research papers (no date). Available at:

http://www-ist.massey.ac.nz/plyons/776/VPL%20papers.html (Accessed: 13 August
2015).
Visual Programming Languages - Snapshots (no date). Available at:

http://blog.interfacevision.com/design/design-visual-progarmming-languages-
snapshots/ (Accessed: 13 August 2015).
Visual Programming with Dynamo (no date) prezi.com. Available at:

https://prezi.com/tdvep_ewvwid/visual-programming-with-dynamo/ (Accessed: 13
August 2015).
‘Visuelle Programmierung’ (2015) Wikipedia. Available at:

https://de.wikipedia.org/w/index.php?title=Visuelle_Programmierung&oldid=14055
9620 (Accessed: 15 July 2015).
Webster, J. G. (2009) Wiley encyclopedia of electrical and electronics engineering.

[New York]: Wiley-Interscience.
Whitley, K. N. (1997) ‘Visual programming languages and the empirical evidence

for and against’, Journal of Visual Languages & Computing, 8(1), pp. 109–142.
Whitley, K. N. and Blackwell, A. F. (1997a) ‘Visual programming: the outlook from

academia and industry’, in Papers presented at the seventh workshop on Empirical
studies of programmers. ACM, pp. 180–208.
Whitley, K. N. and Blackwell, A. F. (1997b) ‘Visual programming: the outlook from

academia and industry’, in Papers presented at the seventh workshop on Empirical
studies of programmers. ACM, pp. 180–208.
Wurzer, G., Alaçam, S. and Lorenz, W. (2011) ‘How to Teach Architects

(Computer) Programming’, Proceedings of the 29th eCAADe, pp. 51–56.
Yalınay-Çinici, Ş., Özsel-Akipek, F. and Yazar, T. (no date) ‘Computational Design,

Parametric Modelling and Architectural Education’. Available at:
http://www.designcoding.net/decoder/wp-content/uploads/2013/03/2013_03_01-
arkit.pdf (Accessed: 1 March 2015).
Zander, J. and Mosterman, P. J. (eds) (2014) Computation for humanity: information

technology to advance society. Boca Raton: CRC Press, Taylor & Francis Group
(Computational analysis, synthesis, and design of dynamic systems).
Zhang, K. (2012) Software Visualization: From Theory to Practice. Springer Science

& Business Media.
A. Appendix 138
Zhang, K. and Zhang, K.-B. (2003) ‘Graph grammars for visual programming’, in
Software Visualization. Springer, pp. 3–27.

Current Application of Graphical Program

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Current Application of Graphical Program

Uploaded by

Copyright:

Available Formats

Current application of graphical programming

in the design phase of a BIM project:

MSc Building Design Management and BIM

FACULTY OF ENGINEERING & ENVIRONMENT

Current application of graphical programming

A DISSERTATION SUBMITTED IN PARTIAL

MSc Building Design Management and BIM

Thomas Michael Vogt

1. That the material contained in my dissertation/thesis is the end result of my

2. The word count of my dissertation/thesis is 19090 words.

3. That unless my dissertation/thesis has been confirmed as confidential, I agree

4. I agree to my dissertation/thesis being submitted to a plagiarism detection

5. I have read the Northumbria University policy statements on Ethics in

6. I agree to the module tutor and/or programme leader nominating my

I am very thankful to my supervisor, Dr Claudio BENGHI, whose advice,

List of Illustrations ...................................................................................... vi

List of Tables ................................................................................................ x

List of Abbreviations ................................................................................. xii

Abstract ..................................................................................................... xiii

2 Fundamentals of graphical programming .................................... 9

3 Graphical programming with Dynamo ........................................ 27

4 Research method .......................................................................... 44

5 Survey Results and Data Analysis .............................................. 47

A.2.15 Question 15 ........................................................................................... 107

Bibliography ............................................................................................. 127

Figure 2.1: Design optimisation (Aish et al., 2012, p. 4) .......................................... 11

Figure A.43: Survey question 24 ............................................................................. 116

Table 3.1: Selection of existing software connections to Dynamo .......................... 37

AEC Architectural, Engineering and Construction

Keywords: Building Information Modelling (BIM); BIM Management; BIM

1.2 Rationale of the study

During a conversation with BIM Consultants a question has arisen, if visual

1.3 Research aim and questions

Aim of the study

 How effective is the usage of graphical programming in a BIM project to

 To what extent is graphical programming effective at helping to improve the

 Can a BIM workflow improved with graphical programming?

 What are the barriers to use graphical programming (Dynamo)?

 What types of employees are using graphical programming (Dynamo) already

 What are common day-to-day tasks for graphical programming (Dynamo)?

 Which types of projects are suitable for graphical programming (Dynamo)

 How can the economic value of graphical programming (Dynamo) be

 What implications/effects have the use of graphical programming (Dynamo)

1.4 Research objectives

 Investigate literature and documentation about the computational

 Test the hypotheses ‘The application of Dynamo improves specific BIM

 Retesting selected application areas mentioned by the participants (AEC

 Investigate the cause and effect of using graphical programming in a BIM

1.5 Scope of research

In the third stage a structured questionnaire with qualitative and quantitative

1.6 Research method

It “refers to an orientation toward gaining understanding through interpretation. The

 Limitation is maybe the unwillingness of the participants to share their

 The reliability of the study is potentially limited by a relatively low sample

 The functions of Dynamo and the possible combinations of functions cannot

1.8 Dissertation structure

2 FUNDAMENTALS OF GRAPHICAL PROGRAMMING

2.1 The current BIM design data authoring process

and Brell-Cokcan, 2014, p. 101). The software is capable of “calculating a building’s

It is important to understand “the distinction between computation and

“The rising problem of increased complexity, […] amount of information in building

optimized design solutions or to validate current design conditions in accordance to

The goal should be to combine “generative mechanisms and analytical/evaluative

Figure 2.1: Design optimisation (Aish et al., 2012, p. 4)