There is no better time than to observe users in the wild than day one of a trade show. After setting up monitors and computers, techs must be around but not in the booth. If we’re lucky there are tables near the exhibit. During this time, I like to observe not just how users interface with machine and software but it’s also a time to reflect on what the agency and/or developer did with the software that powers those interactives.
I have a unique perspective on the user experience when it comes to interactive software development. Of course, while designing software the overall UX and UI are of critical importance, but there is also the other person that often gets neglected. That person is the on-site tech, the one responsible to make sure the client is happy and that everything works. It’s not a glamorous role and when you think about it we are the last mile in what is usually a long distance sprint.
Over the years, I’ve witnessed the transition from specialized interactive software development and production companies loose traction as marketing/advertising agencies create content for these trade shows, specifically Pharma trade shows. These agencies generally come from a print and/or web background. The problem is that when you take a web developer – usually front-end and have that person or team make something that runs on a desktop there is generally something that gets lost in translation.
While I’m sitting, observing from my awesome vantage point here at Moscone West, I thought I’d jot down some items that should be considered when developing software content intended for the trade show and event circuit.
-
- While HTML5/JavaScript/CSS is a very attractive “write once, run everywhere” solution, consider wrapping it in Electron to make an executable. If it could run without a web server, that’s cool. If this bundle of joy requires a web server, it’s adds a layer of unnecessary complicity to the install. Self containment is pure happiness.
- Even better use AIR. Adobe Animate/Flash is still the best and fastest way of developing interactive content
- Provide a configuration file (JSON or XML is good for this) that can:
- Show or Hide the cursor
- Load external content
- Change the timeout value to go back to the attract loop
- Suggest an attract loop for your client
- Provide a secret button or button-click/touch scheme to quit your program. Often kiosks and setups don’t have a keyboard handy which makes it difficult to hit ESC or ALT+F4.
- Add a data tracking/capturing file and save it as JSON (preferred) or XML (old-school) file.
- Include a README file. Give information to the tech.
That’s pretty much it in a nutshell. I may come back and adjust when I get feedback from my techy friends and co-workers. I know there are many options and considerations when it comes to developing interactive software so this list might not apply to all apps, but please think about the person installing your program on-site. We all like boring, uneventful shows. Good software and installs make that possible. Which in turns makes for happy clients (that pay on time).
Related Posts
June 26, 2023
Controlling the Light, part 2
My introduction to DMX and controlling light really started back in the late…
April 11, 2023
Back to One
During the heart of winter, I finally made the switch to using Next.js coupled…
March 23, 2023
Controlling the Light, part 1
At the start of any project, I review the requirements and ask questions. What…