Jump to content
  • 0

Why we need a TeamWork system rather than Workgroup Referencing


Christiaan

Question

I?ve finally put a finger on exactly why I?d prefer an intelligent one-file teamwork system (aka ArchiCAD TeamWork) over a dumb multi-file system (aka Workgroup Referencing).

The inflexibility, the need to link files together and the need for preplanning when using Workgroup Referencing all culminate to provide a system that requires a lot of setup and no turning back.

What we really need is a system that?s flexible on the fly.

Take, for example, a simple scenario:

My Director is working on some planning-design elevations. He asks me to set the file up with Sheet Layers, title blocks, etc. and make some adjustments to some of the elevations. Meanwhile he is going to carry on working on one of the elevations.

We don?t want to split the elevations into other files because we don?t want the aggravation and we want the ability to flick through the layers and compare and edit each of them quickly. Speed and ease is of the essence.

A multi-file Workgroup Reference system does nothing for us in this scenario, where as a one-file system with intelligent management would mean, at the click of a button or two, he could work on the elevation and meanwhile I could work on the rest of the file.

The difference between the two ways is a matter of light years and I really don?t understand why they?re even mooted as being competing systems.

P.S. generally what we do in the scenario above is to duplicate the file and then copy and paste the edits once they're done. For all sorts of reasons this is less than ideal.

Link to comment

22 answers to this question

Recommended Posts

  • 0

Vectorworks desperately needs a flexible, robust and easy to use Teamwork system.

The current referencing system just doesn't seem to be able to provide that, and maybe as Christiaan has suggested we need to move to a one file system that has the ability to have multiple users working on separate project parts within that one file.

Such a system would allow sharing of all project information and not be subject to the resource conflicts and circular referencing complications that bedevil the curret referencing system.

Link to comment
  • 0

Christiaan

Both systems have downsides and upsides.

A one file system works well enough for a singular building but on a large planning project with many buildings and site conditions the one file system becomes burdened with immense size. A one file system has difficulty when individuals travel and have to work on a file as the merge data upon return to the office with a duplicate of the entire project has still not been fully fleshed out. A one file system is limiting in a multiple office location scenario working together on a project.

The positive to the one file system is the computer manages all the links and relationships in a holistic manner that can be seen in a browser of sorts. This alleviates the human management so inherent in a multi-file setup.

Of course the Multiple file Work Group Referencing has many of the same issues and more as has been pointed out.

If Vectorworks had an external data file that existed outside of any singular working file and managed all these file links on a project while allowin for multiple users to effect any one file concurrently we might have the best of both worlds?

Not sure at the present price point for Vectorworks that we are going to see any changes or improvements anytime soon.

Link to comment
  • 0

Goes back to your "Old File Opening" suggestion, Christiaan. A separate entity that doesn't clog up VW.

Looks like, yet again, NNA needs to investigate how others like Maxon in C4D solves these issues.

One Application with many Modules that Can work either Indipendently or Contemporaneously.

Problem solved!!

Link to comment
  • 0
I?ve finally put a finger on exactly why I?d prefer an intelligent one-file teamwork system (aka ArchiCAD TeamWork) over a dumb multi-file system (aka Workgroup Referencing).

The inflexibility, the need to link files together and the need for preplanning when using Workgroup Referencing all culminate to provide a system that requires a lot of setup and no turning back.

What we really need is a system that?s flexible on the fly.

Take, for example, a simple scenario:

My Director is working on some planning-design elevations. He asks me to set the file up with Sheet Layers, title blocks, etc. and make some adjustments to some of the elevations. Meanwhile he is going to carry on working on one of the elevations.

We don?t want to split the elevations into other files because we don?t want the aggravation and we want the ability to flick through the layers and compare and edit each of them quickly. Speed and ease is of the essence.

A multi-file Workgroup Reference system does nothing for us in this scenario, where as a one-file system with intelligent management would mean, at the click of a button or two, he could work on the elevation and meanwhile I could work on the rest of the file.

The difference between the two ways is a matter of light years and I really don?t understand why they?re even mooted as being competing systems.

P.S. generally what we do in the scenario above is to duplicate the file and then copy and paste the edits once they're done. For all sorts of reasons this is less than ideal.

I'm more familiar with Revit's worksets, so I think understand how a one-file system works. I'm not yet quite convinced though if this feature is better especially if the project involves just two or three people in the team. The file sizes can be quite enormous and there is still the need for preplanning with permissions assigned to team members.

In your scenario, why do you have to duplicate the file if you're using workgroup referencing? Why not just setup another temporary reference file and do your edits there? The project leader can then easily view this reference file anytime and just copy and paste when he approves it.

