Back to zzTakeoff Community Channel LogoInside Track
Heber Allred zzTakeoff
17d 8h

Collecting input: Manual Area, Manual Linear, Manual Count, etc.

We are thinking to create a Manual Area, Manual Linear, etc.


If this option is chosen, you could just manually enter inputs as numbers:

Area

Linear / Perimeter

Point Count

etc.


Then when you apply items to the takeoff it will reference your manually entered numbers instead of based on point data on the plans.

For manual Volume calculation, I'm curious if you think we should prompt for Wall Height, and compute the volume by Area * Wall Height, or just have an input that you can directly enter your desired Volume to be used in any child item formulas?


EDIT: The point count is probably the takeoff that will be most used for manual entry, but the other takeoff types will be useful as well.

2
Steve Golubov 17d 6h

Hello Heber!

I want to share this post with the aim of helping, not confusing. My goal is to provide useful insights and clear guidance, so I hope it brings value and understanding rather than uncertainty.


When considering how to implement volume calculations for takeoff items, both options you mentioned have their own advantages and potential drawbacks.


Here's my breakdown:

Option 1: Prompt for Wall Height and Compute Volume

Advantages:

  • Automatic Calculation: This method creates a clear relationship between area and volume, which can help users understand how the volume is derived.
  • Reduced Errors: Fewer chances for errors if the system automatically computes volume based on a wall height that is logically consistent with the area provided.
  • Adaptability: If wall heights change, users can easily input new heights without needing to recalculate the volume manually.

Disadvantages:

  • Limited Flexibility: Users may need to adjust wall height and area values separately, which could lead to confusion if they expect to input the volume directly.
  • Complexity for Users: Some users might prefer a more direct approach, especially if they’re using specific volume calculations that don’t neatly fit into Area * Wall Height.

Option 2: Input Desired Volume Directly

Advantages:

  • Flexibility: Users have total control over the volume they wish to input, allowing for specific requirements without needing to calculate back to dimensions.
  • Simplicity: This approach may be simpler for users who already have predetermined volume numbers (e.g., from previous projects) or who are accustomed to entering final numbers.
  • Speed: Users can quickly enter their desired volume without additional computations.

Disadvantages:

  • Potential for Inconsistency: This method could lead to discrepancies if someone inputs a volume that doesn’t correlate with the specified area or wall height.
  • Less Educational: Users might miss out on understanding the relationship between area and volume, which could be a learning opportunity in construction estimation.


My Recommendation

A combined approach might be beneficial. You could implement an option to prompt for wall height and compute volume while also providing an input field for users who wish to directly input a volume.

Proposed Implementation:

  1. Default Calculation: Prompt for wall height and calculate volume automatically based on input area and wall height.
  2. Manual Override: Include an option (checkbox or toggle) that allows users to enter a volume directly. If they choose this, the system should warn them that this will override the automatically calculated volume.
  3. User Guidance: Offer tooltips or additional resources to help users understand when to use each method to promote best practices.

This way, you cater to both types of users—those who prefer automation as well as those who want manual control—and enhance the overall usability of the takeoff tool.

Kyle Bonde - Vertical GC 4d 5h

This is fascinating. What’s clicking for me is how this ties into how we actually estimate today. In our estimating software, we’re constantly typing in the things we know we’ll need but can’t measure, predictive quantities based on early NAPKIN sketches or experience.


Up until now, the takeoff tool was just “where we measure.” Measurements flowed into the estimate, end of story. But this idea of manual inputs inside the takeoff tool changes that. It means I can start capturing those assumed or placeholder quantities in the same environment, so the estimator’s intent, the “I know I’m going to need this” stuff, becomes visible and connected once the API syncs up.


And yeah, if I’m entering a manual quantity, I’m doing it intentionally, I don’t need the software to compute wall height or volume for me. It’s about being able to log what we know just as easily as what we can measure. Love where this is headed.


Also please let me do a manual unit of measure on the takeoff item would be one thought...like 1 lumpsum for example. Or 50 days for layout. But perhaps I can learn to use the item for that.

You must be logged in to post replies. If you don't have an account you can signup here.