A friend of mine posed a question to me the other day. He was getting ready to write up a little post for his internal blog about the value of using keyboard shortcuts in Revit. He asked if we (Bimbeats) had anything written on that subject, so that he can reference us in his post. Originally, I answered, no, but that Bimbeats did collect some data that might be useful in a write up like that, so I could look into it.
The premise here is that Revit has tabs, inside these tabs there are buttons that do things. In order to click them, people have to jump between tabs all the time. That’s potentially wasteful (time), given that we can store shortcuts to some of these buttons and initiate them via the keyboard. If you ask me, even more efficient would have been to let users just customize that ribbon (AutoCAD), to put all of the most commonly used commands into a single tab, to allow for single click access to all of your tools. However, for the lack of better options, keyboard shortcuts are the next best things, that can save us these valuable seconds. Of course we do have some real estate in the Quick Access Toolbar, but that’s awfully tiny amount of space, and quickly runs out, leaving you with a drop down.
Let’s first look at the kind of impact that we are even discussing here. If we assume that there indeed is an inefficiency in the process of accessing these tools, let’s look at the data to see how much jumping between tabs do people actually do, and whether that’s a problem to begin with.
Revit logs out each instance of someone switching between tabs with a command called “TabActivated”. You will be able to find that data in Bimbeats under *revit-user* and the name of the Tab that you switched to will be under an “Action” command. Let’s start by establishing how many users we are looking at. For this write up I will use data from a company that had 1,313 active Revit users in the last year. That’s not to say that’s how many people work there at the moment, but that’s how many unique users we have data for in the last year.
These 1,300+ users switched between tabs around 3.2 million times. If we assume that each time you have to move the mouse to top of the screen, find the tab you are interested in, and click on it takes about half a second (0.5s), then they spent a total of 454 hours just switching between tabs. That would cost about $90,000 dollars a year at $200/h rate. It’s not a massive amount of money for that big of a company, but significant enough that we might want to look into making some of this a little more efficient.
The above number is actually a smaller subset of the cost that we would be looking at here. This would represent only the first click in what usually is a multi-click process. After all, switching to a different tab, means that you are now presented with a choice of the command that you want to activate. You are only halfway there if command that you are looking for has its own button, and 3rd of the way there if its further hidden under a drop down button. Since we don’t have a way to see if command was hidden under a drop down button, we will have to assume that they all have their own button and in terms of time allocation to access them they have the same “cost”.
With that in mind this company accessed commands via buttons on the ribbon tab 12 million times in the last year. Again, if we assume that each time it takes about half a second to do that (0.5s), then we are talking about 1,676 hours of clicking on buttons on a ribbon. Again, some buttons might be easier to find and 0.5s might be too much, but some might be hidden under additional dropdowns and 0.5s would actually be an overestimation. Anyways, this is not exactly a scientific study, so feel free to swap these numbers up for what seems more reasonable to you. In any case, if we spent 1,676 hours at $200/h, then we are talking about $335,122 dollars a year in total cost of button clicking.
Now, combine these two values together and maybe we are onto something significant here. I am by no means saying that you can completely eliminate this, and make it 100% more efficient. No, that’s not the premise here. What I am saying is that this is, in my estimation, the total amount of time that folks spend doing something, that to an extent can be made a little bit more efficient.
Obviously not all tab switching, and button clicking is bad, and obviously you can’t turn people into robots. But let’s imagine you can shave 10% or 20% of that number by identifying low hanging fruit and doing some training. That would potentially amount to $40,000 to $80,000 dollars in savings a year.Konrad
What do I mean by low hanging fruit? Let’s look at the most popular commands that people use, pick top 10, and train your staff to use these. It’s not realistic to replace all commands with keyboard shortcuts, nor would it be more efficient, but top 10 would make sense. Let’s have a look at that.
OK, this is something that we can probably work with. Top “spender” is the “Move selected objects or their copies” button. That’s easy enough, Revit already has a keyboard shortcut for “Move”, and it’s “MV”. Other popular commands are “Finish Sketch”, “Create Line” or “Create Aligned Dimension”. Again, some of these already have keyboard shortcuts out of the box. “LI” for creating lines, or “DI” for creating dimensions.
Clearly people just have to be reminded that these exist, and that they should use them. Let’s say that you pull folks into the training room, and just remind them that using keyboard shortcuts can be a little bit more efficient than poking around the ribbon. First of all, how would you know whom to train? Obviously not everyone is not using keyboard shortcuts for such obvious commands. We can get that information from Bimbeats as well. All we have to do is look at the same data per user, and we can see that there are 14 people that used the “Move” command over 10,000 times from the ribbon in the last year. Let’s start with that group.
You could also use this data, to analyze the efficacy of your training sessions. You could do that by looking at the exact same data but over time. Here’s use of the “Move” command over time by the “top” user from a previous table.
You could then using that trend data, figure out if training is changing behavior for people participating in these training sessions (of course if you knew who they were).
If training doesn’t prove to be helpful here, then I can think of a software solution to the problem. What if we setup a little “revit bot”, that reminds you that certain popular commands have keyboard shortcuts and that you should use them. We could set it up to get triggered after certain amount of Ribbon command clicks. We wouldn’t want it to be annoying, but let’s say that it showed a pop-up message when you used the Move command from a Ribbon Button, x-times a day. You could have it monitor use of other popular commands like “Finish sketch” or “Create line”, and suggest either creating keyboard shortcuts for them, or remind that some already exist like “LI” for “Create Line”.
Overall, I realize that we cannot force people to use certain workflow over the other. What we can do as BIM Managers, is to educate them, train them, and try to help them see the value in doing things differently than they might have been used to in the past. Maybe something like this is not that big of a deal for your company, but for a company the size we used for this post, saving 10 or 20% on a simple task like this, might amount to a sum of money that’s pretty significant. Tens of thousands of dollars can be saved here in a simple workflow adjustment.
Now is the time for a shameless plug. Two things:
- First, this analysis and many more are possible with a tool like Bimbeats. Go check it out at Bimbeats.com. If you like it, reach out to me, and I will be happy to schedule a demo with you. Here’s my calendar.
- Second, I am proposing a tool here, but unfortunately at the moment, it’s just an idea. Since I work as a consultant, and a software developer, if you think you would be interested in a tool like that, perhaps we can build it for you. Drop me a line at konrad [at] archi-lab [dot] net.