Make NavisWORK for You: Intro to the Navisworks API

JAKE LOVELACE: All right, good afternoon everybody. We've got the unfortunate position of being right after lunch, so are you all awake? Do you need more coffee? It's probably second worst only to the 8:00 AM session on Thursday morning, but--

[LAUGHTER]

My name is Jake Lovelace. I'm with Brasfield and Gorrie as a virtual design slash VDC coordinator. Been there for about two years now.

JESSE CREECH: My name is Jesse Creech. I'm a senior VDC coordinator also at Brasfield and Gorrie, and I've been there about five years now.

So just a little bit about B&G, a little bit of a background of who we are as a company. We were established in 1964. We're out of Birmingham, Alabama. We have 12 full service offices across the southeast, over 3,000 employees, including some of our field staff. We did almost $3 billion worth of total gross revenue in 2017 and we're trending to do about $3.5 billion this year.

Most of our clients are repeat. We maintain really good relationships with all of our clients. And we actually follow them all over the country as well. You can see our offices labeled here. The states in green are states that we currently have projects in; in blue are states that we have traveled to for some of those clients as well.

So VDC at Brasfield and Gorrie started out about seven or eight years ago with just two employees and has grown extremely quickly. Obviously, the demand is sky high. We're the fastest growing department in the company. There are almost 40 of us at this point in time across six offices. We're a pretty young group. Actually, our average age is below the age of 30. And we touch almost all of the work that Brasfield and Gorrie does as a whole. We touched $3.2 billion this year out of about $3.5. So we're very involved on almost every project that comes through our doors.

We're also a very diverse group from all kinds of backgrounds. A lot of us don't even necessarily have a construction background in school or outside of school. We have engineers, architects, all that kind of stuff too. So that allows us to be very diverse in how we solve problems and be creative.

So I'm going to kick it over to Jake here.

JAKE LOVELACE: Before we get started, like we said, we're BIM/VDC coordinators. How many people come from a BIM background here? So pretty much all of you. That's good. It's good to be in a room full of people who know what that means.

Usually when I talk to people who are outside of the industry I have to say something along the lines of, well, I make 3D models of construction projects. And I've no joke had somebody ask me, so you mean out of like papier-maché and sticks? So yeah, it's good that we're in a position where everybody kind of has that common background.

Today we're going to talk about the Navisworks API. I'm assuming most of you have used Navisworks before, that are familiar with it, use it every day. How many know what an API is? OK, so a fair number of you.

For those who don't know, API stands for application programming interface. You can contrast that with like a GUI, a graphical user interface. The G in GUI is graphical, that means that you're clicking buttons and forms on a screen. The U stands for user, so it's for end users, not for programmers. Contrast that with an API, the P in API stands for programming. Guess who uses it? Programmers.

But you can do a lot with it. You can automate certain tasks. You can do a lot of things that you can't do through the GUI. But there's also a lot of things that you can implement that are also possible within the GUI. You can just automate it through the API.

So let's go over a few of the class objectives. The first thing we want to do is explain the overall structure of the Navisworks API. We're not really going to get into the weeds in this class of every function, every method call that's in the API. I just don't think that's the best use of our time given that it's after lunch. I don't want me to bore you to death with a whole bunch of code samples.

So really what we want to do is focus on where's the next step for you to go, where do you want to learn next. And just so you have an overall view of the API and you know where you need to go to find out more information.

But we are going to implement a basic "Hello World" plug-in. This is going to be very quick and just something to get something up on the screen. It's going to be a little button that you add into Navisworks so that when you press it it says "Hello World." So very simple. It's just some good boilerplate code to get you started.

We're going to develop concepts of custom functionality and describe how the Navisworks API can be used to achieve them. That's a lot of fancy words just to say that I want to inspire you with your own projects. I want to give you ideas for what you can do through the API and all the power that comes with that.

And finally, probably most importantly, we're going to identify the right learning path and resources to get you started coding plug-ins. I want you to walk out of this class not necessarily being experts in the Navisworks API, but just being able to say, you know what, I know where to go next to find out more. Because really, we only have an hour. We can't cover every little detail of the API, but we can give you a good path forward.

So first things first, why do you want to develop a Navisworks plug-in? Most important thing probably is to automate repetitive work. A lot of you work in Navisworks every day. You know that there can be a lot of manual entry, a lot of repetitive things that you have to do day in and day out. The API can help in automating those tasks.

