Props in Immersive Storytelling

For the last couple of months, I’ve been participating in an online class on thematic immersive storytelling. It’s been an interesting experience, and you can see what I’ve learned reading this tag. But it’s also been a confusing experience, on a lot of levels.

We’ve spent this class working toward “enchanted objects”, things that incorporate Internet of Things (IoT) technology to allow people to do things that can seem straight out of a science fiction television show or movie. Things that require an ability to talk to something nearby and react in a way the user can take advantage of. Which is why, last night, one of my more tech-savvy team members asked me during a design document revision discussion why we were trying to shoehorn sensors into the enchanted object we’ve been working on for the last month.

“Can’t we just use a cell phone? It can do everything we need.”

Another part of this process has been developing the object within a Sherlock Holmes theme. The objects we’ve been working on have all been taken from the pages of the Sherlock Holmes stories. We’ve built and solved crime scenes. We’ve prototyped a crime scene for others to solve, complete with a map suitable to a time Sherlock Holmes has been presented in. In this last stretch, we’ve been developing a Sherlock Holmes-themed enchanted object intended to help immerse players in the story and the world.

So, no. We can’t just put it all on a cell phone and be done with it.

This came just a couple of days after someone suggested we attach a GoPro to our object, which we had discussed and decided was impractical for what we were really trying to develop. But they attached a picture to their suggestion: a small dog with a camera rigged to its back. Perhaps a bit more practical than what we had been wrestling with, but it had no immersive possibilities (and it didn’t make sense within the crime story we have been working from).

It’s not like we’re creating a set or anything. People will be playing in an open space, and their imaginations are going to have to fill in the blanks. We as designers encourage and empower that when we do what we can to help them paint that picture through props that can actually be in the world we’re asking them to step into. When we make choices that don’t support the illusion, we’re not doing ourselves any favors. And that’s important to keep in mind in this kind of situation.


Narrative Legos

It’s funny when your childhood runs headfirst into your adulthood. Last week, I wrote about artifacts that can tell their own story. This week, I’d like to talk about storyless artifiacts – objects that may or may not have a story of their own that can be repurposed into other stories.

Having a hard time wrapping your mind around that? Then try this: Do you remember when you were a little kid playing with your toys? Stuffed animals, action figures, and fashion dolls all had their own names, their own histories, a set of preferences that made no sense to anyone beyond you. And you would play with those toys within those stories. But then one day, this stuffed animal would host a gathering and would invite everyone except that one uppity action figure. Toys that might never have played together before were suddenly best friends, or hated the hosting toy for shunning the action figure. Two days later the host and the action figure would be best friends in this game over here, but a whole new drama was brewing over there with two stuffed animals over a dump truck.

We’ve all done it.

What’s been interesting, and perhaps a little hard to grasp, in the SherlockIoT MOOC is that we’ve really kind of been designing those toys. We’ve created artifacts that we then used to tell a story within our team, and then we handed those artifacts over to a game system that broke them up and distributed them to completely new teams who used them to tell their own stories. (I think I’ve actually talked about this before. Maybe not.)

In this last bit of the MOOC, we’ve taken a single object from the pile the team created and redesigned it to be a storyless artifact. While it came from the space of the story our team created weeks ago, it’s been redesigned in such a way that others who are unfamiliar with our story can tell their own stories with it. We’ve had to conscientiously move from the security of our story to the freedom of that stuffed animal in the toy box. It’s a different mindset, and a bit terrifying and freeing at the same time.

I feel like this is kind of how it is in narrative design, be it for a game, a transmedia event, or a storytelling collaboration like this. You have to be able and ready to create a fully realized object, developed with its own personality and story, and then be able and ready to let that object go and become whatever those interacting with it need it to be. That’s not easy when you’re so used to creating things that are meant only to be consumed and perhaps interacted with on your terms. It’ll be interesting to see what develops moving forward with this experience under my belt.

Storytelling Artifacts

There’s a phenomenon in the fantasy genre where a person can pick up an object and learn about what the object has “seen”. Sometimes, the person does this through a spell. Other times, the person does it through an inherent psychic ability often referred to as psychometry. You see it in stories where the main character has amnesia; they’re presented with objects and places that had great personal significance to them in the hopes something would trigger. The movie Anastasia has a great scene early on where Anya sneaks into a boarded up building that is really the palace she grew up in. As she wanders through, she touches or picks up various objects, and each one triggers a different memory.

This concept that an object can record and retain memories is completely fictional, but the idea that objects can tell stories about a time, a place, or the people who used it is part of what drives archaeologists and museum curators. Finding remnants of past lives in the form of architecture and objects helps archaeologists and curators construct stories of life within the culture they’re exploring. That said, if you’ve ever been in a museum and refused to walk into a given area because you just knew something dark and foreboding was waiting for you, you’ve experienced a little of this psychometric phenomenon.

We now live in a time where objects can become a player in, or at least assist, creating our stories. A cell phone can record where you go, who you talk to, what you do, what was important to you. Smart objects can learn about who you are and how you behave under certain circumstances to tailor their use and activity to your lifestyle. They craft a story about who you are in a place, in a time, and can in some cases track how you change over time.

