first commit

estimating-ergonomics.md

@@ -0,0 +1,149 @@
+---
+tags:
+  - estimating
+  - software
+---
+# Estimating Ergonomics
+
+## 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.