Hi Heber,
I need to bring to your attention a significant problem we're encountering with zzTakeoff when multiple users are working simultaneously. The current setup creates a "tug-of-war" scenario where if one user turns off takeoff layers, it inadvertently affects other users' layers. This results in a chaotic situation where users return to their files only to find them altered because the program only supports a single, synchronized view for all parties.
This issue is extremely disruptive and hampers our workflow significantly. I understand that this is a complex problem, but I am keen to know if there is a plan in place to address it. As it stands, the only workaround seems to be preventing multiple users from working on the same file, which is far from ideal.
Looking forward to your prompt response and any potential solutions.
# Mutiuser multiplayer mutiple users.
Thanks for the input. We'll discuss how to address this. I think these are areas we can solve and make zzTakeoff stand out. We would have to store hidden/visible per user to solve this, but it should be do-able.
Another idea, is we could store hidden/visible locally in the browser instead of in the database at the server. The advantage to this is that there's no conflict whatsoever between users, but the disadvantage is that if you have multiple computers you switch between, then each computer would have hidden/visible state separately. This same concept would apply to expanded/collapsed state of folders.
Kyle would you mind sharing how your team does their collabs?
On my end, we usually split up things by item type (they'll takeoff items that involves linear objects like walls/windows, I'll do counts & areas, etc) and usually we start from different floors, so there really isn't much disruption when we're hiding items. Also we place all items into takeoff folders right from the start so that when we need to hide objects, only certain types will be hidden, or only 1 page will be hidden, etc.
I am curious how you guys run your collabs because maybe you have a better strategy than what we're doing here?
If you'd rather not go into that I understand
Jes great question. We don't do collaboration right now because we are on OST living in our desktop silos, (Now that the tech is here our folks don't know what there missing, hence why I'm here!)
Kicking this tool around to see if its feasible to scale at at 200 estimator vertical GC. We do a ton of Conceptual estimates, the 2nd project I was using ZZ takeoff on we only have a few sheets for a 20 story building. For example the first thing a user does is generate the gross area, then we get into measuring the area's of the rooms and various widgets. Things get on top of each other quickly and depending what your doing you need to hide certain things. We grouped the folders by user in my example, so each person could quickly turn on/off their stuff, so it was fine if it was one-at a time. To your point we need to figure out a better workflow for sure, as we have never had this ability before. We have 2 templates in ost, one per the below picture, the other is the inverse of that setup by UF3<trades. I know Heber is working on default WBS "sorts" that are more ridged than folder structures that I"m excited to see, for example we would not need 2 templates anymore and could simply right click sort by Trades first, or right click sort by UF3 first, or right click sort by takeoff type (area/length/count) or right click sort by any grouping you establish.
Again, this problem might also be resolved with the use of “Takeoffs On Overlays Instead of Pages.” Each estimator could be working on their own transparent overlay over particular drawings/pages, and the sum of the overlays would constitute the whole. In this case we don’t need to store what items are visible/not for each user…just which overlays are visible for each user. This would be like sharing views or screens except that they can overlay each other.