What’s going on with skeuomorphic design for music software?

What will nostalgic, skeuomorphic design for music software be in the year 2050? 3D renderings of iPads within virtual reality?

I sometimes doubt my own knowledge and music ability when I’m faced with complex user interfaces in music software. I think to myself, “I should know this” followed up with, “I think I should know.” I find this especially true when confronting skeumorphism.

I don’t own any vintage equipment. I rarely interact with classic devices. This isn’t motivated by a lack of interest but instead is a combination of pragmatism and my pocketbook. I do understand that classic equipment plays a significant role in music production and audio engineering for many reasons. This is often expressed through software user interfaces. A sense of value, physical metaphors, and stylized tone are often expressed through a user interface. Skeuomorphism seems to stress all those qualities but I question whether we are being short sighted.

I am attempting to write a series of articles on the subject of user experience and UI design within DAWs but I wanted to cut to the chase of my thesis briefly in this post: Physical representations in UIs need to be more forward thinking to compensate for lost metaphors and the profound influence UIs have on user experience. In other words: Should we be more beholden to authentic hardware or to newer user experiences that can enhance creativity? How do companies strike a balance?

Let’s not stumble towards skeuomorphic representation in the future. Let’s plan for it. Vintage equipment of the past will create more obscure UI metaphors of the future.

There are many hobbyist and amateur music producers who may never have access to the vintage analog equipment represented in some software. I find that this issue needs to be confronted for the long term. The affordances that are expressed through physical hardware may not always translate to a GUI. Especially when such physical interaction is increasingly abstract.

In the example below, the item outlined in orange is a style of a physical button that I have not seen in probably 10+ years and I am 34. I have my doubts as to whether a 20 year old producer has seen this type of knob/button either.

Skeuomorphic Design in Music Software

If we were to analyze the clues of this physical interface item we could discuss the curved front that seems like a perfect placement for a finger or thumb. When I last recall using the physical counterpart, I remember that despite its curved front it could not be pressed in on either side. It was not a toggle. In fact it could sort of wiggle from left to right but always returned to center. During my first time using this type of interface I realized how ingenious it was that the curvature was perfect for gentle motions with just one finger.

Fast forward to today and we have to ask ourselves, “are the affordances of the original physical button evident as a GUI item?” I haven’t performed any tests but upon asking one person, my girlfriend, she deduced that it must be a toggle: you press on one side or the other. She reached this conclusion due to its curved shape.

Let’s be honest. It looks CLOSE to a light switch but it is not. This is where skeuomorphism gets messy.

How does that GUI item actually work? You click on it once–anywhere. You don’t drag side to side as you do with the original physical item. It actually is a toggle but not in the way previously described. It offers an On/Off state but it offers no visual feedback regarding a left or right side being on or off probably because the original physical item has no such states.

What will physical representation of music equipment be a few decades from now?

How do we guide producers and musicians along the way? Let’s not stumble towards skeuomorphic representation in the future. Let’s plan for it. Vintage equipment of the past will create more obscure UI metaphors of the future.

Many musicians interact with production in many more ways than before. I myself am already planning on experimenting with music production in virtual reality. It’s for those reasons that the critical use of the right metaphors has to change with time. We already have many musicians comfortable with modern forms of human-computer interaction such as touch, swipes, pinch, drag, etc. This need not remain exclusive to the realm simple smartphone apps.

I am not suggesting we create new software that arbitrarily uses new forms of interaction. I am suggesting future producers will be most familiar with interaction experiences of 2016 rather than 1960. So software user interface design needs to work with that in mind. Plan for that, as I suggest. But how?

I believe some visual metaphors need to be phased out or better implemented. Within the example the buttons outlined in orange should be clear toggle buttons. This software does offer toggle buttons though. The item highlighted in yellow is an example. Do you see it? That’s a toggle switch in the down position. My test subject did not recognize its visual cues. Let’s unpack why that may be.

In the software the top portion of the toggle switch is a few shades of beige, brown, and eggshell. The rectangular portion overlapping the circle represents the top of a switch. One problem we have here is that height or depth is not visually clear. It is not evident that there is a portion of the interface positioned above another portion in any significant way. It’s also not clear there is a cylindrical component connecting things. Basically you can’t see a switch at all.

In my opinion the fastest way to resolve this is to emphasize the down state by visually communicating that the cylindrical portion of the switch is present and pointing downwards. In my example below you can now see more of the switch. This improves the visual communication.

Made this in ten minutes

But let’s return to my original thesis that skeuomorphism requires a different assortment of questions. Using our switch example if we visually communicate a clearer toggle switch we’re confronted with a visual element that takes up more vertical space. This has the potential to pose problems.

What if we needed words to explain both states of a toggle switch? Should we move the words higher above and lower beneath the switch so that visualization doesn’t overlap? It overlaps in the original software.
What if that took up too much space when the text is placed differently?

In the images below we see the risk of having the visual switch overlap the text. It inhibits some understanding of the interface. Within the “on” and “off” examples we now have extra space between the words and switch. In design, proximity is often used to suggest relationship. We are losing a sense of proximity in the “on/off” examples.

switch4 switch_on switch_off

There’s a way to resolve this: don’t use the visual metaphor of this type of switch.

However if we return to my initial point, how do you avoid this in nostalgic, skeuomorphic design? If you’re copying a vintage item that has this switch do we need to be authentic or more communicative? There is value in mimicking a beautiful item but maybe too many user experiences suffer as a result.

I don’t have the data on this but I aim to argue, eventually, that the interface has a profound influence on creative output. This simple switch can make the difference between a musical parameter being used well or even at all. Imagine that the proper usage of a musical parameter can be heavily influenced on whether the user even understands the interface. The impact it could have on creative output should give any musician pause.