Monday, June 23, 2008

Local Files and other Workset Thoughts

I have been advocating a number of workset habits for many years now. Do a search on this blog and see how many posts there are. Be prepared to read for a bit if you haven't already.

One of the things I've always suggested to people has been to automate the process of copying a local file and renaming it etc. This makes it easier, safer and predictable for the end users and tech support staff alike. Lately there has a been an "explosion" of firms doing this with more and more sophistication. The firms I first started pushing this idea on have nearly all finally done so or have been for some time now. In addition several members at AUGI have contributed their tools for others to use.

David Baldacchino has shared his both at AUGI and on his blog. David Kingham has shared his at AUGI too, in the same thread. You need to read through that thread carefully to find the final versions. Their contributions have both been built on AutoHotKey.

This is all great! Great for the general Revit community.

However I think it is long overdue that the Revit development team address the whole issue themselves. A Revit user once described the whole workset process as fragile. I first thought, "No! It's not fragile", but the word and its meaning slowly sunk into my pea brain. I've come to realize it is very fragile. Too many ways to screw up. Too many rules. Too many messages that require turning on our thinking cap or at least distracting us long enough to focus on Revit's needs instead of our own.

I'd like to encourage the Revit team to take a hard look at the entire workset workflow again now that they have so much more information available. Revisit from the typical user's perspective. Too much of software is written in such a way that it appeals to "techy" folks instead of people who just need to use the software to get something done. They want to know as little as they need to get "it" done!

Local Files, phooey. Who needs them? Why do we need to care? Make it invisible to us or at least invisible to the end user. Let the techy folks know what is going on behind the scenes.

Permission...we need to let people who know what they are doing do it and keep others out of harms way. A user permission strategy would provide that. Let us define who is a magnetic project manager (the person erases hard drives when he walks by) open a project but don't let him/her check stuff out or change things. Let us identify who the power user(s) is/are.

Make it easier to abandon changes. The need to close, don't relinquish, don't save, open the file, relinquish all too many clicks and people start to look crosseyed at you when you explain why and how.

A friend half jokingly once told me that he believes that Autodesk employs a person identified as the "Complexifier". This person takes simple things and makes them complex to appeal to the techy in some of us. It is time that that the "complexifier" spends some quality time with a "simplifier" or two or three.

A long time ago I worked as a lighting tech for various touring bands. Every now and then I'd be standing behind the lighting console during a show and a fan would come up to me and tell me, "To turn up the vocals, NOW!" I suppose I could have told the fan, "I'm not the sound guy, he's over there!" Instead I'd just reach over to another part of the lighting console and push a slider up to full. Naturally this fan wouldn't notice the light coming on. Then I'd say, "Is that better?" The response was always something like, "Epithet Yeah!, COOL!. They'd go back to their fan friend and tell them they got it sorted.

I'm not suggesting we all need to be clueless and easily fooled but Revit ought to always strive to be pretty darn obvious. I know that the team does. I'm writing to encourage them to continue to "endeavor to persevere".


Unknown said...

Hear, hear!!! I too have been using the world “fragile”, not that the whole concept sucks, far from it, it’s just awkward to set up. Once setup, it’s a fantastic way to work. However, as you have highlighted it should be transparent to the user and easy for the cad manager or bim manager to implement. In its present state it isn’t, which is a shame because in programming terms this shouldn’t be difficult to do. Having seen the work that Dave Baldacchino and others have shared, thank goodness for there ingenuity, Autodesk should take note. It’s funny really, because when I demonstrate and train Revit, new users just love the power of the application and without doubt the project collaboration question will always come up. When you demonstrate what you actually have to do to set this up, you can see their faces drop! For the hardcore Revit user who has gone through the pain of implementing the process it becomes second nature, but in reality it shouldn’t be as hard as that. Also, “permissions” are essential! I have seen large scale government projects that have not gone the Revit route because Revit lacked permissions and security. This is must as the product moves forward. Let’s hope Autodesk are listening!!! ;-)

Nicholas Iyadurai said...

You are right. Worksets are a pain to our users. They are kinda like Autocad layers! (you have to be in the correct layer to draw, etc.) Our users seem to be ok to wait for 5 more seconds than to be worrying about adding elements in the correct workset, etc.

GeoffB said...

I too am glad to see this being discussed. Teamwork issues are critical to any shared database solution.

The inevitable improvements to Worksets should be made through the lens of collaboration across the internet via typical broadband connections. Clearly lots of optimizing will be required to reduce the volume of redundant data. But that's what Riverbed appliances do now and they are only working with the file data, not the source code.

As the internet continues it's spread toward ubiquity BIM can become a completely web based application. A service remotely hosted from a secure data center. Hey, we rent Revit as it is, right?

Ultimately this topic should be broadened to included the collaboration between disciplines. If the BIM is truly shared (both technically and legally) then doesn't it make sense for everyone (including builders and owners) to interoperate directly within a single model? The client-side tools might differ but the database is the same.

Such a vision is based on a completely different business model than the one under which Autodesk currently operates. But other companies are aggressively developing these types of capabilities. I suppose when demand for this is undeniable Autodesk will just buy the company with the most promising technology and bolt it onto Revit. Unless of course that company is Google.

Geoff Briggs,