Link to comment
  • 0
Exactly. I'd rather keep the current system than have it replaced, but ideally one would have them both in use simultaneously.

Yes, despite how I titled this thread, I'd much prefer this too. As 1D2D3D_4D quite rightly points out a single-file/multi-file system may not be mutually exclusive.

I guess what I really meant by that title is that I don't want to be told by NNA that Workgroup Referencing is their answer to TeamWork.

Link to comment
  • 0
In your scenario, why do you have to duplicate the file if you're using workgroup referencing? Why not just setup another temporary reference file and do your edits there? The project leader can then easily view this reference file anytime and just copy and paste when he approves it.

To create a WGR in this scenario would have simply been an extra complication (involving browsing to the files, linking them, creating Viewports, etc.). You don't gain anything over and above what copying pasting from the duplicate provides, certainly not when your deadline is 2 hours away.

On the other hand signing into the file and choosing to work on the particular layer that this elevation was on would have been trivial.

Link to comment
  • 0

On the other hand signing into the file and choosing to work on the particular layer that this elevation was on would have been trivial.

I think I have to do some bit of research on how Archicad's Teamwork works. So what do you do when the team member who 'owns' this elevation layer is in a meeting and unable to give you permission to work on it?

Link to comment
  • 0
So what do you do when the team member who 'owns' this elevation layer is in a meeting and unable to give you permission to work on it?

In my scenario we wouldn't restrict access. There would be no reason to.

But there is! You can't have two people competing on the editing of objects: one pushing, the other one pulling.

Link to comment
  • 0

I guess what I really meant by that title is that I don't want to be told by NNA that Workgroup Referencing is their answer to TeamWork.

Catchy phraseology for something that allows Groups to Work on Multiple files Referenced one into another. It at the moment is just a very dumb computer Referencing as you point out.

For instance if you add classes in File A that is referenced into File B, File C and File D via Design Layer Viewports those classes will not Automatically be turned on in these other files until the other user activates them, that is if they are even aware the classes were added.

If in the same example above you rename all the Layers in File A then all the Design Layer Viewports are nothing but loci in File B, File C and File D making it virtually impossible for an average user to locate them for selection. One has to use either the Navigation Palette or the Organization Palette to turn on what in essence are the same Layers just with new names via an edit of the Viewports in the List. And this only works if you have named the Viewports to their purpose.

All human involvement and time for something that would seem that the computer should handle.

Maybe the one file system at present is the only way to handle this issue, but as in Multi File Databases, similar to FileMaker, one can segregate Data Sets into different files while each is connected actively updating as changes are made in each.

Link to comment
  • 0
But there is! You can't have two people competing on the editing of objects: one pushing, the other one pulling.

That wasn't quite the way I understood Ariel's scenario. The way I understood it is: what happens when a person who controls the permissions of a file is not available?

My response to that, in my above scenario, is that we wouldn't create that situation in the first place. Both my Director and I would have had supreme permissions.

Now, in the situation you describe, where someone has signed something out and then disappeared, I would say that's a management issue, and one we already have in networked offices today, where people leave files open on their desktop and nobody can access them. Or people take files/layers home to work on and then we need to merge them back into the project when they bring them back.

If they're in a meeting and they've left something signed out (or a "file open") in our office we would go to their machine and sign it back in (or "save and close the file"). Or we'd wait. Or get hold of them and ask them if we should save on close.

If they've signed something out and gone home (or "taken a file home") in our office we would either discard their changes and maybe try to manually merge them later or we would wait.

They're management issues that already exist.

Link to comment
  • 0
How about if VW had the ability to convert specific layers into WGR files? Would this work for you?

It would be a useful addition to WGRing for sure but it also highlights the inherent limitation of WGR, in that you're restricted to Layers. ArchiCAD TeamWork goes further than this as I understand it.

It also highlights a little the problem of file management. We move files around quite a bit to deal with current issue, options, work in progress, superseded, etc. This is a bad enough problem as it is and then we throw WGR into the mix and it can be a minefield.

It just all seems such an anachronism to me. Like we're stuck in some dark age of geek rule where we're all forced to use the command line or something.

Link to comment
  • 0

Maybe the one file system at present is the only way to handle this issue, but as in Multi File Databases, similar to FileMaker, one can segregate Data Sets into different files while each is connected actively updating as changes are made in each.

Exactly what I had in mind. WGR probably just needs some more intelligence to be aware of how changes in one file affects another. Seems much more doable IMHO rather than having to associate every single object, layer, class or whatever to a specific team member.

Link to comment
  • 0

