Project Team

These all look like reasons for Takeoffs On Overlays Instead of Pages. Each estimator can work on their own assigned divisions/pages/subsystems/items/anything either individually or with others. If the overlays are all related to each other (they overlay the same drawings/pages) then they can overlay each other allowing you to see what another estimator may be doing OVER the same drawings/pages.

Additionally, if we maintain and catalogue the blueprint separately on a Blueprint Tab, there should be no need to tamper with a blueprint during takeoff—unless something about how the print was catalogued needs to be corrected. The print should remain unaltered.

Hi there! 🌟

The Current Context Menu for Takeoff Totals is as follows: 📋

The Mock-up showing how we understood your use case: 🎯

Thanks for raising these important collaboration challenges! 🙌 We're excited to share how our new access control system addresses your scenarios:

1. For simultaneous work issues: 👥

• Estimators can now make their takeoffs "Private" while working, eliminating the need to hide others' work
• Lead Estimators can toggle visibility of team members' work as needed
• All work happens on a single set of drawings, improving efficiency ✨

2. For project management overload: 📊

• Single project setup with shared drawings
• No need for multiple project copies
• Lead Estimator maintains one master project with controlled access 🔑

3. For resource duplication: 📂

• One set of drawings shared across the team
• Drawings uploaded once by Lead Estimator
• Team members work on the same documents with individual access controls 🤝

Technical Implementation: ⚙️

• Real-time updates maintained through access-level controls
• Deletion permissions restricted to Job Administrators
• Built-in conflict prevention through private/team/public access levels 🛡️

Have we captured your core concerns accurately? 🤔

We'd love to hear from other estimators about their team collaboration needs as well! 💡

This feedback will help us prioritize development and ensure we're building the most valuable features first. Are there other collaboration scenarios we should consider as our Developers assess the current architecture of zzTakeoff? 🚀

Please share your thoughts and experiences in the comments below - your input directly shapes our development roadmap! 🗺️

#TeamCollaboration #Estimating #UserFeedback

@Sam that's perfect. This makes it a lot simpler if you guys end up expanding your application to compete with applications such as Procore since I believe RFI posting use the same concept and so does Bluebeam studio sessions.

Chiao, Sophia

If you have any screen shoots from Procore and Bluebeam studio showing how they address the issues you raised this will be very helpful in our considerations.

@Sam

Unfortunately, I do not have access to Procore anymore. We've moved onto a worse application :sad: (it takes so long to load the drawings, that I'd rather not attempt to open the web application). Below is an example of a Bluebeam session. There's the Projects side panel, the folder structure for the project, and then the drawings window. When a user posts a comment or RFI, it probably captures pretty much the same information as your Takeoffs table and just has some logic to query the data on UI/UX via Markups List and Filter List. The only additional implementation you guys might need is adding another database or table to hyperlink to a table that shows all the RFIs and a general template for RFIs (title, problem, tag, etc., probably most similar to how Microsoft Azure has bug tickets set up). From @Darin's demo today, it seems like zztakeoff has already implemented some AI generated hyperlinks between the pages of a document, which is conceptually not that different...)

@John

Correct. I think we're talking about the same thing, but simply using different terminologies. I like the idea of a blueprint tab, but would like to also be able to duplicate it in order to deal with drawing progressions. I've run into a lot of projects from preconstruction to end of construction where I am constantly doing drawing comparisons that I have to create progressive estimates for the client as well as change orders with supporting takeoff. For example, one of the projects I am working on, I did flooring takeoffs off a 50% DD set, but the client now wants an updated estimate based off the 100% DD set. In order to not redo all the work, I'll duplicate my 50% DD drawings and overlay the 100% DD drawings to quickly spot the differences or audit trail. In Bluebeam and OST, we call this the Overlay Image or in Adobe creative suites or Procreate, the Masking layer. Below is an example of what that looks like in OST when we use the term Overlay:

Sophia,

What you are describing is exactly the reason for the takeoffs to be on an overlay. When you get new/updated/revised drawings/pages you just change them out. Slip the new pages under the existing takeoffs. (No need to copy takeoffs from one page to another, hoping that everything is correct, and no need to show a jumble of ghost pages to show that you are in fact using the most recent print.) OR copy the overlay and takeoffs to create a fork with new reference pages.

Have you ever received a truss layout that showed the blueprint? I haven’t. This is because the truss layout is OVER the print…not on it. If the print is revised, the designer simply loads the new print underneath or as a ghost layer and changes the layout over it. The design is independent of the print.

@John

So when you guys get a pdf, you guys do your takeoff on the different layers instead of on the flatten sheet? And did you guys use BlueBeam to do this before?

I’m about to do a takeoff on every subsystem for a large project and I know the drawings will change in a couple months, so understanding the way you guys are doing takeoffs might help me out tremendously (since I would like to save some time haha).

I'd be interested in this answer as well - we do similar to how Sophia is describing but intrigued by yours John. Only issue i see is how to go back to review your previous takeoffs at each milestone set. You'd almost need to be able to have a record blueprint set for each time you "publish". The working set would have all the other sets with underlays to turn on, turn off.

