This week, we wrapped up the Storiverse project. That meant:
Getting our archive together so that future ETC projects can refer back to the work we did
Sending all of our code files and a “Lessons Learned” document to our client, Verizon’s Open Innovation Team
Giving a 15-minute presentation to ETC faculty and students on what we accomplished this semester
Guiding a couple of faculty members through a final playthrough of our experience
All in all, the team feels proud of how the Storiverse project played out. The presentation went very well. Additionally, we were visited by Christian, a member of the Verizon team, and he gave us some extremely positive feedback. He is very pleased with our work and thinks it will be useful to Verizon going forward.
This week was exciting for us, because we got to showcase our product for non-ETCers at the ETC Festival.
We set up for the festival by arranging our room to look like a home living room. We moved couches to face the TV, and hung decorative lights.
During the festival, we had the TV playing the three Relationship Status episodes included in our product (episodes 1, 4, and 5) on a loop. When guests came in, we told them that our experience was designed to compliment the show. Guests could choose whether to see our experience immediately, or to watch a bit of the show first, for context.
We were thrilled to see that most of our guests enjoyed our product. Even guests who chose not to watch any Relationship Status before opening our app were interested in the questions we posed, and many ended up watching the matching clips so they could see where the questions came from in the context of the show. Guests were able to easily navigate through the UI, and enjoyed the personality descriptions they were given.
Week 14 started off with a bang, as Monday morning was Soft Opening, or “softs.” During softs, ETC faculty members came to our project room to see our product, and give us feedback on what we might think about changing in the two weeks before the semester ends. Faculty members visited our room in groups of 3-4, and stayed for 20 minutes. Since we wanted to get as much feedback as possible, we could not have the faculty watch a full episode of Relationship Status, which would be about ten minutes long. On the other hand, we still wanted the faculty to have some introduction to the show before we gave them our product. Thus, we abridged Episode 4 to be around 5 minutes long, and had the faculty watched that shortened version. Then, we gave them our product with no context, and waited to see if they could figure out how to use it.
Faculty reaction to our product was mixed. Some faculty members felt that we had done a good job meeting the requirements we were given by the client. Others were dissatisfied with our usage of AR. However, the faculty were nearly unanimous in their desire for us to iterate upon the UI. We spent the rest of the week tweaking the UI to make the experience flow clearer for users.
Since this was Thanksgiving week, we only had Monday and Tuesday to work. However, we made the most of it! On Monday we finished our implementation, and on Monday evening, we playtested it with ETCers. We offered free pizza and invited our peers to the 5th floor lounge, where we asked them to watch one episode of Relationship Status (episode 4) and then try out our experience. During the playtest, we were focused on answering four questions:
Is the experience engaging for people who have watched the show?
Is it uncomfortable to keep the phone high enough to see the characters?
Do the personality descriptions for each value resonate with users?
Is the experience intuitive?
In general, the feedback we received was pretty positive! Users generally stayed in the experience longer than they were required to, answering all of the questions about Episode 4, and then exploring further to answer questions about episodes they had not seen. The majority of users felt that holding the phone was not uncomfortable – especially since they can put the phone down while answering questions, and only need to hold it up while examining characters. The personality descriptions certainly resonated with users – one user, who was given “Integrity,” literally said “That’s so me!” Additionally, we found that our experience was intuitive. We had one playtester who had never used AR before, and he figured out how to use the experience without instruction. While there were a couple of hiccups that we noticed that we wanted to change before finals, overall the playtest was a success.
During Week 11, we used feedback from Playtest Day to come up with a new (and improved) design for our Storiverse experience. Week 12, then, was all about implementing this design. This meant a lot of work for everyone on the team:
As the designer, I had to write a design document for the new experience, so that the programmers and artists would have implementation guidelines. (That document can be found here.) I also had to go through the episodes we decided to use for our experience – episodes 1, 4, and 5 – and identify each individual “scene” of the episode, which would constitute an event in the relationship maps of the characters involved. Furthermore, I had to come up with questions to ask the user about various scenes, and the personal values reflected in the answers to these questions. (I ended up with Openness, Decorum, Justice, Integrity, Courage, and Stability.)
The artists had to come up with a way to display personality statistics, which would replace the interaction panels from the previous iteration of the experience (although the personality stats would not require the user to find a flat surface in their environment.) The artists also had to propose a way to display the relationship events (when the user clicks on them) that can include a question, but can also have space without a question if there is no question associated with that event.
The programmers had to fill the database with the correct data about each character, relationship event, and question that would be included in the new iteration. They also had to connect the prototype to the database, which had not been done in past versions. (On Playtest Day, we tested a version of the app in which all of the data was hardcoded. However, for this version, there was too much data, and hardcoding was not a viable solution.)
We were also fortunate in that we got to have another meeting with Susan Dansby, the soap opera writer. We pitched our new experience to Susan, and she loved it, telling us that we’ve given the users a great way to interact with the show content. For the show she works on, “The Young and the Restless,” producers have recently started putting “Previously, on The Young and the Restless…” clips at the end of episodes, instead of “Next time, on The Young and the Restless….” They have found that while the “Next time” clips made users who didn’t see their favorite characters less interested in watching the next episode, the “Previously on” clips reminded users of past drama and made them wonder how the situations would progress in the next episode, which hence made them eager to watch it. Thus, our experience has two benefits. Of course, it lets users connect themselves to the show by asking them to evaluate what they would have done in situations that the characters faced. But in addition, by allowing our users to review footage from episodes they had already seen, it also primes the users to watch more episodes. We were very encouraged by Susan’s feedback.
Before we ended our meeting with Susan, she made a suggestion to improve the experience further. She pointed out that when people take any sort of personality quiz, they want to know not just how they are, but also how other people – such as friends and romantic interests – react to them. Since this is the case, she suggested that we write a description for each personal value that can result from the questions, including those sorts of details. We agreed that this was a good idea.
Although we were not able to test with many people in our target audience on Playtest Day, we were able to learn many things which indicated to us that we needed to change our experience. For example, when we asked playtesters where they generally used their phones, we got a wide variety of answers, from bed, to public transportation. We wanted our experience to be available to users wherever they may be using their phones, but our current experience demanded that the user have access to a large, flat surface (where the interaction panel, episode box, and inventory box would be placed), and such a surface would not be available in many of the locations our playtesters use their phones. Therefore, we knew that we had to change the experience so that it would not have specific requirements for the attributes of the play space.
Additionally, we found that many users did not remember the objects to which we had attached questions. The example question we used – “The last time your SO got you a present, was it because you were mad?” – was attached to a rose, because it referenced a scene in which Peter bought Libby a rose after leaving her at the lunch table to go flirt with a waitress. This made sense to the project members, because we have watched the episode many times, so we remember exactly what happened in the episode. However, our playtesters – having only seen the episode once – did not make the connection, and felt that the rose was a random object. Therefore, we decided that we would have to detach the questions from the objects.
Finally, we saw while playtesting that the commenting feature was very clunky. A playtester would look at other users’ comments, and think they were supposed to tap the one that most closely reflected their views on the question. Additionally, playtesters did not see the point in adding their own comments. While playtesters seemed to engage with the question itself, we needed to find a way for the experience to respond to their answers, rather than asking them to clarify in a comment.
Thus, we decided to scrap the episode box, interaction panel, and inventory box, and build our experience based on the relationship map alone. We would still ask the users questions about what happened in the show, but instead of attaching those questions to objects, we would attach them to the relationship event to which the question referred. (For example, when a user looked at Peter and Libby’s relationship and clicked on the event where Libby reveals that she spied on him through Find My Phone, the user would be able to see a clip of the event – as originally designed in the relationship map – and would also be able to answer the question, “Is it ok to snoop on a partner you think is cheating?) Additionally, when the user answered a question, the app would respond by telling the user what their answer revealed about their values. (For example, if a user said “Yes” to the above question, the user values justice. If they said “No,” then they value integrity.) In this way, we sort of combine the relationship map with a personality quiz. No matter how the user answers any question, the corresponding personality value is always a positive one, so the user can always feel good about how they would handle the situations in which the characters find themselves.
This week, we had our Halves presentation on Wednesday. That meant that the first part of the week was dedicated to polishing our presentation – finalizing our slides, and rehearsing what we were going to say. At Shirley and Chris’s suggestion, we spent very little presentation time on QB1, and tried to clearly explain the product that we are making.
Here is a recording of our official presentation on Wednesday:
On Wednesday afternoon, we debriefed with our client, Philip, who had come to see the presentation. He was happy with the direction we had chosen for the project, and thought we did a good job detailing our plans. Then, Shirley came and gave us feedback from the faculty. Overall, faculty response to our presentation was fairly positive. One of our main concerns going into the presentation was that we could not properly justify the use of AR for this project, but the majority of the faculty were satisfied knowing that our client had requested that we use new technology. Additionally, faculty felt that we pivoted well from QB1 to Relationship Status, and had made progress on our project despite the huge change. As we near the end of the semester, the faculty expects us to polish our design and validate that the mechanics work for our target audience.
We were also lucky enough to talk to Christian, our client’s director, about our project. Christian was excited not only about our product, but also about the research we are doing into how audiences want to interact with extra content from shows. He also mentioned that it would be great if we could frame our product in a way that shows how it integrates with the Go90 mobile app. Since we don’t have access to the back end of the app, Philip suggested that we create a video-watching experience to go before the AR experience, which would look like the Go90 app. That is one of the things we’ll be working on next week.
This week, we started by laying out a full, beginning-to-end walk-through of our current design. Here is an abridged version of that walk-through:
First, when the user finishes watching an episode of Relationship Status, the following notification will pop up
When the user clicks on this notification, the user will be taken to our AR experience. The user’s first task will be to find a flat surface for the AR experience to center around. Once a flat surface is found, three panels will appear. The panel on the right is for the user’s inventory, which is built to look like a makeup box. The panel on the left is where the new episode’s “loot box” will appear, and the panel in the middle is what we call the “interaction panel.” In addition to these three panels, an incomplete group of characters will appear above the surface. This group of characters represents the characters that to which the user had already been introduced before the new episode. The blank spaces represent the characters that were introduced in the new episode.
When the loot box opens, the user will see orbs representing the new characters, which will automatically fly up and take their places in the floating character group. Additionally, links will form between the new characters that show how each of them are related. If the user inspects a link closely, the user will see important events in the relationship, and be able to watch show clips associated with those events.
In addition to the character orbs, the loot box will also contain one or more objects that were significant in the new episode. By tapping on the object, the user will move it to the interaction panel. Once it is there, the user will be given a question that relates what happened with the object in the episode to the user’s actual life. In the episode we are using for this example, one character bought his girlfriend roses in the hopes that the girlfriend would ignore the fact that he was clearly flirting with their waitress. Thus, a question we might ask for the rose is “The last time your SO got you a present, was it because you were mad?” (The question is not represented in this concept art.)
Once the user selects “Yes” or “No,” they will be able to see how other users have voted on the same question. In addition, they will be able to leave a comment if they wish. Other users’ comments will appear as they are submitted, so the user will be able to write a comment that responds to other user answers if they wish. Then, the rose will go to the user’s inventory.
A week after the episode airs, if the user goes back to the inventory and selects the rose again, they will be able to see some of the top comments that answered the question associated with the rose. We hope that the “top comment” mechanic will encourage more people to leave a comment than would otherwise, as this mechanic is used by various successful YouTube personalities to encourage their viewers to leave a comment.
After agreeing that this walk-through represents a good base for our experience, our programmers and artists set to work prototyping as much of the functionality as possible. While this prototype is not complete, it does represent a major jump forward from last week.
Finally, we also spent some of this week prepping for our halves presentation, which is next week. During the presentation, we will show our faculty members what we have accomplished so far, and get feedback as to where we should go next. Wish us luck!
This week, we made progress on both the technology front and the design front.
For technology, we made several prototypes of ways that characters and their associated relationship maps could be displayed in augmented reality. Two of the prototypes were designed to determine how users preferred to see augmented reality react to their movements. We called these prototypes “Sprite” and “Pill.” In the “Sprite” prototype, each of the character’s faces was always oriented towards the user, no matter where the user moved. In the “Pill” prototype, the characters were placed in a set orientation, and did not move when the users did. Thus, a user could go around the character, and see that the character’s face was attached to an object shaped like a pill. We wondered if allowing the users to talk around a 3D object (the pill) would help them understand where the objects were located in AR space.
We tested these two prototypes with 11 fellow ETC students. The results showed that while most people preferred the Sprite prototype, people felt that the characters who were looking straight at the camera were creepy, because it seemed that the characters were constantly looking at them. Therefore, going forward, we will ensure that character images are always oriented towards the user, but will select images in which the character is not looking directly at the camera.
The third prototype we created is called the “Galaxy” prototype. This prototype is a proposed way of displaying many characters at once. At first we hoped that we could display the total relationship map of the show via an interconnected web of characters, but when we tried to lay it out in Maya, we quickly realized that the numerous characters and connections made it messy and confusing.
Therefore, we decided to try showing the characters in a floating “Galaxy” around the user, and only displaying a certain character’s relationship map when the user selected that character. Knowing that we will eventually want to display videos as well, the programmers also used this prototype to experiment with the number of videos that can be placed in an AR space.
Initial reaction to this prototype has been positive, but the way characters are arranged in space will continue to evolve as the design of the experience evolves, and we determine which mechanics are most important.
We talked to multiple industry professionals this week to get ideas about how to design an engaging experience.
First, we talked to Brenda Harger, the ETC’s improv teacher. Brenda pointed out that people who watch soap operas love to make judgments about the choices that the characters make. This supported our hypothesis from last week, that users would enjoy an experience that would let them weigh in on the morality of the characters’ decisions.
Later in the week, we were lucky enough to get a meeting with Susan Dansby and David McKenna, both successful television writers. Susan and David told us that in addition to judging the morality of character decisions, soap opera viewers also enjoy relating the situations that the characters are in to their own lives. Thus, when we design the decision-judging portion of the experience, we will frame our questions to users in ways that will make the users reflect on how they have dealt with relationships in the past.
Jessica Hammer, an ETC faculty member who specializes in HCI, talked to us about how to leverage 3D space to organize our relationship maps. She suggested possibly organizing relationships spatially to show how characters feel about one another – for example, if a user selects a central character to investigate, all characters to the left of the central character could be those that a central character dislikes, and all characters to the right could be those that the central character likes. We will begin to play more with the spatial organization of our relationship maps.
Because Relationship Status has a large cast of characters, each of which has several connections to the other characters in the show, it’s sometimes hard to keep track of who knows who. Therefore, we decided that before we designed any content for this show, it was important to write out exactly how the characters were interconnected. The resulting relationship map would hopefully prevent us from creating auxiliary content that incorrectly portrayed the characters’ relationships.
After we compiled the map, we realized that while the text-based map was a useful tool for us as designers, a graphical relationship map could serve as the base of our user experience. Since the main focus of the show is how the relationships between characters change and evolve, it makes sense to allow our users to interact with the show by presenting the users with a visual depiction of the relationships and allowing them to “zoom in” on any relationship they find particularly interesting. We discussed this concept with one of the show’s producers during the client meeting, and he agreed this was a good starting point.
Because the map will be complex, it makes sense to put it in 3D space – so we decided to experiment by using AR to form the map in the familiar 3D space of the real world.
Additionally, we hypothesized that part of what draws viewers into the Relationship Status show is the moral grey-area in which many of the characters make choices, and that viewers would enjoy discussing the morality of the characters’ decisions. To test this hypothesis, we brought in several of our classmates to watch a particularly morally-ambiguous episode – “The Lucky One” – and surveyed them about it.