Under The Microscope


Archive for the ‘The Design Of’ Category

The Design of Audio Hijack 4

Earlier this year, we shipped a massive upgrade to our flagship audio recorder, Audio Hijack. In addition to over 100 new features, Audio Hijack 4 also includes an overhauled design. Without a doubt, this was the biggest design project I’ve tackled as Rogue Amoeba’s designer, and probably in my entire career. Now that it’s out, I can take you behind the scenes and show you how we went from design goals and sketches to a polished app.

Multiple Design Goals

When considering what to do for the new version, I worked out some clear design goals. Audio Hijack 3 was originally released in 2015, and it provided a great foundation. However, I knew there were places we could improve.

Less Visual Clutter: While I loved design of Audio Hijack 3, fantastically executed by Rogue Amoeba’s previous designer Christa, I felt it could be made cleaner and simpler. Audio Hijack’s critical functionality is found in the custom setups called sessions, which users create to capture and manipulate audio. I wanted to make the rest of the interface deferential to each session’s audio grid.

A More Functional Sessions List: Audio Hijack sessions are reusable and saved automatically. The list of saved sessions serves as the starting point for the app, and I wanted to improve that window by showing more details about sessions, as well as allowing the user to access basic controls without having to open them.

Better Navigation: In the previous version of Audio Hijack, a session’s recordings and timers were kept in a separate window, rather than being closely tied to each session. I felt this was something I could make flow more logically.

A Brighter, More Kinetic App: Audio Hijack 3 had a somewhat muted look, and I wanted to brighten the new version. From day one, we knew we’d be adding a new “Light” theme, but I also sought to add splashes of colour throughout the app. Our apps have also been trending towards having more and more movement, so it made sense to liven things up by adding more animation.

New App Icon: Finally, I was excited to make a new icon for the new version.

Let’s look at some of the ways we accomplished these various goals.

Reducing Clutter and Adding Colour

The design of Audio Hijack 4 came together over a long period of time. The node-based UI introduced in version 3 was a huge success, so we knew we wanted to keep that general concept intact, while improving myriad facets of it. I dabbled with various ideas off and on for quite some time, while our amazing developer Grant worked on the underlying code and new features.

Early Mocks

This is the very first mockup that I could find for version 4:

It shows just two blocks, but the connecting wire is surprisingly similar to what we ended up shipping. I knew right away that I wanted curved wires, though I was unsure if they would be worth the development effort. I also experimented with small icons under the block titles. This was quickly axed, however, because it led to too many cases where we needed to split block titles onto two lines.

In this next mock, I tried having tiles snap directly together. It’s an idea I still like, but it hasn’t yet made it past this concept phase:

These first two mockups also show that the colour scheme was fluctuating wildly. Both contained Audio Hijack’s signature oranges and blues, but the feel wasn’t figured out yet.

Getting There

Over time, my mockups moved closer to the app’s final form, and contained more and more of the eventual interface, as seen in the following mock:

This particular mockup is almost a halfway point between versions 3 and 4. The colours temporarily swung back towards version 3’s darker hues and the connecting wires have reverted back to straight. However, the sidebar on the right looks similar to the final product, with a reduction of the more ornate elements of the old UI.


Left: Version 3; Right: Version 4

The above screenshots zoom in on the shipping sidebars for version 3 and version 4. You can see the boxes around each group of blocks were removed, icons were enlarged, and the text was given more space. None of these were major changes, but together, they served to simplify the interface as a whole.

In this last mock, the app really started to look like what we eventually shipped, complete with the new “Light” theme:

This shot shows several ways we simplified the UI. The bottom bar in particular is a lot less complicated, and no longer extends all the way across the window. We also replaced multiple disparate views with tabs in the sidebar – more on that below. Even those great curved wires feel cleaner visually.

P3 Colours

One noticeable change between these early mocks and the shipping version is the implementation of brighter colours. The blues and oranges in Audio Hijack 4 dip into the territory of ‘P3’ colours, which display a little more vividly on newer monitors. Macs have shipped with P3 colour support for quite a few years, but this is the first time we felt it worth using throughout a whole app’s UI.



An approximation of the difference between standard sRGB color and brighter, more intense P3 colour.

You can only see P3 colour on a P3 monitor, but the above image gives an approximation of the relative difference. It’s subtle, but the non-P3 gradient on the bottom is less bright and dynamic than the P3 gradient on the top. Using the P3 colour system, we were able to make colours more intense than we could before.

