158 lines
5.1 KiB
Markdown
158 lines
5.1 KiB
Markdown
---
|
|
id:
|
|
aliases: []
|
|
tags:
|
|
- authorship/original
|
|
- destiny/fleeting
|
|
- status/incomplete
|
|
- topic/estimating
|
|
- topic/software
|
|
- type/idea
|
|
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.
|
|
|
|
<!-- TODO:
|
|
|
|
Count-based takeoff speed increases with count.
|
|
|
|
Optimizing the takeoff process means:
|
|
|
|
* _Minimizing_ the need for information outside of drawings
|
|
* _Maximizing_ organizational consistency
|
|
|
|
-->
|
|
|
|
## 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
|
|
|
|
1. from a panel
|
|
2. up to the ceiling
|
|
3. across the building
|
|
4. down to a disconnect
|
|
5. out through a flex connection
|
|
6. 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.
|
|
|
|
1. Draw a line from start to end.
|
|
* A canvas appears on top of the plans.
|
|
2. Sketch the desired assembly with predetermined conventions.
|
|
3. Draw a checkmark to confirm
|
|
* A render of the interpreted assembly appears
|
|
4. 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.
|