@John

Would you share examples of software/applications where you've seen overlay functionality work well? This could help us understand the type of implementation you're envisioning, similar to how John mentioned truss layouts over blueprints.

@Chiao, Sophia

Are you envisioning overlays similar to CAD layers, where each takeoff Grouping (e.g. Based On Work Breakdown Structure - "WBS" or Cost Centres etc) could exist on its own layer while maintaining alignment with the base drawing?

Note: This is just an early concept we're exploring - we're eager to hear community feedback to help shape any potential future features. 🔄

So kind of like this. The lead will upload the drawings and create subsystems and assign team members to it (similar to BuildingConnected) and then when people are working on it, they are only working on their own little ecosystem. Anyone can click into the rest of the subsystems or follow someone, but not necessarily have access to make edits (similar to Miro).

As for overlays, the company I work for uses it to track changes in drawing sets (see the blue and red image I posted above). We manually have to adjust takeoffs, but it's also for our own QC purposes to do so. But it is best explained the way John did. Essentially, we fork the master and replace some images to redo some takeoffs.

I guess you can think of everything as a fork haha. You essentially have the Lead create a master branch (with set images) and all the team members are forking it and creating their own branches off of it. And once all the team has committed and pushed their branch, it creates the new master branch that we eventually fork and have the Lead replace the images.

I currently use PlanSwift but have been working to revamp pretty much everything that I have access to. This is one of those things where I don't quite have access to everything I need to make it work the way I envision it. The workaround, however, is to add a blank page to a job and then add all the blueprint pages that you want to reference as overlays (in the original sense). Therefore, I am not accessing the layers of a pdf; rather, I am arranging pages as layers of a base, blank page to be viewed individually, together, or not at all. This is how I showed it in my overlay concept video and why I was able to show just the takeoffs at the end. What stinks is that PlanSwift won't let you place folders as subitems of pages under normal circumstances, so it gets very clumsy. If this was possible, then I think I could implement this in PlanSwift properly.

What gave me this idea was precisely that I wanted to save time during revisions, because it is possible to spend as much time on a relatively small revision as a whole new project! So if I could keep my takeoffs intact, without having to find, sort, separate, copy, and paste them to a new version of a page, then all I would have to do is adjust the takeoffs as they already exist--provided I can see the new version of the page.

Further inspiration for this was the need to implement an elegant work breakdown structure that had implications of how a structure actually comes together, so the takeoff could be easily used for shipping materials. The desire was to implement what I am calling an "overlay" as a level of a building or as a major structural system of a level of a building so that elevations could be used to structurally order the takeoffs for obvious shipping order--not to say anything of automatic calculations for wall heights, total stair rise, etc.

On occasion, I do use Component Solutions EWP Studio which is primarily geared toward designers of engineered structural systems. When you start a new project, you have what is essentially a blank page. You can draw walls, header, joists, etc. You can set parameters for the level that this blank page represents. You can import a plan image at any time. You can add new levels with new plan images, and you can ghost other levels to see items on them. In a nutshell, the design is drawn OVER the plan and can be removed altogether when printing the layout for the design. I would assume MiTek also works this way.

The way I see this being implemented in zzTakeoff is that an "overlay" will act as part of the work breakdown structure. An overlay could have drawings/pages as referential subitems (you can think of them as links to the actual drawings/pages that you can catalogue/study/markup from the "Blueprint" tab). It could also have takeoffs as subitems. While working on a particular overlay you can toggle the visibility of the referenced pages or takeoffs however you like. Overlays, along with their referenced pages and takeoffs could be copied and pasted, thus forking the work breakdown structure for an option, a version, or a revision. When an updated print is provided, again it is catalogued via the "Blueprint" tab and the new drawings/pages are added to the EXISTING overlays corresponding to their respective predecessors.

Hi Sofia, interesting that you are calling it "fork" 🙂 We have discussed internally a concept for "Spaces" or "Shared Spaces", and we were tossing around the idea of calling it a "Branch" or "Fork" (to satisfy the developer/version control side of us). We settled on "Space" for now since that term is used by many leading apps, but it's not final.

The idea is that a "Space" would act as a sub-project (or could be thought of as a "super-folder") that utilizes the same plan images, but has a clean slate for takeoff & annotation data, reports, etc. Each project would have one "Main" space by default. Additional spaces could be created for each collaboration group, or just simply to isolate a group of takeoff data (when folder grouping is not sufficient). Each space's data would live in a separate "bucket" with it's own permission control, but still part of the same project. When we allow more sharing options we would allow sharing at the "project" level, or at the "space" level. When we allow chat options, photo sharing, etc. those would be isolated per space along with the takeoff data. It's kind of a way to create a "new project" with it's own permissions without having to re-upload the images. I could also see individual users creating spaces for "what if" scenarios when they don't want to interfere with their main takeoff.

We could build a way to merge contents of a space back into the "Main" space, also, or ways to report that span multiple spaces if a user has permission to all of them. I envision there would be a dropdown at the top of the screen to switch spaces, in a similar way that many version control apps allow switching between branches or forks.

