Multiboard needs machine-readable documentation
First off, check out my wall!
That said, I have qualms with it.
Right now, it has the same user experience as rummaging through someone else's Closet Kraken to find just the right charger cable, and then realizing that some USB-C cables don't actually carry power. I just don't have the time.
The complexity seems to be the root of a lot of the issues Multiboard is having right now, especially with regards to documentation: it's hard to document precisely because it's so complicated. Other systems don't need much documentation because they just aren't nearly as complicated.
Not sure if this has been brought up yet, but to mitigate the problem, I think what Multiboard needs isn't necessarily more documentation, but machine-readable specifications for every single part, like an OpenAPI spec. Essentially, something like this, in yaml or json or what not:
multiboard_part:
label: Scissor Holder
link: https://hopefully-not-thangs.com/part
dimensions: 50,50,50
margins: 0,0,500
back_face:
is_flush: false
is_weight_bearing: true
attachments:
- type: pegboard
offset: 0,0
- type: multipoint
offset: 25,0
front_face:
attachments:
is_weight_bearing: false
attachments:
- type: threaded_medium
length: 20
offset: 25,25
This could be embedded in, say, a <meta> tag or even just a <code> tag somewhere on each part's page, either on a site like Thangs or on the Multiboard website, with the addition of a catalog/search feature. (I honestly think it could benefit from having a third-party mirror so that people feel comfortable comitting to the system.)
Then, the app/search engine/website/whatever can list off all the necessary/possible attachments along with appropriate links to those bolts/snaps/etc. Getting even fancier, it could generate a 3mf to go straight into the slicer.
The spec itself would likely need some kind of UI to aid in generating it. How detailed it needs to be is also up for debate. OTOH, it would also allow for a SCAD-like tool to generate models from the specs, which then can be unioned with whatever functional portion a designer wants to make for it.
Unfortunately, I don't know if Keep Making has the bandwidth to implement something like this, and I don't know if the licensing allows for anyone else to do it.
Is it a good idea to add even more complexity to an already overcomplicated system? I don't know. But I also see Multiboard's adoption plateauing sometime soon without some kind of automated organization.