Presented by
Collaborating with CAD data sucks. In fact, you told us it’s the third most annoying thing in CAD back in late 2014. Onshape wants you to think they’ve solved it. Have they, really? Let’s think this through.
Spoiler
Onshape makes collaboration better in some really obvious ways, but also in some surprisingly powerful under-the-hood ways. In fact, it makes us wonder how we lived with file-based systems for so long. If Onshape isn’t in your 3D toolbox yet, it should be.
The problem
There is currently no good way of working collaboratively with file-based 3D CAD data.
When you think “collaboration,” you probably think about the real-time kind of collaboration–engineers and designers working on the same project at the same time. File-based CAD systems don’t make this easy, but do have elaborate mechanisms for making it less painful, and every office has its own rules and best-practices for coping with these problems.
Real-time collaboration in CAD is limited to over-the-shoulder interactions with one person driving and the other person pointing, hand-waving and scratching their chin-skin over your keyboard. Maybe, you’ll even have another party included via Skype screen-share. Add incessant interruptions and you’ve got a pretty good picture of what it’s like to work in a file-based design office.
But real-time is actually a small part of the problem. Collaboration is actually much more a problem of data management, and this is where things get nasty.
As an industrial design consultant I’ve worked a lot of places over the years. I’ve worked in big corporations running big PLM systems. I’ve also worked with smaller outfits using byzantine file-naming conventions and LAN-based file sharing, even Dropbox. At Mechanical Color I’ve managed projects using GrabCAD, Box Sync, and even a shared fra.me session for a cloud-ish 3D modeling experience. They all leave much to be desired.
You know the PDM process. Check out > open > save > close > check in > repeat, ad nauseum. And, oh fooey, that one guy forgot to check his stuff in before heading off on vaycay. (Facepalm.) PDM is not a collaboration solution, it’s Mentos in your productivity Coke bottle. The sticker-price is one thing, but let’s not forget the IT overhead for buying/running/maintaining/troubleshooting in-house servers, training employees, and an infuriating lack of nimbleness during rapid design iteration (all that checking-out-and-checking-in is a major creative buzz-kill). It’s a headache for enterprise, a nightmare for small and medium businesses, and a non-starter for indy operations. There’s a reason that after nearly a decade as a professional design consultant I still don’t use a CAD PDM system, and I don’t regret that decision.
Smaller shops, if they’re really savvy, might use a lighter, cloud-based PDM solution like PLM 360 or GrabCAD. Both are compelling, but ultimately disappointing. Managed cloud solutions help with the IT overhead problem, and have some other nice advantages over a private servers for ease of collaboration and administration. Still, the problem of conflicts: when two people make conflicting changes, somebody goes home in tears. It also doesn’t solve revision control problems beyond simple, explicit, linear versioning, and it does nothing to solve software version compatibility problems (see below).
Most smaller shops, in my experience, just use good ol’ LAN-based file systems and some kind of filing system for keeping track of what belongs to whom. Let’s not even talk about naming conventions. And yes, there are workarounds and best-practices for making file-sharing less painful–I have my own, and have promoted my own ways of working around these problems over the years–but sharing data in a file-based system is inherently problematic. It doesn’t matter how fastidious your process, nor how draconian your enforcement: file-based systems will eventually let you down.
Oh, and let’s not forget about version-compatibility. Most of us are forced to keep lots of installs around: I have SolidWorks 2013, 2014, and 2015 on my machine for various clients. If somebody with 2016 opens your 2015 file and hits save, suddenly that file is rendered unusable for 2015 users henceforward. Believe it or not, forward compatibility can be just as bad. Dirty secret: the only foolproof way of opening a 2005 file in 2016 is to first open it in 2006, then 2007, then 2008… ugly.
Enter Onshape
One of the things we love most about Onshape is its ability to make incredible feats of software engineering look effortless. On the surface it looks like, well, CAD in the cloud. And it is. But that’s not the whole story. Take, for example, collaboration.
It’s easy to think of Onshape as just another 3D modeling software you view in a browser instead of a stand-alone app installed on your desktop. That’s wrong. Onshape is something entirely different from file-based CAD in one monumentally important way: it’s not file-based at all. Each Onshape project is an entry in your database, and that database tracks each and every tiny step you take as you work. Each step is stored as a Microversion, and there’s one of these for each and every undoable action you perform in Onshape.
“This is how Onshape allows several users to work simultaneously on a single project: each discreet user action is tracked and merged to the project in real-time.”
But that’s going to get annoying, right? Well, ideally you would want some way of cordoning yourself off to work in peace until you’ve solved the design problem. You want to create your very own duplicate of the current working project, mess around with it until you’re happy, and then send the changes back to the main project. We do this in Onshape using ‘branching’ and ‘merging’.
Concrete example: Last year I was designing a housing for a coffee maker, and we were working on the shape of the carafe lid. We’ve had a meeting, and thought up five different ways the lid might look, and we needed to prototype each one before selecting a direction.
I did this in SolidWorks by saving five separate copies of the carafe sub-assembly using Pack-and-Go and a naming convention (carafeA, carafeB, etc), then model the new designs into each. After prototyping, we decided that carafeB was best, so I then manually ran a Pack-and-GO of that design, removing the naming convention, and then re-inserted it into the main coffee maker assembly.
That process was not only a mess of clerical Pack-and-Go monkey-work, it was also very limiting. What if the correct solution were actually a combination of designs A and B? I would then have to do a third Pack-and-Go, carafeC, and then manually re-model the best features of designs A and B. Then, as before, I manually re-export and re-import the result into the main assembly.
The above isn’t hypothetical: it’s the actual process I use when designing a product. I’ve done it with coffee makers, faucets, flush valves, headphones, toys, and robots. It’s horrible.
Onshape makes this process laughably easy by comparison: from your main assembly, just click “Branch” to create design branches for designs A, B, etc. When you’re done, just merge the branch you want to keep back into “Main”. If you want to combine two of them, just merge them both. Don’t like a feature from one of the designs? Remove it. Want to combine the benefits of A and B? Merge them. It’s lovely.
Not only is this straightforward from a process standpoint, it’s also liberating: each and every step in your process has been logged for all eternity, and you can always go back if you need to. Most importantly, it’s collaborative: since I no longer have to fear accidental conflict with other users, I can have multiple designers working on a single problem at the same time. We find solutions faster, and merge the best ones into the main design.
On the real-time side of things, you can even click a collaborator’s name to see exactly what they are seeing in real-time, making pointing, hand-waving and chin scratching unnecessary. If I want to show my client a design feature, I don’t have to email screen grabs with red arrows pointing to things; I can just share the document and show them exactly what I mean. At Mechanical Color, my regular collaborators are in Virginia, Boston, Portland, London, and Estonia, and my biggest clients are in Seattle, San Fran, LA, and Chicago. As far as I’m concerned, the sooner my team can use Onshape, the better.
Still need convincing? Go try it now to see what I mean.
Five reasons to try Onshape
If you haven’t signed up for Onshape, shame on you. Drop what you’re doing and go sign up. A few reasons:
- It’s Parasolid mechanical CAD, it’s free, and it takes like 10 seconds to be up and running. (Yes, that’s three reasons.)
- Collaboration in real-time with teammates and clients
- Branch and merge design ideas with reckless abandon
- Present designs to remote or mobile clients in real-time
- Seriously, there’s no downside. Just do it.
Interested in learning more about how Onshape collaboration works? Then this video is a must watch. It breaks down the simultaneous editing, real-time updating and commenting that make it such a critical tool to the product development process.
The Follow Mode in Onshape allows simultaneous viewing and editing of the model. It’s really a button click to start collaborating on the design.
