Ability to monitor Floor Slabs, Ceilings and Walls

[MPritchy]

Could we add Floor Slabs and Ceilings to the list of items that the Don't Touch Me Tool monitors? We have had a number of instances on LaGuardia of staff deleting these items and as a result all the hosted elements disappear as well. If we could track who deleted them, that would be great :)

[MPritchy]

Can we also add walls to this as well, please? Someone has just deleted all the walls in one of our models

[ksobon]

@MPritchy Like I have said in the private chat we had on teams, tracking down users deleting elements out of the model is not Mission Control's primary purpose. We allowed Grids and Levels because Autodesk made it trivially easy to mess them up. The little 3d, 2d button is such a great/stupid invention. It makes sense for us to try and stop people from messing with these elements because software makes it very easy to do something that you didn't intend to do (change 3d grid while in 2d view etc).

Now, when it comes to things like Floors, Ceilings, and Walls...they were meant to be delete-able. It's a basic functionality of any modeling software to delete things. Sure, things are hosted to them, and we lose work, but there is no ambiguity about what happens when you delete a wall in 2d view or 3d view. It's all the same: It's gone. For these things I would prefer that we focus our efforts on educating people to make sure they understand the software they work with.

It's my understanding that people delete Floors when they want to hide a line across a door (I have seen this a lot). Same can be said of ceilings and walls. I will venture a guess that majority of these deletions in such late stages of the project are actually graphics related, not modeling related and surely not intentional.

There is also the issue of basically tracking everything. Your model becomes unusable if you get an error message every time you touch anything. Revit is bad enough in itself. We should not be making that experience any worse.

Let's not overreact to user deleting a few walls and floors. It's happened before it will happen again.

cc: @gschleusner @jvandezande @dbaldacchino @OneSlowPony @diveyj

Ps. Of course I might be wrong on all accounts in which case feel free to take a vote and i will gladly program users ability to delete anything away.

[ksobon]

@MPritchy you made a great observation in our "private" teams chat...we are not interested in just any walls/ceilings/floors but those that have lots of elements hosted to them. Now, that's a much better suggestion than just tracking them all....

From programming stand point of view, i think that would not necessarily lessen the computational load on the model. We would still need to track them all, and also check for hosts on top of that. it might actually be slower, but logically it makes more sense for me.

Also, you said: "if they don't know what it is, they should investigate the item...", perhaps we create a tool that makes that easier? i can see a tool that you can use to select an element in the model, and check for hosted objects on that element...it would have to be something super easy to use, and we would still have to convince people to actually THINK about what they are doing...but maybe that's worth a shot.

[jvandezande]

Is it possible with the API to intercept the Delete command? Let's say, when more than x number of elements are selected? That might be interesting to prevent REALLY poor behavior in a model. But I agree with Konrad that we must continue to educate our staff on being patient and careful with our data.

[diveyj]

Or at least have it warn you that you’re deleting a link, grid, or level. Those would be the biggies.

[ksobon]

@diveyj so the Mission Control DTM tool already warns user that they are about to delete a Link, Grid or Level. What @MPritchy is asking for is that we start doing the same for Floors, Ceilings and Walls. What I am worried about is that we will soon track everything...and user experience will degrade rapidly.

@jvandezande Yes, we can intercept the ID_BUTTON_DELETE command as well as current selection to track how many elements are selected to be deleted. We would have to wait until after they are deleted to see the REAL impact of deleting something though since our main concern is deleting things that host other things. In reality to control that, we would have to intercept the delete command, and override it with our own command, to check if deleting a given object, deletes many more object hosted to it, and then based on some rule revert the action...

[dbaldacchino]

I agree with Konrad that it might become too onerous at the detriment to user experience over time. And we just cannot end up monitoring everything. Training is the key to avoid the "bull in a china shop" thing from happening :)

[MPritchy]

