| joshua noble

We all know what a presentation looks like: a slideshow, someone stands in front of it and talk, the audience listens, the speaker finishes talking, maybe the audience asks some questions, then everybody leaves. It’s about as tried and true a format as we have in the design community, the bread and butter of delivering projects, viewpoints, ideas, and inspiration. And it’s not just the design community, we’re all living in a world of TED Talks and powerpoint showmanship. But what happens if you start to toy with the format itself? Lots of people take presenting as an opportunity to broadcast themselves and while there’s nothing wrong with that, I liked the idea of trying to make presenting an opportunity to riff on the very nature of presenting. Let’s say this is the model of the presentation:


The filled blue circle is the presenter and the un-filled blue circles is the audience. Is there a way to make the audience the more akin to the presenter, to level the playing field and engage the audience in the process of presenting and in the experience of being presented to?


Could we even make something like this?


One thing is for certain, you’ll never know if you don’t try. Here at Teague every Wednesday we have a Teague Talk that can be an personal get-to-know-me introduction, a talk on a topic that someone here has particular expertise in, or a guest. For my Teague Talk I decided to talk about experimentation and the wonder of not knowing what’s going to happen. I titled the talk In Praise Of Not Knowing and I decided to make the presentation a webpage hosted by a node.js server instead of the usual Keynote or Powerpoint presentation for a very particular reason: I wanted to give at least some control over the presentation to the audience and see what happened. I couldn’t really completely give over control of the content of the presentation itself to the audience but I could hand over control of the slides and the presentation itself and see what happened. And what happened was very fun, very silly, very frustrating, and an absolutely worthwhile exercise. I told anyone attending the talk that they could use the following interface to control the presentation itself:


As you can see it’s pretty simple but also pretty effectively everything you can do in a presentation. The tech magic (which isn’t particularly magic, to be honest) can be summed up in a single word: websockets. Light real-time communication streams between browsers that can reside on different computers or even just in different browser tabs. My presentation itself was actually just a webpage written using a library called Reveal.js that is made for building presentations out of webpages. You can control the presentation itself with a mouse press, a key press, or with a little Javascript in whatever way you’d like. The controller page allowed anyone to move the presentation forward, backward, to a random slide, and a few other silly additions. I gave out the URI to the audience before beginning the talk so that anyone sitting there could control the presentation. The node.js server used socket.io to route signals from all the different controller instances back to the main presentation instance. The code is pretty simple and is all posted here at our github.

So what worked? Well, it was certainly interesting to feel like you were basically doing a Powerpoint Karaoke with your own presentation with the added weirdness of wondering whether people were flicking around in the presentation because they were curious or because they were bored. In retrospect I shouldn’t have put a story together and instead have put together some loose slides that I could riff on. I was interested in seeing what people would make of the chat and (un?)-fortunately one of my co-workers was really excited by dropping whole iframes into the chat window with scripts running. That basically broke the presentation and was a little madness-making but was also educational: when you invite people to play around and leave the door open, don’t be surprised when they kick it wide open. What went really well was that it was different and unexpected and, well, fun. It was really revealing to have conversations about it afterwards, most of which started along the lines of “that was really interesting; why did you do that?”. And the answer was (and always should be) because I didn’t know what was going to happen but I wanted to find out.

Take a look at the code, drop us a line if you decide to use it, and think about what talking to your peers and clients might look like if it didn’t look like what you’re used to it looking like.

No Comments yet. Click to add one »

Introducing Failbox

| John Mabry & joshua noble

Heard this quote: “Ever tried. Ever failed. No matter. Try Again. Fail again. Fail better.”? If you have any contact with the entrepreneurial world you’ve probably come across it either in full or in punchier more abbreviated form as “Fail again. Fail better”. There’s even a Twitter hashtag “#failbetter” to express this even more blithely. So then, here’s a question: why are we so obsessed with our failures? As designers, many of us tend to remember negatives over positives, failures over achievements. The things that haunt us the most, have us cringing when we remember them in the middle of sitting on the couch day-dreaming, are our failures. The unfortunate part of this is that since we tend to only remember the bad things and forget the good a single failure sticks with us longer than a whole day of filled with win.