Also, if there are no comparable solutions available, before I start any plug-in project, I always do a quick search through the Autodesk app store to make sure there's nothing else out there that does what I wanted to do. Because really, I'm assuming most people here are coming from sort of the VDC background where you're not professional programmers or you're really just doing this on the side to help your firm. Am I right?

So you really don't want to spend time reinventing the wheel and creating something that's already out there. Usually if there's something out there that does what you want it to do, it's probably best to just spend a few bucks and buy it. This is really for more when you need high levels of custom functionality. So if you've got something that's very specific to your firm, a certain workflow that you want to try to automate, that's where the API can really come in handy.

Before we get started, we're going to do a little quick programming primer. I want to do a quick summary just so I know how to tailor this. How many people in here are professional programmers? You either do it for a living or you're good enough to where you could do it for a living. Got a few people.

How many people are intermediate? So you've done a project or two and you maybe know one language or two. And how many people have never written a line of code in their life? So we're kind of pretty split. So I'm going to kind of tailor this to exactly what we need.

But I'm not going to go over every little detail about the fundamentals of programming. We just, unfortunately, don't have time for that. But at the end I will point you to some resources to where you can learn more about the basics-- for loops, you know, if statements, variables, that kind of thing.

The one thing I do want to touch on real quick though is object-oriented programming because C# and .NET in general, the language that you write Navisworks plug-ins in is object-oriented. And all this means is that it's a way of organizing your code into logical buckets or objects that you can interact with, and it kind of takes some of the abstractness out of it.

So let's take this example, I pulled a Lord of the Rings example in here because I figured all you nerds would appreciate that.

[LAUGHTER]

So at the top level we have classes. Class is defined sort of like a general category of something. It defines what something is.

So think of like a lowercase noun. It's describing a thing-- a chair, a wall, a hobbit. It's not a particular hobbit, it's just a hobbit in general. Versus objects or specific instances of those classes. So Bilbo Baggins is a specific hobbit.

In the Navisworks API, there is a particular Save Viewpoint that's of the type Save Viewpoint class. So that's kind of how it's organized. Now if you know this, you won't get completely lost when we start going through this structure.

Classes can contain properties and methods. So a property is basically just some sort of data that you're storing with an object. So with a hobbit, you might store a hobbit's eye color or foot size, really big.

And with methods, methods are verbs. These are functions, basically, if you've heard them in any other language. So put on ring, take ring to Mordor. In the Navisworks API, you've got a method for creating a viewpoint, you've got a method for transforming an item.

And also important to note that classes can be derived from other classes. So more generally, the hobbit class could be derived from the character class. Like say you're creating a Lord of the Rings video game and you want to create certain properties and methods that go with the characters in general and then apply them to specific types of characters.

Let's get a little bit into the structure of the API. First we're going to talk about Navisworks in general just so we kind of know what we're dealing with here.

Navisworks was acquired by Autodesk in 2007. It was originally called JetStream. I believe it was made by a company over in Europe called Navisworks. And when they adopted it they made into three flavors-- Manage, which is the full package that gets you everything; Simulate, which has limited features-- I believe it doesn't have the clash detective and a few other things; and Freedom, which is a free viewer.

An important note here is that the API currently only works with Manage and Simulate. So bear that in mind. You can't use plug-ins at all in Freedom.

It's organized into modules. At the core module is called the Roamer. In fact, if you hover over the Navisworks link when you open it in your computer, you'll see that it opens a program called Roamer.exe. That is Navisworks. That's the core of the program.

In addition to that, you've got modules that plug into it that Autodesk has kind of added over the years. You've got the Publisher, the Clash Detective, the Renderer, Quantification, Timeliner, the Animator, and the Scripter.

There is mixed API support for these modules. Clash Detective has support, Quantification, Timeliner, and a little bit of rendering is possible through the API. Currently, I don't think you can control the Animator and the Scripter completely through the API. So if you have projects that were going to use that, bear that in mind.

Let's talk a little bit about the API specifically. Let's talk about COM versus .NET. COM was the original Navisworks API introduced back when it was first created. It's dated now though. And now since 2011, the API has moved to .NET.

