We are a small firm. This concept may not apply to large firms that have learned how to enforce strict policy. I would also not be surprised to hear that this has been said before, in one form or another, but here goes.
I’ve been writing and implementing dynamo scripts in our office for the past two years. It seems to be that in my experience, there are at least three classes of dynamo script: Class A, Class B, and Class C. And I don’t really know which class of script I am writing until the project is done.
Class A scripts are for all users. The script can run in dynamo player and saves the user time. There is no requirement that says everyone has to use this script. If a user wants to save time and effort it is entirely up to them.
Class B scripts I build to better myself. They are often very complicated, may require tweeking between Revit versions, and may or may not run in dynamo player. Users typically come to me when they want me to run this script on their project. Class B scripts can extend a users skill set beyond that of the common draftsman, but I wouldn’t ask anyone else on staff to run them.
Class C scripts usually end up on the cutting room floor, or archived for future reference. They may do a great thing, that the users have been asking for, but to be useful they must be run constantly by all users on a project all the time (https://goo.gl/9uZNHL). That’s just not going to happen in a small office. Most users are still learning Revit and often refuse to run dynamo and even dynamo player, as simple as it is.
I always try to build the Class A script, I appreciate the personal and professional benefits of the Class B script, and I have hope for the Class C script, that perhaps one day its time will come.
2 Likes
I gave a webinar to a few hundred people today which classified everything as either single project use (your class b)or multi project use (your class a) and gave the recommendation to review both periodically and at updates for dynamo and/or packages.
IMHO every graph should start as a single use. If it fails there then you never would have made it work as multi. Then add the input controls and UI to make it a good multi project use. If that fails you still have a single use graph you (and someday other users) can modify to work anyway. Note that cataloging even the failures and discussing all of it with others (in and outside the office) is important as otherwise you will take longer to turn the fixes into successes, and will never know how to turn the working graphs into even better ones.
1 Like
Thank you Jacob. All of my scripts do start out as Class B scripts, viable for me to run on all project files, once as needed. I use the Class B scripts all the time.
I’d like to write all Class A scripts, simple for all users to run on all project files. And we do have a few users who are comfortable running some of the deployed Class A scripts in dynamo player.
But when a dynamo player script, as written, needs to be run often to be effective, I don’t deploy it, because by myself I cannot update all the projects, all the time, and I can’t force everyone to use player.
I am hearing that Forge might be able to run scheduled dynamo scripts on C4R projects in the near future, but we haven’t moved from Revit Server to C4R yet.
What type of script are you referring to which has to be run often? And what does often mean? Daily? Hourly? Constantly? Do you utilize datashapes to give the dynamo player scripts a helpful UI or are you using the built in UI for player (which is much more limited)?
I do recommend looking into the benefits of switching to BIM360 instead of Revit Server or a local network - lots of time savings on the management end. I went back and did a retroactive review of a project I worked on at my last office and it would have saved me 4 hours a week.
Well pointed - I’ve been fighting this vocab snafu in my daily life for the last 6 months and I keep tripping up. That said, most of my graphs have a lot of scripting as well (design script not python).
2 Likes
Thanks Erfajo and Jacob
I Always used until now the word script when i mean forming graphs
I knew it could not been the right words.
But i could not find the right words. until now
Maybe it is because my english is not that good. Even though i read the dynamoprimer.
I probably missed it. Strange because when i read the topics now i see that the word graphs are frequently used 
1 Like
@erfajo thank you so much…! Ealier I was also bit confused about the terminologies people use on posts
2 Likes
Thank you erfajo,
If I use the general term script at the office they get it. No questions, no blank stares, and we can move on with our work. When I post in a forum, which is not often, I should really use the specific terms.
I’ll rephrase. I build graphs, with embedded designscript, UI nodes, no zerotouch nodes, and occasionally a python node, to form an algorithm.
1 Like
Jacob,
I do utilitze datashapes, I’ll take a closer look at BIM360. Examples of Class C graphs include but are not limited to:
-
A graph that shades rows of all schedules in alternating white and grey for graphics clarity at the request of architects. This graph would have to run continuosly so that shading is updated when elements in the schedule are added, removed, or rearranged.
-
In our door and window schedules we reference the detail number and sheet (5/A8.1) of head, jamb, sill, and misc drafting views. I have a graph staff can use to map the unique id of the four views to each door and window, but I would need to run a supporting graph that updates the numbers in the schedule continuosly should someone change detail numbers or sheet numbers.
Basically graphs that emulate the parametrics of Revit.
Both of those are examples of graphs I would have the team run ‘right before printing’ to confirm outputs and as needed (you modified the detail numbers, run the script via player). All that added computation time for the intermediate changes made as the model develops isn’t going to provide a better product but just create more issues with additional element borrowing overlaps (Bob can’t programmatically change that parameter value because Susan touched a door there, but you can’t back out because the graph is in constant run mode so it always sees the previous change).
Good point about element borrowing overlaps. Perhaps a reporting graph that does no borrowing is a better candidate for “continuous run” graphs.
Maybe a print dialog reminder to run recommended graphs would aid in the implementation of “run before print” graphs.
Data reporting is also useful, but only to a point - do you really need to report every change that is made, or is a periodic review of a moment in time more valuable?
On the subject of Run before print:
“Ok guys it’s noon - everyone stop picking up redlines, sync and run your assigned graph(s), we need to send the PDF for final review now.”
Seems like that would work rather well on a team of any size. For smaller jobs you might even be able to combine graphs into one and have them kick off in order, perhaps even making the PDF at the end.
1 Like
If graphs like the two I mentioned are not run pretty frequently in the background, unresolved views are going to bug architects who have to work in them.
If the continuous run graph or any other executed graphs are interfering with element borrowing, maybe an element change request queue would solve the problem.
When an element is relinquished, it triggers queued changes, requested from dynamo graphs since the element was borrowed, a periodic review of sorts. This might promote more frequent synchronization.
On the subject of Run before print:
If assigned “run before print” graphs are really just a form of periodic graph, the same queue could process element changes after everyone syncs and relinquishes.
When the change request queue is clear you know you can print.
@David_Duarte
before printing i advise my colleages to close and reopen the project, making sure all links are up to date aswell.
Thank you guys, your input gives me a lot to build on.
Agreed, but there is always the ability to run it manually before you print. If they’re too old school ask them how many times they would have to type refresh for that ole object to get it to update. This is no different, but smarter still as that schedule actually refers to the live Revit data not what was writen in time a few months back.
How do you propose tracking every borrow?
An interesting thread!
Regardless whether they are graphs, scripts, a combination thereof or Classes A,B,C - how do you all approach the legacy/continuity issue? That is, the facility for someone else to take over development when the original author has moved on to pastures new, especially when there is no role overlap.
Obviously, there are a number of documentation options – annotated groups, clearly commented code, structured custom nodes and so forth – to make the task straightforward. However, I’ve seen many instances of complex, seemingly workable graphs where I would be hard pressed to decide whether to spend time understanding the logic or simply rewrite from scratch in order to customize them.
Do your firms have structural procedures in place to ensure productive continuity?
My advice to that is to teach out what you know to as many as will listen and get others up to speed with Dynamo.
To be blunt, I don’t know how much traction those efforts get though. Really, this isn’t an new issue - every day firms have problems finding people to rework lisp routines and macros for AutoCAD and Revit plug-ins which were written by others who left. It’s been that way for decades now. The good news with visual programming is its a lot faster to pick up where someone left off.
@jacob.small Yes, as I suspected! I find it intriguing that most firms have had procedures in place for decades re: 2D/3D CAD and more recently BIM – but anything to do with code seems to be relegated to the digital ‘sketch’ category. The issue is that most using tools like Dynamo are ‘designer’s rather than ‘professional developers’. So, like myself, ‘amateur programmers’ as in Robert Woodbury’s benign definition – I’m currently re-reading ‘Elements of Parametric Design’ for inspiration.
@erfajo I think the ‘sourdough’ analogy is apt – but the concern is a situation where the ‘catalyst base’ is copy/pasted because ‘it works’ and the reasons for its specific internal structure have been lost.
I guess ‘wheel reinvention’ is a reasonable justification for keeping the employment rate high!
Hopefully, A.I. algorithms won’t get too ‘clever’ in the foreseeable future.
Great explanation, thank you @erfajo!
We are documenting Dynamo graph process for end user.
And most of the graphs are Class A (per @David_Duarte), and to be run through Dynamo Player.
When you hover over the play button, in player, it reads “run Script”, not graph.
That might be where this misunderstanding comes from 
Now, we are tended to call for Scripts in our documents, not to confuse the end users.
Hope it will be fixed in Player and say, as in Dynamo, “Run Workflow”
