April 21, 2015

Crandall's Simple Steps To Avoid UI Suck...

by Chris Randall

When I gave my talk on UI design for music software at UCSB, at the end of the talk, I attempted to distill my rant to its essence, and provide a simple set of guidelines for uX and UI for plug-ins and apps for musicians. While some of this seems self-evident, I came up with these steps with the idea of providing some insight in to our world for engineers and academics that might not have any experience with professional musicians.

These are by no means Rules™ that must be adhered to, but rather some simple tips to keep your software product from looking like Pd. Basically. I break them all the time, but I have 75+ commercial products under my belt, so I get to do what I want. :-)

Musicians are generally either in a dark studio/spare bedroom/basement or on stage, and generally working in the evening or at night. Looking at a bright white slab of screen can be irritating, and occasionally painful. A UI for musicians should be lighter colored elements on a dark background. The accepted guideline for contrast is 4.5:1 for normal text and 3:1 for large text. In real world RGB terms, assuming a black background, your text should be at least #959595 or lighter. (I prefer lighter.) Dark text and elements on a light background just sucks for the most part, but if you do it, maintain the same contrast ratio for any element that provides information to the user.

Traditional fonts (and yes, I include the venerated Helvetica in this group) were not designed for readability on high-resolution computer screens at small sizes. They were designed for signs and newspapers. Don't use them. Make the effort with a modern display font, designed for modern systems. I am a DIN whore, I won't deny. But you can do far worse than Source Sans Pro, which is free as in your mom, and made by Google specifically for modern high-resolution displays. (Google actually makes quite a few modern display fonts for UI work that are free-ish.)

Unless, in addition to being a top-notch DSP engineer, you're also highly skilled at using 3D modelling software to make user interfaces, Don't Do It. There is a place for skeumorphism in audio software: this place is usually reserved for interfaces meant to ape vintage gear, to provide the user with a familiar experience. So I won't dismiss it out of hand. But it's something best left to pros. You're far better off just making a circle with a little line on it for a knob. It's hard to fuck that up.

When an engineer or academic sort is intent on making a piece of commercial (or professional, at least) music software, he/she tends to get the DSP done first, then put a UI on it during or after the process. This results in a product that doesn't have a holistic feel. It is far better to codify your initial DSP idea, then design and code a full UI, then fit the DSP in. There's no law that says you can't change the UI during or after the process, but it really helps make a better product when you're building to a set goal, rather than "seeing where things lead." Sometimes, that's unavoidable, but you should really see where things lead before you draw the first pixel.

Designing products for musicians, if you're not one, results in bad products. You wouldn't want to buy a car designed by someone that doesn't drive, would you? There are... well, I won't say "standards," but there are ways of doing things in the music world that can perhaps go against normal uX conventions, and if you've never made music for money, in the studio or on stage (preferably both) then you should get somebody in your Circle of Trust that has, and does. And I don't mean at the beta-test stage. I mean as soon as you have the UI coded. Fitting the DSP in to a musician-friendly context is much better than trying to make a scientific/academic chunk of DSP musician-friendly by brute force after the fact.

Anyhow, these are just ideas that some may find helpful. If I'm way off the reservation, or other designers that read this blog have some different (or better) ideas, by all means hit up the comments.


Page 1 of 2

Apr.21.2015 @ 12:06 PM
I think Ableton Live really follows your design rules. Now if they could figure out a browser that wasn't braindead and could search on audio file metadata ...

I haven't really messed with it much but a lot of people have been messing with 'look cool in the dark' skins, i.e. link [www.unit27music.co...]

Apr.22.2015 @ 12:09 AM
UX/UI designer of 11 years here, I mostly work on web apps and enterprise software. Love this article, thanks CR. I'd add:

6. It's 2015; we've got touchscreens
Touchscreens make using a DAW much, much easier. If your plug-ins are easy to use on a touchscreen too, then they're more likely to be used. Some light reading about touch friendly designing here: link [www.smashingmagne.co...] . Basically, make things larger than you think, and don't group huge banks of controls together where you're likely to mis-touch.

Apr.22.2015 @ 3:29 AM
Really not keen on the trend to white lettering on black. Much prefer dark grey on grey for the same reason this web page is designed that way around - it's just more legible. At least not BLACK black for the whole back.

Admittedly I'm mostly on video production software where there's 1000 named widgets but white text just hurts my eyes after a while. And the different gamma on Mac/PC/sRGB/AdobeRGB screens means all kinds of Dracula Was Here.

Apr.22.2015 @ 4:08 AM
Tom Whitwell
#4 is one I've found really useful in hardware design. I work out what knobs/switches I want, then try to build the simplest possible circuit that will make those knobs/switches useful, AND DO NOTHING ELSE.

I wonder if #6 is not doing things just because you can. Anyone you show your creation to will often jump straight to 'that's cool, it could do xxx' and you end up with link [media.soundonsond.co...]

Apr.22.2015 @ 8:40 AM
I'd dispute #6, having to use a DAW with your fleshy appendages is anything but 'easier' in my experience. Imprecise editing, 'dumbed down' UI to accomodate the bigger controls etc. Maybe in the future when the technology has matured and we all have large, flat touchscreens.

Agree with the rest though personally prefer dark-on-light; maybe it's an eye thing like how some people can't see 3d in movies. I find looking at something like Logic or Reaktor much more stressful on my eyes than a lighter Ableton scheme for instance.

Apr.22.2015 @ 12:50 PM
I think #4 is the most interesting step (although it is tied in with #5 in my mind). Earlier in my career, I tried to figure out how to design a GUI that could accommodate a great deal of complexity. It turns out it is a far better idea to simplify the concept so that a simpler GUI can be used, for a large number of reasons (including #5 of your steps).

Apr.23.2015 @ 9:48 AM
Was "make sure it's legible on both high and standard res screens" left out because it's too obvious? Seems like the most common complaint I see about UI's lately has been "it's too small on my retina display" and "make it scalable."

Apr.23.2015 @ 11:35 AM
Chris Randall
Well, that's an interesting problem. The whole high-resolution trip is relatively recent, and most plug-ins take quite a while to develop. You don't really want to switch GUI SDKs in mid-stream just for the hell of it.

The plug I'm working on now, I'm trying out writing my own vector UI lib, so that this won't be a problem down the road. The following statement should be taken in the context that I generally find building UIs in whatever kit, either procedurally or with bitmaps, to be a fairly simple matter:

It is really, really hard.

So, don't come down on people that don't do it. At the end of the day, both OSX and Windows are moving targets, and we have to pick a spot to land on with any given product.


Apr.23.2015 @ 11:28 PM
I really dig scalable GUI. Doesn't have to be Valhalla DSP and Madrona Labs scalable. Just a couple choices in small/medium/big like U-he or Fabfilter do on their plugins

Apr.24.2015 @ 7:18 AM
Chris Randall
That is much easier, and what I'm going to try to implement on our stuff from here on out.


Page 1 of 2



Sorry, commenting is closed for this blog entry.