The device market is filled with quantified-self devices to help us measure our health and wellbeing from a physical standpoint. They tell us the number of steps we’ve taken, how stressed we are, how much time we’ve spent sitting at a desk, the list goes on and on. The fundamental idea though is always the same: giving you a quantified number means you can understand and manage whatever it is that you’re tracking. So then lets ask a question: when it comes to the messy tricky metric of “win” and “fail” abstracted from anything easily quantifiable, how do we record that and help ourselves keep ? This was the thought behind Failbox.

The Failbox lets you easily keep track of your fails and wins with two buttons and a classic analog dial voltmeter to show you where your current fail-to-win ratio is living. We have some fine arcade style buttons that have a highly satisfying action and sound to them. Slap the green button for a win, red for a fail. After a few iterations we’ve gotten the form nailed down with a laser cut wooden box that has our motto inscribed on it and the feel of a console from a classic game console or TV gameshow.

Internally the Failbox is using a Particle Sparkcore to keep track of the button presses and drive the voltmeter. We went with a Sparkcore so we could hook it up to some internet services and log the data, broadcast it out, generally have a little more fun with our wins and fails. It’s not the most optimal controller but it gives us a lot more options and in the world of prototyping and thinking more options is generally the way to go.

The one tricky bit of the Sparkcore is that it’s a 3.3V controller while our voltmeter is a 5V. In order to get a clean 0-5V range we needed to get a way to turn a 3.3V PWM signal into a 5V PWM signal. Most of the usual ways of stepping up current aren’t fast enough for PWM. The components don’t fully charge before the PWM signal drops back to 0 so you often actually wind up with a range smaller than the original output from your microcontroller. You need something that responds fast and there’s nothing that’s both fast and cheap better than a MOSFET. The wiring is actually pretty simple because the Sparkcore can be powered at 5V meaning we had 5V around to drive our voltmeter, we just needed a way to control that 5V power source. You also need a diode to make sure that the current doesn’t flow back through your circuit and into the Sparkcore but all told that’s about $0.50 of parts and we’re off to the races. Here’s the entire setup right here:

Now, what to do with these wins and fails? Like a lot of other places we at Teague use Slack internally as a non-email way to communicate with one another. One of the best things about Slack is that you can script in pretty much anything you want, letting bots, other services, and even microcontrollers into your communications channel. In our case we used If This Then That aka ifttt.com to connect our SparkCore to our Slack install. The ifttt recipe is pretty simple:

“If CoreMan published fail_message, then post a message to a Slack channel”

CoreMan is the name of our SparkCore and we pick the channel we want to it to go to and we get a nice notification any time we want to let everyone know how it’s going.

The next step for this is, obviously, to get more Failboxes to more people and get enough data so that we can do something interesting with it. We’re also looking at setting them up with our MakerBot 3D printers to keep track of the quality (or lack thereof) in our printing setup.

No Comments yet. Click to add one »

Hello (again)

| joshua noble

Why hello there, you have may noticed that there is teensy little gap in the posts here on Labs at Teague. After some discussion and planning we’ve recently decided to flip this blog back on and get our making, testing, playing, and thinking back out in the open.

Teague Labs is for the experiments and explorations that we at Teague have worked on in our internal projects, hacked around with in our time, or put together to uplevel our knowledge in areas with which we’re fascinated. Typically the labs section of a design firm focuses on hacking and making and while we are very enthusiastic hackers and makers we’re also designers with serious passion and curiosity about what it means to actually design (that is in the verb sense not the noun). That means this lab isn’t just making, it’s making and thinking and exploring what it can mean to design, communicate, and create. We want to explore our tools, our dreams, our processes, and our talents in the most open and honest way possible.

So, welcome to the rebooted labs at teague. Take a look back at what we have done and keep an eye out for the things that we will be putting up every week or so from now on.

No Comments yet. Click to add one »

Make it! Better

| John Mabry

