Extending the Drawing Environment by the Abstraction of the 'BOM' & 'Balloon' tools, to 'Table' & 'Key' with parameters and aggregates as table columns: The above and below images are not mine and are just an example of the point to take. There can be any table, with a symbol key (here hexagon) bound to data context (entities on the page as rows, here a Door, Window etc) in the Table (here, Note Block). A Table whose rows represent the collected items tagged beneath the arrow heads of the keys. Intuitively, the very act of building the table is the act of keying the context on the page, i.e. placing tags/balloons, or by scheduling the table's row context, (sim to Revit schedules). History, Then & Now: The Table & Balloon representations appear within many facets of many design documents, various standards (NCS, etc.) and CAD software, where each abstract use holds different meanings to the reader and presenter, usually dependant entirely on the design's context, for example as a Parts List, cut-list, legend & key, etc… In your case, a BOM (Parts List) is a WYSIWYG (What You Model Is What You Get) style of displaying a part list and balloons. Consider abstracting BOM to Table where we can display multiple data-driven representations and visualizations in the form of Tables/Schedules. Where users can choose the source of the table, as a collection of items or nested-collections that are tagged or just on the page, each item in the tables collection inheriting base classes with similar properties, allowing for data abstraction such as running/complete totals, data grids, etc. I think this gives the user the flexibility as to the level of detail the tables contain and who the audience is and what the message is, while still using CAD conventions that are standard and the 'norm' Random thoughts on the implementation: Row Types, such as instances/collections of Bodies, Body Features, Components, CAM Setups or operations, Sketches, etc. With each type, the user's ability to insert parameter fields and custom fields, into the table as columns represented by the keyed object's properties. This would make the Ballon Key interface a little sticky, with many entry points and arguments. This way you can have unique shapes and associate the keys directly to the Table. Most importantly, you can then have a complete custom table where the data is dynamic, where each row is a line item on the table, represented by a key placed in the drawing. Regarding that Key Element Behaviors and Context: Selecting the key allows you to edit the tables data context, pointing the table to certain parameters related to the table's collection and of course the item(s) beneath the arrow leg. Note, Abstract the arrow leg from the key symbol collection so that you may have multiple keys on many different tables, and you can have a key(s) with multiple legs. So, the row's data context should be represented by the content beneath the arrow, perhaps the rows context could be of a type, collection (with aggregated properties, linear feet, total price) or an instance of an item itself. There should be obvious indicators that the values of the table are either 2-way or 1-way bound links to parameters (ReadWrite vs. ReadOnly Properties vs. Custom (Typed String)). It should be true that a user can edit a rows parameter (if 2-way), or a custom parameter(2-or-1 way), of a keyed data context. Examples of useful 2-way parameters: Name, Description, Time Line Color, any editable individual 's parameter. Examples of useful 1-way parameters: CNC Setup Details, aggregated properties (Length, Cost, Qty, etc). A concatenated field perhaps: Species & " " & Thk & " x " & Wid & " x " & Len Sappy Cherry 3/4" x 4" x 34 1/2" Parameters should have display properties: Aggregated Length of collected items, for example Fractional Inches, Fractional Feet, Decimal Feet, Feet and Inches, cm, m, etc. Parameters can be edited to represent other data abstractions, perhaps Math. Summary: Tables are built by tagging items in the drawing or by scheduling them on the sheet. You could specify an aggregate of the total linear feet (Length Property) of eased/profiled edges applied to the tagged entities. You could be able to specify every property you need to display. You could use this information to have sheets for Quoting, Assembly, even sheets for instructing a Mfg process. For home builders, it might be tagging some studs and plates and getting cut-lists, or a Trim company selecting rooms and getting lineal feet of trim. Or a manufacturer getting a one piece flow drawing capture of a design in animation, thru to completion. The point is we can acknowledge that the use of a 'Keyed Table' is an illustrative technique designed to instruct/inform the truth about the context of the design, to various and specific audiences. As our audiences and the design context changes so do the visualizations of the design data. Certainly more than any specifically requested table structure to date. What I am asking for is this, specifically: Abstract the way we create tables, allow us to schedule the design context in a table to fit the needs of our audience and let us do it dynamically and parametrically. Just some thoughts, Matt Harrison | MSH Please share, reply and upvote.
Show More