To avoid overwhelming your eyes, these brighter colours are used sparingly, generally when we want to draw your attention. In our very basic array of colours, we use a bright orange to denote when something is “live”, and this extra pop of P3 intensity for the orange makes this important status just a little more eye-catching and harder to miss.

Enhanced Navigation via a More Powerful Session Sidebar

One of my biggest frustrations with Audio Hijack 3 was the navigational architecture of the app, which divided much of the content across different windows. For example, after you made a recording with a session, you then needed to open the Home window’s “Recordings” tab to access your audio. There, the recording was shown in a list with other sessions and their recordings. Schedules suffered from similar issues. It all worked, but the recordings and schedules for a session were not closely tied to the session itself, and I often found myself taking a few seconds to try and remember where to find them.

To improve this, we built out a much more powerful sidebar for the session window, one which incorporates these related items. The sidebar is already literally attached to the session, and thanks to the power of tabs, it now holds that session’s recordings, schedules, and even the newly-added scripting features. Sessions are now fully self-contained, and it works wonderfully.

An Improved Session List

Another element of the UI we wanted to improve was the list of reusable sessions. The previous Home window showed a rudimentary grid of saved sessions, with no indication of what was running.

The new session list in action, showing a quick summary of each session as well as which are active or inactive.

For Audio Hijack 4, we wanted to make the session list an active part of the interface. It’s now possible to start or stop a session, view and adjust the Auto Run setting, quickly scan sources, check audio levels, and see status. The new Session List window is now a much more powerful starting point for using the app. It’s also easily expanded-upon, and in the future, we’re planning to add even more.

Animations Abound

Audio Hijack 4 is a kinetic app, with subtle animations to aid in understanding. The tiles and wires move, meters bounce, and status icons pulsate to show when things are in action. I’m proud of all these animations, but there are two particular bits I want to call out.

First up are the amazing animations on the connecting wires. While the previous version’s wires could occasionally look somewhat soft, Audio Hijack 4’s wires are all drawn with vectors, so they’re super sharp. They’re also beautifully curved and feel incredibly snappy as you drag blocks around.

You may not have noticed, but these wires actually morph shape. When a device isn’t running, the wire is made of arrows showing the direction audio will flow. When you hit ‘Run’, however, each arrow changes into a pill shape, as it starts moving and bouncing to represent the audio levels of the sound passing through that wire. Hit ‘Stop’ and every single blip on the wire morphs back into an arrow.

My other favorite animations are the various status badges which show what a given session is doing. Much like a photo on a cereal box, here they’ve been enlarged to show texture (I’ve also slowed them down):

In app, these animations are infinitely-looping, vector-based, and very cool.

Marketing Too

Animations also found their way into the app’s product marketing. Animated versions of the interface can be found on the main product marketing page for Audio Hijack, as well as the welcome window we show on first launch. Using still images just didn’t do justice to the dynamic app we’ve made. Getting these various videos working required a decent amount of troubleshooting, and a bit more file bandwidth. The extra work was well worth it, however, to show off the app in motion.

A New App Icon

One final thing I’d like to discuss is Audio Hijack’s new icon. App icons serve as the most recognizable symbol for a product, and Audio Hijack 4’s icon took a long time to nail down. It seems almost nothing is as prone to endless discussion and debate as icons.

Audio Hijack 3’s bottle icon was attractive and well drawn, but the “audio in a bottle” metaphor was a bit oblique. I did briefly try to modernize the bottle concept with my own take on it:


The original bottle icon on the left, with my sketch of a refresh on the right.

Ultimately, though, this never left the early sketch stages. I next tried using some abstract shapes as a base. I still love many of the designs I created. This page of my sketchbook is particularly pleasing:

Those sketches eventually led to more refined mockups, like this one:

I was very into both abstract patterns and this particular colour gradient, which does partly mirror the orange and blues of the app’s UI. However, while this waveform-inspired look was tangentially related to audio, it lacked a strong visual link to the rest of the app.

So it was that the slanted wavy pattern was tilted to vertical and changed to orange on a darker background, to match the meters inside the app. Finally, I added a physical microphone to more clearly communicate the concept of ‘audio’.

Many of us inside Rogue Amoeba lament the recent “flattening” of app icons on the Mac, and the attendant loss of personality. While I did feel we needed to somewhat conform to the new tile design paradigm, I wanted to overlay a bit of 3D to help differentiate the shape (see also: SoundSource).

Above is my first rendition of the concept with a 3D microphone. This icon is a lot more visually tied to the actual app it represents. Once I got here, we were close, though there was still plenty of tweaking and refining. Perhaps most interestingly, the final icon actually features two small Easter eggs: the waveform is based on a recording of me saying the word “Hijack”, and the mic reads RA 2002, representing the year Rogue Amoeba was founded1. Now you know!