Design your own printable headphones. You can download the editable CAD files here and go to town on them. All the 13:30 pieces; the speaker drivers and RCA jacks are also included in the CAD so you can start from scratch if you wish. Make them better, make them awesome, make them yours! We’d love to see what you come up with! Send us your screenshots, or renderings of your version of 13:30!

Send your designs to John Mabry.
(5MB limit)


Prototype as Product: 13:30 Printable Headphones

| John Mabry

With 3D printers becoming more accessible we decided to have a think around the concept “life in beta” as a future scenario. What if printed prototypes could become actual products? Meaning, once off the print bed an object could be assembled without any tools and be made functional by readily attainable components. I decided to stress test the premise with the challenge of making electronically simple yet functionally complex headphones.

My first go resulted in a good-looking functional model created on a professional ABS FDM machine (Dimension 1200ES: print time 13 hours and 30 minutes, hence the name). It worked out well, but the machine we used isn’t accessible to the average maker, and two of the critical parts relied heavily on soluble support printing—a non-issue for professional 3D printers, a major issue for desktop 3D printers.

With that in mind, I started to adapt the 13:30 design to the Maker Bot Replicator last week. The main challenge: How to build to a similar level of quality without soluble support. With a bit of experimentation, I’m pretty sure it can be done. So, look for some updates on that very soon! In the meantime, I posted the current model(s), component list, and instructions on Thingiverse for you to make your own working headphones right now.


Doug Engelbart’s Chorded Keyboard as a Multi-touch Interface

| Adam Kumpf

Doug Engelbart’s contributions to computing and human-computer interaction have been phenomenal. In what’s been named “the mother of all demos,” Doug and his team introduced the world to the mouse, video conferencing, hypertext, multi-pointer collaborative interfaces, and dynamic file linking (all in 1968!). If you’ve never watched the videos of the demo, definitely check them all out.

However, what’s often left out was an equally-important input device opposite the mouse, the chorded keyboard. Using this input, the user could type and issue key commands using only one hand. This left the other hand free to navigate with the mouse. Unfortunately, since there’s a pretty steep learning curve to using a chorded keyboard, it never really caught on.


A chorded keyboard works by using combinations of finger presses to signal a keypress (for example, pressing both the first and second finger down simultaneously might send an “A”, while pressing the first and third finger down might send a “B”). With 5 fingers, there are 32 possible binary combinations. Leaving out the rest state (all off), and a drag state (all on), we have 30 useful mappings. With 26 letters, that even leaves a few for high level text commands (such as space, delete, and enter).

Engelbart Chorded Keyboard touch screen interface by Teague Labs

As designers, we all know that on-screen soft keyboards are cumbersome and rather slow to use due to their lack of physical texture and haptic feedback. And with the continual rise of touch screens on phones, tablets, and laptops, we got excited about giving the chorded keyboard another chance!

Here’s what makes this little keyboard so exciting:

  • One handed use.
  • Bring it up anywhere by putting down all 5 fingers.
  • Large hit area per key (since there are only 5 keys to press) allows for blind/touch-typing operation.
  • Contextual feedback to make learning easier (possible letters are shown at each level).
  • Drag anywhere by pressing all 5 fingers down and moving your hand.
  • Cancel a mid-phase chorded keypress by pressing all 5 fingers.
  • Issuing keypress on touch-up allows users to type at any speed.


Ok, enough build-up. :) If you have a tablet (android or iPad) handy,
give the chorded keyboard a try here!

Of course, this project is completely open source for you to play with and build upon. View the html and javascript source code directly in the demo to see how it works and incorporate it into your own projects.


Muze Radio: a virtual musician in your browser!

| Adam Kumpf & Josh Maruska

A few months ago, we created Muze, a musical instrument that plays with you. Unlike most digital music creations tools, Muze doesn’t allow the listener to directly play notes or control the composition. Instead, Muze behaves more like an improv musician that’s constantly playing and taking cues from the listener to nudge it in new directions. Leave Muze alone, and it will slowly evolve itself over time; generating new melodies, rhythms, and progressions.

