Ferrite Design Evolution
Part 1
To look at how Ferrite Recording Studio’s design evolved, we need to go back, waaaay back, to late 2012/early 2013, when I was doing some user-interface experimentation.
I’ve been wanting to make a more DAW-like audio editing package for a long time, but I wanted to get the user interface right. Desktop DAWs have always been designed with the precision of the mouse (and lots of keyboard shortcuts) in mind. This is awkward on devices where you’re using fingers to edit on a touchscreen.
On the flip side, Mobile DAWs have often had very “modal” interfaces, where you have to keep tapping between different modes: in this mode you can move things, in that mode you can select things to be moved, in this other mode you can cut things, in that other mode you can fade things, and yet another mode just to pan the view around, and so on. You have to keep swapping to get anything done, slowing the whole process down.
Shiny
So a few years ago, I did an experiment (codenamed “sliceology”) that was the bare bones of a DAW user interface. It wasn’t a real app, just a UI “playground” to test out some ideas. There were no projects, you couldn’t import, record or even play back audio. There was just some hard-coded fake audio data rendered into clips that you could move around and adjust.
The idea was simply to prove to myself whether or not a better DAW interface was possible on iOS, streamlined without sacrificing features. It’s not an easy task. With just (relatively-inaccurate) finger input, no hover states, not a lot in the way of “Ctrl”/“Alt”-style modifier keys, you need to be able to discern whether the user wants to:
select or unselect audio clips
move audio clips around
scroll around the project
zoom in or out
cut or join clips
adjust the starts or ends of clips
fade audio in or out
add, delete, and adjust automation points
…all packed together on a series of tracks. Apple guidelines recommend no less than 44 pixels square for a hit-testing zone, but that’s a problem when you’ve cut audio down to smaller clips, or they’re lined up next to each other.
I believed you could address a lot of these issues with a combination of carefully-chosen iOS Gesture Recognisers, and a system of assigning a score to possible actions/targets based on various factors, instead of the default iOS system of “first gesture that could possibly work, wins”. It turned out, this worked pretty well.
It was also shiny. Very, very shiny. No, shinier than that. This was in the iOS 6, skeumorphic days of “realistic” shiny textures. Don your peril-sensitive sunglasses before clicking through:
I know, right? My eyes, the goggles do nothing etc.
Snowball
From a user-interaction point of view, it was a successful experiment, but it was around this time it got put back on the shelf, while I went off to make Mitosynth.
See, one of the factors I consider when planning projects is “how do I get there from here?”. Put another way: there are projects I want to make, that are ridiculously ambitious. There’s no way I could just go out and make them, because it would take many years, and Wooji Juice is entirely self-funded and based on trying to make useful or fun things that people actually want to pay for, not some kind of VC-backed “eyeballs play” (ick).
But what I can do, is find elements that can be developed on their own as smaller projects, then rolled forward. I call it “snowball development”. You just keep on rolling it up and it builds and builds and eventually, you’ve really got something. And here’s the thing: you can’t make a DAW with no sound engine. And, by its nature, a DAW needs a powerful and flexible sound engine.
But you can make a sound engine without housing it in a full DAW. For example, by making a powerful and flexible synthesiser.
Just before I dove into that full time, as part of the process working towards Mitosynth’s flat design, I was trying out some other flat interface ideas, just to get a feel for the different constraints of the flat design space. And that included some flat DAW ideas.
Flat-ish
Flat design is a curious thing. On the one hand, it has the potential to be a more level playing field: you don’t need to invest lots of time and resources in photorealistic textures, its simplicity can work in favour of smaller developers like Wooji Juice.
On the other hand, it can also be really hard to get right without looking seriously fugly. It has a lack of visual cues to help users get oriented. Plus, even when carried off well, it can easily look bland, cold, brutalist, or just cut-price.
One of the solutions I came up with – in both Ferrite and Mitosynth – was to go “almost flat”: a primarily flat design with one or two elements that are subtly shaded or textured. In Mitosynth, it’s the background and the “cells”. In Ferrite, some of the large flat areas of colour have subtle gradients to them.
I stumbled across this back in early 2013 working on those flat DAW experiments, with this, the first piece of flat(-ish) design I created that didn’t suck:
Surprisingly familiar, right? It’s not (quite) Ferrite, but there are a lot of familiar elements:
The slate grey, subtly-shaded background
The slim, slightly-golden icons
The glass sidebar allowing the underlying track to show through
The blue variant on Mitosynth’s dials
The large central time display & progress bar
The simple triangular play-head merging into the bar above it
An interesting side-effect, almost an optical illusion of this design, was that the colour of the icons somehow lent warmth to the background, and in combination with the shading, made it seem a little more like stoneware rather than just a boring flat grey background. In fact, “Ceramic” became the internal codename of the app, as a result.
Ferrite For Real
So when, much later (in the autumn of 2014) I started thinking seriously about creating Ferrite, I already had a decent starting point. I worked at iPhone scale, for the same reason as with Mitosynth – it’s a lot easier to scale up to iPad, than to cram down to iPhone.
So here’s where the iPhone mockups started, fiddling about with what should be light and what should be dark, and worrying about contrast ratios:
The way I tend to work these things is to start with a crude version, iterate lots of different variations, homing in on something that “clicks”, and when I find it, start a new sheet with that image and begin the process again, through generations of unnatural selection.
Iteration, Iteration, Iteration
Some notes about these versions:
Initially, there were 6 controls in the sidebar, but really, deleting tracks isn’t something you need to do often enough to justify having a button for it on-screen all the time. Similarly with Ducking: you typically set up the duckable tracks at the start, and then forget about it for the rest of the project. So both are now inside the tools menu. Unfortunately, this meant getting rid of the duck icon. (Sad Quack.)
With any complex app, there’s always a tension between simplicity and power. You’re always trying to make it as clear as possible, while still retaining the app’s features. One of many ways this manifests is in the design: it can be “clearer” (in the sense of “more explanatory”) to use extensive labelling and highlights to call out different aspects of the app. It can also make it look like an explosion in a widget factory, which then makes it less clear again, but in a different way: with so many things competing for your attention, it’s harder for your eyes to pick out what’s going on.
An example of that here, is taking out the arrows on the cropping handles. Likewise, a design for the selection that stood out enough to understand & keep track of it, without it being so “loud” it was distracting.
Towards the end, I redesigned the toolbar, moving Import out to become a peer of the Add New Track button (necessary for the smaller-sized iPhones, and also it made more sense with how the command’s used) and reorganising the forward/back/play buttons with a more traditional “cassette deck” layout and iconography.
The big ugly popup menus were because I was (and still am) a little unhappy with the standard iOS popup menu for selections (Cut, Copy, Paste etc). It works great when there are only 3-4 items, but as you add more features, it turns into this awkward situation where you’re using arrows to page through about 2 items at a time. I stuck with them for now, but as more commands get added, I may yet redesign this at some point down the road.
I was unsatisfied with the sidebars throughout these iterations. They’re all dark with light controls on top, because I wanted the consistency of having a single “interactive” colour (the tintColor in UIKit terms) for the app. Consistency is a good thing for helping users understand an app, but when I took a flyer on a light sidebar in the final iteration, it was so obviously an improvement, that I relaxed that restriction instead.
On Final Approach
So then I set about doing a new set of iterations based on the light sidebar. With the addition of the “swipe to hide” chevrons below the sidebar, this starts to look a lot like the final version of Ferrite.
Most of the rest of this sheet is working on designs for additional elements like the way undo/redo is combined on the smallest screens, and trying to make an automation track that didn’t suck.
There are a few changes left before the final version: the Undo/Redo buttons were updated, because with iOS 9 previews, Apple revealed their own “U-turn”-esque design for a standardised Undo/Redo icon in the new software keyboard. And (as part of a series of changes that I’ll hopefully come back to in a future post) I ended up expunging the “gear” button in favour of the spanner/monkey-wrench “tool” icon.
Also, despite how standard using “❮ Back” is on iOS… I just couldn’t in all good conscience have an entire toolbar where every single button was some variation on a theme of an arrowhead. :P
Not only that, but it lead to confusion when you have pop-up panels open (like the Ducking or Strip Silence control panels), since those are non-modal in Ferrite: you can continue to pan, zoom, and use the toolbar to undo, redo, play, rewind, and fast forward while editing those panels, and they need their own “Done” button, and having two Done buttons at once is A Bad Idea. I ended up going back to the Document icon, with a checkmark to indicate Done-ness specifically with the document. Not the best option in the world, but better than the alternatives.
And that leads us up to our final design:
That’s all for now – I have some big updates coming up, but once those are taken care of, I hope to find time to come back and look at the design of the rest of the app.