Prepping for an immersive installation

You’ve got your team assembled. Everyone is ready to head to the installation site and get the complex system up and running in full glory. The plan has been set with deadlines and time estimates. Client expectations are set and reviews are scheduled. What happens next can be a million different things. The install might go smoothly and everyone will high five repeatedly. It may end up a total train wreck with everyone pulling out their hair. While you may not be able to avoid every possible situation, there are a few things you can do to try to put the odds in the favor of success. Here’s my top 5 things I suggest doing before heading out to an installation site.

1. Quality check ALL of your assets

This sounds so boring, I know, but it’s one of the biggest time wasters when the heat is on. Quality assurance of assets is ideally a multi-stage and multi-person process where everyone is responsible for their own work. Everyone should confirm that their work meets the specifications created at the start of the project and that their work meets a certain professional standard. This ends up being the job of the last person in the virtual production chain, more often than not and will burn a lot of their time.

The specification check is pretty simple, often seems unnecessary, and everyone grumbles, but in real time and generative systems it only takes one asset at the wrong resolution, bit rate, codec, or length, to cause unpleasant results or even negatively impact the whole systems performance. There are many apps you can use to verify specifications like Quicktime or VLC. It’s easy to do and will avoid developers complaining to you about how they spent time debugging their systems only to find out a bad asset was the culprit.

The professional standard check will vary based on what you’re working on and takes quite a bit more time. If budgets are big, then there will be people wanting every pixel to be perfect, and if the budgets are small you might just need to do a simple quality check. It boils down to watching every single asset from start to finish to confirm there aren’t any artifacts from encoding, processing, or rendering. Little blips and bloops sneak into assets in long processing pipelines, and a quick watch early on gives you enough time to inform the creators that another version is needed. Quality checks mean ensuring looping assets actually do loop properly.

Asset quality assurance will invariably have to happen somewhere and the job site is not a great place to watch assets and verify specifications. It takes longer than you think and you will almost certainly have more important things to deal with, so get this out of the way before getting to the installation site.

2. Finish all developments before you’re on-site

This sounds obvious and frankly idealistic to anyone who’s been on an installation site. “That’s the name of the game!” some people will say but that’s only because we allow it to be. It’s not the designer’s fault they don’t really know the development process, just as a developer might not have insight into the full design process. They would agree with us wholeheartedly if they knew that developing on-site usually creates untested and less stable systems that reflect everyone, including themselves, poorly. I bet most clients would be willing to pay more to have offsite mock ups if they could review their designs without impacting the stability and quality of the final installation. I would guarantee it if we didn’t sugar coat things and told our clients that changes on-site would result in system crashes and unexpected behavior that they would have to explain to their clients.

There are always issues that crop up on-site that can only be dealt with on-site. Those are what they are and you have to roll with them. You should strive to have all developments complete before showing up to the installation. This will allow you to focus on testing the system in place, making it rock solid, and really pushing for the last few percent of quality.

3. Bring backup hardware

I read a quote a long time ago that I can only paraphrase as “Faster hardware reaches a crashed state faster”. I wish I remember where that quote was from (leave a comment if you know more about the quote!!!). There really isn’t much grey area to this point. Computer parts break and burn out. They act up and do funny things for no reason. It’s even worse when they only start to act up and sometimes work and sometimes don’t. Always bring back up hardware. This doesn’t just apply to cheap hardware either. Professional high-end top-of-the-line parts are just as prone to failure.

I know what you’re thinking, “If I bring 2 of everything, it’ll double my hardware costs!”. I’ve been there first hand and done plenty of gigs where I just sat still with my heart beating in my throat hoping that my computer would survive for one more hour. It’s a tough move to try to claw back a bit more money just for safety. You should try to get to this level as soon as possible. If I could talk to a younger version of my self, I would tell myself to take some money on the side and just bring a few extra critical parts of every gig if I couldn’t afford bringing a whole second system. Something like a backup stick of RAM, an extra SSD, an extra graphics card, and (annoyingly) an extra power supply. These are the most common part failures you’ll have in your computer, and if you can’t afford a whole second system, one of those parts and screw driver might save your ass a few hours before the gig!

In the past 30 days I’ve had:

