I've been busy...

by Thomas Brady in , , , ,


There's been a lot going on at home, at work and in my third place. I'm excited to finally get a chance, and in some cases the clearance, to talk about some of what I've been up to.

Wearables

A couple months ago I got really hot and bothered about wearable tech. I saw projects like the Pebble Watch and even got a Jawbone UP, but I didn't see the total package in any of these options. I wanted a watch that would vibrate to alert me that I was getting call or text message, and maybe show me caller ID information about the call. At the time, there wasn't a device for sale that I could find that did all—or in some cases just—those things.

So I decided to build my own.

I got an Arduino Fio, a replacement iPod battery (they didn't carry iPod mini replacement batteries at the time, but that looks like a better option), a BlueGiga WT32-based bluetooth module from an off-brand, much more affordable source and a real time clock module, which I had no idea I'd need at the start of the project. That last bit required different voltage than I was using everywhere else (needed 5V, but all I had was 3.3V), so my rigged setup required a AA battery, too, for a good-enough boost to 4.8-ishV (couldn't seem to find a voltage booster that would be small enough/cheap enough). I intended to fashion a bezel with this hand-moldable plastic from Inventables.

The best-laid plans...

Have nothing to do with this story. I spent hours. Hours. HOURS on this project. I don't regret it in the least. Every step was new information. I'd tinkered with Arduinos a bit, but I hadn't encountered one, yet, that required special hardware just to be able to connect to a computer to be programmed (it's called an FTDI adapter—something that can connect to your computer via USB and speak computer languages on one end, and connect via serial connection on the other end, and speak in micro-controller languages. They're built into the flagship Arduinos (Uno, Leonardo, etc.).

Oh, and a .96" OLED screen. It felt unreal the first time I got that thing going. Hours of soldering, writing code, watching video tutorials (available at that link for the screen itself) and testing, and it was just strange to see something I'd made rendered on that tiny little OLED screen. I've been writing software for most of my life, and every new platform is a bit of a thrill. This, for some strange reason, was one of the bigger thrills. I think it's because it felt like a realm in to which I shouldn't be able to reach—like I was manufacturing my own consumer electronics. This less-than-$100 pile of Radio Shack-available parts didn't exist in this form 10 years ago. This was a new frontier.

In the end I learned that it's not as easy as pulling a bunch of Radio Shack parts off the shelf and beating them up with your soldering iron. The package never got small enough that I would actually be willing to wear it. But it did work, which was a pretty satisfying end to what could have been a downer of a project. Here's the working code at Github. With compatible hardware, that'll get you a 5-minute-increments clock (if memory serves), and, when paired with a bluetooth phone, a vibrating alert when an incoming call is received, as well as caller ID info.

Sadly, I fried the Fio when trying to clean up my late-night soldering job, and I only just realized I never got photos or video of the working rig. : (

Research on Rails

After a few weeks of not having a side project, I got the bug to a) learn Ruby on Rails and b) build a research tool I'd been kicking around for a while. When you design products for clients, they get pretty picky about where you keep your notes. It's become a tradition at frog to build internal-use-only clones of services like Dropbox, Evernote and the like, because, well, we're jealous. We can't store our client's data outside our firewall, so we have to build our own toys.

For everything but client work, you can pry Evernote from my cold, dead hands, so I set out to build something similar for client work. I've long been interested in collaborative workspaces, so I also took more than a couple cues from Pinterest. I call it Catcher. It's my first Ruby on Rails app, and it's currently in use by a couple dozen frogs. I couldn't be happier. Here's a demo:

One feature not shown there is the ability to email items to an internal-only email address, which get scraped and added to your list, including attached or embedded images, URLS and keword tags that were in the subject line. I was trying to make sure that this was a tool that could serve alongside the ways that we frogs currently solve this problem, one of which is by sending emails. Of course, this is better than those emails, because in six months when you go looking for that thing you know you got from somebody on some project about something kinda like… Well, good luck searching your inbox. The email you're looking for probably has a ssubject line that reads something like, "Exactly like this:" and the body of the email is just an image or a URL. If you added it to Catcher, which you could do just by forwarding the email, you might have taken a moment to add some keyword tags. Even if you didn't do that—shame on you—you stand a better chance picking out the image or a big block quote on the infinitely scrolling "Home Plate."

At least that's the idea.

You might recognize a bit of Pinterest in there, too. At frog, and other agencies where I've worked, it's another common practice to have big pegboards up around team areas, where you can print and pin project-related artifacts. These are anything from wireframes to Gantt charts, but most of the time they're inspiration bits—mood-boards, funny pictures, mockups and just plain pretty pictures. I wanted that kind of content to have a home in Catcher, too. A forthcoming feature will add a filter that will let you see just "inspiration" items, or just "bookmarks," etc.

I spent hours on this project, too, enjoying every minute. The vast majority of them were outside work hours. Note to employers: I ended up building something very similar to this for a client in record time because I had just done it for this side project. And screen captures of the tool have ended up in some pitch decks, too. Free time, in the hands of the right people, can be a very powerful thing.

I'll spend a lot more, hours on this, too. Looks like someone in China just started using it, even though I've tried to keep it under wraps while it's in "beta."

SxSW 2013

frog Austin has been an integral part of SxSW for over a decade now, in that we have thrown the kickoff party for all but a couple years of the existence of the conference. Each year got a little crazier. Apparently the party was broken up by the fire department one year.

It's a chance for a bunch of frogs to get together in a warehouse with power tools, buckets of electronics parts, loud music and the goal of making crazy-cool attractions for a party full of thousands of geeks.

Sadly, I got tricked (I kid) into doing something for the party that didn't involve any of that. I ended up working a good number of hours alone at coffee shops and at my dining room table, at all hours of the night. It sure paid off, though. The attraction I got to work on was an experiment in crowdsourced DJing. We teamed up(again) with TouchTunes(again—we partnered with them to design their latest hardware and software), makers of touch-powered digital jukeboxes found in thousands of bars and restaurants. They brought 20 of their jukeboxes (an intimidating sight by daylight, and the closest thing I've experienced to being a moth near a fluorescent light at night) and added the event space as a venue in their smartphone app. This made it possible for any or all 6,000-ish party-goers we had that night to cast a vote for what would be played by walking up to the Tron-tastic jukeboxes or whipping out their smartphones. And they did. We had nearly 10,000 votes, playing over forty songs chosen by the crowd all night.

