vault backup: 2025-12-17 17:03:56

optimal-estimating-patterns.md

@@ -35,120 +35,3 @@ Optimizing the takeoff process means:
 * _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,
-allowing flexibility of input.
-
-* define variables
-* search and replace
-* undo
-
-#### Project Structure
-
-Organizational info (items, assemblies) as submodules.
-Solves database conflicts by pinning estimates to a commit.
-
-#### Related Notes
-
-* [[breakdown-objects]]
-* [[assembly-objects]]
-* [[functional-labor-factoring]]
-
-### Bayesian Takeoff
-
-#### User Story
-
-Frank is estimating a 20-story high rise
-and notices that their are roughly, but not exactly,
-the same number of receptacles in the corridors of levels 2 to 19.
-Frank starts a new takeoff for duplex receptacles,
-typical of levels 2 to 19.
-He counts and inputs quantities for 3 levels,
-each adjusts the prior to calculate the expected quantity for all 18 levels.
-
-### 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.