Conclusion

I hope you enjoyed this peek at the design process for Audio Hijack 4. I was fortunate to work alongside a development team that was happy to spend time creating a wonderfully dynamic interface, one which shows off the useful new features and the rock-solid backend. I’m very pleased with how it all turned out.

However, I’ve only scratched the surface of all the new things you’ll see in Audio Hijack 4. I didn’t even mention major new features like manual pipeline connections or the new Global window. If you’ve used Audio Hijack before, be sure to give the “What’s New” page a look. Of course, if you’ve never used Audio Hijack, you ought to check out Audio Hijack 4 right here.


Footnotes:

  1. Hey, that was 20 years ago! What a pleasingly round number. I doubt it will come up again anytime soon.↩︎

The Design of SoundSource 5

Not so long ago, I wrote about the design of SoundSource 4. That version marked SoundSource’s transition from a simple audio device selector into a much more powerful app. Recently, we released the new SoundSource 5, featuring many improvements, both technical and in terms of design.

Getting Better All the Time

When I think of the design process for SoundSource 5, a single word comes to mind: refinement. We revisited every part of the user interface, to deliver an update that goes well beyond the sum of its parts. The new interface both looks better and works better.

In this article, I’ll go over some of the refinements we implemented to make SoundSource 5 both useful and delightful.

Compact View

SoundSource 4 started out very small and compact, but as features were added, the main window grew. While it wasn’t massively oversized, we knew we wanted to find ways to slim things down.

The most obvious way SoundSource 5 accomplishes this is with the new Compact view. As you can see below, when SoundSource is switched to its Compact view, many text labels are removed. This significantly reduces the width of the main window, which is particularly handy if you leave SoundSource pinned open. Clarity in the Compact view is somewhat reduced, but toggling back to the Standard view quickly restores it.

The Compact view also removes text from the device selector, cutting it down to a fraction of its standard length. The device icons which remain work particularly well if you have a small number of devices attached to your Mac, as most users do. To create consistency, we also added those icons to the Standard view, where they serve as a secondary visual cue.

Animation

SoundSource does most of its work while in the background, with its only visible part showing in the menu bar. When it is open, we wanted the app to feel snappy and vibrant. One of the ways we accomplished that was by adding subtle animations throughout. This is most noticeable in the toolbar at the top of the main window, where each icon subtly moves between states.

Here are two of the animations from the toolbar:


The size and pin toggle animations, enlarged and slowed to show details

All of these animations are native CoreAnimation assets, built with a tool called Kite Compositor. Kite builds pre-packaged animation archives, which allowed me to iterate super quickly on the animations. I could open, tweak, and re-export animations without much work from the developer.

Reducing Visual Clutter

Before starting work on SoundSource 5, I took some time away from version 4. When I came back with fresh eyes, I noticed a busier interface than I wanted. The bubbles within bubbles within bubbles were logical, but visually cluttered. The best example of this was the nesting that occurred with effects.


Effects were nested two levels in

We knew we could do better. In SoundSource 5, we cleaned this up significantly, and un-matryoshka’ed those nesting shapes. The selection indicator became full width, which rid us of the bubble around individual effects. We also moved the full version of our built-in 10-band equalizer into a popover, matching the way Audio Units are loaded. This enabled us to make the entire Effects area much more uniform. Moving the EQ’s advanced controls out of the main window also allowed it to fit better in the Compact view.



SoundSource 5, with fewer nested shapes

Overly-nested interface elements are harder to parse, so this new design is a big win for readability.

Accent Colours

For many years, MacOS has made it possible to adjust the hue used for all kinds of standard controls, such as sliders, buttons, and checkboxes. Changing the accent colour setting in the General System Preference lets the OS color those controls in many applications.

Though Rogue Amoeba’s applications use many standard controls, some also use what we call a “key colour”, which overrides the system’s accent colour. For example, our soundboard app Farrago has a purple theme, and many of its controls are thus tinted purple.


Farrago’s purple key colour in action

In a similar fashion, SoundSource 4 used its green key colour on almost all the elements in the UI. For version 5, we toned this down quite a bit. SoundSource now uses neutral greys and blacks in many places, and its remaining green elements can all be re-coloured programmatically:


The default tint

This change allowed us to also provide a new appearance preference. When the “Follow System Accent Color” checkbox is turned on in SoundSource’s preferences, the interface will respect the system’s accent setting, adjusting controls to use the selected colour. Here’s a composite, showing all the system tints SoundSource can take on:


