Reflections on My Interactive Exhibit Design Project

In the Beginning…

As the term comes to an end, it’s time to reflect on my Interactive Exhibit Design project and what I learned from the course. I decided to take Interactive Exhibit Design to continue learning about digital tools and how we interact with them as historians as well as consumers of culture and technology. This was a great opportunity to think in different ways and learn new skills, specifically working with Max 7.

When I first started brainstorming about what I wanted to build for the project, I had envisioned designing a working mechanized lock, controlled by a Max 7 patch, which would allow people to see how a lock operated to move boats between different levels of water. We were learning how to create interactive programs with Max in class and I wanted to apply that new knowledge to something I already understood. Having worked for the Trent-Severn Waterway for four summers, I understood how locks worked, but also knew how often visitors asked questions about them. This was especially true if someone wanted to know how they worked and there were no boats around. I set out to make a program that would allow people to interact with a virtual lock and learn more about its function and operation. I quickly realized, however, that it takes a lot more time than I had anticipated to learn a new program and to get to a level where I was happy with the result. This meant that the physical model of the lock did not end up being as sophisticated as I had planned.

The Code

As for my Max 7 patch, our professor Bill Turkel helped me smooth out the visualization of the water rising and falling in the lock to better recreate what an actual lock looks like. He also helped to rework my patch so that it was less convoluted and more efficient. There were fewer patch cords, which made it much easier to understand how the various components interacted and what each activated on the lock. The revised patch also showed me that there are lots of different ways to create a program but that some are more efficient than others.

A lot of this project was trial and error – working to figure out which parts of Max were the most useful for what I was trying to create. This meant there were long periods of sitting and thinking, followed by mad bursts of creating pieces of the patch and then tweaking them to make the display look cleaner. Max is relatively flexible in terms of changing what you can see in its “Presentation Mode” which was very helpful throughout this project. That being said, I realized too late that once you set a certain size for an LCD display, you couldn’t expand it without changing the values in your program to match the new dimensions. This meant the display was quite small which made it hard to see unless you were right in front of the computer.

While most of my patch works quite well, there are still a couple of issues that I wasn’t able to resolve. Most notably, both of the gates can be opened at the same time and the gates can be opened even if the water is not at the right level (i.e. if the water is up, the lower gate shouldn’t be able to open and if the water is down, the upper gate shouldn’t open). This is virtually impossible in real life because the water has to be at the same level in order to open the gate. This was a great example of how a digital representation of something like a lock may not be entirely accurate if the person who designed it doesn’t know how to transform this logic into program components. If I were to continue on with this project, this glitch would be the first thing to work out.

To demonstrate how the program works, here is a short video that shows what the patch does and why:

The Physical Model

The physical lock was constructed from a variety of materials I had lying around my house such as cardboard and tissue paper. I used a Makey Makey sensor to connect the different components of the lock to the computer program so that when a person moved the gates or the water level, the gates and valves in the Max program would respond. Unfortunately, the program seemed to work better on my computer than it did when I hooked up the model. The way I had designed the lever to move the water up and down would get stuck on the parts of the box, which meant sometimes the water in the visualization stopped moving at the halfway point. I also covered one of the sensors for the gates at first and had to adjust the model so the Makey Makey sensors would connect. This was an easy fix but showed me how easy it is for something to not function the way you were anticipating.

I will openly admit that I am not particularly artistic. The model was very rough, and if I had been designing this to actually go into an exhibit, it would have had to be much more stable and user-friendly. I also should have written out descriptions for what each piece of the model (the gates and levers) was and how to operate them in order for someone who didn’t know about locks to interact with it and not get frustrated.

A frog riding up and down the lock (unfortunately the Dollar Store didn't have a small boat).
A frog riding up and down the lock (unfortunately the Dollar Store didn’t have a small boat).

Final Thoughts

Using Makey Makey and Max 7 together was a great way to combine a digital program and a physical model. These tools work very well together and made it much easier to decide how many parts on the lock would move and what that would look like (the Makey Makey only has four sensors, so you can only have four things operating in a Max patch). They may have been relatively simple tools to use, but combining them gave me a better appreciation for how sensors can help provide interactions with digital programs.

After our project presentations, Bill and a few students in the class were discussing how much we take for granted when we interact with models or screens at museums. We have come to expect sophisticated interfaces that work seamlessly, like navigating through a site like Facebook. What people don’t realize, though, is how many hours have gone into developing those sites to make them user-friendly. I think this is part of the reason that I had to scale back my original idea. The site I based my program off of was easy to navigate and intuitive to use, so I thought it wouldn’t be too difficult to replicate. This experience showed me just how much time and effort goes into making something work properly and still be accessible to users.

This project gave me a greater appreciation for the digital tools and interactive displays I encounter online and in museums. There’s a lot more to a program than what the end-user sees. Thinking into the future, it’s important to create interactive exhibits that are easy to use and understand (or that have appropriate instructions) and to realize that there will probably be issues that you won’t realize exist until someone interacts with it.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s