While using a different button for each function is often technically possible, it’s bad practice, and an old-school way of doing things. I don’t program control systems that way. Not because I’m difficult and stubborn, but because it’s a bad idea and I know better. This request is much like saying, “I know how to get to New York from Orlando, so if I want to go to New York from Chicago, I need to go to go to Orlando first.” Of course, you can certainly get to New York from Chicago via Orlando. But it is rather absurd isn’t it? Nobody would do it this way, they’d figure out the easier way that requires less steps. The same concept applies here.
Back in the old days of control systems built from switches and relays (pre-1990 or so) you used to see discrete buttons for each separate ‘device-task.’ In those days the job of a control system was simply to consolidate all of the buttons into one place. That was about all you could do with the limited technology of the day. For the past 20 years now we’ve moved on to control systems that are microprocessor based. So much more is possible, and because of that, the mentality of the users has changed.
I’m not sure how far back your experience with automobiles goes, but here’s another analogy. In the old days, in order to start a car, you had to take multiple steps. First you’d pull the choke, and then you’d turn the key. After the engine started running, you’d wait for it to run smoothly, then you’d close the choke and you’re free to put it in gear and be on your way. Now you simply turn the key and the car does the rest of the process behind the scenes. Modern cars will go even further and turn on the headlights or windshield wipers if it thinks you need them.
You shouldn’t make the user think about the individual equipment actions that are required behind the scenes to get the job done, but rather, you should present the “activities” that the user would want to do, and make the control system do everything else behind the scenes. For example, there’s rarely a need to have a projector on button — because there’s never an action that stops at turning the projector on. You don’t turn on a projector to have it just sit there powered on. The next step is always deciding what to show on that projector. So the best way to program it would be to simply have the user choose what they want to show, and the control system turns it on behind the scenes.
So in deciding how to design a touch panel (and consequently program a system) you need to anticipate the actions of the users, and coordinate that with the functionality of the system. You then come up with an organized way to operate the system. In some systems where there’ are multiple sources, and multiple displays, the action list gets more involved, so it’s critical to sort it into a logical workflow. And that means by how the user will use it — not by how an engineer or technicians would categorize functions by equipment or system category. In the average classroom scenario, a user will usually want to display a source, then they’ll interact with the source, then they’ll turn the system off. So that’s exactly how the main menu should be presented. “Media Source”, “Media Controls”, “System Off”. There’s also some other common on-the-fly actions they’ll want to do as well such as ‘hide/show picture’, ‘volume/mute’, ‘lighting’. So long as it’s just two or three actions in total, they can also be presented on the main menu. If each of those requires a number of buttons (6 different lighting presets) it should be presented as a popup, or page that disappears on its own, returning you back to the main media controls page.
A well thought out interface makes or breaks the whole system. If the system is hard to use, they’ll never take the time to learn how to use it, and they’ll have bought something that ends up collecting dust. If a customer has an easy time using the system, they’re more likely to come back for more.