Sorry, this trippy rainbow mode is not available in the app.

These changes should make the app feel at home in almost any setup. And of course, all of these tints look great in both light and dark mode.

Big Sur’s Influence

At the virtual WWDC 2020, Apple announced MacOS 11 (Big Sur), which will bring a wholesale redesign of MacOS. Development of SoundSource 5 was nearly complete when Big Sur was first shown off, so these changes didn’t cause much in the way of updates. Fortunately, many of our design choices for SoundSource 5 already aligned quite well with Apple’s new design guidelines.

However, we did make one change specifically as a result of Big Sur. You may have seen that one of the most talked-about changes in the new OS is its updated style of app icon:


Big Sur’s updated icon style

We don’t plan to rush out updates to all of our app icons to match this style. However, SoundSource’s icon adapted rather easily, so we updated to the new, boxier style for SoundSource 5.

The impact on SoundSource’s icon

We’re hard at work on updates for Big Sur (watch our Status page and social media for more), so this new icon will fit in nicely on Big Sur soon.

Handling Applications

The last big change I’ll touch on is how SoundSource handles configuring per-application audio control. In the previous version, controlling an application’s audio required you to manually add the app to SoundSource. We overhauled this rather dramatically with SoundSource 5. Now, when an app produces sound, it automatically appears in SoundSource’s main window. It’s then immediately ready for adjustment, with less setup required.

This improved behavior seems very natural now that it’s implemented, but it didn’t occur to us for SoundSource 4. Sometimes you arrive at a new solution to a problem, and it’s so obvious that other solutions no longer make sense. That was very much the case here.

Try It Yourself

One of the major areas we focused on for SoundSource 5 was doing existing things better. The update is faster, smarter, and takes up less space on your screen. Overall, it’s a tremendous leap forward in quality, and we couldn’t be more pleased.

If you’re new to SoundSource, learn more on the main SoundSource page. For existing users, we have a helpful “What’s New in SoundSource 5” page available. SoundSource has become an indispensable tool for controlling audio on our Macs, and we hope you’ll find it similarly useful.

The Design of SoundSource 4

At the end of March, we unveiled an all-new release of SoundSource, our powerful system-wide audio controller. SoundSource can help every Mac user who uses audio, whether you’re streaming music, participating in voice chat, or just watching videos.

Last month’s release was officially SoundSource version 4.0, but that doesn’t really tell the whole story. Despite its version number, SoundSource 4 is an entirely new app, with massive updates over what came before. Here’s a side-by-side comparison:

Unlike some more linear updates, the design and conceptualisation of SoundSource 4 began from a nearly blank slate. This is a story of how we got to our eventual release.

Starting With Posture

Whether intended or not, every app has what design researcher Alan Cooper calls a ‘posture’. From Cooper’s essential interface design book “About Face”:

Most people have a predominant behavioral stance that fits their working role on the job. The soldier is wary and alert; the toll collector is bored and disinterested; the actor is flamboyant and larger than life; the service representative is upbeat and helpful. Products, too, have a predominant manner of presenting themselves to users.

A workhorse app like Photoshop or Sketch, for example, takes over most of the screen and has what Cooper would call a ‘sovereign’ posture. These are apps you spend hours upon hours in. They tend to have a lot of features, and a correspondingly sprawling interface.

SoundSource is very different, as it works for you in the background, nearly invisibly. It needs to stay out of the way, so the user can accomplish other things. Occasionally, SoundSource needs to be accessed for a quick tweak, then just as quickly hidden away. It has a ‘transient’ posture.

Understanding that transient posture was essential to the app’s design. With this in mind, the menu bar was the obvious home for SoundSource. Making everything we wanted fit into the tight constraints of a menu bar app proved to be an interesting design challenge. At times, it felt more like working on a mobile app than a traditional desktop app, because of the smaller surface area.

Setting Priorities

Once we’d determined that SoundSource would live in the menu bar, the next step in our design process was creating a list of the main functions we wanted the app to have:

  • Volume control

  • Muting

  • Audio metering

  • Output device selection

  • Magic boost

  • Equalization (EQ)

  • Audio Effects

From this list, we needed to determine which elements were primary and which were secondary. Because of the transient posture of the app, we didn’t have the luxury of a lot of space to easily show all the controls at once. The more important elements needed to be more visible, at the top level of the interface, while the secondary elements could be slightly more tucked away.

