Posted By Rogue Amoeba Alumni on February 5th, 2015

We unveiled Audio Hijack 3 to the world last month, but it was almost six years earlier that I downloaded Audio Hijack Pro for the first time. I was doing contract work for Rogue Amoeba in September of 2009, hoping to get hired full-time (spoiler alert: I got the job!), so I wanted to familiarize myself with their full software lineup.

“Awesome,” I thought. “I’m going to love this application, and I’ll really be able to use it to its full extent, thanks to those audio recording classes I took in college. See, Mom, Film Production was a sensible major!”

That first launch was intimidating, though. I could tell immediately that Audio Hijack Pro was a sophisticated piece of software…but I had no idea where to begin. The manual was a huge help, of course, but I still felt like I was up against a steep learning curve. I wasn’t alone in that feeling. Audio Hijack had long provided users with an incredibly powerful, but often challenging, solution to their needs.

Co-founders Paul and Quentin knew there had to be a better way to present Audio Hijack’s wide range of capabilities, and they’d been kicking around ideas on how to improve the design and experience for quite some time before I joined the discussion. Visually designing a software application that revolves around something inherently non-visual—like sound—is daunting. The immediate impulse is to lean on idioms and affordances from existing audio hardware (as our charming and easy-to-use Piezo does). The more complex a task becomes, however, the less convenient it is to refer to these real-world devices, which themselves can have steep learning curves and be a chore to use.

Software like Propellerheads’ powerful-but-complex Reason is based on analog devices
[Photo credit: possan]

Saying Yes to Nodes

Quentin was the first person to suggest a node-based design approach for Audio Hijack 3. He and Paul both liked the idea of starting with the audio source you wanted to capture, hooking it up to various effects, and ending with a recording file node.

My initial response was something along the lines of “absolutely not”. Having used the node-based applications Quartz Composer and Shake, I imagined Audio Hijack users dealing with a hairy web of randomly-placed, text-heavy rectangles connected by fiddly, intersecting lines and a general sense of chaos.

The complex interface of Quartz Composer

Even if this style of interface made the application more flexible and powerful, this was not my idea of an improvement. Fortunately for all involved, my protests were ignored. “We’re doing nodes,” Paul said. “We’ll just have to make nodes easier to use.”

And so we worked our way through many different designs. We eventually settled on four basic types of blocks which would automatically snap together when dragged to a grid. The blocks themselves went through many iterations, with various methods for connecting and showing the flow of audio. We finally arrived at the idea of blocks auto-connecting via “pipes”, which would then show a live spectrogram as audio moved through the pipeline from left to right. Here are some early mock-ups showing that evolution. (I’m just as appalled by Past Christa’s design choices as you are, I assure you, but in her defense, these were closer to wireframes than true mock-ups.)

A very early Audio Hijack concept design (Oof!)

We also spent quite a lot of time on the button which initiates audio capture. While Audio Hijack Pro had differentiated between capturing (“hijacking”) audio and recording it, we eventually settled on a single button for Audio Hijack 3 to activate the entire pipeline. Adjacent text in the LCD details what’s happening in the grid.

A later Audio Hijack design with a rectangular “Run” button
and 50% zanier color scheme

The blocks above are color-coded by block type. While this helped differentiate between various blocks at a glance, it was decided to be overwhelmingly colorful and a bit too whimsical, so we shelved the idea. Perhaps it will find its way back into a future version of the app, though!

After many more iterations, we got to our shipping design, seen below:

Audio Hijack 3.0, as she shipped

A Unified Home, A Stand-Alone Audio Grid

I originally wanted all of Audio Hijack to exist within one window, with tabs for Audio Capture, Schedule, and Recordings. I quickly realized that this was just too complex, cramming far too much into one place.

A concept combining the audio grid with other sections of the app

Instead, we created a unified Home window, with tabs for Sessions, Recordings, and Schedules. The Home window provides a place to work on tasks related to all Sessions, while each individual Session opens in its own window for active use.

The Home window’s Recordings tab

IT LIVES!

Another huge component of the design was the use of subtle animation throughout the application. Audio Hijack 3 feels responsive and alive, thanks to the way the blocks pop and grow as you drag them from the Library, how they slide and snap together, and even the way they jump off the grid when deleted. Lead developer Grant was able to breathe life into every interaction within Audio Hijack, and the overall effect is delightful.

Deleting and un-deleting audio blocks in the grid

Streamlining Common Tasks with the Template Chooser

Even after all our work on the node-based design, we knew that jumping into a completely overhauled Audio Hijack interface might be confusing for veteran and new users alike. Thus, Templates were a key feature of the app from the outset, with the aim of making it as simple as possible for users to get to their task. As a bonus, Templates also serve to suggest additional uses for Audio Hijack.

Left: An early concept for Templates; Right: Templates in Audio Hijack 3

Capturing Sound in an Icon

A wholly re-imagined application, Audio Hijack needed a re-imagined icon, too. I tried to conjure ideas that would illustrate the concept of “capturing audio”, and even returned to an old Piezo idea of catching a sound wave in a net (which several people have said looks like a ham at first glance).

A few sketches of icon ideas

We settled on a “jar of sound” concept, like something from a sci-fi laboratory. We still had more work to do, though.

Some versions of the “jar of sound” idea

We worked through many variations, starting with a sound wave and landing on representing sound as a sort of glowing ether in a stoppered glass jar. Of course, a glowing ether isn’t immediately recognizable as sound, so the jar needed a label. After a few iterations, we arrived at the bar-type spectrogram:

Audio Hijack’s final icon design

The Long and Winding Road

Because Rogue Amoeba is a small team, we’re continuously working on all of our applications. This massive update to Audio Hijack has been literally years in the making. In 2014, we made a major push to finally finish it and send it out into the world. Just a couple of weeks into the new year, we finally accomplished our goal.

The reception for Audio Hijack 3 has been the most positive I’ve experienced in over five years of making software with Rogue Amoeba. It’s been incredibly gratifying to hear from satisfied users. The path to Audio Hijack 3 was long, and at times it resembled a nest of interconnected Quartz Composer nodes. Ultimately though, it was a fantastic journey to make our flagship product visually intuitive and, with any luck, fun!