Below are videos demonstrating the multiple versions of code I used in the cubes while testing.

Dropped off cube for Test #3

User: Unsworn Industries

I am in the middle of writing, pure thick thesis writing! It is much more difficult than it sounds.

“Why a SUI?” A question I am asked often, and have always felt I could never give a good answer to. I feel I am closer now.

All of the examples that I have documented on this site so far have included two elements: physicality and virtuality. There has been a physical element, typically in the form of a button, that provided access to an interface or functionality. There has also been a virtual element, typically in the form of a touch-sensitive surface, that provided access to another interface or set of functions. Even though many of my examples have been determined NOT to be a SUI, they have all included these two elements which made them a consideration to begin with.

My SUI Cube prototype takes these two elements to create a simple abstraction of the concept…

The physical element is the one-button, 2-state, press down, interface. A person can press the button down, and when they remove pressure, the button pops back up. There is a physical displacement of finger position when using the button.

The virtual element is the touch-sensitive surface of the button. For my prototype it is possible to see the touch-sensitive area, but in most occasions, “touch sensitivity” is invisible. You can not see the touch sensing on an iPhone, for example. Depending on design and technology, this touch-sensitive layer in the cube could be programmed for a wide range of functionality and interaction. My prototype only has a single touch capability. What if multiple touch points could be detected? If I had more time I would consider testing these ideas. If I sewed multiple independent threads on the surface, I could detect movement, direction, and speed of my finger moving across the top. This would also offer the possibility of creating gestures! The number of interactions and programmable actions with just a simple touch-sensitive button could be limitless!

Apple Trackpad

The lower layer of interaction in the trackpad is the button level. When you press down, it is the same result as if you clicked a mouse or tapped the trackpad: a mouse-click event is triggered. Since a press of the trackpad and a tap on the trackpad are both registered as the same event, it could be argued that this button level could be removed from the trackpad with no degradation of interaction. It is my thought that the button level was kept in the design to assist in those few occasions when only using a tap can make an interaction more difficult than using a button. Some interactions are more efficient and manually possible through the addition of physicality, instead of attempting to combine a string of touch motions that virtually create the same result.

Two ways of dragging an icon across the desktop (a simplified example):

• Move finger to place cursor on the icon, press down with left finger, use right finger to drag cursor across screen.
• Or, move finger to place cursor on the icon, double-tap finger but hold the finger down on the second tap, move finger to drag cursor across the screen, tap finger again to release the double-tap-hold.

The button level of the trackpad provides access to a single mouse event, click.

Apple Trackpad: button level

The upper level of the Trackpad provides a plethora of interaction that goes beyond the assumed abilities of a typical trackpad. For full disclosure, I must admit that I do not have an Apple Trackpad and am only stating functionality from what I have witnessed or seen online.

All typical interactions are possible: tap, double-tap, drag. Apple expands on these interactions, though, through the use of a multi-touch trackpad: “right-click” when tap with second finger when first finger is already touching, two-finger scroll for a webpage, four-finger up to hide all open applications, four-finger down to show a small icon of each open application, pinch two fingers to zoom, rotate two fingers to rotate an image, hold your thumb down while moving your finger to perform a click-drag, press with two fingers for a “right-click”, three fingers swiped to the left or right to move back or forward while surfing the web, four fingers swiped left or right to open the Application Switcher… and on top of all that… you can customize all of these gestures through a preferences pane in the control panel!

Apple Trackpad: touch level

The Apple Trackpad is not a SUI because it does not contain multiple interfaces. This was not an immediate verdict though. If the definition of “multiple interfaces” were stretched thinly, the answer could almost be “Yes” to the multiple interfaces question.

• The top layer provides cursor movement control, cursor event commands, and access to a limited set of gesture commands.
• The bottom layer provides cursor event commands, too.

