---
title: Nontraditional Computing for Construction Estimating
tags:
  - topic/construction
  - topic/estimating
  - type/cross-topic
---
# Nontraditional Computing for Construction Estimating

Cross-topic of [[nontraditional-computing]] and [[construction-estimating]].

### Sketch-Based Lookup

%% TODO:
This section is a transcription of a dictation.
To be condensed.
%%

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.