It would be a useful addition to WGRing for sure but it also highlights the inherent limitation of WGR, in that you're restricted to Layers. ArchiCAD TeamWork goes further than this as I understand it.

In the case of Revit, yes it does go further. You can assign ownership of specific object types or groups of objects to a particular user. I've seen this to be more of a hassle than an advantage in actual practice though. (What the... I'm not allowed to move this wall?)

It also highlights a little the problem of file management. We move files around quite a bit to deal with current issue, options, work in progress, superseded, etc. This is a bad enough problem as it is and then we throw WGR into the mix and it can be a minefield.

As you already mentioned, this seems to be a very minor problem which you have to deal with in any system. You can always delete the reference links and have your one file can't you?

Link to comment
  • 0

Seems like a database type issue. A VW drawing is essentially a long list of individual items which have information attached to them (position, rotation, layer, class etc. etc) and WGR is acting like an old flat file db cross linking on lookups. The same data can be manipulated as in a relational db using the same rules (access, ownership, commit etc. etc) that regulate relational database use and have done very well for some time.

Specifically the data used in both systems (flat file & relational) is the same. The program manipulating it is different. In Petri's push-pull dilemma then Alice (who selected the object first) has control until she commits to a change and Bob (who would like to edit the same object) has to wait for that commit. This only applies to the base data (the objects); things constructed from them (viewports etc.) would necessarily be locked on individual modification - Alice can't work on the same viewport as Bob - but Alice could be editing a design layer that was relevant to Bob's viewport.

The open file dilemma would barely occur - only selected uncommitted data is unselectable elsewhere; it would either be invisible if mid creation or the unmodified version would be visible but unchangeable until the "rogue user" had committed to their changes or discarded them. This can be dealt with on a time basis with manual update or other more rigorous methods.

Database design has met & dealt with all of the difficulties that arise with a number of simultaneous users. The large file problem is a question of perception. The total data stored in a relational db will be less than in a flat file system due to less duplication but it can be perceived that a monolithic vulnerable file is generated compared to a large number of dispersed & therefore safer files. This is not the case as the relational file is best viewed as a container within which there are a number of individual tables of data which are individually no less secure than a dispersal system.

VW should be relational. This is old tech, a known path. I've been doing database work on these principles since Infostar in the early 80's and it's amusing to see flat file structure still in use, much like coming across Filemaker 5 in the mid 90's when everyone else had been relational for many years; thankfully Filemaker is now somewhat more modern.

Link to comment
  • 0

Charlie,

Very good points! However,

Database design has met & dealt with all of the difficulties that arise with a number of simultaneous users.

I'm not entirely convinced. CAD is a different concept in many ways, eg. as comes to the arbitrariness and frequency of user operations and especially in VW and other programs with object-verb -syntax and selection of a number of objects.

(I've dabbled with databases since the mid-1980s.)

VW should be relational. This is old tech, a known path.

Indeed.

BTW, I think that VW's layers are lists of objects within the document.

Link to comment
  • 0

Morning Petri,

Yes, it is arguable that multi user databases are trouble free, however I would say that there are principles that could be applied; whilst CAD is necessarily a non linear environment and data entry into a database extremely linear there are essential similarities.

Multiple object selection and object verb syntax are not too awkward, this is after all what SQL databases are all about.

Layers are indeed lists of objects, one layer has many objects (one to many) rather than the layer being an attribute of the object, which I would guess is how it's done under the present system. (sort of an artificial many - many which is a logical black hole)

Excel has a database foundation and whilst in many ways it's an absolute horror there is a hint there about data manipulation in a non linear environment, especially with VBA and the limited object orientated programming that is allowed.

Thinking about how to implement this is a good way to waste a morning if you find this sort of stuff as interesting as I do; unfortunately I can't see a way to do it without ditching 9/10ths of the app and starting again - that's the sort of statement that creates awkward silences at meetings.

Charlie

Link to comment
  • 0

Multiple object selection and object verb syntax are not too awkward, this is after all what SQL databases are all about.

Maybe not. On the other hand, the current schema of layers as tables and only one user at a time with editing privileges to each is, I think, quite simple and sensible. With better management tools (project structure, privileges, ability to see who is doing what and to move to any layer of any file easily etc.) and really robust mechanisms for all this might do the trick.

Link to comment
  • 0

I need to comment on this because I have used Revit's multi user system with 5 of us on it and it worked flawlessly. VW's workgroup referencing is lacking. Most architecture firms I know of have more than one person working on a file and our office is very disappointed with the workgroup reference feature. VW seriously needs to look in to upgrading this option.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...