Idea for Spaces (I just realized I had created this post, but forgot to publish it).

Example, if the user is in the "Main" space and has done some takeoff:

If they click the dropdown they get a list of existing spaces or an option to create a "New Space" ("Test Space" in this example), and they get a clean slate, but the same plan images. This isolation between spaces could be used for many purposes, but the primary would be for separate collaboration groups, or the ability to do a separate takeoff and optionally merge it into the "Main" space.

Another thought we had was to call these "layers" instead of "spaces", which would work well from the graphical side (most users understand how layers in graphics apps work), and we could show/hide items in those layers as a group easily. It is a bit if a misnomer if we start using layers (instead of "spaces" terminology) to isolate chat discussion, photos, files, and other data, but is another possible term. No matter how we do it, there will be some terminology overlap. You could have one layer "active" which all new takeoff / annotation items would save into, but then we could allow show/hide each layer individually. The nice thing here is that it separates show/hide of layers from show/hide of takeoff & annotation items, so users aren't stepping on each others toes hiding/showing items, to get them out of the way, they just hide layers they don't want to see. For us to track/save layer visibility separately "per user" would be much easier than tracking visibility "per user" for every single item in the takeoff.

"Main" layer active:

Spaces

Layers

Forks

Branches

Buckets

Regardless of what we call it, it will be useful for segregating data within the project. We will for sure be adding version control for the pages so that the main project always has the latest, and you can see version history for each page: V1, V2, etc.

@Heber

Yes, I think if you are able to separate each takeoffs based on the defined subsystem set by the lead works well. Since I can see an estimator getting assigned building specialties and wall finishes at the same time. This will in the long run help you guys in not having to load all takeoffs and images upfront and helps estimators with separation of issues.

I think one of the biggest issues I have seen in the construction industry is not being able to pass along information seamlessly from pre-construction to construction. It’s like how in developer world, a developer will create a component and instead of the team reusing it, another developer will spend time building the same component with the same functionalities. 🤦🏻‍♀️

^This.

The problem is that we are all spending time putting together representations of specific blueprints and not constructing models of the building to be. Architects and designers can be as creative as they want, but all buildings are pretty much the same. Therefore, the takeoffs need to model the building to be and be separate from the blueprint altogether. This way, when there are revisions or different versions of the same house the takeoffs can be quickly adjusted to suit the requirements of the design.

Have you ever done takeoffs for different versions of the same house? It’s infuriating to not be able to use your previous work effectively and efficiently.

Heber,

So is this “layer” idea analogous to the “overlay” idea that I am advocating with the takeoffs being separate from the blueprint pages? Or are the takeoffs still on the blueprint pages?

@John

I think Heber's idea is the same as yours. But just to be sure, here's what I've interpreted from all the different terminologies we've all used so far:

Blueprint = The drawings that the designers are giving us

Overlay = what we are using to compare different drawing sets

Subsystem = the different "trades" that are used for building (structural steel, site utilities, paint, terrazzo, etc.)

Master Branch = the project created by the Lead Estimator with a drawing set

Fork = Creating a NEW blank document/sheet in the project that estimators can work from

Branch/Layer = Subsequent blank document/sheets within the Master Branch; Different blank document/sheet that estimators can use for Quantity Surveying

I would refrain from using the term spaces in quantity surveying because we use that term a lot in relations to rooms or departments within a building.

Thanks for all the input. Good info and insights.

@Sophia Regarding your comment about reusable components above, I agree. There's so much inefficiency and data duplication, and the whole industry needs to think more like programmers 😁 (haha - coming from a programmer).

@John In a way, yes, but I would envision that area items, linear items, etc. still have a "home" on a specific page. Our data is "above" the page, so there is nothing stopping us from showing some kind of layering system and allowing users to stack pages and takeoff items how they wish. But, if we create an actual "layer" entity in zzTakeoff, I think many takeoff items could live in that layer as a group similar to a "layer" in most CAD or PDF files (so we can show/hide as a group). It could be that we're just using different words for the same thing. When I think of "overlay" I think of stacked plans on top of each other for comparison, but technically all of these items are overlays, layers, etc. There's a lot of terminology overlap. It's mostly just a matter of making it user friendly. What you are describing is very powerful, but may be over the head of the average user, so we just need to make sure the software is easy out of the box, yet very powerful under the hood for advanced users.

@Sophia Thanks for the additional comments. I think we're on the same page. We're discussing terminology internally, so some of the terms may change a little, but I think the gist of what we're trying to accomplish lines up. It will take us a little time for the software to "evolve" into having all these features. We will probably start with some layer capabilities and expand from there. I think adding layers first will give users the ability to not "step on each others toes" (hopefully solving the primary issue above) while doing takeoff, and isolate the takeoff into visual buckets with the ability to show/hide layers as a group (and we would track visibility of layers separately per user - if I hide a layer, it's not necessarily hidden for other users).

Thanks again for all the detailed technical discussion here.

Heber,

Why not have the takeoffs live in the layer (to use your terminology) and have the blueprint drawing/page have a home as a reference for that layer?