How many people know what the .NET framework is? I'm not going to get into the details about what that is. Just know that it's a software framework that's kind of sits on top of the OS that manages low level aspects of your code. But that's what the Navisworks API is built on top of, and it wraps the core code in Navisworks so you can interact with it in the .NET framework.

There's many different types of API applications that we can make. The two most common are the add-in plug-in-- that's what I'm going to demonstrate today that adds a button to the Navisworks ribbon-- and the dock pane plug-in, which allows you to create your own docking pane similar to how the Saved Viewpoints pane works or the Saved Viewpoints or any of those other panes that you open.

There's others. I believe the input plug-in let's you map keyboard shortcuts to certain plug-ins, and a bunch of others that you can look up at the documentation.

The automation API automates basic product functionality. So basically, it allows you to interact with a Navisworks document without actually opening it. You can open a pin, save a few of those basic functions, and you can also run other plug-ins from within the automation API. Very handy if you need to just pull data out of a document without actually opening it.

Next there's the application controls. These are .NET controls that can be added to your own independent .NET projects. So for example, if you want a Navisworks viewing object inside of your own .NET application, you can add that in. Now, you do have to have Navisworks installed in order for the application controls to work.

Finally, there's NwCreate. This is not part of the .NET API. This is a C++ library that provides the ability to create Navisworks geometry. So if you for some reason have the need to build your own custom Navisworks exporter from whatever software you're coming from, that's what you would use. It, however, does not add geometry to the existing model since that kind of defies the point of what Navisworks is about. It's more of a model manipulator. It's not an authoring program.

We'll dive into the class structure a little bit. This is not the entire API. This is just some parts I wanted to highlight and sort of the most important parts of the API. But we'll drill down into this a little bit.

So at the top level, you have the application class. This provides access to any application level elements. So the active document, the GUI plug-in. So you can get your, I think you can get your active tool in the application that way.

Important note, Navisworks is currently a single document application. So there is a property in the application class called Active Document, and that gets you the active Navisworks document. And it is currently the only document because when Navisworks opens, it only supports one document at a time, unlike Revit, for example, that supports multiple open documents. They built it this way so that it's extensible, and in the future if they decide to make Navisworks a multi-document application, they can.

Next is the document class. This provides access to any document level information. So models, any current selections or viewpoints applied, viewpoint sets, et cetera.

Next is the model class. This represents a loaded file within the document. So for this, just imagine the Selection Tree that you have. At that top level of each one, if you're in an NWF, is a model file. That's the top level node. And so that's represented by that class.

And then inside of that class, you have model items. This represents sort of the hierarchical tree that you see in the Selection Tree as you drill down into a model.

They can have parent and child element. So a particular model item can have child elements that are associated with it that are also model items. So the API provides a way to drill down into that.

You can also get geometry information out of these, properties and property categories if you need to access that.

AUDIENCE: [INAUDIBLE]

JAKE LOVELACE: I am going to touch on Saved Item, which this-- heard me talking about inheritance earlier. This is the base class for saved items in the Navisworks document. So Saved Viewpoint, Selection Sets, any type of data that you save back to the document besides the model items themselves, those are generally represented as saved items. That includes Saved Viewpoint, Selection Sets.

I've also got highlighted here on the right Clash Results. So once you get to the Clash Detective module, those actual Clash Results are stored as saved items.

I stole this from one of the Navisworks training labs. This is a good overall picture of what the Navisworks GUI looks like from the perspective of the API.

So around the whole thing you've got the application. It's all the controls, everything. And then just in the Viewing area and Selection Tree over here, this is sort of the document area of the GUI. It's where you manipulate document level information.

Over to the left in the Selection Tree, you can see your individual models as you go down. And underneath those you've got individual model items that you can drill further down into.

Let's jump out real quick and get into a "Hello World" demo. I'm actually going to do this live in Visual Studio. And decided I like to live dangerously so we're actually going to do something live.

So what you're going to need for this, you'll need Microsoft Visual Studio or another .NET IDE. IDE stands for integrated development environment. It's basically a software package that includes a bunch of things you need for code development. It contains code editor, debugger, compiling tools, that kind of thing.

Visual Studio is the most common, but you can also use SharpDevelop or any other of the .NET IDEs. You also need Navisworks Manage or Simulate to make this work.

This is a little slide I have on here about the .NET framework. Like I said, we really don't have time to get into that, but this is on the handout and you can get to that if you want to. And it's also in the PowerPoint that's attached to the class.

