16th October 2020 – Wrap Up
Back in 2010 I was employed as a researcher at the University of Technology Vienna. One particular project’s goal was to build an educational tool set together with blind and visually impaired students and teachers. Smartphones just had appeared on the market, and their mainstream adaption demonstrated – in a very compelling way – that touch-based human-computer interaction was not an obscure field of research anymore. Low latency multi-touch technology hinted toward possible alternatives to the then still dominant WIMP paradigm. It opened up new design spaces.
Inspired by this shift, it was easy and exciting to dream up new forms of “screenless computing” – computing not based on graphical user-interfaces made “accessible” in retrospect, but screenless by principle. The problem: To experiment with functional prototypes I still had to adjust my concepts to the constraints of “hacked” consumer products – products that had been optimized for different purposes than I had in mind. The necessary workarounds had significant impact on the over-all design and user experience.
Design is all about trade-offs, and I was working with the wrong constraints. The process didn’t feel right.
What turned out to be the underlying problem was difficult to address: The wealth of consumer products we were (and still are) surrounded with today rests on a variety of technological mass-produced black-boxes. These black-boxes foster development by concealing their inner complexity. They simplify. But by doing so, by not giving full access to their inner workings, they restrict local innovation to the boundaries they establish. Moreover they make it all look easy. They are setting the bar high. They elevate expectations. This creates a challenging dynamic for researchers.
By hacking consumer products one may test and shift these boundaries, but only slightly. To break out requires a more radical approach. One is “design fiction”: non-functional futuristic design studies based on (more or less carefully) made up design constraints. Ironically, following this path may further elevate expectations, while failing to deliver any palpable result beyond mockups with corresponding narratives. This form of design research may inform and inspire future products. But it may also lead to frustration, especially in the field of assistive technologies that is plagued by overpromise and underperformance. The alternative is to build things from scratch. This, however, might simply exceed the ressources available. It might also lead to failure. For the individual researcher it is a risky career step.
Back in 2010, we – a small team of young and highly motivated (foolish) academics – took the plunge. We started building a prototypical system from the ground up. We wanted to design, build and test new forms of interaction. We also hoped our efforts would not only inspire others, but provide them with something to start with. I do not know if building WireTouch the way we did was the right approach. It definitely turned out to be trickier than we initially thought. Hopefully it was a tiny step in the right direction (or at least someone can learn from our failures).
Looking at the general situation at the moment, however, I don’t see much improvement since we built WireTouch. Open hardware and “physical computing” both had their moments in the last decade, but the rift between design and implementation didn’t close. It rather seems to have grown, in particular within the academic HCI community (and maybe even more so in the professional ux/ui field, which has distanced itself from front-end development and nearly lost all contact to hardware engineering). A simple “bottom up” approach, as I have argued here, turned out to be rather insufficient.
What is needed is a much stronger long-term support of open and “technology-aware” prototyping tools and processes in the academic context.
Still 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.
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 2016
We 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 2016
When 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: [1], [2], [3]). 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.