We considered several options for elegantly hiding certain features. These included an inspector, a separate palette-esque window, and even an Audio Hijack-like popover bubble. However, I wanted to keep everything contained in the same space, which led us to an expanding “Advanced” area. When compared against the shipping product, even the very first sketches might look familiar (though messy):


An early, but recognizable, sketch of SoundSource 4. Most of the main UI elements are here, like boost, volume, and mute.

This layout was refined over time, but the basic ideas were set early on. Each source would get a single horizontal line, and an expanding section would hide the less frequently used controls.

Branding Boost

One of SoundSource 4’s central features is its Boost ability. This real-time audio compression makes audio seem louder, and it’s a great way of getting more out of even the smallest MacBook speakers. Right from the earliest sketches, it used a magic wand icon, because, well, in all honesty it was the first thing I thought of.

I assumed that visual concept of the magic wand would eventually change. In fact, I worked through dozens of alternatives. Here is the page from my most productive session of brainstorming alternative ideas:


A gallery of the many, many alternate boost concepts

Some of these ideas weren’t bad, but most ended up being too cute. We wanted SoundSource to feel reliable, almost like part of MacOS, and these concepts just didn’t help create that. Ultimately, the magic wand stuck, along with the name “Magic Boost”.

The App Icon

Once our Magic Boost concept was more or less settled, other elements like the app icon began to take shape as well.

SoundSource has had several icons in its long life. The most recent icon was inspired by the icon Apple used for the audio input on older Macs which actually, you know, had separate audio inputs.


An iMac’s audio input icon, highlighted


SoundSource 3’s app icon.

Working from that, I experimented with various ideas, starting with the previous app icon and eventually working in the magic wand:


Some early SoundSource 4 icon brainstorming

This was the first high fidelity version I made:


A mix of the old SoundSource 3 and the eventual SoundSource 4 icons

From here, the icon evolved slowly, eventually taking on a speaker background to help reinforce the audio aspect of the app, and losing the input icon altogether.


The final icon for SoundSource 4.

The SoundSource 4 icon also continues a bit of a retreat from flat design. The wand and speaker background are geometric, but still containing shadow and depth. The colours are bright and visually inline with the rest of flatter icons on the Mac these days, but overall I find the icon feels like a good combination of the two aesthetics.

The colour scheme of the icon was rooted partially in the green from the previous SoundSource, but then faded in a gradient to a new blue. This gave us a palette to use for the marketing, manual, and the website.

The Menu Bar Icon

We expect most users to set SoundSource as a login item, so it will run whenever their Mac is on. As a result, the menu bar icon will be seen far more than the app icon.

This icon took more time to get right. We wanted a design that captured the feeling of the main icon, while also feeling properly at home in the menu bar.

The above image shows a progression of menu bar icons (enlarged to better show details) made throughout the development process, with the oldest on the left and the final product on the right. Leading up to the final version, you can see a gradual simplifying of the wand to better fit in with the existing system menu bar icons.

Adding Life Through Animation

We took some time in a few places to liven up the UI with some animation. The first place we used animation was on our Magic Boost button. Early alpha builds used what was basically a check box, with just two states, on or off. We knew we could do something better though. I started by doing a mockup in Keynote, whose Magic Move transition is a great way to prototype ultra-basic animations. Then we built the final assets in PaintCode.

Magic Boost’s animation up close:

A second, and more subtle, animation can be found in our equalizer. When you change presets, the sliders all smoothly move to their new values, and the sparkline indicator in the menu updates as well.

These small details might be easily overlooked, but they do a good job of making the app feel livelier.

Iterating To Our Shipping App

Good design of any product takes many revisions. SoundSource 4’s interface is ultimately quite small, but it still required a great deal of design thinking. What’s described above provides a brief look into a process which spanned several months.

After many iterations, we succeeded in our aims to design something both compact and powerful. With SoundSource 4, we’ve made a useful sound control that’s simple enough for even novice Mac users, while also packing enough punch to be indispensable for the pickiest audio pros.

The Design of Loopback 2

When we shipped the first version of our audio routing tool Loopback in early 2016, its powerful technology was packaged into a somewhat stripped-down interface. Because we were uncertain how large the market for this tool would be, we chose not to devote too much time to the front-end of that initial release.


Loopback’s first design got the job done, but it was plain and not very intuitive.

By Loopback’s first birthday, it was clearly a hit with audio professionals and hobbyists alike. We knew it was time to begin planning how to flesh out the skeletal Loopback 1 into a much more refined version 2.

Initial Thinking

We knew we wanted users to have an easier time understanding and using Loopback, while also having access to even more functionality. Power and ease-of-use tend to be countervailing forces in interface design, so these requirements meant we had our work cut out for us.