So let's jump into it. So I've got Visual Studio open. If you're in Visual Studio, the first thing you'll want to do is create a new project, and that will be a class library project under the .NET framework. So we'll click that.

And it'll take you to this screen where you can create a new project. And I'm going to save this just in Directory. You can give your solution a name. So Visual Studio, the way things are organized, you've got top level solutions, which can contain multiple Visual Studio projects. It's just a way of better organizing your code and the various projects you're working on. So I'm just going to call this Demo.

And you're going to want to create a directory for the solution, so you keep that checked. I'm working in C# by the way. Who knows C# or has used it before? A few people. More than I expected, actually. Wow.

So I'm working in C#. You can also do this in Visual Basic or any other .NET supported language. I like C#. I think it's just kind of like a cleaner looking code, but whenever you prefer, you can use.

Now I'm going to jump into some boilerplate code. If you're not familiar with that lingo, boilerplate code is just basically template code that we throw into a project. This particular one that I'm pulling from-- and I'm actually pulling this from the class handout, so if you all want to download that after the class, if y'all do this on your own, this is where this is at. So I'm going to copy this boilerplate code. This is actually implementing an interface, which in C# is basically just sort of like a template for boilerplate code that you can use.

And I'm going to completely paste all this in my Class1.cs file; .cs is for C#. There's a few references we're going to need to add. References in Visual Studio bring in other DLLs, which are dynamic link libraries. This provides access to the API itself. So under References we're going to right-click and hit Add Reference.

And we're going to Browse if it will let me.

And you'll actually find this in your Navisworks Installation folder. So we're going to go to-- I'm actually already there. So C, Program Files, Autodesk, and then Navisworks Manage 2018. I'm using 2018. You can do this in whatever version you want.

And then we're going to go down and find Autodesk.Navisworks.api.dll. And that's the one you'll want to reference in. That contains the API. There are several other DLLs that you can bring in. There's one specially for the Clash Detective.

There's an interoperability mode. And I forgot to mention this earlier when we were talking about the COM API. The .NET API for Navisworks provides interoperability for the old COM API.

The reason it does this is because although most functionality has now been transitioned over to .NET, there are still a few features that only COM supports. So it provides an interoperability mode to where if you need to access one of those old COM features, you can do that through the .NET API.

There will be certain situations where you might have to do this. I would advise staying in .NET as long as you can before switching to COM. A good example of this in the plug-in that I'm going to show you here in a little bit, one functionality of it was exporting out an image file of the current viewpoint. And that's something, interestingly enough, you can only do through the COM API. That has not been implemented in .NET as of yet. So that's one example of where we had to switch it.

We're going to pull this in. So now it's referenced over here on the right. And, very important, when it comes in, by default, it's going to set Copy to Local to True, you're going to want to put that to False. That way it gets embedded into the application.

And you'll see Visual Studio is actually doing a sort of spell check on my code. It's called IntelliSense in Visual Studio. And it was highlighting these in red because it couldn't find the reference, but now it found it.

You also have to put a using statement in order to actually use the API in your code. And this references the namespace and the classes, which it's drilling down into.

We also need a system.Windows forms reference. This pulls in the UI API for Windows to allow you to create the text box that's going to pop up that says "Hello World." So I'm going to pull that in real quick. I did the same thing as before, go into References, Add Reference, and find this one under Assemblies, and down here, system.windows.forms.

Now you see that the red went away.

So let's go through this real quick. The namespace level, namespace is, in C#, is basically just a way to organize your classes. It's kind of like if you think of a class as a book, like to take a library example, a namespace is a bookshelf. It's just a way of organizing your classes.

We've got some configuration options that go with this plug-in. So we've got a plug-in attribute function here. The first argument to this function is the name of the application or the name of your plug-in. We'll keep this as Hello World. That's your plug-in name.

The next string is a four-character string. This is your individual developer ID that helps Autodesk recognize who you are as a developer. So you can pick whatever four letters you want to do to represent yourself there.

You've got a tooltip argument that allows you to put in a tooltip that when you hover over the button, that's what it says. And also, your display name. So That's what actually displays on the button in the UI.