We loved playing with the physical Arduino-based Muze, but there was one big problem — we couldn’t easily share the one-off prototype with the world. So we went back to the drawing board and cooked up a new version that takes the best of the physical, and adds to it browser application support, a visual interface, and a bunch of new features. It’s Muze Radio!

Have a play with Muze Radio. Twiddle, tweak, and nudge; if you like what you hear, take a snapshot and grab the Midi file to import into your favorite music software to continue the fun.

Tune in to Muze Radio

Of course a curious thing happened on they way to virtualization; the radio version has become a great debugging tool for the hardware version and has really informed the underlying approach to the generative aspects of Muze.

Everything is open source, so if you’d like to look behind the scenes also check out the Muze Radio Processing project. Enjoy!

No Comments yet. Click to add one »

Teagueduino to the Makers!

| Adam Kumpf & Matt Wolfe

After a successfully backed Kickstarter project and four months of assembling thousands of little bits and pieces, it’s official — Teagueduino is finally out in the wild!

But the most exciting part is seeing the Teagueduino community come to life, with over 100 active users in the past 10 days downloading, filming, and sharing their projects for all to enjoy. This is what Teagueduino is really about; people making awesome projects, sharing them with others, and learning along the way.

If you’ve never heard of Teagueduino before, don’t fret. Here’s a quick overview to help you get caught up.

Teagueduino is an open source hardware platform that makes building interactive things super easy. There’s realtime feedback to help you debug and learn, always-valid code creation to reduce frustration, and no soldering required to enable fast experimentation. And when you’ve mastered the basics, Teagueduino is designed to grow with you, transitioning to Arduino and beyond as you progress.

Here’s a quick video showing how to build a simple police car using the Teagueduino and a little bit of craft.

Still not quite sure how it all works? Here’s an in-depth walkthrough of the Teagueduino editor that provides a more informative step-by-step guide for how the board is programmed.

And of course, there’s lots of additional information to check out in the Teagueduino Reference for those curious about how all of the inputs and outputs work, as well as the download page for links to all of the Teagueduino source code, schematics, and specifications.

Wish you could just click a button and buy your very own Teagueduino? We do, too! We’re still looking for open source hardware partners, but keep an eye on the buy page for the latest news on how that unfolds.

Thanks to everyone who has supported the project so far. We’ll keep working hard to make Teagueduino better and better. In the meantime, if you have thoughts drop us a line on the discussions page.

It’s great to watch this new community of makers come together and create awesome things. We can’t wait to see what you’ll make next!

No Comments yet. Click to add one »

‘Duke’ capped up

| John Mabry

An important part of the ‘Duke Reboot’ project is deciding what to do with the open spaces left in the Duke controller. Specifically the hole left by the removal of the  logo badge and the open front section left by the removal of the Duke’s card slots. To this end, I have created and printed some quick caps using our Dimension machine.

Closing up the body really cleans up the Duke and makes it much easier to picture and plan where we may want to place the remaining connectors and additional controls. Deciding what to do about the ‘Guide’ button was probably one of the easier decisions yet to make on this project. Placing it in the center of the original logo ring just seemed to make sense. Not only does it gives the controller aesthetic ties to current hardware, but it also means we can reuse the 360 controllers 4 LED array light pipe and the very nice metal finished 360 ‘guide’ button. We may wish to explore some other options here later on, but in the meantime though these caps will be a good starting point to get the imagination rolling.

I am also posting the CAD IGES versions of these files for anyone else to use.
Duke Template Caps

1 Comment so far »

‘We Have Liftoff!’

| John Mabry

This is the first full button function test for the ‘Duke Reboot’ controller conversion while its connected to an Xbox 360 console. As you can see in the video the result was a success. By the way, those switches you see temporarily taped to the ‘Duke’ housing  are the ‘360 Guide’  and ‘Wireless Bind’ buttons which we will be finding a home for later on in the build.

For now, passing this function test was the first big goal of the build and I’m quite happy about it. Our next step is to finalize our special ‘Duke’ enhancements and install them into the controller.

No Comments yet. Click to add one »