5.1 KiB
id, aliases, tags, title
| id | aliases | tags | title | ||||||
|---|---|---|---|---|---|---|---|---|---|
|
Optimal Estimating Patterns |
Optimal Estimating Patterns
construction-estimating-software consistently fails to innovate on the stale patterns developed for marginally similar applications decades ago.
Flaws of Traditional Patterns
Required Hyper-Specificity
The reason that it's such a big deal to change between 1-hole straps and and unistrut straps is because it takes so long to do. If it was as simple as it is to visualize, which it could be if you were drawing these things and it was being interpreted, rather than having to explicitly specify every aspect of what you wanted. Then that would make a huge difference.
In the (granted, limited) market segment that we've worked in, I use ~10 assemblies on a regular basis. That makes up 99% of the work. Why are there hundreds in in our database? They just need to be better. You could probably get away with hard coding some of this, even if that irks me, if they were good. It's just that it doesn't seem to be a goal that Trimble or anybody else has.
Assumed Finality
While they may support a multitude of creative methods to create takeoffs, traditional methods are rarely as convenient when it comes to modify those takeoffs, as is frequently necessary as in the case of mistakes and revisions.
More Optimal Patterns
Note
Note that while the patterns described below are more optimal than those of traditional applications, the bigger problem with such applications is their suboptimal implementation of their patterns. If you could just do what they're trying to do correctly, you probably wouldn't need all these optimizations anyway.
More "Innovative" Patterns
These ideas are farther out there in terms of what existing estimators may be willing to accept
Estimating As Code
Compared to Existing Frameworks
Traditional methods interact with an existing database. EaC builds a static database at runtime.
Project Structure
Organizational info (items, assemblies) as submodules. Solves database conflicts by pinning estimates to a commit.
breakdown-objects assembly-objects
Sketch-Based Lookup
A better use for computer vision in estimating is sketch based assembly lookup. Probably the the biggest hang-up in the workflow is searching through available assemblies and items based on text, which has a number of problems, mostly that names, in electrical material for certain, are practically meaningless.
Trade names are incorrect, and there are often many different names for the same item. Basically, there's just so many problems with text-based lookup as a rule. That sketching and handwriting recognition would be more idiomatic.
Drawing lines for raceways, angles representing bends, squiggly lines representing flexible conduit, etc. All things that are common sketching conventions that estimators are probably drawing in their workflow anyway.
Many parts of the estimating workflow would be greatly benefited by the sort of non-traditional interface that Ink & Switch promotes. Traditionally estimating software is all tables and forms.
Suppose you were to sketch a takeoff indicating a run
- from a panel
- up to the ceiling
- across the building
- down to a disconnect
- out through a flex connection
- to a piece of equipment
that's a very complex assembly, and despite how common it is, it can be very difficult to to get exactly that from databases.
Suppose instead you draw that that sketch and the application creates a graph of all the primitive parts of that assembly.
It may include the panel and the equipment by default but with the same stylus you used to draw the sketch, you just cross out the panel, the equipment, the parts that that you didn't intend to include.
- Draw a line from start to end.
- A canvas appears on top of the plans.
- Sketch the desired assembly with predetermined conventions.
- Draw a checkmark to confirm
- A render of the interpreted assembly appears
- Draw a second checkmark to select.
A Non-Traditional Computing approach (journal-type, heavy-stylus-use), would would be great here, too.
Keyboards as a takeoff input device are an anti-pattern. Every time you're entering data is an interruption.
But perfect for that would be drawing takeoffs on the on the prints then using stylus based interaction patterns to edit them. Lasso selecting groups of takeoffs to change aspects of them.
There is so little typing necessary. Everything that you're typing is just short descriptors that, in a lot of cases, don't even need to exist. the language exists purely to roughly communicate ideas that are intuitive in even a crude sketch.
Estimating is a perfect use case for a purely stylus and handwriting recognition based workflow, probably more perfect than whatever Ink & Switch is using.