Next, we have our class definition. So this is the Hello World class, and it's taking the add-in plug-in interface right there. Inside the add-in plug-in interface, we've got an execute function, and this is what actually runs your plug-in. So when that button is pressed, that execute function is going to execute. And you see our little message box dot show Hello World, that pops up a little text box that just says Hello World.

All right, so let's go ahead and save and build this. To save, you hit Save All up here. Now I believe all my references are good. Hello World plug-in, that's my namespace.

I'm going to hit Build. And I'm building under the debug mode right here, so that's important to remember. Build and then Build Solution. And it's going to start that Build. You see down there at the bottom where it says Build Succeeded.

There were zero errors. If there were errors in your compile, it will show up in this little error list dialogue over here. And now to get to where this actually spits out the output that this puts out is actually a DLL file, and that is your plug-in. That's what we're actually going to copy into the Navisworks Install directory to actually install your plug-in.

So I'm going to right-click on my project file and hit Open Folder in File Explorer. This gets me to my project directory. And it's actually going to spit out in this Bin folder. And we pushed out Debug mode, so it's going to put it in the Debug folder. And there it is right there, ClassLibrary1.dll.

So we're going to right-click and copy this. And then we're going to go into our Navisworks Installation directory and paste it. So we're going to go back to C, Program Files, Autodesk, Navisworks Manage 2018. And then we're going to actually put it in the Plug-ins folder within the Install directory.

And this is very important. You have to have it in a folder named the same thing as your DLL file, I believe is what it is. So I'm pretty sure, what did we call that? ClassLibrary1? Yes.

So we're going to put it in that folder.

Right-click, Paste it in here.

So now it is basically installed to Navisworks at that point. Let's pull it up and see if it works.

Before I do that, I'm going to make sure I didn't have any other previous demos on here that's going to mess this up.

I'm going to take that out because I think that was an old example.

Now we're going to open Navisworks.

If I can get to it.

Now you see it actually added a ribbon panel to Navisworks. It's called Tool Add-ins 1. This is where you're add-in plug-in comes in by default.

There is a way to customize this. I've not actually tried it yet, but there is a way to create a custom ribbon with a custom name.

And we'll see on here we've got our Hello World button. And you see our tooltip there. If we press it, a little message box up comes up and says Hello World. So we successfully got code to execute inside Navisworks, which is huge. So that's the start of the plug-in.

There is step-by-step instructions for all of this in your handout too, so you can follow along with this after class if you want to and try this yourself. With that, let's jump back into our presentation.

Now that we've kind of gone through that, I want to talk about UI design real quick. More than likely, the plug-in that you make is not going to be so simple that you can just click it once and it runs and you don't need to enter any other further user input. More than likely, your user is going to have to add in other information besides just clicking that button. So you're going to need a user interface.

There's two main ways to do this inside Visual Studio. There is Windows Forms and there's WPF, which stands for Windows Presentation Foundation. Windows Forms is old, like Windows 95 old, and it looks old.

So you can see over there on the right what Instagram would have looked like in Windows 95 days. That's kind of what it looks like. It's all your standard check boxes, menu boxes, buttons.

But the nice thing about Windows Forms, it's very easy to use and it's very user friendly. There's actually a drag and drop form designer inside Visual Studio that you can arrange all your form controls. You're not having to code every position of where it is. So it's very easy to pick up if you're new to this.

The other option is Windows Presentation Foundation, which is sort of the next generation platform of Windows UI design. It incorporates XAML, which is a markup language. Windows Forms also supports WPF inside it, by the way.

My opinion on this-- this is just an opinion-- but if you're new to this and you just want to create a quick and dirty plug-in that you want to use inside your firm to kind of solve problems, Windows Forms is probably the easier route to go. It is very dated, but it's got very good support and documentation online and it's very easy to get up and running with versus WPF, which is a little bit more of a learning curve. However, if you're doing this to make money, if you're creating a professional plug-in, I would recommend using WPF because it will look cleaner and it's a more responsive interface.

Let's talk about deployment for a minute, too. Now you saw me just copy that DLL file into the Navisworks Install directory. You do not want to make your end user do that. There's just too much room for error.

We have a saying in our group when we're evaluating new software. We say if it's going to take a project manager more than two clicks to use it, they're probably not going to use it. And the same is true within your own group even, that if you make it too hard for your users to install, then they're probably not going to use your software.

So we want to make this easier on everybody. So the way I recommend doing this-- I did a little bit of research-- I use Inno Setup to create an install wizard for all of my plug-ins. And I actually bundle it as a suite.

