Talk:Triloboat
Introducing Myself (Dave Zeiger)
Hi Folks,
I'm the originator of the TriloBoat concept, which I've offered up for OSDevelopment.
I took the wiki instructions to heart and did a 'braindump' on the content page. I realize that it needs to be deeply edited to bring it into conformity with OSE and general wiki format. Please excuse my gaffes.
Due to time and access restrictions (we're about to sail off the edge, again), I won't be able to participate often or at length. I will, however, check in as often as I can.
If you have any particular questions I can help with, please visit my site at http://www.triloboats.com or blog at http://triloboats.blogspot.com, where I have a lot of information posted, or write me at triloboats AT gmail DOT com. I'll be sailing, and slow getting back to you, but unless overwhelmed by volume, will eventually write back.
PS. Here is a video from my Team Culture Bio, showing a few TriloBoat configurations:
Enabling the TriloBoat Approach vs Product
I note that TriloBoat (any Boat, for that matter) will be an unusual project within the OSE, with many more variables than is usual in product development. This won't be a case of zeroing in on a design for a single, modular tool.
(OR, if it IS decided to BE a single product approach, the rule set can be further constrained... focus on hull only, make ends uniform (limited to a single sheet), and only scale by beam and adding sheets to lengthen or shorten... this, however, severely limits adaptability, and is a relatively trivial result... this might, however, be the core product design within a larger design portfolio.)
The Bill of Materials and Builder's Instructions, for example, are going to be very different if using steel vs plywood vs composite construction, as will portions of the User's Manual. A landing craft will have wildly different requirements than a sailing coaster or skiff. Being more approach than product, it's going to take some special handling.
I'd suggest that the OSD process re TriloBoat orient itself from the outset toward enabling end-users to follow a number of paths through the TriloBoat 'design space' as well as the subsequent build.
Design guidelines, various material suites with associated construction techniques and methods, layout and outfit options - the erector set approach - will be much more versatile than any given plan or set of plans.
That being said, a portfolio of product-level designs for various configurations will be useful, and sufficient for most end-users - each design similar to the standard OSE product, and all under the header of Boat
TriloBoat Design Decision Tree?
Boat concept strikes me as a bit unusual within the GVCS, in that it is scalable and adaptable to a far wider degree than, say, the Truck or Car.
Decisions that will go into a Boat include materials, method, size, intended conditions (eg, protected vs open waters), intended purpose, and propulsion methods. It will be outfitted with a far wider range of tools, and can be 'packaged' with other tools to a far greater degree.
TriloBoat narrows the range considerably by rules-of-thumb constraining shape, but still generates a class of thousands of instances. By the time even GVCS options are factored in, the class is... um... freaking huge!
I propose that a Design Decision Tree be given OS consideration, as a means of navigating the class of TriloBoats, to assist arrival at an instance of TriloBoat.
Questions include:
- Do we want to spend time/energy on this?
- How to prioritize the tree?
- How to represent the tree?
- Can navigating the tree be computer assisted?
- How best to integrate the tree with other materials?
- Can this approach be generalized to work with other OS development?
