zmVault/estimating-ergonomics.md

---
tags:
  - estimating
  - software
---
# Estimating Ergonomics

[[construction-estimating-software]] consistently fails to innovate
on the stale patterns developed for marginally similar applications decades ago.

## More Optimal Patterns

It must be noted that, while these optimizations are better patterns than those of traditional applications,
the bigger problem with those applications is their suboptimal implementation of those patterns.
If you could just do what they're trying to do correctly,
you probably wouldn't need all these optimizations anyway.

### 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.

To draw lines, angles representing bends, squiggly lines representing flexible conduit.
All things that are common 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.

But you draw that that sketch and it creates a graph of all the primitive parts of that assembly.
It includes the panel and the equipment
on the off chance that you actually want to install them or haven't included them elsewhere.
All this on a graph in that same interface where you drew the sketch.
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 want 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.

### Spatial Indexing

Scope exists in a three-dimensional space,
more if you suppose phases and bid options
as having a position on time and decision space axes respectively.

The most idiomatic alternative to time-indexed takeoffs
would be to represent them in the space of the drawings,
then only extend them as necessary.

## 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.

### Enforced Linearity

Something that I've realized that really bothers me
about the the traditional methods
(e.g. database-based takeoff, audit-trail-type-abstraction)
is the the *enforced linearity*,
which is at odds with the reality of takeoff.

No matter how you slice it,
the user is thinking about your takeoff in some linear fashion.
Whether it's the takeoff creation date, or however they've sorted it,
Really date is the only useful measure,
but it's also useless, because you forget stuff.

The fact that forgetting something
totally disrupts a previously logical timeline of takeoffs
means that you stress about every single takeoff;
Instead of being in a flow state,
you have to be thinking 10 steps ahead.

I mean, I do, because I care about that sort of thing.
I suppose other people may not be as concerned,
but that doesn't really justify it.

The problem is that there's nothing linear about electrical installations,
at best it's a directed acyclic graph.
You can almost represent that linearly
if you go down each branch to the end and then pick a new new line,
but that's unideal.

### 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.