Tactile Surfaces on control desks

[scottmcleod]

Take with grain of salt. I'm in a rotten mood today

 

Clearly! :)

 

As for inputs, the mentality should be the same. Your device should be a touch screen at it's core, but allow for fader wings, button wings, encoder wings, etc... Maybe even as modular "blocks" or something along those lines.

 

I really don't think there is any 'should' about it. The topic is about what users want & many, including myself, will place much greater value on physical faders and buttons in preference to touch-screens and expansion modules etc. For me the latter would just be inconvenient. This is not an argument, but a reminder that there is no right & wrong, this being the very point of the topic.

 

Regarding the whole colour-control thing, given software can do anything within reason I would suggest the user can have all the various options available, should they wish. ie. colour pickers which translate/different models and (always IMO) a way to control a units channels directly.

 

 

Sorry, I meant "should" as in, "should offer the option". What I like, is seeing units like the Strand LP's that when you open them up, are a huge network of modular bits. One bit breaks, you replace it. You want more bits? You buy more, and network them in.

 

It's all about data translation, and less about the methods you use for inputs. In a perfect world, it should accept ANY form of input and allow quick and dynamic mapping so it can be used for a variety of functions.

[dbuckley]

It's all about data translation, and less about the methods you use for inputs. In a perfect world, it should accept ANY form of input and allow quick and dynamic mapping so it can be used for a variety of functions.

 

yep.

 

As an example, my favorite tool: PCStage has this structure whereby if you can get data in - somehow - then you can map it to most functions of the software. It's not perfect by quite some distance, but it is still very powerful. For example, doing the huge piano in 'Big', translating underkey switches to DMX for underkey lighting and MIDI to notes to make the noise. A bunch of switches on stage is an odd example of a user interface, but a user interface it is, and supporting such a thing should not require huge amounts of specialist knowledge and equipment; it should be possible by any fairly competent technician, if only the generally used tools supported such flexibility.

 

I just wish someone round here would do Big so I can do the piano...

[niclights]

Sorry, I meant "should" as in, "should offer the option". What I like, is seeing units like the Strand LP's that when you open them up, are a huge network of modular bits. One bit breaks, you replace it. You want more bits? You buy more, and network them in.

 

It's all about data translation, and less about the methods you use for inputs. In a perfect world, it should accept ANY form of input and allow quick and dynamic mapping so it can be used for a variety of functions.

 

Oh, absolutely yes. The modularity of the Expert hardware was the thing that impressed me most about the new board. All parts are USB, interfaced to two 7-port hubs. This leaves great scope for things like changing to a touch screen or adding new technologies.

 

No harm in having a touch screen. It's just for operation I want to be looking at the stage and minimise any need to look away. Ideally the interface would be brain -> lights. Potentially a problem for the local supports, but I guess it's never going to happen anyway!

[Michael.James]

imagine hitting go and having .net re-jit the console code or doing a big garbage collect before actually doing anything?

 

This isn’t quite right, I can understand your point, but programmed well, there wouldn’t be any delay.

 

With regard to "glitzy GUI", there is defiantly a fine line between making software more usable and "glitz". Take minimizing a window, it animates it way down to the taskbar or dock (for Mac users). This helps the user see where there window has just disappeared to.

 

Not glitz but a very helpful animation. That is one reason for my use of WPF, to easy create such animations which take place in less than 1 second, but help a novice understand what has just happened. (all animations will be user configurable, so they can be turned off)

 

My views on using a standard PC or laptop as a lighting control is limited. I have never wanted to run a show from my laptop. I have a 128 channel Jands Vista dongle for my laptop so I could if I wanted to, but it’s too fiddly for the type of shows I do. I don’t have a chance to preplot, and using a track pad or mouse, makes busking just too difficult. From this thread alone, I can see people want to touch there desk and I like to tap on my 530i, and “throw” faders up and down. You just can’t do this on a PC.

 

I love the idea of multi-touch though; I have really looked into it. But to build something which is useable on a day to day basis, well, it’s currently not possible for me to do.

 

Microsoft’s Surface is small, for a multi-touch screen, Apples iPhone is TINY, and I have no idea how they have built a multi-touch screen into the device, but it’s not the way most people do it.

 

The way most (including Microsoft) build a multi-touch display is to project onto a sheet of plastic or glass and use infrared cameras to pick up the figures.

 

