Week 7: New Schedules, New Implementations
Alumni Meetings
Starting late last week and continuing mostly into this week we set up appointments with a bunch of alumni who had initially responded to a survey we sent out early in the semester. We wanted to get some first hand knowledge about the festival experience from people who had experienced all stages of it, as a first year, a second year, and as a guest.
We were looking to get information from them about how exactly they navigated around festival and how they decided which projects and worlds to visit, as well as finding out who they were hoping to spend time with.
Generally what we found from the alumni is that they relied on the festival heavily as a social experience and navigated around it as such. One of almost all of their primary motivations was catching up with people. By talking to fellow alumni and faculty in the context of festival they also got suggestions for projects to check out, and relied on this network to tailor the experience down into something more manageable.
New Schedule
The primary update that we have for this week is around scheduling. When we started this semester, we hoped to extend the festival out across a whole week, unlike any previous year. As we got into it a bit more we realized that spreading it out so much would cause the experience to be too diluted as guests would be joining at odd moments when they had free time and we’d lose the richness of the singular night event.
We’ve had a plan in place for several weeks now revolving around a three day event started by two of livestreams and culminating in the virtual festival experience solo on Sunday. After thinking about it this last week, we’ve seen that by preceding the virtual festival with two days of livestreams we would end up covering redundant information in what is intended to be the highlighted, VIP experience.This means that invited guests wouldn’t have a reason to tune in to the livestream, or if they view the livestream, they have less of a reason to join the Sunday session. There is also the ever-present concern about what we are asking and expecting of guests and students. Are we communicating clearly enough what exactly we expect guests to attend/view? Are we asking students to work too many hours just to host the festival, ending up totaling around 20 hours of festival time?
To address these concerns we are condensing the festival back down into a single day. On this day there will be three sessions of the virtual festival experience, in the morning, afternoon, and evening, and a livestream of each of these sessions as well. By shrinking it back we are hoping to create a more impactful experience because we are funneling all our guests into a single day, instead of letting themselves spread out across three days.
We’ll also be solving the issue of how much we are asking of each student. During a one day event, each project team will be able to split the virtual festival sessions into shifts that they will work according to their convenience and preference, ending up with about 3-4.5 hours total depending on both the sizes and numbers of their teams in festival, which is much closer to their typical expectations for a normal festival.
Overall this new schedule will help us to address our three types of audience: waders, swimmers, and divers, who all differ in regard to how deeply they want to jump into the overall festival experience. Condensing it down gives us the ability to accommodate all of these audiences at once.
Guest Flow Options
In early stage of the development, we evaluated our choices based on our testing results and how to balance easier guest experience and student work loads. As we decided to move forward, we faced another problem that to incorporate Zoom calls in our build requires the guests to jump across applications a lot between Zoom app and our PC build. We decided to reevaluate our design decisions, with the focus on the guest flow through the experience. This is a more in-depth evaluation because not only do we know more about tech from testings, we’ve also learned more about what ‘projects’ we’re expecting to support on the Festival. We took in consideration of Zoom communication, project needs, virtual space needs, and what those mean in terms of guest flow.
Why do we Need Zoom?
We are designing an implementing BVW rooms for each BVW project. These rooms will feature an interactive object that will directly download and subsequently launch project builds. There will also be an area of the room that will trigger the launch of a Zoom call that will have the BVW or 2nd year project team waiting in it to either run the world together or to talk about the work.
Zoom provides the most direct and robust video chat experience, so we decided to develop our virtual space with the help of Zoom, that we’ll send our guests to a Zoom room for more in-depth talk and certain experiences. Our virtual build can run simultaneously with Zoom, that said, each guest can be in a Zoom room with others while still running around in the virtual space in their avatars.
Plan A: A Local Build
One option we are looking at is still, a local version of the festival, which would instead be a .exe downloaded from the festival website and installed on their PC’s. This is far easier for us to build because we know that all of the plug-ins work stably, but the guest experience may be a little less than ideal as we ask them to navigate from a window of the festival, to a window for Zoom, to a window for a BVW world and back again. After consulting with Dave and Shirley on these options, we think that this is the path we will pursue, primarily because having a stable and functional experience is among the highest priorities for us.
Plan B: Develop with webGL
Another option is to host the festival build on a festival website using webGL. The web page would feature two windows. One on the left would hold the virtual festival space. On the right would be an embedded Zoom call that begins as guests join from BVW and project rooms. This path is much more straightforward for a guest to experience, as they will stay in one window for nearly the entire festival, but it will be much more difficult to get working stably. Many of the plugins that we are using currently to support our chatting and broadcasting systems likely won’t work using WebGL.
After multiple discussions with faculties, we decided to go with our Plan A, and focus on iterating the ‘jumping between the applications’. Plan B comes with too many restrictions on development, and it is harder to manage comparing to a local build. And we immediately started preparing for our playtest on Friday to test on the guest flow to help us refine our ‘Plan A’.
Avatar System and UI Updates
Within the festival itself, we’ve made some iterations on the existing UI for the avatar system and the onboarding introduction. We’ve started to apply the ‘Festival of Tomorrow’ theme to the work, pulling out color palettes, typefaces, and art styles inspired by it. With the onboarding animation, we currently have the friendly face of Quasi, a recognizable ETC ‘celebrity’ to guide the guest in, which provides them a welcoming and familiar experience to something new.
Playtesting: for Guest Flow
We playtested our first prototype of this in one-on-one sessions on Friday, asking the testers to use think-aloud protocol to explain their thoughts, feelings, and actions during their activity. They were asked to join the festival by logging in, ‘create’ their avatar(system not yet implemented), and then navigate to two different buildings that would do two different things: download and launch a build, and launch a Zoom call that was screen sharing an AirConsole project.
What’s Next?
Next week we’re stressing about ½’s presentations first and foremost. We’re also looking to set some time to check in with Janice Metz and Caitlyn Zunic to get the ball rolling on the festival invitation process.
