The projects examined in previous posts had a lot of interesting concepts and ideas- this is a condensed list of them, with recommendations for future attempts.
===============================================================
Squishy Circuits:
- Non-prescriptive medium. Unlike other ‘modular’ approaches which can only be fitted together in certain ways.
- Similar to, and in some senses more flexible than designing PCBs or electronic circuits.
- Use of familiar materials (clay, playdough).
Tern:
- Modular components.
- Inactive components. The blocks themselves contain no electronics, simplifying their design and allowing them to be more robust and cheaper.
- External processing. Interpretation and running of the program is performed by a device not physically attached to the program.
littleBits:
- Modular components.
- Strictly colour-coded categories of piece – input, output, power, wiring, etc.
- Keyed connectors. Can only be fitted together one way.
Tangible Programming Bricks:
- Modular components- each representing a ‘function’.
- Parametric components. Timing or other aspects of each function can be altered.
- Direction-insensitive connection. Modules can be attached any way round.
- Familiar materials – Lego.
Electronic Blocks:
- Modular components, all inputs and outputs.
- Icons to indicate function, instead of text.
- Familiar materials – Lego.
Reactable:
- Local medium- programs can only be created in a certain space, and only affect that space.
- Multifunctional modules- some modules have different effects depending on their orientation.
- Symbols to indicate function. Function must be determined by experimentation or reasoning.
- Proximity-based connections.
- Virtual tangible user interface. GUI elements are attached to physical elements, and are manipulated as though they were tangible objects.
StoryRooms:
- “Wizard of Oz” interface- all functions are actually performed by a man behind a curtain.
- Programming mode/playback mode- system is taught, then reacts based on this teaching.
Cuboino:
- Track as program- the purpose of the ‘program’ is to direct objects along a path, which set off outputs as they pass by.
- Modular components
- Active components
- Inactive components
GameBlocks:
- Modular components
- External processing
Dr. Wagon:
- Modular components
- Active components
Topobo:
- Modular components
- Active components
- Passive components
- Programming mode/Playback mode
===============================================================
PRINCIPLES COMMON TO PREVIOUS PROJECTS:
MODULARITY:
Nearly all tangible programming interfaces use modular components, where a single block, device, or item represents a function or serves a single purpose. Programs are created by putting these components together.
ACTIVE/PASSIVE COMPONENTS:
Some had the components themselves provide power, processing, or effects, whilst others had a dedicated power supply, or offloaded these functions to an external device. Both approaches work well, though self-powered and processing devices tend to be larger and more complex. This may not be a downside- larger components are more easily manipulated.
FLEXIBILITY:
Schemes involving ‘active’ components tend to be less flexible with regards to their connections. They have to be connected in one or two ways, limiting the physical structure of the programs and thus the possibility of incorporating them into other devices.
Many schemes were created to control a specific device, such as a turtle or microwave. Few were able to interface with a variety of sensors and effectors in the same manner as the Arduino.
IDENTIFICATION OF FUNCTION:
Most modules’ functions are indicated to the user by icons. These mean users do not have to be able to read in order to use them. None of them actively used texture to indicate function, but occasionally had surface details as a side-effect of their design. Colours were often used to group modules into categories.
===============================================================
RECOMMENDATIONS:
Modular components are a useful way of providing flexibility whilst still giving users some pre-defined functions to use. Manipulating several small objects, each with a clear individual function, is easier than a “blank canvas” like a word processor.
Active components, being those which provide their own power or processing, are more complex and therefore more likely to cease functioning or malfunction. This may be due to failure of their power supply, damage to their circuitry or mechanisms, or from poor connection to other necessary modules. Modules should be kept as simple as possible.
Passive components, although more robust and simpler, cannot provide some features that active ones can, like the ability to ‘test’ a module without connecting it to a program. Active sensors or outputs could be constructed with a ‘test’ button to trigger their output, or sensors could be given an indicator to show when they have been triggered.
Both approaches would be suitable, though it should be noted that passive components will require an external processor which may introduce complications.
Connectors should be keyed to prevent damage to the components, and to prevent frustration of the users- if a connection is incorrect but this is not indicated to the user, the device may not function as expected, with the fault being difficult to locate.
Ideally, connectors will be able to accommodate several different orientations to permit the programs/devices to fit into other creations more easily.
It should be made possible to interface with a wide variety of sensors and effectors, rather than limiting control to one device- given that the project’s aim is to simulate sensory experiences, limiting the possible types of experience is counterproductive.
The function of a module should be obvious from its features. This should be accomplished using as many senses as possible, rather than simply writing the function of the module onto its casing. Icons should be preferred over text.
External processing does make individual components simpler, but introduces complications as the interface between the program modules and the external processor must be reliable.
It also allows for software upgrades to be applied to the processor, without having to alter the program modules. As these are likely to be embedded systems, compared to an external processor which has fewer restrictions on size and power, upgrading its software is probably simpler.
It can also more easily accommodate new modules, as only the processor must be updated as opposed to all modules.