User InterfaceSeveral years ago, I was commissioning a new control system for the boardroom of a major US company. I had taken great pains to ensure that the pages of the touch panel were properly laid out, sub-pages properly linked, buttons aligned, etc. I also went to great lengths to make sure the program functionality fit the customer - make sure the system controls just enough - nothing more and nothing less.

With one sentence, the room administrator's opinion of the user interface created a large dent in the ego, "Oh no, you're going to have to dumb that down."

Lesson learned that day? Regardless of the programmer's opinion of system functionality, the opinions of the project manager, consultant, and customer will be different for almost all projects. And to alleviate the need for extra hours (and tears), programmers have to know their audience and plan accordingly. Here is what I learned, and what I do to soften the testing/commissioning process.

Know your customer - more specifically, the end user. This is the person(s) who will use the system everyday. Does a room administrator setup the meeting or is it done by the participants? Does the company have a technical staff and does a member of that staff have access to the touch panel? The three main user groups in involved in the use of a commercial A/V system are participants, administrators, and technical staff. Here is a brief description of how I develop the GUI for each group.

Participants - Require the most functions in the fewest amount of buttons. Although we haven't quite perfected the "Do what I think" button, there are some participants who require only two buttons - "Start Meeting" and "Stop Meeting". And each button controls power, lights, shades, screen, and a nominal audio level. Participants are concerned with event workflow - not technology.

Administrators - Most administrators are assigned the room admin duties as an added responsibility. They may have a little more tech savvy, but desire to get the room running and be on their way. They also like to control meeting variations - a screen but no projector, or an audio conference without presentation. Administrators are concerned with the participant's workflow - not their own.

Technical Staff - Need the most granularity in the user interface. They will require individual power control, custom video/audio routing, and individual device settings. They may also need to monitor power/room status and lamp hours. And if the room's layout is configurable (room combining), they will need access to that functionality. The programmer may be required to hide or protect access to the technical pages on the panel.

The main goal is balance. Making a panel highly technical for participants will eventually relegate that panel to a back room to collect dust, and the customer will rewire the rack to make the system work...happens a lot. Making only a limited user interface available to the technical staff will reduce the value of the technology for which the customer paid...and result in increased service calls.

fShare
0

Blog

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Go to top