Terminology - Area Section vs Area Object

I have few thoughts.

If this system were being designed from scratch today, “Object” would be the natural, consistent choice. But that’s not the situation we already have:

• established users
• existing formulas
• existing training material
• existing mental models

So, the real decision becomes:

Is the current confusion around “Section” significant enough to justify the disruption of changing it?

Based on what we’ve seen so far, the confusion is minor. It doesn’t cause measurement errors or workflow issues, it only creates occasional uncertainty about terminology.

Because of that, the most practical approach is:

My Recommended Path: Keep “Section,” but define it clearly and consistently

• Keep [Section Count]
• Continue using “Section” anywhere it refers to a takeoff-related object
• Add a clear definition in documentation: “A Section is an individual Takeoff Object belonging to a Takeoff.”
• Use “Object” only when referring to the broader category (takeoff objects + annotation objects)

This preserves stability for users while tightening the terminology.

If you decide to standardize later

Treat it as a planned terminology update, not a silent change.

• Phase out “Section” gradually
• Introduce “Object Count” alongside “Section Count”
• Provide migration notes
• Update training material at the same time
• Use tooltips or transitional labels to help users adjust

I think, this approach avoids user confusion and prevents backlash.

@Steve Thanks for posting your thoughts on this. The feature we're working on that re-surfaced this discussion internally is Section Level (aka Object Level) property overrides. We currently have it as "Section Properties", but just revisited the discussion. The primary purpose of this feature would be for Zones or WBS data attached at the section/object level.

Not a huge deal either way. I never struggled with the "Section" terminology in Planswift. Honestly, though, I would ditch the "Section" terminology. "Section" is a bit of an ambiguous word, even beyond the plan sections you mentioned. For example, when I draw a perimeter, each segment of that perimeter could be thought of as a "section" to some people. That's just my two cents. Having Takeoff properties and Object properties seems pretty darn simple and effective. What I definitely would NOT do is continue to use both Section and Object. I honestly had to read your post two times because I was slightly mixed up after reading it quickly the first time. I would switch to only using "Object", and have some sort of pop-up notifying folks of the change until they are comfortable and can turn off the pop up when they please -- just like Google rolls out their updates.

Also - being able to individually modify and manage individual sections/objects more easily is going to be awesome!!

I prefer the sections, for my purpose, it lets me know sections of conduits that I am able to then know how many fittings I need for a particular conduit run

Sections in my mind always makes me think of section details on drawings, not takeoffs. But I know PlanSwift always referred to individual pieces of takeoff objects as sections so I got used to that

I have found myself confused a couple times between section count and segment count. I like the idea of using 'object' because it is distinctly different from segment.

In OST these are referred to as Area Counts and Linear Counts.

I know how important this will be in the future. The BIM world (and other 2D/3D tools like Kreo) references these as "instances" If I were building zzTO that's what I would call them. "Instances"... Done full stop, no debate required.

"Annotation Instances"

"Area Instances"

"Count Instances"

"Length Instances"

It just works.

Picture from Assemble, note there are 3 instances associated with that 3" metal deck that could have different sub-properties. Instances are labeled randomly when exported from Revit with the odd "1104711" numbers. If revit makes instances, why doesn't zzTakeoff?

Thanks for all the input guys. We've had lengthy discussions internally about this as well. We are planning to move the direction of calling them "objects" across the board. We like "instances" as well, but "objects" is shorter and also accurate. We also already call them (draw) objects in our code base throughout. Many CAD apps use the term objects as well. Formulas currently use [Section Count], but we will plan at some point down the road to make the switch to [Object Count] and auto convert all the formulas for users. For now, we will start UI level changes, and make it more permanent in the data structure over time.

Example: previously when hovering over an area it would say "*This section only"...after the update it will say "*This object only". Standardizing this term should help when we have discussions.

For example, the following image shows a Concrete takeoff that has 2 area objects associated to it. Currently, the objects automatically inherit properties from the takeoff. We're working on the ability to properties of the individual objects (overriding the takeoff properties). This will be for WBS / Zones / varying wall heights in some cases, etc.