Enchanted objects, as smart objects in an Internet of Things setting can be called, can tell us a story. They can be embued with a set of triggers that will reveal bits about a story as you interact with it and with other parts of the story. It opens up a world of storytelling and immersive fiction possibilities. I doubt this will be my last time exploring enchanted objects, and I’m looking forward to seeing how different storytellers incorporate them into their narrative designs.

A Tale of Two Collaborators

A lot of my time lately is spent collaborating. I contribute to projects on hitRECord, responding to prompts or taking someone else’s record and remixing it. The work in the Sherlock Holmes and the Internet of Things MOOC is largely collaborative, in brainstorming, in writing, in designing.

But I’ve noticed something funny about how I approach my work on each site.

On hitRECord, which builds largely on contribution and collaboration, I tend to get a bit perfectionist in my work. If you ever look at the site, you’ll realize quickly that “perfect” isn’t really a thing there. hitRECorders create. They get inspired by something around them, be it their world and experiences or records others have contributed, and they build something from it. It’s very much by heart, a key value of the site. But I feel like if I’m going to add my voice to someone else’s work, it should be as perfect as I can get it or else it disrespects the initial contribution I’m responding to. There’s a tension in my work, a holding back, you don’t find often across the site. But they seem to like my efforts anyway.

In the MOOC, we’re all throwing out ideas and building off the ones that work. The MOOC was intended to incorporate aspects of improv, primarily the “Yes, And” element, and I do that with my team without a second thought. It doesn’t matter where an idea came from; if it works, it moves forward and becomes something. We may take only aspects of someone’s comment and tie it into what we’re doing, and so I throw out ideas and projects with that understanding. What I offer may not get used. It may get used in its entirety. It may get picked apart, only the more interesting bits making it out alive. And I’m perfectly fine with that, because we’re pulling together something really cool from all these bits of ideas.

I can’t tell you why I seem to have this split personality when I’m collaborating on these sites, just that it happens. What’s really funny is that hitRECord really works like the MOOC does, but I work more like a cog in the system than one more voice blended into the pile. It’s fascinating to watch.

Data Collection in Context

Any time you create something, you want to know how people interact with it. Did they like it? Did they get it? Am I a horrible failure?

In a classroom, this most often manifests as grades, numbers intended to tell us how well the student understands this concept at the moment of assessment. And then we assess in a manner that doesn’t really show what the student understands. Sometimes, we do actually need the quantitative data. Sometimes, we put the wrong emphasis on the interpretation of the quantitative data. Sometimes, we really just need to know that the student understands the material well enough to apply it in other situations. It’s one of the great dilemmas in the classroom at the moment.

Beyond the classroom, we’re less concerned with how well someone “got” something and more concerned with whether or not they finished an activity and what they did next. Sometimes, we even want to know what they did before that led them to take on the activity we’re measuring. Those don’t necessarily generate a neat little set of numbers that we can model and manipulate. There’s something human in them. The data that’s generated is of a different nature, but still provides a set of patterns and outliers that can be useful to the group working with the data.

I’ve been thinking about this lately as the MOOC has us creating mind maps centered on a user in a space. We’re looking at things like: Who is this person as a whole? What do the different aspects of the person’s personality would engage with our space, and how? What is the person likely to do in the space, and how do we expect they will feel? In some cases, this is a really interesting set of data because it would give you a really nice bead on your target audience. (I’ve actually considered trying this method out on the blog.) But in other cases, it’s information overload. We might just need to know whether or not the person completed an action and triggered the next part of a process.

But thinking about assessment and mastery and data gathering altogether has made that last bit interesting to think about. If we have no data on a person past a given checkpoint, we can assume the person either didn’t clear the prerequisites to move past the checkpoint or they decided to quit the process before they reached that point. We don’t necessarily need to know what brand of diapers they wore as a baby or where they currently live. We might need to know how far through the section they moved before they stopped making progress toward the checkpoint. That’s a far more useful bit of information.

If anything, it’s a reminder that information has a context and data collection and analysis has to be completed within the right context to be of any use.

Developing Fictional People

This week’s adventure in MOOCing centers around creating a user persona, running that user persona through a qualitative data gathering exercises, and then creating our second user journey of the class. So…basically…creating and manipulating a fictional person. Seems simple enough, right?

Apparently not, and I knew that going into this class. I have a long history of struggling with the concept of developing personas. A persona a fictional person you create who might use the product you’re working on, whom you can then place into context with the product you’re using and play with how they might interact with the product. But it’s a fictional “real person”, somebody who could really exist, and I don’t even believe in real person fan fiction. (I got forced into collaborating on one years ago, and that’s one of many things I will never forgive that person for doing to me.)

What’s funny, though, is that I have no problem creating fictional “fake people”, or what we call “characters”. I’ve done it for years. I can create a whole cast of characters for stories. I can help someone brainstorm a character for their own stories. I’ve created PCs (playable characters) and NPCs (non-player characters) for tabletop RPGs and LARPs. People have paid me to create people who don’t exist. I don’t suck at it.

