Blueprint Tab

Thank you for this detailed feedback about blueprint organization and workflow. To help us understand your suggestions better, could you clarify a few points?

1. For "Takeoffs On Overlays Instead of Pages" - are you suggesting separate layers for measurements vs. blueprints?
2. Could you share any screenshots or examples showing your ideal Blueprint tab layout and workflow?
3. How do you envision the AI detail/section finder working across multiple tabs?

Your suggestion about separating markup/notation tools from takeoff tools is interesting, particularly for individual user notes and dimensions. If you have any visual examples that demonstrate this concept, they would be extremely helpful.

This kind of detailed feedback helps us improve zzTakeoff. We appreciate you taking the time to share your ideas, and any visual examples would help ensure we fully understand your suggestions.

Hi Sam,

1. See “Takeoffs On Overlays instead of Pages” https://www.zztakeoff.com/app/default-workspace/community?postId=Y2omYrvWa4NpyE5cg&channel=feature-requests

I will get back to you on 2 and 3.

3. The way I usually work, I will have takeoff software open on one monitor with only the pages I need to perform the required takeoffs. On a second monitor, I will have a pdf viewer with the complete blueprint for reference. However, if there was a blueprint tab then I would be able to use that in place of the pdf viewer on the second monitor in a separate instance of the browser.

Now, as stated earlier, at the beginning of a project you would import your print and other required layouts. Immediately after, you would land at the blueprint tab so you could prepare for takeoff. You name, tag, and organize the pages with the help of AI. Further, if possible, AI tiles the pages by the individual drawing. Once tiled, AI should be able to help name, tag, and organize the drawings. Then make any corrections if necessary.

Now you have a blueprint that is completely catalogued by drawing. This is now your reference for an AI search function that is instantiated from the takeoff tab. Simply highlight the mention of detail 12 on page A9 during takeoff and select “Go to…in Blueprint” from a popup. Then you are taken to that drawing in the blueprint tab based on how it was tagged. This should work regardless of whether or not you have it open in another browser tab or instance. But in my case, it would take you to the detail drawing on the second monitor.

Notice also that the blueprint tab may eliminate the need to have a dozen pages open in different browser tabs, since the blueprint will be easily navigated from the blueprint tab even if operating entirely in one browser tab.

Does that clarify things?

Hi John

Thank you for providing that detailed clarification of your vision for the Blueprint tab functionality. I now better understand how you envision this working:

1. The Blueprint tab would serve as a complete reference viewer, similar to having a PDF viewer open on a second monitor, but with enhanced AI-powered organization capabilities.

2. The workflow would be:

  - Initial import lands you in the Blueprint tab

  - AI assists with naming, tagging, and organizing both pages and individual drawings

3. During takeoff work, you could:

  - Use "Go to...in Blueprint" from the takeoff tab to quickly locate referenced details

  - Have this work seamlessly whether using multiple browser tabs or a single tab

  - Navigate to specific drawings based on their AI-generated tags and organization

We're considering the practical implications, Technical Requirements and trade-offs of implementing this functionality.

Would other users in our community find this workflow helpful? We'd appreciate hearing your thoughts and experiences with similar reference workflows during takeoffs.

Here is a Mock-up to try and visually communicate what you are proposing:

I'm thinking "Plans" may be a better tab name, but I'm liking the general idea. Procore and Stack also have similar tabs for management of the plans with large thumbnails, etc.

Here is an amended Mock-up with suggested Changes

I don’t think I care for the large thumbnails. I would prefer a tree of folders by page type > pages > drawings, notes and markups…maybe a means bookmarking which pages/drawings are most relevant. The screen would look and function essentially the same as the takeoff screen except that you don’t do takeoffs here…you name, organize, rotate, level, scale, study, add markups, measure, and so on.

Its all about getting ready for and supporting takeoff.

I agree with Heber on the tab name, except that it should be “Plan”—in keeping with the idea that this is where you plan before you takeoff. Make each tab a verb, suggesting the action to be performed in each tab, correlating with each step of the estimating process: Plan, Takeoff, Estimate, Report, etc.

