This topic will be tackled in four parts, check out my post from July 31st for the initial discussion about Dynamo and come back next week for the angle on custom plug-ins.
Whenever I see an asterisk, I immediately look for the catch. Well here it is:
*Some coding required
The Dynamo community is indeed excellent. Thankfully there are a lot of people who are solving common problems by creating new nodes and releasing packages for all to use. However, it is possible that the problem you are trying to solve may not have been solved before or it may not have been solved exactly the way you needed it to be. This is especially true for items related to firm standards that may be unique to your office. Dynamo does allow you to code your nodes to increase customization, but now we’re back to ‘some coding required’. From personal experience, I found that after getting into Dynamo, I quickly wanted to do more and needed to apply my coding skills to tackle all the problems I wanted to. I’ll touch more on this when I discuss custom plug-ins next week.
For the past one and a half years, myself and two co-workers have worked to develop Dynamo standards, build up a script library, introduce scripts to the firm, and help people save time with Dynamo. We are a mid-sized firm with about 130 people using Revit across many different market sectors and four different offices. For our initial launch, the team and I were targeting scripts that would work for everyone. We wrote clean scripts that were clearly labeled but did not have any additional user interfaces or feedback incorporated into the scripts. About a year ago, we held one of our monthly Revit Forums, and we introduced the key scripts to everyone. It was one of our most attended meetings. People were so excited to start using Dynamo, and we were excited that everyone was ready to dive in. We were geared up to answer questions, help work through any problems that we were sure would arise, and keep everyone excited about Dynamo. The next day, I heard nothing. The next week, I heard nothing. The next month, crickets. People were not using the scripts.
One mistake we made was that we did not have a user interface in place. We made the scripts very clear and easy to understand. We highlighted all the inputs in blue and gave people clear directions on what they had to change. But, users had to open Dynamo when inputs were involved. They had to look at the scary graph, and it was too much. To have a successful user base, you need to provide a clean user interface.
Another thing wasn't quite right. We did a poor job of timing the release. Not everyone had a project in a production stage in which the tools would be useful. When that time rolled around, they had forgotten. The only reference we had back to the education session was a video of the session itself. There were no handouts, no quick tips, no reminders. We did not provide enough education. Providing written information with visual aids about what each script does and how to use it will help adoption. People will have something to refer to next time they want to try it. People are more willing to try new things if there is support for them.
I think it is a challenge for mid-sized firms to implement Dynamo. At the firm I am at, we have agreed to not have an individual as a BIM Manager or Computational BIM Specialist. We do not have one individual who spends their entire time creating, updating, and managing a script library. From conversations with people at other firms, this is almost necessary to have success with Dynamo scripts in a firm larger than a couple of dozen people. It takes a significant amount of time to maintain existing scripts and even more time to create new ones and grow the library. In my opinion, implementing a Dynamo library at a firm for regular use is best suited for a firm that can dedicate full-time resources to the process or a firm that is small enough that they don’t have to dedicate full-time resources to the process. But don’t despair if your firm is not interested in dedicating full-time resources to Dynamo development and maintenance. Next week we’ll jump into custom plug-ins which provides an alternative with no packages to manage.