So you'll see in a minute, the flagship plug-in in that update for our group is called IssueTrack, which tracks issues in the coordination process. But I also have a few others there that also bundle as a suite. That way we can install them all at once and users aren't having to switch back and forth between different install files.

It makes a typical install wizard just like you've seen with any other type of application if you've installed it. And it's got a pretty simple scripting language. You see it over here on the right. Basically, you just specify what type of files you want to copy and include in this exe file that will spit out, any registry keys you need to be added or modified, and it will run and create an install wizard that's one file that's a .exe that your users can run.

We got into this and thought, I can make this even easier. More than likely, your plug-in is going to have to be updated. You're going to have to update it over time. You're going to have to make bug fixes, add new features. You don't want to have your end users having to go back and reinstall manually every single time.

So there's actually a very clever little library that you can add in to .NET projects called AutoUpdater.NET that with one line of code, you can actually check for updates over the internet through your .NET code. And then if there is an update available, it'll prompt the user, similar to what you're seeing here, and then it will download and automatically install the new .exe file, the same one that Inno Setup spits out.

So that's what I would recommend looking into for your deployment solutions. There are more. These are just the two that I work with.

With that, I'm going to talk a little bit about a live case study that we've been using at Brasfield and Gorrie. This is a real world plug-in that we developed to solve issues with the coordination process and to better track issues than what we were currently doing.

It's called IssueTrack. In hindsight, I wish we would have given it a cooler name, like PowerBimTrack 5000 or something, but it is what it is now. So I've got a little video that's going to play in the background while Jesse is talking that just kind of shows me going through the interface. So you can kind of watch that as well. Jess?

JESSE CREECH: So this IssueTrack came about due to a project that presented some pretty unique challenges, specifically with the design and our schedule constraints. It was a very challenging design, but even more challenging schedule.

So with that-- we also had a sub team, that's worth noting to say, that had one person on a very, very large hospital job that was in charge of modeling and coordinating about five different systems. So we at B&G offered to actually self-perform model and coordinate all of the plumbing for that sub to help out the coordination effort.

This led to us generating a lot of RFIs and immediately kind of got the project behind schedule with the typical generate an RFI, send it in, design team has two or three weeks to spit a response out, comes back, sometimes that doesn't work. And we started getting further behind schedule.

So what we decided to do was to have recurring meetings with the design team. And to help facilitate this, Jake created this plug-in to where what we can do is come into our model and create RFIs that live within Navisworks itself. These can be broken out.

It obviously gives an issue number that you can see up there, date created, a brief description of it. We can break this out by area of floor, tag different disciplines in it, who needs to see it per the design team for a response. And also, we can have how much of an importance or an impact to the schedule that these are going to create.

It's creating an issue right now.

So what we would do is go through and identify a lot of our problem areas that needed to be talked about on these recurring meetings, create all of these issues, and then push out a document that I think we'll see in just a minute.

JAKE LOVELACE: Yeah, maybe a little further down here. It's kind of walking through right now. This is sort of the issue creation process. And I've built in several options for creating issues. The goal was to make it as easy as possible for our users to go in and make issues quickly because I knew any additional labor I added to their scope is going to discourage them from actually using it and reverting back to what we were doing before.

So here you're seeing several ways to create and edit issues. Got to see where this is in the video here.

This is me going back and adjusting issue fields after they were batch created. So you see me going in here and assigning trades to each of these issues that were created through viewpoints. And I'm just going to scrolling through one at a time, evaluating what the viewpoint was, and hitting Apply to make those changes.

Something else that's built into this, I really designed this with the mind of trying to get our people and our group adjusted to tracking issues through an external program. And so it was really meant to do this without disturbing their existing workflow as much as possible. Jesse, you want to talk a bit about how we've been creating issues in the past?

JESSE CREECH: Yeah, so, I mean, what would be typical as far as generating an RFI or an issue from a Navisworks model, I'm sure that you all are familiar is, you know, generating screenshots from viewpoints, putting those in a Word document and sending them to your project manager for them to compile, put on whatever company's RFI stocked whatever thing that you're using, if you're using Procore or whatever, and then send those in.

JAKE LOVELACE: So we've been tracking this through a viewpoint folder structure. Many of you probably kind of use the same workflow where you create folders into the Viewpoints pane and kind of track it by trade there about the type of issue it is.

