16th October 2020
Back in 2010, I was a researcher at the University of Technology Vienna. I was working on a participatory design project. The goal: to build an educational tool set for blind and visually impaired students and teachers. The technological solutions available at that time looked promising. Inspired by the new generation of smartphones, it was easy and exciting to dream up completely new forms of gesture based interactions. But there was a problem: To get to a functional prototype, I had to retrospectively adjust my concepts to the constraints of “hacked” consumer products – products that were designed for completely different purposes. The necessary changes had significant impact on the design and the user experience.
Design is all about trade-offs, and I was working with the wrong constraints. The process didn’t feel right.
To be able to do basic research and design new forms of interaction, I decided to build them from the ground up. This not only included a close co-operation with possible future users, but also a real full stack technological design approach. In the midst of it, I realised that I had stumbled over a general problem: We are surrounded by technological high-end black-boxes. These black-boxes are setting the bar high. They elevate expectations. They make it all look easy. At the same time they actively hinder local innovation. You have to work within the boundaries they set up. If you want to break out, you either restrict yourself to pure design fiction, or you start from scratch. But starting from scratch might exceed the ressources available to you. You are not Apple’s R&D department. You can’t do this all alone. So what can you do?
The situation hasn’t changed much since then. Although open hardware and “physical computing” both had their moments in the last decade, the rift between design and implementation seems to have grown, in particular within the academic HCI community.
What is needed is a much stronger long-term support of open and “technology-aware” prototyping tools and processes in the academic context.
I do not know if building WireTouch was the right approach. It was risky. It was hard. Maybe it was a bit too ambitious. But I hope it was at least a tiny step in the right direction.
Got interested? Read page 1-2 of this paper (no paywall). If you like it, cite it. You may also take a look at this book (an excerpt is available here) and this older paper. There is a Github repository. There is a Youtube playlist. If you still want more, you can read my partially related (non-technical) article about the history of touch research. Thank you for your attention and good luck!
26th June 2017
The latest MacOS upgrade caused some troubles with our patched FTDI driver. I decreased the transmission rate and recorded a short video of the update process. I'm also answering a few viewer questions. By the way, if you are working on a WireTouch build, if you found an original application, or if you have some insights or criticism to share, send me a link! Occasionally I get emails about related projects, but I don't have any idea who's building what and to what end. Share you accomplishments (or failures).
The manifesto I'm mentioning at the end of the video is here: Engineering Academic Software (Dagstuhl Perspectives Workshop 16252).
5th September 2016We have written a few lines on WireTouch: How it works, why we built it and what you can use it for. You can download the pdf here (no paywall). If you want to reference it, you may use this BibTex file.
3th September 2016When it comes to large multiplexers, the 74HC4067 was and still is a popular choice in the DIY scene. We used two of them on the WireTouch signal board. Then, a few years ago, manufacturers stopped producing the DIP version. By now it is completely out of stock. Companies like Sparkfun jumped in and started to sell breakout boards, so hobbyists could use the tiny SSOP version. But as I don't want to introduce another hard-to-solder part to WireTouch, I decided to give the MAX306CPI+, one of Maxim's "high-performance" muxes, a chance. It has some interesting properties and it can be purchased in the form of a massive 24 pin dual in-line package. While drawing a new board layout, I also simplified the connection to the signal board (no more criss-crossing) and updated the firmware accordingly (see version 1.3 on Github).
26th June 2016
Why the long silence? What happened in the last two years? A few things. Georg founded a startup. I became involved in several larger commercial ux projects which demanded my full attention. There simply wasn't much time left to invest into WireTouch – and time flies fast when you are busy.
However, even though we didn't advertise it actively, people occasionally stumbled over this website, reached out to us and asked for more information. There definitely seemed to be some kind of audience. But it appeared that the documentation was lacking sufficient detail. So I decided to take some time off to undust the last prototype. I brought the codebase up to date. I cleaned up the schematics (see: , , ). I corrected a few minor errors and I reworked the board layouts. The version 1.23 does not bring any functional changes to the 1.2 version we had back in 2014, but it hopefully presents its inner workings in a more concise way.
17th November 2014
The project has been sidetracked a bit in the last months as other projects/jobs demanded attention. While processing the emails that piled up, one topic emerged which might make sense to address publicly:
WireTouch is not a plug&play-like end-user product. It is not designed to be that. Instead it is meant to be used as a prototyping platform for the development of new interactive systems. It's made to experiment with, to explore untapped potentials. If you are searching for a commercially available and robust input-device, ready to be integrated into daily work routines, WireTouch is most probably not the solution you are looking for.
OK, having that of my chest, I want to thank you all for the positive feedback we have received so far!
In the last days the software underwent a major overhaul. Take a look!
29th March 2014
Here we are experimenting with a new sensor array to get a better feeling of the different parameters relevant in the design. This one is based on 30 AWG wire grid (5cm spacing) glued to the backside of a West African (Senegal?) plastic rug. The results were moderate, to say the least, but it was worth a try.
28th February 2014
We redesigned the main- and sensorboard (the first row in the picture shows the current version). This time we didn't solder the SMD parts by hand, but used a standard heat gun (yes, we are working on a low budget here). This worked better than expected. A DIY kit, however, should come with at least the SMD parts already assembled. We are currently evaluating our options here. If we can gather enough attention we could crowdsource a first small batch.
The next upcoming task: refining and porting the tracking software.
21th December 2013
Adjusting the measurement circuit is a delicate business; a tricky fine-tuning process. Yesterday we were finally able to leave the breadboard stage behind us. The picture shows a working prototype, consisting of the mainboard (top left), the signal board (top right), the sensor board (bottom left), a PCB based sensor matrix (center) and an impromptu cardboard casing.
6th December 2013
The new mainboard, featuring an ATMEGA328P, which is programmable via the FTDI connector and the popular Arduino IDE.
24th November 2013
The signal board v1.1, assembled and fully functional. In the next step we will test the new motherboard which controls the signal board and processes the received signals.
20th October 2013
Here's a short demo of our current build (it's also a little homage to the Apple iPad Mini ad). The software we use to generate the sounds is a small Processing sketch. It loads an SVG file, connects the shapes with MIDI notes, receives the TUIO messages of the tracker and finally translates them into squeacky piano music.
27th September 2013
The circuit on the breadboard behaves reliable, so we layed out a new PCB. Until the boards arrive - the shipping might take up to 3 weeks - we will work on a few demos.
23th August 2013
The software now provides several interpolation techniques, it detects blobs and it already sends out TUIO data. We also cleaned up the repository and decided to release the source code under the GPL v3 license.
19th July 2013
Today we decided to upload our whole code base to Github. One of the things included is a little perl script which patches the OSX FTDI driver configuration. We decreased the latency and are now able to get bitrates up to 1000000 BAUD. The picture above shows the new implementation of our monitoring software, now running on a Mac (before we used Linux only).
5th July 2013
We got the chance to test our device in a (very tiny) EMI-chamber at the AKH (the Vienna General Hospital). The idea was to compare the sensor data we get there with our usual readings. Interestingly, the measurements didn't defer much. The strange behavior we sometimes observe while simultanously touching the sensor matrix and a connected computer seems to be related to the missing grounding of our notebooks.
The picture also shows our new (still very minimal) visualisation software. We are currently switching from Processing to openFrameworks, refactoring the existing code. PLEASE NOTE: In the picture above Georg is touching the grounded casing of my laptop. This increases the sensitivity of the system considerably, a technique we usually do not use in our test setups.
31th May 2013
Georg gives an overview of the circuit and functionality of the current prototype.