Walkumentary

An Interactive Story App for Google Glass

Summary

Walkumentary is the codename for a class project involving the development of an interactive story application for Google Glass. Back in 2014, the curiosity for Google Glass was at its peak. Our client, 8 Leaf Digital Production, was interested in discovering the potential of merging storytelling with wearable tech, and knowing how such an idea could be applied to the tourism industry.

 

I was tasked with compiling data from user tests and then translating that data into validations. Using those validations I then advise the team about what to keep/fix/change in the current development process.

 

As we started, we thought about the challenges of merging story with wearable tech. At the time, such an idea had not been explored and written about, so my team and I were more-or-less pioneering the bleeding-edge concept. One of the core challenges we faced was how to design without the screen as the main mode of interaction. Another important, and obvious, problem central to our project was how to tell a compelling interactive story using wearable technology. Of course, we stumbled upon many other roadblocks throughout the project, but we tackled them through improvisation, rapid prototyping, testing, and plenty of failures.

Approuch

Mentorship

Walkumentary was a class project where we had to incorporate what we learned about digital media strategies in developing our product. We had mentors who are leaders in the field guiding us throughout our journey with Tim Bray, inventor of XML, as our main facilitator. In a sense, when we felt lost (which happened a lot) Tim would use his wisdom to guide us in the right direction.

 

Bullseye

We then used another process activity known as a Feature Bullseye. This process was useful for prioritizing our ideas and getting a sense of what was important for the group as a whole. By converging our many brainstormed ideas into only the ones that were the most widely popular, we were able to reach some kind of consensus within our group about which ideas to pursue and which ideas to let fade into the background for now.

 

Personas

We also created personas to represent the potential users of the product-to-be. By looking at each persona’s pain points we came up with a list of demographic details, needs and solutions for each of them. This activity helped our group better identify and visualize what the users of our product would look and act like, so we could focus our thoughts around what these users would potentially be looking for in our product.

 

Assumptions

The task of designing such a product was monumental. As we were generating ideas in our first week, many questions, none we could answer at that moment, whirled around our heads. We created an excel sheet to document all of the questions and assumptions we had that we could validate later on.

Discovery

Our journey in this project was mired with roadblocks upon roadblocks. Not to say that the project wasn’t rewarding, but it did bring with it a thick fog of uncertainty. To put it symbolically, the fog gave us just enough information to start making decisions but no way to judge the accuracy of that information. To lessen the effect of this fog, we needed to validate the assumptions we gathered from our research and personas. At this point we didn’t have a prototype to test our assumptions, as simple wireframes would not suffice. We had to improvise by simulating the experience of our product using audio recordings, a makeshift Google Maps, and picket signs with instructions written on it. Even with the improv nature of our initial tests, we were able to gather enough useful data to help us move forward in our R&D.

Unknown unknowns popularized by Donald Rumsfeld

The focus of our interactive story was in Vancouver Chinatown, captioning the history of arrival of Chinese immigrants to Vancouver, racial discrimination faced in the early 20th Century, to redemption after the 2nd World War.

Development

Prototype I

As mentioned before, we couldn’t use wireframes to test our ideas because the screen on Google Glass was not the primary mode for interaction. We also had to think about the other crucial interfaces built inside the device as they were integral in our product’s design. And with our engineer working on the only device we had available, we needed to find another way to prototype and validate our assumptions. So we designed an environment near our office with picket signs, an iPod, written instructions, and ourselves representing each of the core features in Google Glass. It was a fun process and a success in that we were able to gather enough useful data.

 

Modular Design

After phase I of our prototyping, our developer devised a modular way to tell stories through google glass. This meant that we’d now had to break our story into chapters. Each chapter would be comprised of voice-over recordings, videos, and images to accompany each story. These media components would then be implemented into Glass through a JSON created by our developer. The chapters are intended to be experienced through an interactive trigger inside Glass.

 

GPS Triggers

An important aspect of our product’s design was merging the digital stories into the real world. One of our valid ideas for doing that was placing augmented reality (AR) in certain places and using the AR sensor to trigger the stories. Unfortunately, the feasibility of it wasn’t in the project’s scope so we had to look for the next best alternative - GPS triggers. In perspective it seemed like it may be a better idea than AR, but GPS had its share of disadvantages, mainly it’s accuracy as a sensor.

 

Prototype II

With the features and components pretty much connected we were ready to use the Google Glass device in our tests. This time we invited our clients to playtest our product in Chinatown. We did this about 4 times leading up to the completion of our project. Each time we took their feedback with utmost importance. One of the comments that informed the rest of our product was the idea of hand-holding when using and interacting with the device. In other words, they wanted more instructions on where to go and how to interact in order to avoid user confusion.

The red waypoints indicate areas where the stories will be triggered when the user approaches them

Reviewing notes after a day of playtesting. We had playtested the latest build with  our clients from Zeros2Heroes. They had given us some insightful feedback, including the concept of "hand-holding", meaning the device gives more precise instructions to the users as they go through this interactive journey into the story.

Conclusion

By the end of our project timeline, we gave them a package consisting of a design document, our protoype, all media files we’d created, and a short video detailing a hypothetically finished product and possible features to include. Our clients were very supportive of our findings. They realized the challenge of using wearable tech for storytelling and were extremely gracious of our discoveries.

Next Project -

Enso

View

Back

Facebook  -  Twitter  -  Instagram  -  LinkedIn

Web Design and Content © 2017 Jessie Altura

FACEBOOK

TWITTER

INSTAGRAM

LINKEDIN

Web Design and Content © 2017 Jessie Altura