Can you provide a visual on how this would work when we receive revisions and need to compare a ton of pages to the existing takeoff, versus the old way of just overlaying each revision page on top of the original pages?

Jes,

Here's a mock-up that demonstrates how we could handle comparing revisions at scale. The interface allows you to:

1. Select any version from the dropdown menus (R2, R1, or original v1.0)
2. See changes highlighted in blue (additions) and red (deletions)
3. Compare versions side-by-side instead of overlaying, which should make it easier to spot differences

What are your thoughts on this approach versus the current overlay method used by some of our competitors?

I'm particularly interested in whether this side-by-side view would be more or less efficient for your workflow when dealing with multiple page revisions.

The mock-up is for discussion purposes - we'll need to evaluate technical feasibility with the development team

I think the side-by-side is interesting, but I don’t know how useful it would be for my workflow. Personally I’d prefer to compare revised plans to my takeoffs first and then to the previous plans since any takeoff out of place will stick out like a sore thumb. As you may have guessed already, this means takeoffs must be independent of blueprint pages. It also means that direct plan comparisons are as easy as changing the color of one or both of the plans and turning them on and off however you like.

I would go so far as to suggest that you are able to set the color of the new set if plans as a default or at import. Then if AI is capable, it could organize the new plan in like manner, and automatically add the new pages/drawings as underlays to the relevant “overlays.” After comparison and revision of takeoffs one could change the color of the new plan to something reasonable for reports and then discard the old plan if desired.

See Takeoffs On Overlays Instead of Pages for a mockup of the overlay concept mentioned.

So is the side by side idea still going to place the revision page on top of the prior page to see the changes? Or it's just going to generate a finished product between the two after performing a comparison? I'm a little confused about the idea there. Would there be any difference between that and simply pulling up the two versions on two separate monitors?

Also, I understand john's concept a little more now. So the takeoff you did on the original/prior revisions would be overlayed over the new revision page, and then you make adjustments. In a crude sense, it's comparable to how with other software you can presently copy and paste your takeoff items from previous plan pages onto the new revision page and then make corrections/adjustments, only with john's idea it's more like grabbing seamless tracing paper that places your prior takeoff items right on top of the revision. I still have to be careful though when I do that, because there have been times where I pasted my old takeoff on top of a new revision page and I missed some items, due to my area boxes inadvertently covering up a change I didn't notice for example, or a count/linear item that pasted which made it seem like I accounted for something that actually got changed and I didn't catch it thanks to a crowded set of pasted takeoff items.

I do wonder from a memory footprint perspective which solution (copy and paste stamps vs floating takeoff overlays) is more efficient. That's beyond my scope though

Jes,

The elegance of the overlay concept is that you don’t have to copy/paste anything when switching to a revised plan. You don’t move the tracing paper; you move/remove/add the plan underneath the tracing paper. The plan changes; the takeoffs are untouched.

I have had so much trouble and wasted so much time updating takeoffs for even minor plan revisions that I have at times just updated the takeoffs over the old plan. Copying and pasting items to a new page is a nightmare even when there are no changes to the takeoffs. Without comparing the final reports line by line, how do you know for certain that everything is the same?

The reality of it is that the takeoffs are a representation of the thing to be built just as the prints are…or that the combination of the two is a functional model of the thing to be built.

This is indeed a valuable and necessary conversation. We all get used to the ways we have been doing it. However, it is also one area that could really turn people off if too convoluted. I am not saying it is, just pointing it out that it could be to some. Deltas can always be challenging. The attention to detail when reviewing changes is crucial. I would like to see this conversation continue with other estimators as well. I think it is too soon to make this a radical change for all users. Again, not disagreeing, but my past UX and CX positions with other precon software is kicking off my "spidey" sense. I think you may be on to something but it needs much more discussion. I really do appreciate all the conversations here!

Mark,

I’m not sure I’m understanding your reservations in having blueprint related functions separate from takeoff related functions. Or is it the complimentary overlay concept that gives cause to your hesitation?