Under The Microscope

Rogue Amoeba’s 2018 Status Report

In January of 2017, I posted a summary of our 2016, and a peek at plans for 2017. With today’s post, this becomes an annual tradition. Read on for a roundup of what happened in 2017 and a look at some of our plans for 2018.

Recap of Releases

SoundSource IconThough neither was a major product launch, we actually shipped two new apps last year. On Valentine’s Day, we gave our users the most romantical gift of all: sound control software. The audio device control functionality from the then-retired SoundSource was merged with LineIn’s play-thru ability and modernized to create SoundSource 3. The best part? Rogue Amoeba customers who own a current license for any of our other apps are eligible for a free license to SoundSource 3! If you’re not up-to-date, now’s a great time to get the latest, then take advantage of the free SoundSource offer as well.

Our second new app came about as the result of some unexpected changes made by Apple. In late March, a tvOS update from Apple broke Airfoil’s ability to send audio to the Apple TV. Shortly after, we shipped a new tvOS app called Airfoil Satellite TV. This served as an interim solution for streaming audio to the Apple TV while we worked on restoring compatibility directly within Airfoil.

Fortunately, we were able to work around Apple’s changes, and we released Airfoil for Mac 5.6 and Airfoil for Windows 5.2 to restore full Apple TV compatibility. With these updates, the Airfoil Satellite TV app became largely redundant for the time being. However, it will continue to exist as a fallback. If Apple again breaks the Apple TV’s AirPlay compatibility, Airfoil will still be able to send audio to the device.

Fission IconOne other release worth noting was version 2.4 of our audio editor Fission. This update also resulted from changes made by Apple. The new iTunes 12.7 utterly broke the ability for any app to make custom ringtones for iOS devices, even Apple’s own GarageBand app. Knowing how much users love this feature, we worked quickly to restore it. We also posted instructions for using custom ringtones with newer versions of iTunes, whether or not they’re made with Fission.

Of course, we shipped plenty of updates for all of our applications, with a total of 33 releases last year. This was actually our lowest yearly total in almost a decade, however. This reduction in releases was largely due to a lowered need for bug fixes, which is always a good thing. We also had a larger-than-average amount of work in progress that didn’t ship in 2017, and I expect our raw number of releases will jump back up in 2018.

The Newest Amoebas

We made multiple hires last year to keep our team strong and productive. In June, we hired Andy Taylor to work on Airfoil for Windows. Since then, he’s worked to ship the necessary updates to restore Apple TV compatibility and fix other minor bugs. We’ve still got more in the pipeline for Airfoil for Windows, including the long overdue support for Chromecast, so stay tuned for more updates.

Later in the year, Robert Charlton joined us as we doubled the size of our support team from one full-time tech to two. This larger team continues to provide fast and friendly help, but also has more time to refine and improve our support site, manuals, and backend processes. All of this will allow us to provide ever more solid software.

Other Major News

In February, we posted the results of removing Piezo from the Mac App Store. Piezo actually earned more revenue when it was available exclusively through our store than it did when it was also available in the Mac App Store. That’s a nice outcome, but the far greater benefit to leaving the Mac App Store was that it allowed us to improve the quality of Piezo. Given the convenience the Mac App Store could provide, it’s unfortunate how poor an overall experience many developers have had with it. Fortunately, direct distribution of software is easier and more convenient than ever. In fact, in 2017 we also switched our entire store over to use Paddle.com for payment processing, with very few issues.

At June’s Worldwide Developer Conference, Apple announced the new HomePod, which is finally arriving this week. We’ve confirmed that Airfoil can send audio directly to the HomePod, so you can stream any audio from your Mac or PC to the HomePod, right out of the box. We’ll be updating Airfoil to improve compatibility, so watch for updates in the near future.

Apple also announced a new AirPlay 2 protocol, which they have since delayed. There are many open questions with AirPlay 2, and for now, we’re all waiting for more from Apple. Worth noting though is that Airfoil can already match AirPlay 2’s announced ability to stream to multiple devices, all in sync.

In September, we celebrated a rather momentous occasion, our 15th anniversary. It was fun to look all the way back to the very first version of Audio Hijack, and to reflect on how far we’ve come. We plan to be here providing great audio software for many more years to come!

The Future

We’re always tight-lipped about what we’re up to for the future, but I’ll share what I can.

Farrago IconLast year, I teased a new app codenamed “Iron Beetle”, which has now shipped as our new soundboard app Farrago. We’ve been getting lots of great feedback already, and we’ll use this to help guide the development of Farrago updates in 2018.

We also expect to ship a major Airfoil for Windows update in the near future. This was discussed last year, which means it’s quite overdue at this point. Progress was slowed by the Apple TV issues we had to work around last year, but we’re still working hard on support for Chromecast.

Our work on big updates for Loopback has progressed well, and we hope to have more to share later this year. We’re planning to offer even more power coupled with a more polished user experience. For now, here’s a sneak peek at some interface improvements we’re working toward.


More to come!

We’re not currently planning the release of any brand-new products in 2018, so we’ll instead be focused on updates for our existing apps. That will include new features and functionality, as well as more run-of-the-mill bug fixes. We also always plan for updates for Apple’s nearly-annual MacOS release (this year’s name guess: “Sequoia”).