For some reason, though, while my brain can create a battle-hungry princess and her fabulous war unicorn on the spot, it shuts down when asked to create the person who would play a slumber party mystery game aimed at tweens. I can’t even get to deciding that the persona is a ten-year-old girl. Honestly. It’s awful.

And it shouldn’t happen. Regardless of where the character is being used, it’s just that – a character. A figment of someone’s imagination being set into a given context in a given storyworld. Period. And people will be watching the persona for the purposes of drawing off information, but they do that with characters, too. To think of personas and characters as separate activities is to build a false wall for yourself, and to unnecessarily stunt your creative work.

Prototyping and User Journeys

In the Sherlock Holmes and the Internet of Things course I’m doing this fall, one of the things we’re practicing on a weekly basis is prototyping. Really, what we’ve been doing is generating, exploring, and responding to user journeys. Both are necessary parts of developing anything you expect people to encounter or interact with, and (despite my interest in information architecture and experience design) both are something I had no experience creating until a couple of weeks ago.

Prototyping you may recognize from the PLE posts. It’s playing with an idea, exploring different ways to execute it. You then share the prototype with others and see how they interact with it and get feedback. Armed, you go back and explore more ways to execute your idea and present it again to see how it falls. Prototyping is essentially dedicated play time with a purpose. (To clarify my earlier statement, I tend to draft rather than prototype. I don’t just throw unrefined ideas into the world…usually. Sometimes. Heh.)

User journeys are narratives that explore how a visitor/reader/etc. might encounter and interact with your creation. In both information architecture and experience design, you would create “personas”, a batch of characters who represent the set of typical users you’re expecting to use your creation in some way. For all I’m able to create characters for stories and games on the fly, creating personas has always just flummoxed me. They’re nothing more than fictional people who belong in the context of what you’re working on.

What’s made developing the user journey process interesting in this class is that we’ve come at it different ways. For the first assignment, we were asked to create a narrative of someone interacting with the object we’re creating for the class beat by beat. Only in this case, “beat by beat” involved beats composed of an action and an emotional response we want to provoke through that action. After years of creating with a goal of transferring knowledge, creating with a goal of triggering emotions was a bit of a fight. As frustrating as it was, though, it did illuminate ways to encourage someone to interact with my otherwise uninteresting object.

The second assignment had us creating less of a user journey and more of a user experience by mind mapping a fictional person. The assignment might have been easier if we’d had a few constraints on it, but I was finally able to create a map of roles and actions before I ran out of space to address the persona’s emotional responses and potential ways to make use of the actions and emotions triggered in this made-up environment. It was interesting, because there are a lot of potential uses for looking at and thinking about roles, actions, and responses. Because working through this with my class object didn’t pan out, it didn’t provide any new insight, but I imagine I’ll play with it as I work on other projects.

I guess what’s really important here is giving yourself permission to create these reality-based fictional characters and playing with them in the experience you’re creating to see what comes about.

Tools of Innovation in Networked Learning

The online class I’m taking gave an assignment last week based on a common innovation exercise: The Five Whys? This exercises is well known as the one Toyota uses to incite innovation among its employees. Someone brings in an idea or prototype, and other people ask, “Why?” five times. The idea is that each “Why” is really asking the person in the hot seat to further clarify or respond to what they just said, and that by the time you hit that fifth “Why” you’ve really drilled down to an idea worth working on.

It’s been rather successful for Toyota, but I noted in my reflection that it was somewhat ineffective in our class setting. We were given the assignment detailing the process, and then given a week to find a partner and do the exercise. Despite finding a partner and completing the activity relatively quickly, both my partner and I admitted that we’d self-interviewed ourselves already. We’re both the sort who do that. In effect, we ended up doing the assignment twice and not the way it was intended. (That said, I did come up with an extension for my object that I hadn’t thought about before while self-interviewing, but I’m used to doing that with my own work.)

This week’s podcast explained how to do the assignment…the day after it was due. Apparently, I wasn’t the only student concerned about how the assignment shot itself in the foot, and the professors kindly informed all of us who are like me that we’d done the assignment wrong. (The instructors have proven open to conversation on this.) Again, we’re overthinkers. It’s our nature. With the assignment sitting right in front of us, how could we not?

I’ve been sitting here since listening to the podcast trying to think about how they could have conducted this assignment to get the actual reaction they wanted. In a classroom, it would have been simple. We wouldn’t have been given the assignment until after we paired up. In a distributed classroom situation like a MOOC, they could have asked us to pair up and then contact them for the assignment. But we’re working in teams and everything goes into the team documents. Once the first pair completed and posted the assignment, the other pairs would know what the assignment was and it would trigger any overthinking tendencies in them.

But Toyota employees grounded in realspace know that The Five Whys is a common practice, and it’s one that still benefits the company. So, maybe they’ve figured out a way to not self-interview themselves.

Or maybe they haven’t. I’m not sure there is a right answer here.