Hannes
If you know my work for Mutable Instruments and other modular synth companies, you know that I’m a big proponent of substituting text with symbols or icons. The reason is very simple: text takes up a lot of space, often adds clutter while not necessarily being more obvious.
But first of all, some disambiguation. The little images we use in place of words can be described using a wide range of names: icons, symbols, metaphors, pictograms. In semiotics they are generally divided into icons, indexes and symbols.
Put very simple, an icon is a visual representation of the thing it stands for, an index shows evidence of the thing it stands for, whereas a symbol does not resemble it in any way. You need to learn to read a symbol to understand its meaning.
To keep things simple, let’s focus on just icons and symbols. Symbols we use every day are for example the letters of the alphabet. On the other hand, the little little camera drawing, which you tap on to open the camera app is an icon (it looks like a camera). To make some more musical examples: the kick drum drawing that represents a kick sound is an icon. Three stacked notes to represent a chord are a symbol.
Confusingly, the little images you click or tap to launch an application are called icons, even when they are symbols. The floppy drawing you click to save your work, went from being an icon to being more of a symbol, at least for the younger generation. The commonly-used function-plot of an envelope’s amplitude over time could be both a symbol or an icon. The distinction is not always clear and there’s many graphical signs that live in a grey area.
We learned that we are supposed to plug modulation sources into the inputs labelled “CV” and that a “VCA” allows us to modulate the amplitude of a sound. For the the non-initiated these bits of text are completely meaningless, or could mean the wrong thing: “why does this module want to know about my curriculum vitae?”
There is of course electronic instruments who are completely devoid of labels of any kind. For example synth designer Peter Blasser, best known for Ciat Lombarde, likes to completely avoid any kind of labelling on his instruments (but uses colour coding extensively).
No labelling means you really need to learn to play your instrument. We don’t put stickers with note names on our piano keys after all, except maybe when we’re kids and we’re just starting out with music.
I find that idea very fascinating, and I can see how this can work on a self-contained instrument, but it seems a bit extreme on something like a modular synth. The complexity and variability of the interface is just too much. In fact Peter Blasser’s modules (released under Ieaskul F. Mobenthey) extensively use icons and text labels.
One key aspect is still valid though: to be able to play an instrument, any instrument, you need to learn it first. Also instruments want to be explored, ideally over a longer period of time, and they should be inspiring. The learning curve can be flatter or steeper, but it should not be a chore. Ideally instruments should be fun and rewarding to learn and explore. There’s various things we, as designers, can do to ease and support the learning process, for example by carefully designing the labelling.
Icons and symbols often have an edge over text. They do a great job at reducing the visual clutter and work where text would not fit. Some of the panels we designed don’t use any text at all.
At the same time icons and symbols are a valid mnemonic that help you to remember what the hundreds of knobs, buttons and jacks in your modular actually do. This is the core point of my thinking: labels are not there to explain what a module does, they are here to help you remember. They support you with the complex task of learning how to play the instrument.
For this reason, they don’t need to be completely obvious, although they should also not be confusing, or allow for too much interpretation. In some cases you can use a graphic that visually represents the function or action related to a control (i.e. an icon). Other times you need to rely on symbols.
Icons generally are easier to read and interpret, while symbols can be tricky. Sometimes they are widely understood, but that can change quite radically depending on the age of the person, their geographical location and cultural background. While the article I’ve linked above claims that there is such a thing as a “universal icon”, I would argue that they don’t really exist. I know enough people above 65 who are not able to read the play symbol (the triangle pointing right). To them it’s just a triangle.
Symbols can be learned though, and playing an instrument should ideally come with a higher learning motivation than operating a DVD player.
The challenge is to find icons and symbols that will be as widely understood as possible and make sure that they are unique looking enough so they can function as a mnemonic on the long turn.
Some time ago I asked this question in the Mutable Instruments thread on lines: “what is your experience with Mutable modules, specifically in conjunction with the icons?”.
I got 140 answers. Admittedly this is not enough to be statistically accurate and my poll answers where probably biasing people a bit. Still, the discussion that followed was very interesting and gave me a feeling of how well I did with the icons and symbols and how they work in general. Here’s the results:
But let’s also see some practical examples shall we?
Plaits is probably the Mutable Instruments module with most icons/symbols on the panel. There’s one icon for every mode, plus a few more.
Plaits has 16 synthesis modes, covering quite a bit of terrain. You have classic analogue waves, FM, wavetables, modal synthesis, noise, etc. A synthesis algorithm can be quite an abstract thing. How do you represent something like “Granular formant oscillator” or “Particle noise”?
For some modes (eg. the drum sound modes) we could use actual icons. Other times we used icons that were related to one of the words in the mode’s name (eg. we used a cloud for the “granular cloud” mode) or we relied on the visual representation of the waveforms. To further help the user to remember which mode does what, they were grouped based on common traits. Noise and physical modelling modes are all on the right, with the noise ones being on top and the physical modelling ones on the bottom.
Putting the complete names on the panel would have been impossible, the only alternative would have been to use a display, but that is something Émilie didn’t want to do, and for good reason. Displays come with their own set of UI challenges and disadvantages.
To get back to the Alright Devices modules, those ares a bit more extreme maybe, because we replaced common text labels like for example “cutoff” or “resonance” with symbols. The advantage here was that the underlying functionality is well known. You don’t have to explain to most people how a filter works. You already know that one knob changes the cutoff and one the resonance. Replacing text with symbols is not requiring as much cognitive effort from people as when doing it on a module with a less established functionality, although it can potentially be disorienting at first for the exact same reason.
If you ask me if one “should replace all text with symbols/icons?”, my answer would be something between “maybe” and “it depends”. While the benefits of symbols and icons are added visual personality and less clutter, the benefits of text are immediacy and being a more established, standardized language. The choice depends a lot on the overall visual style, if the icons or symbols can work as a mnemonic and if their benefits outweigh their shortcomings for the specific application.
This is it for now. It’s a complex topic and I’m sure there’s some I am missing here. Design Clipboard is a way for me to share my notes and thoughts, but doesn’t want to be a design manual in any way, so that’s ok. Also, this is a bit of an ongoing research I’m making. Maybe I’ll post an update on this in the future.
