88 lines
3.0 KiB
Markdown
88 lines
3.0 KiB
Markdown
---
|
|
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.
|