Stay Tuned

You can keep up to date with our latest news in several ways:

We can’t wait to share more with you in 2018. For now, I hope the new year is treating you well. Stay tuned for updates from Rogue Amoeba!

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. ↩︎

Meet Farrago, Our Great New Soundboard App!

Today, we’re delighted to unveil a brand-new product! Our new soundboard app Farrago offers the best way to quickly play sound bites, audio effects, and music clips on your Mac. Podcasters can use Farrago to include musical accompaniment and sound effects during recording sessions, while theater techs can run the audio for live shows. Whether you want quick access to a library of sounds or you need to run through a defined list of audio, Farrago is here to assist!

We often use a wealth of text and images to show off a new product. This time, however, we thought we’d let Farrago introduce itself. Check out this quick one minute movie for a great overview of the app:

If you’ve used a soundboard app before, we think you’ll find Farrago familiar in its power and capabilities, yet refreshingly well-designed. Fast triggering via keyboard or mouse is coupled with robust playback options including fades, adjustable in/out points, and more. Meanwhile, the ability to customize unlimited sets of tile-based audio makes managing your sounds a breeze.

The end result is a powerful tool that’s still powerfully simple-to-use. Performers of all stripes can turn to Farrago for their on-demand audio playback needs.

A Great New Podcast Teammate

Farrago’s not just a skilled solo artist either. It also teams up splendidly with other tools in our software lineup. If you host a podcast, you can use Farrago alongside our audio routing tool Loopback to send all your audio to VoIP apps, such as Skype.


Loopback can combine audio from Farrago and your microphone, then get it to Skype

The setup for this is a breeze. Use Loopback to make a virtual device which grabs audio from both your physical microphone and Farrago. That virtual audio device, shown below as “LB: Mic + Farrago”, can then be set as the microphone source in Skype. Everyone on your call will then be able to hear the audio from both Farrago and your voice.

Of course, you can record this with our own Audio Hijack. With the above setup, setting it to record Skype will give you a file that includes everything you’d want: your voice, your remote caller’s voice, and Farrago’s audio.

With Farrago and our other tools, you can make your podcasts richer, with songs, interview clips, sound effects, and more. We hope Farrago can become a valued part of your podcast setup. Let us know how it goes!

Try Farrago Now

Visit the Farrago page to view more details and screenshots. As always, you can download a free trial and test it out. Better still, for a limited time, everyone can save over 20% with our introductory price of just $39!

We’re excited for you to get your hands on this new tool, and to hear how you use Farrago. We hope you’ll check it out now!

Get Started With Farrago

Usability Nightmare: Hawaii Emergency Management Agency’s Alert System

It’s been a few years since our last Usability Nightmare post, but today’s particular design disaster is definitely worthy of being featured. You’ve likely heard about the recent false missile alert in Hawaii, which scared the heck out of a whole lot of people. Over at Dev.to, Ben Halpern had a good overview of the general issue, correctly noting that this was almost certainly a failure in design.

Today, Hawaii’s Emergency Management Agency (HIEMA) released an annotated image showing the system which was used.

Screenshot of a confusing text-based interface
An incredible trainwreck of a design

The same selection screen contains both drill and real options, in extremely close proximity to one another. The naming of these options is inconsistent, and often opaque. Further, there’s no grouping to differentiate items. While there was a confirmation screen after this, it seems certain that it did not fully spell out what would occur. All of that led to literal panic in the streets.

This false alarm wasn’t even the worst thing which could happen as a result of this terrible design. While it caused a great deal of distress, there were no serious injuries reported. Far worse, and clearly possible, would be for someone to accidentally select the “Drill” option if a missile actually were inbound. In that case, no alert would be sent to the public, and the devastation could be greatly amplified.

Just a few minutes of time from a designer with even minimal experience could improve this layout dramatically. Here’s hoping HIEMA improves things, and that other agencies take notice as well.

Meet Our New Support Tech, Robert

Here at Rogue Amoeba, we take great pride in offering top-notch support to our users. Whether you’ve already purchased one of our apps, or you’re just considering it, you can always email our support team. That’s the best way to get help, provide feedback, and much more. Today, we’re pleased to announce the addition of Robert Charlton to our support team! Today actually marks Robert’s first day as an official employee here at Rogue Amoeba, but he’s been helping customers for many weeks already as a contractor.

Customers really shouldn’t notice much difference at all, because we’ve always sought to provide fast and friendly help, and Robert is helping us continue that quest. Earlier this year, we decided to increase the size of our support team. We wanted to be able to assist more customers in less time, while also working to improve our software and support systems. Our larger support team will now have more time to answer email queries, refine our support site and manuals, and improve many of our backend processes. All of this will allow us to provide ever more solid apps.

In Rogue Amoeba’s infancy, I spent part of my time handling our support via a simple email client. Over time, that job grew until we needed to hire a full-time support tech, and utilize a full help desk backend. We’ve now got multiple techs working to help our customers. The support team’s work isn’t quite as obvious as a flashy new software release, but it’s still vitally important, and we’re delighted to have Robert joining us!

Our Software