Lighting control software should not have a user interface. It requires an Operator Interface.
People using this kind of software are no ordinary users. And I am not referring to the industry’s habit of collecting people who have 5-day weekends and a 2-day midweek, adjusted their biological clock to ‘stage light’-saving time, enjoy beams flashing in their eyes and speakers blasting in their ears. No, that’s not extraordinary, we find that quite normal.
The real reason that sets us apart from any other user is ‘how’ we use the software. Users work during the day with a lot of daylight; operators work at night in the dark. Users sit behind their computer; most of the time we stand (or wiggle a little dance to become a man-sized metronome). Users look at the monitor when working; operators have their eyes on the stage or dance floor. Users control with a mouse or keyboard; operators like faders and buttons. Users can take their time to do a task with the software; operators would by then have missed their cue.
One summer night I found myself in the Space Club in Ibiza. It was 3 o’clock in the morning; Carl Cox was about to start his gig, the main set of the evening. We had just installed VisualDMX in the club’s main area and enjoyed hanging out that night to see the system in use. I was helping the crew operating the lights. I think the sound system’s bass bins must have been placed right under the ‘cabina DJ’ because I had great difficulties operating my mouse; trying to use VisualDMX’ little pull-down menus to select a cool feature, if it wasn't for the bass vibrations swinging the mouse pointer all over the screen. It would have made a super-duper effect if I hadn’t missed the cue already, and for most of the other cues that evening. From then on I couldn’t stop thinking that the user interface should be radically different for what we need to do with it.
When writing software, especially from a Windows point of view, it’s very tempting to create a typical Windows desktop user interface. It is dead easy; all the GUI elements are supplied; just throw them together and start enjoying Microsoft’s millions of dollars worth of investments in UI design.
There is one catch; Microsoft assumed the software’s user was sitting in an office, during bright daylight with his hands on the mouse and keyboard. Perhaps Bill wasn’t much of a disco kind-of-guy.
What our operators need is a ‘night vision’ colour scheme that does not strain our eyes in our low-lit environment. A colour scheme that - opposite to Windows - has a dark background with bright coloured information. We need buttons big enough for touch screen control, even when our fingers won’t be that accurate because our eyes will be focused on the stage. We should avoid floating windows because they slow us down, prevent pull-down menus because they’re fiddly. Furthermore, on touch screens drag-and-drop is very tricky and a right mouse click is quite a challenge…
So let’s break away from the typical desktop UI whether it’s Windows or Mac. Let us rethink the way our software should look'n'feel and take into account the way our operators prefer to work.
You might not be surprised to see that this exploration will inevitably lead us to the lighting consoles that our industry professionals already enjoy using. The interface of those desks have had 20 odd years of development, tweaking, adjustment to market feedback. And never did they feel the need to comply with the ‘Windows User Experience Interaction Guidelines’.
I think the resistance I have met in the early years, proposing a software lighting controller as opposed to hardware, was in fact not an objection to software as such. We are all smart enough to realize that every decent lighting desk contains an embedded PC, quite a few of them running XP anyway. Instead, it might have been the dislike for the typical software user interface. And with this resistance fading in the last few years, I could conclude that the understanding for a specialized Operator Interface is growing amongst software developers.