As I mentioned to @ksobon on Teams, I don’t want to track every single item in the model, I’m more interested in these items that have hosted elements attached to them. I don't want to prevent people from touching anything and everything. We don’t have to track escalators, shaft openings, floor box families or whatever else is hosted to a floor, I’m just asking about the floor itself. I want to prevent people from, or at least dramatically slow them down from deleting items that have dozens of other things hosted to them.

We have had an issue in one model where the floor slabs have been deleted 4 times in the last 3 months, ceiling have been deleted and as recent as Wednesday last week, someone deleted all the shaft openings in the model, which has effected all the slab edge opening drawings.

These items as you know, host a range of other items as well as dimensions, so when these items get deleted, the drawings basically have to be redone all over again. All these drawings have already been issued to the contractors and the client, so the team has to redo them 3 or 4 times over. It's a massive time and money waste that can be prevented. Pinning objects doesn’t seem to work either as people just ignore the warning message that pops up and hit delete anyway.

I’m sorry but I don’t buy the graphics excuse. If people are deleting lines on plans because they don’t want to see it and want to “hide” it, then they should not be working in this industry. That is basic drafting skills that you should learn in college. Using this software in particular, you should know that there are multiple ways to hide something instead of deleting it. People can’t be that ignorant to not know that deleting something has a knock on effect. This brings me back to hiring staff that don’t know the software, but that’s a whole different discussion.

I can "educate" people (and have been) until I’m blue in the face, about how to filter things before deleting, but at the end of the day, it's still happening. My whole point to this request, is not to stop them from deleting it, but to at least find out who it was, so that I can at least target my training to that person to prevent it happening again.

[diveyj]

Got it. Thanks

[ksobon]

@MPritchy I get it. I have been there many times before. I would not credit colleges with ability to educate people successfully. As a matter of fact I like to fall back on a basic principle called Hanlon's razor which states: "Never attribute to malice that which is adequately explained by stupidity." I won't go as far as calling people stupid (ignorant perhaps), but there are reasons we make bad decisions.

Most of the time we do things "automatically" trusting our intuitions MUCH MORE than we should. This leads us to accepting certain solutions even if they are not the best solutions, we just don't know any better. In general people will "find" proof or a good reason for making a certain decision, retroactively justifying their choices to themselves (they will remember that they deleted a floor before and all was good, they will remember that someone told them it was OK before, etc.). All this basically happens because "we don't know any better".

The only way to fix this is to put a team together of Revit users that have each 10+ years of experience. If they haven't done these things enough times in the past, that they are burned into their subconsciousness, they will keep making the same mistakes. I haven't seen a Revit project, that didn't have these issues. I don't get mad at people any more. It's pointless. We can talk to them, train them, and hope for the best but always be ready for the worst. That's how it is, because at the end of the day, we are human.

Now, let's take a vote tomorrow at the DTM call, so we can agree on this. I am not opposed to putting some preventive measures into the models, but I just want to make sure we are all aware of the potential pitfalls, and that we understand that this will not stop people from hitting that delete button and ignoring warnings. The more warnings they see, the more they will get used to them, and learn to ignore them (anybody ever pays ANY attention to the little yellow ones that Revit shows in the bottom right corner of the screen?).

[ksobon]

Per our conversation at DTM Summit we have agreed to create a Prevent Deletion tool. This tool will have the following ability:

• Intercept Delete command
• Check if user is deleting an object that would cause deletion of more than x-number of hosted elements. That number will be controlled by a setting in Configurations so it can be adjusted by DTM while setting up the project.
• If deletion passes a threshold specified, it would notify the user that he/she is deleting certain number of elements. We want to list out what categories these elements are.
• User can either approve the deletion process, or it can undo.
• We want to track every deletion operation, so every time this tool kicks in it would report to DB what is being deleted, by whom, etc. In case that threshold is passed, the data payload would be tagged with a special property that reports that.
• Reports will be displayed in a table on a configuration tab so it's only accessed by the DTM (when we get around to creating permissions). You will be able to filter the table for deletions over the threshold, by user, by date/time etc.