The first step in our redesign was boiling down Loopback to its essential components. Loopback creates virtual audio devices, and these virtual devices consist of three logical parts: audio sources, output channels, and monitors. Our challenge was to determine how best to arrange and connect those parts, so configuration would be both easy to understand and extremely flexible.

Back in 2015, we brought an updated UI to our recording tool Audio Hijack. This block-based interface allows users to see how audio flows through their specific configuration, and it was very well-received.


Audio Hijack 3 shows audio flowing visually.

Knowing how well this “nodes and wires” concept had worked for Audio Hijack made it an early favourite for Loopback as well. However, we wanted to consider other options to see if a different design would suit Loopback better.

Failed Concepts

I often sketch out multiple ideas so we can do head-to-head comparisons, which tend to be a productive way of evaluating options. While these low-fidelity sketches are very rudimentary, they still helped us determine how we wanted to proceed.

Rejected Concept: Channel Checkboxes

This idea involved having each source channel on its own line, with output channel checkboxes available for that source. Above, you can see “iTunes L” (for iTunes’ left channel) and “iTunes R” (for iTunes’ right channel), with four output channel possibilities. Configuration isn’t too terrible with a small number of sources and output channels, but even slightly complex devices would quickly require dozens of checkboxes to configure. Worse, most devices would require a good deal of analysis to understand. This one didn’t really leave the drawing board, thank goodness.

Rejected Concept: Grid Outputs

Here, output channels would be represented by a space on the grid. You could drag sources to the output you wanted. Channels that were paired (like the left and right of most sources) would have a line between them to denote the link.

Even as I made this, I realized it had severe issues. It was very difficult to parse how audio would flow through a device, and monitoring would have required an additional step in the interface beyond this grid. The fatal flaw, however, was that splitting sources into multiple channels would require creating many copies of each source, which would quickly get out of hand.

Selecting Our Final Concept

The aforementioned concepts, and others like them, scaled poorly for complex devices and didn’t lend themselves to easy scanning. Eventually, we returned to our early idea of nodes and wires.


This very early sketch of Loopback 2’s wires isn’t too far off from what shipped.

This wire-based approach was our clear winner, working well for simple devices and complex ones. Importantly, this layout offered space to add monitors and volume controls, and provided an easy-to-understand look at how audio flows through each step of a virtual device in Loopback.

Refining the Design

Of course, determining the fundamental layout of the app was really only the beginning. There was still lots of additional work required to turn those rudimentary sketches into mockups representing a real app.

I used Apple’s Keynote presentation tool to rapidly test how the product would work, creating many quick prototypes. The sketch below helped visualize how wire connections would be created automatically when a new source was added to a virtual device:

Starting from my rough sketches, I began to create higher-fidelity mockups showing the application in action. Here’s the first serious iteration of what would become Loopback 2’s design:

This minty green mockup looks similar to what we eventually shipped, but we were still relatively early in our process. When I compare this against our final product, I can spot dozens of changes, big and small.

More Powerful Monitoring

Early on, it became obvious that our design offered very powerful mapping to output channels, but an underwhelming monitoring function. That above image shows a single monitor available in the bottom bar, with no channel adjustments possible. Our earlier wire sketch had shown a more robust monitoring column, and we determined that this was worth adding back.

Flexible monitors in Loopback 2

Giving monitoring its own column made it possible to fully map channels and add multiple monitoring devices. We also allowed users to hide the column entirely if they don’t need to monitor their device.

Connection Wires

The connection wires also received a lot of polish. While they started out as simple straight lines, they eventually became elegant curves, which were more visually pleasing. Even better, the curved wires create visual groups which make the mapping easier to follow.


Evolution of the wires from early mockup to shipping app

Many More Small Changes

Many other things were tweaked, adjusted, and refined as we tested and experimented. For instance, we opted to make channels appear in pairs, as we realized odd-channel devices are rare (and there’s no real downside to having an unused channel).

We moved the device’s on/off toggle to be more logically placed next to the device name. The “on” state was also toned down, because it needs less attention, while the “off” state was given more color to draw the eye.

As well, we de-mint-ified the app, removing the green background and other green elements. This provided better emphasis to the more important parts of the interface, where color was used in a more exacting fashion.

Going from that first high-fidelity mockup to the shipping version of Loopback 2 required quite a bit of time and effort. Getting the details right took many more iterations, before we could eventually call Loopback 2 finished.

Shipping It

