looking for a few good ideas
  amongst the irregular verbiage

The Value Slider (III)

Mon, 28 May 2007 09:36    in Studio, Computers

This discussion began here, and continued here.

A modest proposal: Virtual audio hardware manufacturers should define and agree to use some additional standard controls for their user interfaces instead of inventing their own widgets. It's Anarchy in the UI out there... the causes for it are reasonable: 1) the standard dialog controls specified by OS vendors such as Apple  and Microsoft are boring, incapable, or not compact enough; 2) they are trying to distinguish their products from others; 3) their intent is to make their software mimic the UI of the original hardware that they are modelling.

This discussion is an attempt to address reason #1. I think reason #2 is not valid. Guys, make your products excellent and usable, and believe me, you'll be distinguished from those that don't. One way of making your products usable is to use standard controls in your editing interfaces!

Arturia's CS-80V is a case in point for reason #3. The software mimics the original front panel of the Yamaha CS-80 synthesiser religiously, and looks great. Except when you try to edit a patch, and then it's horrible.

There's a fourth reason: multi-platform support. It is very hard to use standard UI widgets when you are also trying to write software for Macintosh, Windows, and perhaps Linux as well. Much easier to roll-your-own controls. That's no excuse to ignore standard behavior, though.

I think there is room for a middle ground, where virtual hardware interfaces can be designed to look good, resemble the source hardware where appropriate, but use standard controls to improve usability. All we need is a couple more standard controls: a Value Slider, and a Toggle Button. In this post I'm going to look at how a Value Slider control could express the principles of UI I established last time. Later on I'll look at the toggle button.

The Value Slider

Sliders already exist in most standard GUI toolkits, but they are not ubiquitous, and I don't want to be constrained by their default specified appearance. So here's ours:

It consists of four main visual components: a perimeter rectangle; a colored bar proportional to the value of the control; a handle widget to grab with the mouse pointer to set the value; and a label that displays the value in text form.

When the slider is adjusted with the mouse, I recommend that a tooltip or similar metaphor is used to display a more precise value (see above).

So the control expresses its value in three increasing levels of detail: 1) the size of the colored bar; 2) the value displayed in the control, and 3) the more precise value displayed in the tooltip.

Color and Clarity
We've got some flexibility here. We can decide not to show the text representation of the value if we like, or move the text display to the other end of the control when the handle would otherwise obscure it:

We can use color to relate and distinguish controls. We are also not limited to a horizontal orientation:

Here I am using the red and green color to distinguish between the level of high-pass filtering applied, and the amount of resonance in the filter circuit.

The slider on the right is an experiment to see how it handles the concept of +/- deviations from a center value. This is an important type of value editing in virtual audio hardware and our control should be able to express it clearly.

State
Typically, UI controls can be in one of a number of states: Enabled and editable; Disabled; and Read-Only. Our control should express its state visually:

The difference between disabled and read-only is subtle. Both states are not editable, and the control should express this fact clearly so that a user is alerted to it and doesn't attempt to change the value. However a read-only control is allowed to receive the keyboard focus (more on this below), whereas a disabled control will not.

Scalability
One problem common to many applications, not just virtual hardware implementations, is that high-resolution displays tend to make everything look smaller on the screen, unless they've been explicitly written to deal with this problem. Our value slider control should be designed in such a way that it can be scaled easily:

Behavior
Controls should not respond to mouse-wheel events unless they have the focus. That really needs to be engraved on stone tablets and placed in the temple of the whatever, high atop the thing. Take the following as an example: You're in Cakewalk SONAR 6.0, scrolling down the list of tracks, and an input trim control scrolls up underneath the mouse pointer. Suddenly, you're scrolling the value of the input trim control instead of the track list. (Note: they fixed this in 6.2)

On the other hand, if you click on a control, you should be able to use the mouse wheel to change the value. The control has to have an understanding of focus. Once a control has focus, you should be able to use the keyboard to change the value also. I suggest the + and - keys.

Precision
Some values need precise editing. In situations where dragging the slider does not allow for the necessary level of precision, you should be able to double-click the control to get to an editor:

Next up, I'm going to talk about the second proposed standard control, the toggle button. Should be simpler.

 |