• a stick of RAM die
• a power supply act up
• an SSD stop working
• I dropped an external HDD and it stopped working (whoops)
• 2x workstation graphics cards started acting up for no reason
• a stick of RAM come loose in the slot, so a system wouldn’t boot and made beeping noises (not related to the dead RAM!)

I’ve had more than one hardware problem a week this month! These didn’t impact me negatively since I had backups of everything ready to go.

4. Expect everything will take forever

I was told about this book Godel, Escher, Bach: An Eternal Golden Braid and didn’t get all the way through it but there’s a funny part in it where this law is stated:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Hofstadter’s Law is something you might hear developers talk about in regards to estimating the time to perform complex tasks. Most of those lucky developers won’t need to estimate how long complex tasks take on-site. I’d like to take a moment to make the immersive installation equivalent:

Sorkhabi’s Law: Everything takes forever.

This means it’s a bad idea to try to cram 5 days worth of work in 5 available days when you’re in the thick of things. Assume that you’ll only get about 3 or 3.5 days of actual work done in the 5 days you spend on-site. You may get more or less work time depending on what kind of installation site it is. You will not be working at 100% capacity when you factor in less-than-ideal working conditions, possible interruptions, unexpected installation issues, and all the reviews and unexpected visitors.

The best thing that you can do is schedule time with extreme reservation. I know this sounds really lame when you think about it. Artists always want to deliver above and beyond and feel like heroes after the battle. I guarantee you’ll have happier clients if you always deliver to a schedule, even if that schedule is slightly slower than another vendor who regularly promises fast turn arounds and generally has delays and issues. Give your clients a good surprise like “We finished early and had time to add a few features you asked for!” instead of a bad surprise.

5. Don’t just say “yes”

This point relates to finishing developments before getting to the installation site. Most designers or clients don’t know all the elements of the development and deployment process. Designers will always ask for a ton of changes on-site until interactive and immersive installation processes are taught in design schools. They really don’t mean to be a complete pain in the ass, but they can be if not managed correctly.

We all want to make our clients happy and be proud of the work we do. It’s easy for young developers to quickly say “yes, of course I can do that!” and “yes, that’s an easy add, it won’t take long at all!” when designers request changes. It feels good! It makes you feel like you’re good at something and can roll with the punches! I remember my first projects and trying to please everyone by saying “yes” to any request.

What I learned over time is that designers don’t want to/mean to jeopardize project delivery and schedule with their changes. They just want them to be known, accounted for, acknowledged, scheduled, and implemented within reasonably prompt timelines. You should sound some alarms when they own and drive the development process they aren’t knowledgeable of. Letting them take it over is a rookie mistake and starts when you quickly say “yes!” to anything that a designer says on-site.

This doesn’t mean you have to be rude. It means you have to get your business pants on to be professional and ask questions/say things like:

• “How would you prioritize this change in relation to other elements that need to be delivered?”
• “I’ll do my best to implement that, but I’ll have to check our implementation schedule so that we don’t negatively impact the existing schedule and launch”
• “I’ve made a note of the change and I will have to confirm it’s within the current scope, otherwise we will have to schedule it to roll out after the scheduled launch”
• “Can the launch date be rescheduled to incorporate these changes?”
• “Is this a change we can roll out shortly after launch?”
• “I’ve made a note of the change. When we’re finished reviewing everything, we can review the list of changes to determine their priority and schedule them promptly without negatively impacting the existing schedule.”

These phrases and questions allow you accept and acknowledge their requests and changes, as you should since they’re paying you, while keeping ownership of the process so you can deliver the installation on-time and within budget. Don’t forget point 4 either, everything takes forever on-site, even little changes that should only take 10 minutes…

Wrap up

These tips aren’t hard and fast rules that you must follow. Every interactive and immersive installation has a certain level of instability and risk to it. You may follow all these points and still end up in a train crash. I’ve had disastrous projects where none of these things were actually the issue and nothing I did beforehand could have helped. These tips have overall helped our team to minimize unnecessary risks and time wasting activities so we can focus our available energy at taking on artistic risks. Hopefully they do the same for you! Leave a comment if there are things you make sure are done before showing up at an installation.