Just to kind of ease things, I also built into this functionality to keep those issue fields and those viewpoint folders in sync. So say you've got an issue in a mechanical folder that needs to move to an electrical folder. Once you move it to that folder, it will actually change the issue fields that it's linked to, and vice versa. If you change the issue fields, it will actually move it to the new folder.

This is one way of kind of adapting people to start getting them used to this type of workflow versus the traditional viewpoints workflow that we've been using.

JESSE CREECH: One of the things that we keep coming up with that this is really helping to alleviate as well is it would seem that from a BIM coordination standpoint, our coordinators and our subs, people that are actually in the model every day are five steps ahead of our PMs or the design teams that aren't in Navisworks and aren't on these coordination calls day in and day out.

And it's almost like two different languages. We're taking all the information that is within this Navisworks and all these viewpoints and then having to export it out and then get it all back into the model. So this is helping us live within the truth of the model and everybody's updated information.

JAKE LOVELACE: See, I think that's getting close to where it'll actually show the report interface in a minute. But one of the most important parts of this is actually being able to push issue reports out.

This is very important for our current workflow because we've got a lot of people, stakeholders involved in the project that may not have Navisworks or may not have the capability. And they really just want to see a simple PDF showing screenshots of all these issues.

And so this interface here, what you're seeing now is the report interface. This allows the user to go in and create reports based on a filter list of issues. And they can actually be saved in a template-style interface so that you can pull up templates, then reuse them, the ones that you've been using before.

So you see the Sort and Filter options being edited now. And I'm about to press Create Report. There I go. Come on, me. There it is. So that's the report that it generates at the end. It is very clean, formatted to our B&G standard format. You can see all the viewpoint screenshots and images coming in.

I did see one thing that came up on the video earlier was you saw me adding in external images. So that's another feature of IssueTrack. Not only can we link in viewpoints and clashes, we can link in external images. So if we need to show a planned screenshot inside of an issue, we can do that. And that feature actually is something that evolved after the fact. When we started getting into this hospital project, we realized that was a need, so I went ahead and built that into the system.

Just to kind of talk a little bit on the back end. How am I doing on time over there?

JESSE CREECH: You've got six minutes.

JAKE LOVELACE: Six minutes?

JESSE CREECH: Until questions, yeah.

JAKE LOVELACE: OK. Just a little bit of how this works on the back end. Right now the data format we're using is an XML file. So how that works is that we're actually using link to XML inside the code. And that is taking objects in the code, which are-- the issues are modeled as objects in the code and they're stored in memory. And then once the Save Project button is pressed, it gets exported out to XML. And then if next session when the user wants to come back into Navisworks they press the Import button and it re-imports all of those issues from that XML file back into memory.

This is not an ideal solution. It's not the way I want IssueTrack to work long term. Really want it to start syncing to the cloud. So really, you've heard a lot of presentations here at AU about data being in the center. And the reason that's so important is if you get data in the right format, you can do a lot with it. You can start applying analytics to it and start leveraging it, creating an access control system.

One big limitation of IssueTrack now is because it's a local file, we can't have subs and other stakeholders come in and be in the data simultaneously with the coordinator. Future iterations, and actually in development, something I've been working on lately is taking IssueTrack to the cloud and having it to where users can log in and post comments to issues, similar to the way you've seen some more commercial issue trackers work.

Also importantly, you can move data between systems this way. So that if you've got another system you want to port data over to, say another issue tracking software-- if you want to get it into Power BI or any other of these analytics programs-- you can get it into there maybe with just a little bit of code, or no code at all. You can query that database to give you the data that you want.

JESSE CREECH: I think as a senior coordinator that oversees several different types of projects, that would be invaluable to me. As opposed to being in the weeds on that project every single day and knowing where our hot button issues are that need to be brought up or pushed with the design team, I have the ability to come in and check each one of those and get a really quick snapshot and understanding of what needs to be pushed, where do we really need to circle the wagons and push through some of these issues to make sure that we stay on schedule.

JAKE LOVELACE: Wanted to show this slide real quick just to illustrate that there's more that you can do with the Navisworks plug-ins than just create an issue tracking application. That's kind of the flagship one that we have, but I've also got a suite of other tools that our coordinators use every day.