Many products for sale can really only be understood via direct manipulation. This is especially true for computer hardware and software. Consider for example the problem of selling a Tablet PC. Pictures of the device and screenshots of its display and lengthy descriptions of its capabilities can enable some comprehension of its abilities, but most people don't really "get" its uniqueness until they play with it for awhile. I myself experience this regularly, as people see me using my Tablet PC on the bus and have no end of questions, which interrogation inevitably ends with the question "Can I try it?".

The best way to sell this type of product, then, would be to put one in the hands of every man, woman, and child on the planet. For most hardware this would be prohibitively expensive. The next best thing might be a software simulation of the device (or, in the case of an application or operating system, the full application itself or a somehow-crippled version of it). CDs of software can effectively be put in the hands of everyone on the planet (as various direct mail and cereal box campaigns have made evident), but such software must still be installed on a computer, with the concomitant problems of compatibility with the host operating system and software. Not to mention the delay in satisfaction that is part and parcel of all this: if I give a CD-based demo of my fancy new application to someone I meet on the bus, they can't use it until they get home, remember to pull the CD out of their bag, sit through the installation routine, and then finally launch the demo. This is a lot of work to go through just to experience some advertising!

Marrying the immediate experience of receiving a brochure which then can be perused with the interactivity of a software-based demo would be ideal. An application could be "compiled" to circuitry that is printed onto cardboard or some other substrate. This app-in-hardware could then be married to a display and then the two combined to form an Interactive Brochure - what appears to be a (perhaps rather stiff) piece of paper but is actually a functional computer program that does not require installation or even a host computer and which can be produced cheaply enough that "carpet-bombing" the world is eminently affordable.

  1. A computer program is designed, coded, and tested on a computer. Any computer language (including assembly or machine language) could be used to do this but a managed language such as VB.Net or Ruby (especially, the combination of Avalon and .Net) may simplify later steps.
  2. The computer program is processed by an Analyzer that reviews the program and verifies its instructions can be converted into hardware circuitry. This analysis may be a no-op depending on the capabilities of the circuit printer (e.g., if the circuitry can be printed sufficiently small and dense an entire operating system could effectively be laid down alongside the application). This analysis may determine which parts of the host operating system and other frameworks (e.g., .Net CLR and Libraries) the program requires and thus which parts may be omitted from the printed circuitry, if minimizing the size of said circuitry (either due to limits of the circuit printer or simply due to a desire for small output) is desired.
  3. The computer program is then converted to equivalent hardware circuitry. The frameworks and other host code on which the computer program is dependent are also converted to equivalent circuitry. (Requiring the computer program to be built using the .Net Framework or other such frameworks would vastly simplify this process, as the code for interacting with the display and input device would be in well-known locations (e.g., a Mouse class in the framework) which could easily be replaced with the specifics necessary for interacting with the display and input device on the final product, as opposed to attempting to ferret out everywhere a program writes directly to e.g., display driver RAM.)
  4. The instructions for creating this circuitry may be stored to persistent storage at this point (e.g., for transmission to a printing service that will mass-produce large numbers of copies of the circuitry) or sent directly to a printer.
  5. These circuits are then printed onto cardboard or some other substrate using a printer that outputs electronic circuits rather than text and images.
  6. The printed circuitry is then married to a combination display/digitizer such as that on a Tablet PC. (Obviously the time delay between printing the circuitry and attaching it to a display could be any length between zero and infinity. For example, the creator of the application being processed may contract one service provider to print the circuitry and then have them shipped to another service provider for attachment to displays.) A power supply of some sort would also be required (a small solar panel might provide sufficient power).
  7. The finished product can be immediately used. It can also be stored for any length of time, subject to the expected lifetimes of its component parts (e.g., documents printed by most inkjet printers fade after some number of years).

Given the work currently being done worldwide to develop cheap circuit printers and cheap displays, Interactive Brochures could be created sufficiently cheaply to make their cost negligible, akin to that required to print static brochures today.

The flexible displays being developed by various parties today would obviously make an Interactive Brochure more usable, as they would enable a Brochure to be folded and otherwise better withstand the rigors of being passed out on the street, sent through the mail, being stuffed into pockets and purses, and so forth.

The types of programs for which an Interactive Brochure would be useful are not limited; for example, beyond the software demos and hardware simulations mentioned above, a clothing manufacturer could publish interactive catalogs, or a movie studio could publish trailers for its upcoming movies.

Until such time as displays are as cheap as required for Interactive Brochures, the following scheme could be followed:

  1. A computer program is converted to printed circuitry as above, although the frameworks and such supporting the program would not need to be printed alongside the program.
  2. Separately, a "reader" device is acquired. This device would be almost identical to the Interactive Brochure described above, with the following exceptions:
    1. The program would not be hard-coded onto the device but rather would be inserted into the device via something akin to a PC Card slot. In effect, the program-in-hardware becomes a pluggable component to the device.
    2. The frameworks and such supporting the pluggable programs-in-hardware would not have to be embedded directly in circuitry in the device but could instead come on ROM or PROM modules.
    3. The device would be expected to be reused for multiple pluggable programs-in-hardware and so could utilize components more expensive than the printed circuitry in an Interactive Brochure. The device would still necessarily be much less than a full computer or even Pocket PC in order to keep its cost low enough to enable it to be more-or-less given away, a la the disposable cell phones in use today.
  3. Rather than marrying the printed circuitry to its own display, the "card" is inserted into the device described in step 2 immediately above.

This idea is obviously dependent on the availability of printers that can print circuitry, and of cheap displays, but both of these technologies are the subject of much research around the world and are near to commercialization.