Documentation in live events is generally used for three things. These include documentation for:
• Planning of equipment layout and installation of equipment
• Keeping everyone on your crew on the same page and aware of currently installed equipment
• Run sheets
This sort of documentation is written in a way that each member on the tech team is able to understand because it is not seen by anyone else other than people working tech in the event.
For instance, documentation comes in handy if Audio Tech's are bumping in equipment in the band pit and are going to be using channels 1 through 15 in a multicore. Then when the Lighting Techs come in they look at the documentation and see that channels 1 through 15 are already taken and they need to use a separate channels. Alternatively because a multicore is part of the Audio Department the Audio Techs may already have documentation done so that the DMX run has a pre-designated channels through the multicore.
The sort of documentation that is mentioned above can be broken up into:
• Audio
o Cable routing diagram which aid in trouble shooting and keeping track of equipment
o Band pit or stage layouts may be done by the audio or the stage manager.
o Cable routing and equipment connection logs used for keeping track of what is connected to what and changes made.
Diagram 1, Part of a cable routing and equipment connection log
• Lighting
o Installation or layout diagrams containing light installation locations, angles, gel colour, DMX address or dimmer patch.
o Light layout planning mud map to get an idea what lights are lighting up areas.
Diagram 2, Light layout planning mud map
• Vision (AKA Projection)
o Cable routing and equipment layout used for planning or trouble shooting.
Diagram 3, Cable routing diagram during a large school whole School Assembly
• Run Sheets:
o Used so that everyone is aware when things are happening in the show. Sometimes there are different columns for each section and spaces for making notes for remembering extra things that relate to a task being performed during the event.
Diagram 4, part of a Run Sheet used at a large school whole school assembly
For me this sort of documentation is not generally done at my church because I'm the only tech however I have done such documentation when working on large shows with multiple tech departments. It has come to my attention recently, that there is a form of important documentation I have not done for church and that is end user documentation. This form of documentation is used to let the everyday Joe the use the sound, lighting and vision equipment. In a lot of churches, the techs are not the only ones that use the equipment. Church members may use need to use the equipment when putting on ministry events as sometimes it's not possible for a tech to be at every event. As a result people that don't know what they are doing may need instructional documentation to tell them what to do. Such documentation is what I am in the middle of doing this month. So in the next part I am going to discuss what to keep in mind when writing end user documentation.
Use of language:
An end user is anyone using your system that is not trained or literate in using a system. End users that read and use end user documentation are not trained to use the equipment and they are also generally not technology literate. This means when you write the instructional equipment documentation you need to keep the language simple, to the point and easily understandable. To do this you should avoid including slang terms and idioms because end users will not get the extended meanings of such words or phrases. Instructions should also be broken up into small linear chunks so that each task can't be confused with others and are easy to follow. When you're finished writing get someone like your mum, grandparents or guardian that is not tech literate to read and preform each step. If they can't follow your documentation it is not simple or clear enough and chances are that your actual end users will not understand your documentation either.
Document Layout:
Keeping content; in documentation, in the same style helps with the readability of documents. Doing so will reduce the time the reader spends figuring out the flow of the document because the structure of the first item read is similar in style to the next ones read by the reader. The following items may help in achieving a good document flow:
• Keep the layout the same throughout the document
• Numbers should be in either word or numeric form throughout the entirety of the document
• Headings that have relational sizing to the main topic and sub topics
• Uses similar instruction structures and wording throughout the document
Photos and diagrams:
Photos and diagrams are good way of pointing out buttons, switches and dials or areas of interest for the reader. Using such visual devices helps end users by physically showing on the document the equipment and what they should be doing or touching in each step. It's also a good idea to include captions of what the photo or diagram is portraying so that the reader is able to make sure which image correlates to what instruction. Adding captions is something I find myself leaving out and I really should include them more often.
Simplifying things:
Removing the complication out of using a system is a good way to make things a lot easier and more manageable for your end user. For instance, a large to medium size mixer can make using audio equipment look like a daunting task because all the dials buttons and faders make things look very complicated. By providing a Mini Mixer instead of a full-sized mixer for use when people need to just use a microphone or two or show a video, should reduce the stress that comes with using a larger mixer. Min Mixers are very small and often have very few dials and faders. They therefore look less complicated to an end user. The less complicated a device or system is the less chance there is of something going wrong or not working.
Zach Radloff lives on the Gold Coast and is studying IT and Multimedia at university.
Zach Radloff's previous articles may be viewed at www.pressserviceinternational.org/zach-radloff.html