Building Block
Web Application Development Project
UC San Diego (CSE 170 – Interaction Design)
Scope: Full-Stack Development, Project Management, User Research, UI/UX, Testing
Timeline: 3 months (January - March 2020)
Overview/Background:
As part of a 10-week Interaction Design course at UC San Diego, I worked on a team of three to develop a web application that would promote collective creativity. Our application, Building Block, focused on the creative process of choreographing a dance performance set. We used React to develop our web application and Google Firebase to handle database operations.
As a choreographer on a competitive dance team on campus, I noticed that different choreographers have different ways of visualizing their placements of dancers on stage, called blocking. Some map out the stage movements on pen and paper while others might take a more interactive approach and use coins to represent dancers and physically move them around to simulate the effects they are trying to create. Everyone’s unique style of blocking makes it difficult when the time comes to share each others’ notes and ideas, and nobody can understand anyone else’s visual representations. Our application seeks to solve this predicament.
The Problem:
Blocking is the most time consuming part of this creative process, and making this stage more efficient would significantly improve the speed of set building, allowing teams more time to refine their performance and ensuring the final product is stage ready.
Performances and competitions are few and far in between and the set building process often takes months at a time to complete and refine. Most teams perform or compete only two or three times a year due to the long process of set building, so any time not spent in crunch time is time wasted. Streamlining any segment of the set building process would relieve the amount of time wasted.
Needfinding:
The first step of our development process was to conduct needfinding research. Since our app’s target demographic are choreographers, we decided to conduct interviews onto the artistic board of dance teams on campus. We asked them questions that would elaborate on their blocking style and their experience when it comes to sharing their blocking ideas with the other choreographers on their team such as:
- What do you use to visualize blocking?
- How do you differentiate the dancers in the piece?
- How do you plot the movement from one formation to another?
- Do problems usually arise when sharing your blocking notes or when receiving your peers’ blocking notes?
- What problems arise in the process of translating blocking notes into actual on stage dancers?
Over the course of our needfinding research we took notes on recurring answers that we thought should become a core part of our app. For instance, the biggest issue is that most of the choreographers use pen and paper to graph the placements of dancers in formation, however a problem that arises is that some peoples’ drawings are sloppy and hard to read. From this finding, we determined that it would be a good design idea to have our dancer plotting space to be a well defined grid where icons representing the dancers can only inhabit on the intersections of the grid similar to that of the chinese board game “Go”, therefore creating a structured and clear picture of the formation.
Figure 1.1 (left) & 1.2 (right): The above photos are actual blocking notes used in a competition set and one can see how differently each choreographer designs the formations. Figure 1.1 assigns dancers to a number for organization and uses those numbers to assign positions. Figure 1.2 maps out possible formations first and then assigns dancers after Both are practically undecipherable without an explanation.
Figure 2: We decided that if we designed our app’s creation space to operate like the game Go, any possible dance formation could be built cleanly and organized.
Storyboards:
Since all three of us in the project group are choreographers on teams in the UCSD dance community, we drafted up some storyboards that depict how we want our application to address the problem. The stories were driven by our firsthand experiences as choreographers as well as common issues we found out from our interviews with other choreographers on campus.
Storyboard #1:
This storyboard illustrates the frustrations of not knowing what other choreographers have already done in their blocking. Therefore Bob doesn’t know that certain formations have already been done, and too many repetitions of the same formation would be boring to watch. Not knowing this would make him frustrated that he has to change up the assignment of the dancers in his piece.
Storyboard #2:
This storyboard illustrates the difficulty of visualizing the transitions between formations due to the difficulty of imagining how people will move to a new spot. Choreographers sometimes don’t realize that they might send dancers across the stage in a matter of a few seconds and the transition is impossible. The app would help them track the individual dancers.
Storyboard #3:
This storyboard illustrates the difficulty of collaboration between choreographers because of the readability of their blocking notes. Bad handwriting or personal note taking techniques might invoke confusion for others who are reading it. By using the app, everyone who is reading the blocking notes through a universal medium would have an easier time collaborating with each other.
From these three storyboards, we were able to pinpoint that the most apparent issues were due to a lack of organization in formation management, dancer management, readability, and shareability. Therefore we needed our application to force the user’s workspace to be clear and readable, provide tools to better manage dancers and formations and develop a way for choreographers to collaborate with each other. We kept these core solutions in mind as we set on creating our low-fidelity prototypes.
Paper Prototypes:
Prototype #1:
This paper prototype was designed by one of our programmers who has more of a computer science background. Consequently the paper prototype has more of a focus on functionality and usefulness over things like aesthetic and workflow. The inspiration for this design comes from game menus and how the design is generally one main workspace with side menus in the peripherals.
Prototype #2:
This paper prototype was designed by one of our designers who has a background in design and interaction. Therefore, the paper prototype focuses more on visual design and user friendliness with a clear workflow. The inspiration comes from real life experience of blocking, and what a choreographer’s mind goes through for every step of the blocking process.
Workflow Demonstrations:
User Testing:
Our team then conducted user testing on the paper prototypes to see how users would interact with the screens on our app. We chose to have random people test our product rather than just dancers. This would give us a sense of how accessible usable our app would be for a diverse audience, even if our target demographics are dance choreographers.
Users that tested Prototype 1 liked the simplistic minimalist design of the app and the menus, specifically how the menus didn’t move the user away from the workspace. This way the user’s work flow isn’t interrupted and they can still see what is going on without having to switch back and forth between a menu and their work. Our testers said that the concept is easy to understand and use; however, they did voice their concern of not knowing what each of the menu buttons symbolized or meant without the labels. This made us realize that there weren’t any universal icons that symbolize important terms in dance terminology so labels will have to be necessary for ease of navigation. They also said that it would be nice if the design was more aesthetic.
Users that tested Prototype 2 liked the aesthetic design of the app and said that the proportions of the screen and menus make it more appealing to look at than the first prototype. They also liked that the work flow is more linear and makes it easier to set up the core details of a project before the creative work begins. However, a question that arose was the problem of dynamic changes to those core details, such as what if we wanted to add dancers after already setting up the project. The testers also liked the overlay of the preset formations as that gave them easy access to common shapes without having to manually create them every time. Also, as with the first prototype, the menu icons without labels made it hard for the testers to navigate the menus.
High Fidelity Prototypes:
Using what we learned from our user testing, we decided to merge the best of both prototypes into one design. The aesthetic and the user accessibility of the second prototype with the freedom of creation of the first.
Our first draft was based on the design of our second paper prototype, redesigned with the critiques we had in mind. The menu icons have labels under them for navigational ease and we have our music bar placed right above the main menu rather than having it buried within a menu feature.
For our next iteration, we tried to come up with a color scheme that would make the app look nice. We went with purple and white as our primary colors for the app with blue as an accent. We also designed a login, signup, and home page for the app along with beginning our development on our app’s identity. This included coming up with a name and logo which we thought would personify what we wanted our app to be. We went with “Building Block” because it was a nice play on the word block and we felt that blocking really is what builds and assembles a dance performance. Our logo is a simple cube reminiscent of wooden blocks kids would play with. We decided on this because we wanted our app to be simple, straightforward, and easy enough for anyone to pick up and start creating.
Final Design:
For our final design we decided that simplifying our color scheme to just white and purple would give us a cleaner and more aesthetic look. We developed a color menu that would signify dancers performing different accents in the piece. We developed a formations menu so the choreographer can jump between different formations in the piece, and a share function to share their project to other choreographers through a link. With our limited resources and manpower, we decided to remove our music function and opted for a simpler transition function that would scroll through to the next formation on the list. Below is what the screens for our final design looks like.
From the App to the Stage:
We realized that the concept of this app and its usage is difficult to explain to someone who isn’t knowledgeable in dance or is not familiar with the set building process. What we intended with this app is to visualize a dance piece and then translate the choreographers’ vision onto the stage. So a visual demonstration is usually the best way for people outside the dance world to understand the concept.
Here the choreographer wants everyone dancing in unison so we colored all the dots in the formation one color, and this is how this particular “V” formation translates from the app to the stage.
Here the choreographer wants the dancers to perform a ripple effect with the center core group (red) performing a move and then some dancers performing an accent move (blue) after a delay. This would allow the choreographers to keep track of which dancers do core choreography and which dancers perform accents while managing complex patterns and effects throughout the piece.
Video Demonstration:
Reflection:
After working in a team for ten weeks to develop this app, I have learned that this experience was a great way for me to learn about working on a team and the dynamics between filling in for each others’ strengths and weaknesses. Our most effective solution was to congregate amongst each other and evenly divide the work for a deadline according to each of our members’ strengths. We also had the problem of nobody in our group being experienced in React, so one of the challenges of developing this app was to learn the language as well as meet the deadlines every week. However, with a hunger to learn and dedication to our responsibilities we managed to work through sleepless nights to develop our app in React and meet the deadlines on time every week.
Additional design features we wanted to implement, but couldn’t due to constraints on time and manpower include a music function. This would allow the choreographer to sync their music to the movement of their workspace. Another desire we had was to implement a real time collaborative workspace where multiple people can participate at the same time. Finally, we think that releasing our product as a standalone app would reach a wider audience and be more convenient to the user so that they don’t have to launch a browser every time they want to use the app.
Working in a ten week timeframe with a small team of three consisting of one designer and two programmers proved to be a challenge in matters of both time and resources. If we had more resources I believe the success of our concept would not just be measured by how many people use our app. It could also be assessed by how the whole process of blocking and set building will be revolutionized from a predominantly physical space to the digital space. Further success would see other performance based entertainment such as theatre or marching band follow suit into the digital blocking workspace.
Here is a link to the final app:
Building Block