I got to build a very-large-screen experience that visualized all this activity real-time. A projected screen near the jukeboxes showed, on rotation, something akin to a slide presentation wherein the slide were alive with data. I got to do a lot of the design of the experience, as well, at the information architecture/wireframe stage. Thankfully I got to work with a visual designer to bring those to vivid, neon life—thanks, Gloria! I'm no data-viz-whiz, but I think it turned out all right. I tried to make sure to balance the exposure the votes got. If we only showed you which songs were in the top 5, for instance, those songs would be assured their top 5 spot. If you're standing there and you look up at that big screen and see a song title, you're likely to say, "Oh, I love that song!" and vote for it. So I tried to expose the underdogs. There was a screen that only showed songs that had recently (within the last 30 seconds) received their first vote. Another show every song that had received any votes at all as various sized squares—the more votes the bigger. At regular intervals a random song from that collection was chosen and spotlighted, showing you the artist's name and the song's title.

Lots of people, myself included, gamed the system. You could, if you so chose, stand at the jukebox and choose the same song again and again, if you didn't mind looking a little, obsessed. Early in the evening, this was fairly easy to do. Into the third hour, you'd have to vote hundreds of times this way to break the top 10. I single-handedly chose the second song of the night. I was determined to hear some Tom Waits, and we did. I was kind and played "Jockey Full of Bourbon" and not "Earth Died Screaming" or "Pony."

There was also a slide that showed a real-time 10-band EQ graph of the sound of the event. A mic was connected to the server running the event, which captured not only the music, but crowd noise.

Here's a video from our marketing department covering the event, with a section—starting at 2:06 on the crowdsourced DJ attraction, and some shots of the part I worked on starting at 2:22:

The Aftermath... math

I spent a lot of time building and testing and testing and rebuilding and testing and... You get the idea. The app was pulling voting data from Heroku, synchronizing that data with a local SQLite database, and then going through the same hoops to get song metadata. We had a test server and a production server. For some reason, every time we tested with the production server everything crapped out. Up to just a couple hours before the event. I was sitting in the rain at the outdoor venue re-writing whole chunks of the application. In the end, it worked. Perfectly. I started the app, and only watched—never had to touch—the admin console I'd built for it, except to call up the "Bar's closing/Last call" slide.

I was as tired as I've been in a long time that day after the event, having been up very late for a couple weeks working on this code, up early the day of the event rebuilding signage girders and setting up PA equipment, and up late again that night tearing things down. But I was sitting there the next afternoon with a database full of 10,000 votes cast by thousands of people, and 250,000 pixels worth of graphed waveforms recorded at the party. I had to see what was in there. I wanted everyone to see what was in there. So I set out to learn some more HTML5 and some d3, and the next thing I knew I had another side project. A couple weeks later, with some much-needed design help from fellow frogs Michael "Gondola" McDaniel and Mike Herdzina, this popped out:

A screenshot of the SxSW Opening Party Data Visualization

A screenshot of the SxSW Opening Party Data Visualization

The coolest/craziest/scariest part is that this thing has been published. First by Core 77, in part three of their coverage of the crowdsourced DJ thing from SxSW itself (crazy just doubled, Inception-style), and soon, as I understand it, on Design Mind.

Until very recently, it had been about five or six years since the last time I had actually shipped an HTML application, one where cross-browser use actually had to be supported. The web has change so much, and so little in that time. There are myriad little pains in developing for the web, but the ubiquity of software that can make use of your work is intoxicating. And making use of a good web browser to lay out text or deliver content to a screen-reader is like riding downhill on a bicycle. Hardware-agnosticism in the form of Java and similar technologies is, to me, a myth. They try to tell you, "We can make it easy to write your software once, and run it anywhere." Web development sounds, on first blush, like it's making the same promise. The difference, though, is that no one ever said it would be easy. You'll be able to run your software in lots of places, but you're still on the line to support all the thousands of little differences between hardware, software and user needs your software will find itself surrounded by. To me that's a lot more realistic. Honest.

Thanks

I'm coming up on my first anniversary at frog. I had a great start in my technology career at a little eLearning house called Enspire Learning. I was hired as a technical writer, but they trusted me when I said I could learn to be a developer, and, what's more, they equipped me. They surrounded me with smart people who cared about their craft. They gave me time to learn on the job. They cultivated an environment where people shared their knowledge (with lunch-and-learns and even after-hours classes offered by colleagues). After lots of false-starts, Enspire was where I really became a developer. I outgrew the work in a few years, but for the next several years I felt like I would never find that environment again. I feel I've finally found it in frog. I'm very happy to be here.

Special thanks to Jared Ficklin, who owns the frog SxSW engagement, for involving me, and giving me such a fun bit of the work to tackle.