The culmination of this work recently shipped as the completely re-thought Loopback 2. While this upgrade offers many new features, the most obvious change is of course the overhauled interface. Here’s a direct comparison between old and new:


The original Loopback 1 was powerful but extremely utilitarian in design.


While Loopback 2 is polished and refined, to provide both power and ease-of-use.

As you can see, Loopback 2 replaces the previous version’s spreadsheet-esque look with a more intuitive wiring-based interface. It’s now easier to understand how audio will flow through a virtual audio device, and this visualization makes Loopback easier to grasp as a whole. That should make Loopback accessible to even more users, all without sacrificing anything in the way of functionality.

The Future

To paraphrase a line often attributed to da Vinci, software is never finished, only shipped. Loopback 2.0.0 has now shipped, but there are still many more updates and enhancements we hope to make in the future. The new and improved design found in Loopback 2 should provide us with a solid base to build on for years to come.

Designing Farrago

Since I started working as the designer here at Rogue Amoeba in 2015, I’ve contributed to several major updates. However, our new soundboard app Farrago is the first Rogue Amoeba app I’ve designed from the ground up.1 The design process for a new application is very involved, with countless discussions, hours of research, and even plenty of guesswork. A long sequence of hundreds (or even thousands) of little choices is required, with each decision impacting choices made later on. Ultimately, designing a new app feels more akin to pruning a bonsai tree than to simply drawing a picture. The design lives and grows in ways you can’t always predict.

Planning for Farrago began in 20162 with a simple pitch: “We want to provide users with a fast way to play short audio clips”. Building on that, we prepared a rough list of features the app would require, including basic playback, looping, volume control, and much more. With that, we began to flesh out what the app would look like, and how it would work. Farrago went through many iterations to get to the version we shipped late last month. I thought it would be interesting to share a look at a few different parts of our design process.

Early Sketches

From its very first mock-up, Farrago focused on easily arrangeable tiles. The rigidity of other grid-based interfaces was something we wanted to avoid. While many things changed from my initial sketches, there’s still a clear resemblance to the Farrago we shipped almost 2 years later.

The earliest sketch of Farrago I could find. The top bar and tiles were present from day one. The idea of sets on the bottom was abandoned not too much later (phew!).

Early on, we also decided we wanted to split the app into two modes: a nonlinear mode shown as a grid, and a sequential mode shown as a list. To quickly work out a basic transition between the grid and list views, I used Keynote and its indispensable Magic Move transition. This ultra-fast tool provides a quick sense of how an idea will work (or fail).

The five-second movie above shows the first mockup of the transition between grid and list views. We eventually went one step further, making the tiles follow arced paths that don’t overlap as much while transitioning.

Tile Troubles

Farrago’s UI is built around tiles, with each tile containing a single audio file to be played, along with many controls and settings for playback. My initial planning had each tile’s face containing multiple click zones to enable different functions. These early drafts show different click areas for playback, ducking, scrubbing, and editing settings.

Assorted sketches of sound tiles, with controls on the tiles itself.

A good amount of time was spent tweaking the layout of the tile face, but the ideas were all excessively busy. These sketches were fussy, filled with too many click areas and tiny icons. The design went in circles, as I repeatedly tried to cram the functionality I wanted on the tile’s face. We wound up stuck on how this critical aspect of the design would work.

There were a lot of conflicting sketches like this. We couldn’t decide how to proceed.

Ultimately, we realized tiles with multiple click areas were a dead end. Getting there, however, actually required us to reevaluate some of our base assumptions for the app.

User Interviews Cut Through the Clutter

Despite a key element of the app being up in the air, work was progressing in many other areas. Eventually, I knew we needed to figure out a way to solve the problem of how tiles would look. To break out of my rut, I decided to bring in outside viewpoints.

I reached out to my social network here in Montreal, and sought out the sort of people who might use a soundboard app — podcasters, radio folks, theatre techs, and more. I bribed several of them with free lunches, during which I showed them mockups and got their responses.

The feedback I got was immediate and consistent: Prospective users didn’t want to rely on a mouse or trackpad to play clips at all! They wanted to use their Mac’s physical keyboard to play sounds. Though I’d been focused on providing access to many controls right on the tile face, it turned out that mouse-based controls should be secondary.

This pivotal insight gave us a clear path forward, and in fact, it now forms the basis of how we expect Farrago to be used by most people. At this point, we decided the tiles would be mapped directly to the keyboard, and this would be the primary way to trigger sounds. Rather than being cluttered with on-face controls, each tile would consist of one large click area. A simple click anywhere selects the tile, while a double-click provides an alternate method of triggering playback.

