Open Source Ecology Forums

Howard_V_Agnew

Complex simplification ... sounds contradictory right up there with military intelligence or bureaucratic efficiency, but my essential premise I am pursuing while actually working on the directions is we, as documenters, should take extra potentially complex steps to simplify the documents.

For instance, as I am working on the CEB Press instructions, specifically the Primary Support Arms, these are long, narrow parts (seven feet long, with the two angle sides only 4 and 6 inches wide). Various holes need to be machined in, and the essential diagram and instructions are about exactly where to punch holes of what diameter.

The directions have been written going from one side, completely in inches (from 2" to 70"). Creating dimension lines to each hole in Sketchup from the same side makes for a messy diagram (because you'd have dimension lines originating from the left side running all the way to that last hole at 70"). Further, Sketchup defaults to reducing pure inch lengths to feet and inches (so it autoconverts 70" to 5'10"). A solution to too many dimension lines originating from one edge is to move half of them (past the center point) to the other side. This greatly un-clutters the diagram, making it easier to read the dimensions.

From a documentation perspective, this creates a readability issue: the directions will say punch holes at various lengths from the left side from 2" to 70", but the diagram will show a hole at 2" from the left side, and continuing right the last one would be (in the diagram) 2" from the right side instead of 70" from the left. Further, 12 or more inches from either side will get translated to feet and inches in Google while the written directions may read only in inches. These things create a readability gap between the diagram and the written directions.

I think taking the extra step of doing the computations ourselves to make them match exactly is, I think, our job as documenters that make the document simpler for the end users to understand. We should write the text to match the diagrams exactly; where dimensions in the diagram are measured from the right instead of the left, describe them that way in the text. Similarly, if the dimensions are in feet and inches in the CAD diagram instead of just inches, use feet and inches in the text.

I believe this is the right thing to do and makes the documentation more readable when it matches the diagrams. I realize it isn't rocket science for most folk to convert distances from right side/left side given a fixed length, and quite a few people can easily convert 12-or-more-inches to feet and inches, but if we take the steps to do that ourselves in the documentation, I think it makes the documents simpler to read and reduces the "I dunno if I can build this" intimidation factor for the end user. I hope others agree ... or if you have obvious reasoning why this isn't the case, please let me know!

Mike_Apostol

Hi Howard,

The dimensions on a drawing has more to do with tolerances/stack-ups and fits-of-parts than aesthetics.

There is no such thing as an exact location when you're talking about dimensions and locations of features. A hole is not drilled at exactly 3" from the end, it's drilled at 3" +/- 0.1" or some other tolerance deemed reasonably acceptable for the purpose and what the capability of the machining process is.

Because of this you actually have to be very careful the way you place your dimensions especially when it comes to assembly of multiple parts together. Lets take a 10" bar with two holes at 4" and 6" (4" from either side). When you cut the bar to 10" size, that has a length tolerance, so maybe it's 10" +/- 0.1"

Now lets say the location of the two holes relative to each other is extremely critical and needs to be 2" +/- 0.01" apart. If you created the dimension to the first hole at 4" +/- 0.01 from the left side and the dimension to the second hole at 4" +/- 0.01" from the right side, you can see how if the length of the part was on the high end of the length dimensional tolerance at 10.1" your holes could end up being up to 2.12" apart instead of within the require 1.99"-2.01" apart.

This is a very simple example too, realistically there is another order of magnitude of complexity once you really start getting into things like weld distortion, pattern hole stack-ups, etc.

This gets into the entire field of dimensioning called GD&T (http://www.tec-ease.com/what-is-gdt.php) which in itself is almost a specialty in the world of CAD.

Basically what I'm trying to say is that when someone is creating a drawing, a lot of thought needs to be put into how to properly dimension the part and analyze the entire design at both the piece part and assembly level to ensure proper fit/form/function of the piece being manufactured. Dimensions are critical and something that cannot just be altered for aesthetics. Naturally making the drawings as readable as possible is desirable and minor changes in how you label your drawings can help immensely and these are things that CAD drafters just pick up over time.

Ned_Ludd

Another factor is our design thinking itself; and the imposed discipline of a loose-fit mind-set.

When I document additions and alterations to existing buildings I always design with dimensional inaccuracy in mind. In fact I choose very carefully which dimensions not to give. Those absent dimensions are in a sense wild cards, dimensions that can vary within fairly wide limits without materially affecting the design intention.

Drawings should effectively communicate intentions in terms of a hierarchy of importance. The reader should not be overly concerned about dimensions that are less important to the detriment of dimensions that are crucially important. I would suggest making use of non-numeric dimensions, e.g. "equal", "remainder", letter symbols, etc.; notes spelling out quite simply what is important; "set out from here" notes; etc. I've even listed measuring instructions, in cases where existing structures were so out-of-square-and-true as to preclude figured dimensions. Referring to the drawing itself, the list began, "1. Take measurement A. 2. Measure distance A from corner B. ..." The result of this is to communicate my process of deriving the intended design, rather than the form of the product I arrived at. It is something many designers instinctively wish to keep private, but I believe it is consistent with an open-source approach to be up-front about it.

Indeed, as many things in any design are non-critical and therefore open to aesthetic or even functional reinterpretation, it is consistent with an open source approach to indicate the critical dimensions very clearly.

A slight tangent, but also consistent with this is a shift from strict dimensional mastering to principle-based pattern definition in the Christopher Alexander sense. Alexander's analysis of historic American barns is informative in this regard: the barns comprise a fairly small range of technical solutions, used because they are known through long experience and repetition to work; but no two barns are dimensionally or even proportionally identical. We should be heeding this and designing sorts of things rather than exact products. That is even more reason to communicate clearly what is critical and why.

Matt_Maier

Awesome! It's good to see someone else working on this. I started documenting the process I worked out as I was building the tractor instructions
http://opensourceecology.org/wiki/Distributed_Collaboration could you tell me what you think?

I totally agree with the need to clearly communicate the information. In the end I totally abandoned text-based descriptions of the parts and just labeled pictures. I still used text for notes and process information. What I realized was that the key to making sure each "definition" was clear and unambiguous was to break things down into small enough steps. Admittedly, that gets harder when multiple steps depend on each other, like when you need to drill one hole based on the position of a previous hole.

My "solution" to that problem was to incorporate an easy feedback mechanism and ensure it actually gets used by keeping the documentation of each step largely independent of all the other steps. That way if someone suggests a small change it actually IS a small change to the documentation, so it actually gets done and released quickly, rather than waiting for an eventual large update and getting forgotten.

Howdy, Stranger!

Categories

In this Discussion

Tagged

Open Source Ecology Forums