This really only works well in a dim room, so doing an outside gig is almost out of the question. The things are huge, have a mirror in it, so no dropping the flightcase.

 

I have chosen to go with 22 Motorized faders for my console. All completely customizable, but two are going to be placed for Time and GrandMaster as default, although the user can change their use.

 

Instead of multiple touch screens, I have been experimenting with screen sizes and find that 1 17” touch screen is surfactant. Do you think one screen and more hardware is better than 2 touch screens and less hardware?

 

Cheers

 

Michael

[niclights]

Personally, one screen is plenty as I would only want it for programming and maybe info/feedback during show. I'd prefer more faders too. Motorised is not important to me, quantity for fast access is.

[Dmills]

Instead of multiple touch screens, I have been experimenting with screen sizes and find that 1 17” touch screen is surfactant. Do you think one screen and more hardware is better than 2 touch screens and less hardware?

 

One touch screen, plus the ability to add at least one further monitor, and hardware is good.

 

An issue you will want to think about is mounting the touchscreen, as a touchscreen on a conventional VESA mount is notoriously tiring to use, and in any case tends to put the thing between you and the stage, whereas one built into a console surface tends to get scripts accidentally dumped on it.....

 

I would also urge that the touchscreen be a secondary means of input and that everything that can be done on it should also be possible without removing the hands from the keyboard. I find a graphical interface to be useful when trying to figure out a new controller, but for speed once I know it I need to keep the hands on the 'Home Row' as it were.

 

Under no circumstances are any modal dialogues acceptable.

 

On the touchscreens, do make sure they can be dimmed way down, a lot of LCD monitors are way too bright in a darkened theatre.

For accurate timing when using a touchscreen, it is IMHO normally better to time to the release event rather then the touch event in my experience, as this allows a spurious touch to be dragged somewhere safe before releasing (Found that out writing a radio automation app).

 

Don't forget that touchscreen controls need to be big! IMHO even a button matrix really needs to be no more then about 10 * 10 on a 17 inch screen to be usable.

 

Regards, Dan.

[Modge]

Just to pick up on one point that's come up a couple of times now:

Modal dialogues (for non programmer types: see here http://en.wikipedia.org/wiki/Modal_window )

I realise some people don't like them as an interface element (whom ever wrote that wiki article for a start, from the look of it!) but surely they have a place in interface design?

Not all over the place, not often, but say you save some thing would you really rather you could forget to finish saving it and potentially cause your self a problem later on? Or be forced to enter a name for it before you do anything else? Often when say saving things (say a fixture group, for a relevant example) It's not like you can use the thing before you save it and there would be things (important ones) that it wouldn't make sense to be able to mid-save e.g. change what fixtures you have selected: If you could do that the user would be left guessing: is it the fixtures that where selected when they pressed save or the fixtures that were selected after you entered a name?

 

By all means random pop ups when ever e.g. you plug some thing in annoy everyone if they have to be dismissed before you can continue but from my perspective there is in fact a place for the odd modal dialogue, in lighting console interfaces. Being as this is somewhat directly relevant to me I'd be very interested in other peoples views on this.

[Dmills]

<Of saving things>

By all means random pop ups when ever e.g. you plug some thing in annoy everyone if they have to be dismissed before you can continue but from my perspective there is in fact a place for the odd modal dialogue, in lighting console interfaces. Being as this is somewhat directly relevant to me I'd be very interested in other peoples views on this.

 

That sort of thing is what a status line at the bottom of the screen is for IMHO.

Also, ref the time taken to save, what is wrong with the windows equivalent of he unix style fork(), <save in the child>, when child exits parent gets error code from childs return value? That way there is no need to stop work while waiting for the save because it happens in the background (at the cost of a few page faults for copy on write).

 

Now I do make a slight distinction between things like file name dialogues which appear deterministically because of some user action (But they better finish appearing and be ready to take input faster then I can type), which are merely annoying, and things that pop up at random times, which firstly get ignored, and secondly may not even be seen until I notice that half a dozen commands have been ignored.

 

Ok, I can see a modal dialogue of "Unblock the fan you muppet, CPU is melting", "UPS Critical, going away in 10,9,8....", and the like, but grabbing focus from whatever the user is doing is rude at best.

 

Regards, Dan (Who doesn't tend to look at the screen much when plotting).