Today I’m going to talk about “look” – well mainly about “look”. This often has a massive impact on people buying or not buying your plug-in.
As an audio developer I spent a huge amount of clock-cycles(machine and brain) on getting the instrument to sound good, where “good” is often more than a bit subjective, but this tends to skew my thinking about “look” – and here I’m talking about asthetics, so NOT (cough) “practical issues”. There’s a whole other discussion about layout, widget choices like combo-box or radio buttons?, what should and shouldn’t be on a given page, but no: here I’m talking about what it actually looks like.
At the highest level this “look” breaks down into skeudomorphic or vectorised. Skeudomorphic is a fancy term for “mimic the real world”, so make the knobs look like knobs that exist in the real-world, in fact make the whole interface look like a real object – I guess we’ve all seen EQ plug-ins that slavishly try and look exactly like a photo of a Pulteq EQ, right down to teh scratches and rust, or the fake wooden ends on soft synths. The arguments for this go like this:
- its a real-world thing, it’s already proven to be a good design, why change it?
- People will recognise each widget(object) for what it is and will expect it to work in the way it does – knobs turn, switches flick etc. etc. Its sometimes called “cultural association” or “cultural mapping”
The counter-arguments go like this:
- Are you sure its a proven best design? There are many many examples in the “real-world” of very very poor interface design. I recommend every user-interface designer read “The Design of Everyday Things” by Don Norman, it’s full of bad real world design. My fave is: any door that has to have a user manual is a failure. User Manual? Yeah having a sign on the door that says “PUSH” or “PULL” is a user manual – you really shouldn’t need it.
- Things in the virtual environment don’t exactly work the same way as in the real-world – you cant actually grab a knob, you are clicking and dragging a mouse, so its not the same and introduces whats sometimes called “cultural dissonance” – its subtle but its there..
- Limiting yourself to real-world styled interactions reduces the flexibility and power you can invest in your interface – look at the image at top – right in the middle is an X/Y pad – sure some synths have joysticks – and I’ve even seen those emulated in software – but actually that X/Y Pad up there is showing two cross-hairs (the blue is user movable – the grey is showing the “movement” added by the randomisation process) so that sorta thing is never really going to work well with a skeudomorphic design.
The argument for and against something more abstracted to the computer interface (what I called vectorised above) are pretty much just those arguments swapped over.
So clearly I went the vectorised route. Nearly everything in the UI is vectorised(drawn by a set of commands not as little pictures of things). A few are not. The knobs for instance, there are some nice features that the dev. lib. I use allow me instant access to if I use “picture” based knobs:
You can shift-click on the widget and it opens a value editor
As you drag over the knob a little pop-up shows you the current value
You can do all this AND have a vectorised knob- using a trick from the ever great David Healey – but its a bit of additional work and I haven’t got round to it – not sure I ever will.
So having decided on this “vectorised” or “clean” approach I’ve spent a huge amount of time on stuff like colours and layout, here as an example is what the Main UI looked like earlier:
Yeah mostly sort of the same but some little changes to make things cleaner, compare the two:
- The preset area has its “loud” colour scheme tempered
- A bunch of controls in the X/Y pad area have been changed and hidden – as well as whole new features added (“Humanise” and “Freq”)
So point 2 here is another example of one of the decisions developer make: hide complexity(ease of use) vs instant accessibility(power). In the old UI can you see those two grey-bar-thingys below the X/Y pad and to the right? Should the user select to have velocity-based modulation applied to the X/Y position – these controls allowed them to set the X and Y range for this modulation. Now they are hidden: if you click the word “Velocity” in the top left of the new UI it pops a window to allow you to set how much effect you want to have:
Same for the Humanise – you get to set the amount in a pop that shows up if you click on the word “Humanise”:
So I’ve traded away visual complexity (a good thing) and lost some functional immediacy (a bad thing). Why this decision? Well it’s mostly about how often you would be changing these values – and I decided not often enough to be seeing them messing up the screen every day, plus the old UI was dealing with just velocity based gain modulation, and the new UI deals with that as well velocity based filter freq. modulation, and the humanisation controls too – so it would be pretty crowded in there.
So every little widget and its placement and how it looks gets a level of consideration that you might not imagine when you’re just looking at the UI from a user point of view, and that’s a good thing – really you dont want to be spending ANY time worrying about that stuff – in the end its what you pay the developer to DO.