Where the definition of “multiple interfaces” could be stretched, and I think where most people are convinced that it is a SUI, is how gestures are incorporated into the overall functionality of the trackpad. Without the gestures, the Apple Trackpad would without a doubt not be a SUI because of the absence of opposed interfaces. The button and touch-sensitivity are both controlling the same interface. With the inclusion of gestures in the top layer of interactions, the line that separates the interfaces becomes blurred, and the definition of “interface” becomes uncertain.

From my inexperienced understanding of the Apple Trackpad gestures, they are simply shortcuts or “quick-keys” to functionality that is attainable by other means. The gesture is providing the user with a quicker way of performing the function by allowing the user to maintain their hand position and not move their arm to press a button, or by eliminating multiple cursor movements and click commands. Because of this, I do not consider the gestures to be an interface. I do admit, though, that more investigation is necessary…

Apple Trackpad: SUI levels

Dropped off cube for Test #2

User: Apokalyps Labotek

Dropped off cube for Test #1

User: Do-Fi

My initial sketches, based on component sizes, showed a cube that would need to be approximately 7 cm square. I would then have enough room for an Arduino Pro board, 3-AA batteries, QT110 chip, RGB LEDs, and enough open air that the LEDs would be able to spread the light in the cube. I had a prototype cube laser cut at 1scale1 to use while figuring out component placements and PCB board sizes. Once all the pieces for inside the cube are determined, I will have 3 final cubes laser cut, with all the necessary holes for switches cut out as well.

Hightlights:

• “How to diffuse an LED” instructables article, showing how to sand the outside of an LED for better diffusion. I’m using this method because it doesn’t decrease the brightness too much while still nicely mixing the RGB LED.
• Turkish Delight boxes make a great way of organizing all the pieces I need for each cube!
• My original intent was to etch my own PCB design to speed up the cube construction process. I’m not currently familiar with the Eagle PCB design software, and it is shorribly difficult to learn, so I am opting to just use simple “swim lane” prototyping boards.

Almost all of this will go in the cube.

Proto board will be attached to top of Arduino.

Small board to capture "button press" state.

Sanding RGB LED for better color mixing.

Inside cube, with proto board, Arduino, and battery pack.

Inside cube with button in place.

Cube with all components.

Sketch for layout of components and circuits.

Collecting components for each cube.

• button double-press (hold red light on)
• button press hold + touch tap (switches rainbow color)
• button press hold + touch hold (cross fades between rainbow colors)

My initial electronics design made use of a very small code library that would allow me to sense the touch of the button. This method did not require any additional hardware and used only a small amount of code to detect the touch. (See photo above) It is a great piece of code and only requires connecting a single wire to a single digital pin on the Arduino.

However, this method did not work for the level of control that I need for my cube. My basic debugging showed that the touch is being consistently detected, but the detection cycles quickly between “touch” and “no touch”. For my cube, I need to be able to detect when a finger is touching the button for more than 1.5 seconds, an action I’m calling a “hold”. This “no hardware touch detection” would cycle between “touch” and “no touch” so quickly when my finger was “holding” on the button, that I wasn’t able to accurately interpret the “hold” action.

I instead moved towards a “hardware required touch detection”… (see video)

The button touch is now being detected by the Quantum QT110 QTouch Sensor IC (chip). Only a simple setup is required, connecting the chip to power, ground, a capacitor to filter out noise, a wire that will be touched, and one digital pin on the Arduino to receive the HIGH/LOW output signal. The good thing about using the chip, is that it does the touch processing for me and outputs a simple HIGH/LOW signal to the Arduino, and also allows me to detect the “hold” action! Integrating this chip to the electronics was almost too easy. The only custom wiring I did was to lengthen the “auto timeout” from 10 seconds to 60 seconds. I changed one wire from power to ground for one pin on the chip to achieve this.

Functionality so far:

• button press (red light on)
• tap button touch (blue light on, repeats number of taps)
• hold button touch (blue light, cycles brightness up and down)