The final tile design is all one big click area.

This change led us to move many secondary controls into our Inspector area. In that location, they’re still easy enough to reach, without being obtrusive.

The inspector in its final form.

Close(r) to Complete

At this point, my mockups really started to resemble the Farrago 1.0 we eventually shipped. The keyboard-focused interaction model seems clear to us in hindsight, but it took a serious amount of work to arrive there. The outside feedback we solicited was invaluable in helping us move forward.

A mock-up from spring 2017 that pretty closely matches the final design.

Zooming in on this mockup will show you the ridiculous placeholder names nobody was ever meant to see, such as “Onions” and “Fudge”. Ugh. You’ll also see the code name under which Farrago was developed: Iron Beetle.

The above mock is similar to our final product, though we still made many smaller adjustments and tweaks after this. The value of outside feedback continued to be proven during our private beta period as well, as testers forced us to reconsider more of our assumptions, and make changes based on real-world usage.

While our design was getting pretty close to what we eventually shipped, actually getting it all coded and tested would take many more months of work. From this point though, the design work was more about making things look nice, as well as solving smaller functional nitpicks.

Farrago’s Icon

After the design was largely complete, I took some time to work on nailing down Farrago’s app icon. While the design of the actual application is crucial for long-term use, the application’s icon is often the very first thing people see, and we all know how much first impressions count . Ideally, the icon should be distinctive and pleasing to look at, while also conveying something about the software itself. Farrago’s icon went in several different directions before arriving at its final form.

Most of the iterations riffed on the general idea of tiles and playback in some form. Here’s an assortment of different sketches I toyed with:

Very early rough sketches done on paper or iPad.

A key part of my design philosophy is to put designs in place as soon as I can. I created icons from these early hand-draw sketches, so we could use them in early builds of Farrago. This way, we could see how well they worked in places like the Dock.

One of the very rough hand-drawn drafts actually being used in the app.

Later designs began to look a lot more like what we eventually shipped. The final icon design started out purple, temporarily took a sidetrack into a rainbow neon phase, and ultimately returned to our toned-down final purple shade.

The design on the left looks pretty similar to the finished icon, while the design on the right shows a temporary experimentation with neon colours.

Icon design is less scientific than application design. While feedback on icon designs is useful, in the end it makes sense to just go with what feels best. After numerous iterations, we landed on the final Farrago icon. It’s not too flashy, but its distinct shape and colour make it easy to differentiate.

The final icon design is quite a bit more subdued than its livelier neon predecessor.

A Team Effort

I led the design for Farrago, but I was very lucky to be able to work with fantastic teammates. No designer wants to hear that their design is “impossible” to implement, particularly when the developer actually means it’s merely “impractical”, or even just “difficult”. Farrago’s lead developer Grant never once backed down from hard problems I threw at him. In fact, he frequently went the extra mile to make the Farrago interface really shine.

To show just one example, we could have only allowed dragging tiles into open spots on the grid. Instead, tiles dynamically rearrange themselves when needed, to make space.

As a result, you can do ridiculous stuff like dragging 15 tiles at once, and it just works:

In addition to Grant’s great work, Rogue Amoeba co-founders Quentin and Paul did everything they could to help the project succeed. They served as the final decision makers on the app, but they also gave us the time and space needed to complete the project, while keeping distractions to a minimum. Working as an ad-hoc team of four, with one designer, one developer, and two “editors”, proved quite successful.

Beyond 1.0

After many months of work, Farrago shipped to the world on January 24th, 2018. We’re very happy with the 1.0 version of Farrago, but we also look forward to making it even better. At this point, the design process will be more externally influenced. More and more people are using the app in real situations and giving us great feedback.

Over time, we’ll gather more data and discern trends in how the app is used, and how it can be improved. I’m looking forward to the next iterations of Farrago’s design. For now, we hope you’ll check out the first version of our new soundboard app, and keep an eye out for updates as well!


Footnotes:

  1. In an amusing coincidence, this is not the first app I’ve worked on with the name “Farrago”. That distinction belongs to a now-defunct augmented reality app. ↩︎

  2. The idea of a soundboard app from Rogue Amoeba was actually several years old at this point. Prior to my joining Rogue Amoeba, development was done on a soundboard plugin for Audio Hijack called QuickSounds. This work never made it past the early stages of development. In fact, I didn’t see it until after Farrago shipped!

    QuickSounds in all its glory, circa 2011

    While this app didn’t influence my own thinking directly, years of folks at Rogue Amoeba mulling the idea undoubtedly helped our final product. ↩︎

Our Software