Previously I specified a structure like:

Product Name/
	bin/
	bom/
	src/
	tmp/
	usr/
		assembly/
		make/
		use/

After a sleepless night I realised that it should be:

Product Name/
	bin/
		software/
		fabrication/
	bom/
	src/
		software/
		design_files/
	tmp/
	usr/
		assembly/
		make/
		use/

Product Name/bin/software
An optional compilation of embedded device code.

Product Name/bin/fabrication
An optional translation of the design files into CNC code such as G-Code or SBP code. Some CNC type code is more efficient than others - so there is value in being able to distribute ‘binary’ versions of the cutting or disposition instructions.

Product Name/src/software
Source code for embedded devices.

Product Name/src/design_files
The design files for the product.

This is to account for products that have a software component. Imagine you were specifying an Arduino powered device such as this ‘game boy‘.

We’ve started to see something really exciting with Ponoko… regular traffic blips driven by products that capture people’s imaginations. Over the past 3 weeks the following products have gained a delightful level of traction:

• The iPhone document scanner by kyleakoch
• Type coasters by Alan Chao
• Stilletto laptop stand by our very own John Lewis
• One swallow doesn’t make a summer by Hammer

It’s super exciting to see the larger ‘machine’ working the way we predicted.

A question I have been asking myself over the weekend is whether or not you’d ever see products shared across the web in the same way as MP3s. If so, what sort of file format would you need? I have come to the conclusion (and it might because I have typed ‘make’, ‘make install’ once to many times) that a product file will probably look a lot like a software application - rather than being a single file it will be a directory structure that contains a package of things that you would need. A product needs a bunch of info. For example:

• Design files
• Bill of Materials (x N)
• Assembly docs
• Instruction manuals

So for any sensible product description you’re looking at a range of files - it doesn’t make too much sense to try and jam that into one file.

So as a first cut I think a product package might be a tar.gz file containing:

Product Name/
	bin/
	bom/
	src/
	tmp/
	usr/
		assembly/
		make/
		use/

Product Name/bin
An optional translation of the design files into CNC code such as G-Code or SBP code. Some CNC type code is more efficient than others - so there is value in being able to distribute ‘binary’ versions of the cutting or disposition instructions.

Product Name/bom
A set of structures (like yaml or xml) that list the materials required for the product. This would include both the materials from which the product was cut or deposited and other items like electronics.

Product Name/src
The design files for the product.

Product Name/tmp
A temp directory that is used by parsing software - included to keep things tidy. The contents aren’t guaranteed to exist over time.

Product Name/usr/assembly
Assembly instructions for the product.

Product Name/usr/make
Other manufacturing instructions for the product.

Product Name/usr/use
Usage instructions for the product.

The next few posts are me just getting ideas out in the open before I forget them. I promise they won’t be as crazy as my lawn mowing tales, but you’ll need to grin a bear things for a little while.

Design files really tire me. They consume a vast amount of my time. But like some sort high-maintenance relationship I stick with them because the reward is great. The big issues are around interrogation. Technically - the vast majority of my job is looking at a file and asking two seemingly simple questions:

1. How long are the lines?
2. What and where are the areas?

The amount of effort you need to go to to get that information is mind boggling - but pretty valuable once you have it. Once you’ve asked and answered those questions you are able to start asking and answering some interesting business questions.

Having spent two years doing this I have come to the conclusion that this situation suffers from a HIFI/LOFI problem. A good design file needs to be a HIgh FIdelity store of information and it needs to handle some pretty hard-core issues - like lines tangent to a circle:

Looks simple, but it ain’t and it’s important. That sort of stuff that guarantees the hand-gasms you get when using an iPod. So this is a necessary evil of the space - the file formats need to be hardcore (created by monkeys smarter than me)… but that hardcore nature really gets in the way of creating vital and valuable business systems. That’s why Sequoia and SAP are sinking cash into Right Hemisphere - there is gold in them thar’ files. But the thing is business systems really only need a LOw FIdelity version of the data. As I see it the fidelity requirements of a design file look like this:

The above process is a gross simplification of the product design-manufacturing lifecycle. A product gets designed, business stuff happens and the product gets made. Pragmatically the hifi requirements (in fetching blue) are at the ends of the process - when you’re creating the design and when the final product gets made. The other stuff you can get away with having a lofi version of the data.

“So what! Stop you’re whinging,” I hear you say. Fair cop. The ’so what’ lies in the potential of “what next”. Creating a solution to this LOFI/HIFI dichotomy has a real potential to unlock some really interesting innovation in the manufacturing and product spaces.

You can try and tackle the problem by saying ‘one file format only’ but culturally, that doesn’t fly too well and you then need to get onto the treadmill of file format support, which given the plethora of closed file formats is very very painful. It would be really powerful if there was a way of recognizing the separate requirements…

Another sublime piece of work by nervous:

photos in the yard for the Ponoko competition
Originally uploaded by jrosenk.

Another piece of design awesomeness by a Ponoko user - NotAClock by Kevin Byrd.

Doing something right

When I started Ponoko there were a list of specific people I wanted to end up using Ponoko. Stephen Templer was one of those people. I really love his art work. On Friday his latest automata was installed at Deluxe Cafe… some of the pieces were made using Ponoko. Stoked!

The second goal was that Ponoko was to be something that parents and children could use to learn… Whispering Inferno posted a small review - the key lines being:

We got out the beads tonight, some leather twine and hey presto, personalised jewellery. Can’t wait to try out some more complex stuff now we’ve mastered the basics. One more thing that technology lets me and my daughters learn together; nothing beats turning a paper design into a real world item!

From the “you have no idea how it will get used” files:

This is a pendulum clock made of clear acrylic and nested brass tubes. The design of the gear train, escapement mechanism, and housing is original. As such, I’m sure it’s not as refined as it c…

View >>

Check out this recent piece of art produced using Ponoko:

engraving detail
Originally uploaded by nathan_leland.