With regards to material design and engineering, building this project will entail three main planks:
- Fabrication ||| Designing, constructing, and refining frosted/matte plastic orb enclosure.
- Arduino-computer communication ||| Making the computer and Arduino talk to each other via bluetooth, and mapping Arduino-powered LEDs with computer-run program via IDE.
- Program and programming ||| Building the keystroke frequency analyzer and activity measurement/timer.
- Bonus/Future ||| Build a more elegant interface for the customization and control of the orb.
Thinking about the physical form of my orb enclosure, I was inspired chiefly by the “ambient orb,” which was, in the 2000s, a sort of darling among interaction design theorists as an exemplary “ambient interface.” Ambient interfaces are embedded in the surrounding environment, in peripheral space, rather than directly in front of the user where their direct attention is focused. Interaction with ambient interfaces is subtle. Rather than direct and intentional action, engagement with ambient interfaces involves environmental awareness and near-passive receptivity.
Another kind of household object that could be classed an ambient interface is the aromatherapy diffuser. Diffusers are made to reside on nearby desks or tables, with their rounded, unobtrusive, self-supporting designs. Always in the background, never the focus of attention in themselves, diffusers (such as those pictured to the right) communicate with us only tacitly, enlisting our senses in a specific and limited capacity while we go on doing whatever it is that we otherwise do.
The physical form of my orb should be one that facilitates exactly this kind of interaction: a slight sphere with a flattened bottom—large enough to accommodate the bluetooth-enabled Arduino and array of LEDs it will be housing, but small enough to reasonably, and unassumingly, fit onto a desk.
The form of the flattened-bottom sphere will be modeled in Vectorworks (a software I am currently in the process of learning) and 3D printed. Depending on how thick the material can reasonably be, I will opt for either a matte or translucent finish. If translucent, I will apply a spray-paint layer to give the interior a frosted effect, so all that is visible from the outside is the brightness and hue of the LEDs, and not all the wires and chips and such.
Danny Rozin has cautioned me to reserve a backup, prefabricated enclosure in the event that the 3D printing doesn’t go as planned (this can be a notoriously finicky, and time consuming, process). The prefab enclosure—a sphere modified to stand on a desk—isn’t ideal, either functionally or aesthetically. But it will do the job if plan A doesn’t pan out.
This stage entails work with the bluetooth device, the array of LEDs, and the computer that will be talking to the former and controlling the functionality of the latter.
The bluetooth connection is integral to the effectiveness of the orb. Not only does the wirelessness that the bluetooth allows increase the range of the orb’s placement (or its distance from the computer), it also confers on it the illusion of autonomy, which enables the orb to be seen not as just another subordinate, USB-connected gadget. Although the distinction is subtle, it’s important that the orb be seen as something that responds to a person’s behavior, and not strictly to the state of the computer over time (i.e. the sequence of inputs made to it over time).
The LEDs, on the other hand, are the thing that will be doing the interfacing with the user. The changes in their color and brightness are what tacitly alert the user to their behavior and relation to their work and the computer.
The bluetooth, the LEDs, and the computer will be programmed and made to talk to one another with the Arduino IDE software. Some of this remains as of yet undetermined, as it’s possible that the bluetooth can be talked to directly from the node.js program (which will be logging the user’s keystrokes and mouse activity). About this program…
Program and programming
This will be my first sustained encounter with node.js, so this part of the plan will necessarily entail the most studying and preparation.
Luckily, owing to the node community, there are a number of existing programs designed for the logging, tracking, and measurement of activity related to keystrokes and mousepads. The best case scenario, then, would be that all that is required of me is to retrofit and/or combine the functionality of two or several programs, and then make node and the Arduino IDE talk to one another.