Introduction and Overview of the Project
Our goal this semester was to create an experience that can inspire African American youngsters (early teens) to take up S.T.E.A.M (Science, Technology, Engineering, Arts, Mathematics) careers in the future. We worked with Damola and Wole Idowu who together run the company Toyzelectronics.
Our deliverable was to deliver this experience on a mobile platform. We went back and forth trying to decide between a browser based experience and an Android application. Finally we chose to go with the Android application since targeting mobile phones was quite important and an Android application was a good way to achieve that. This application was also supposed to achieve our goal as mentioned above. The hard part of course, was how to achieve this.
Team members for the semester were Chuhan Wu (UI/UX Artist), Yifan Deng (UI/UX Artist), Ram Iyer (Producer), Runzhao Xiao (Programmer) and Zi Wang (programmer).
What went well
Looking back, here are some of the things about the project that we are proud of:
- Once we were able to get a build up and running, we worked quite hard: Most of the work seen in our final version of the application was built in the second half of the semester (after halves). It took us a while to get there for several reasons that will be discussed later. But once we got to our first build, things started looking much clearer to us when we brainstormed about what to do. It was easier to think of improvements and new features to be added and overall we all had a morale boost and started working hard to end with a strong final product.
- The numbers game and rhythm game turned out to be quite enjoyable: Playtesting revealed that these pieces were the strongest and most engaging parts of the entire experience. Of course, the main reason for this is that we have iterated on these the longest. These two were the first pieces that we completed (we had prototypes of them by halves).
- A happy client: Overall, we feel that Damola was quite happy with what we delivered. We tried to deliver as many of his requests as possible and he appreciated that. He brought a lot of energy to the table which, on more occasions than one, made all of us feel good about the project and kept us going. He even spoke up for us during the Q/A session of the final presentation!
- Release on the Android Playstore: We were quite happy at the end that we were able to publish our project on the Android playstore before the end of the project (find it here). To be fair, it is still in its open testing phase. But it makes the team proud that our work is published online and something that we can show on our resumes. This is one of the best tangible takeaways that we have.
What could have been better
Here were some issues with our project and things we would look to change if we had to do it all over again:
- We were not able to come together as a team in the first few weeks of the project: We think the reason was that first years and second years had never met before in real life. This made a difference because it was the first time one half of the group was meeting another half of the group. We took time to get introduced to each other, understand what our strengths and weaknesses were. It took time to establish effective communication with one other. This was quite a new experience for everyone. First years had never worked on an ETC project before. Second years had never worked on a project where half of the group was unknown to them. Maybe externally this could seem insignificant, but internally it did have an impact on how well we worked together.
- Our goal statement was a little too broad: Designing without constraints is hard. When we started, we were quite confused about what to do and no one had any good ideas. Eventually, when we did have ideas, we realized that it was difficult to evaluate them because everything seemed like a good idea on paper. Many times during brainstorming, we found that a lot of pros and cons that came up while evaluating ideas was based simply on personal preferences of the team members. It was difficult to visualize what the ending product was supposed to look like and this gave rise to our next problem.
- Slow progress and low morale in the first four weeks: In the weeks leading up to quarter walkarounds, we had no clue what we were going to do. We had three initial ideas but we had a hard time choosing which one to select. We ended up settling with the graphic novel idea simply because we felt pressured into picking something. After all, it was already quarters and we hadn’t really built anything substantial. This made all of us feel uneasy and we ended up rushing into a terrible choice that wasted more of our time. Five weeks in, when it became obvious to us that the graphic novel idea was a poor choice because we lacked artists, we felt like we were back to square one with nothing to show for it. This ended up lowering our morale and made everyone really anxious. Honestly, the choice to build a minigame driven experience (which we ended up delivering) was also a rushed choice because we wanted to have something for halves. Luckily, that did end up working out.
- Playtest problems: We really underestimated how difficult it was going to be to do remote playtesting with Android builds. The way we tested it amongst ourselves and with other ETC students was simply by sending out .apk files and asking them to sideload on their Android devices by overriding permissions. The educators that we reached out to were uncomfortable with getting students (aged 10-14) to do this because it would mean the students who had limited knowledge of permissions on Android would have to enable installation from unknown sources. To the educators, this was a dangerous proposition which was best to avoid. In fact, the only reason we pushed hard to get an Android release on the Google Playstore was because we wanted to make playtesting easier. However, we wasted valuable time in learning this lesson.
Lessons learnt
Keeping our major issues in mind, here are some valuable lessons we learnt from the semester:
- Thinking about constraints early on and driving the design using them: Our lesson was that we should have thought about internal constraints when there was a lack of external constraints. If we had thought about the project from this perspective, we would have realized quite early on that choosing to build a graphic novel without artists on the team was a foolish choice. For this project, we should have thought about the lack of artists, STEAM centric, superhero and father-son theme, Android as the target platform and educational content targeted towards children. We ultimately did end up with these, but we did so by reactively stumbling upon these pieces one at a time through client and faculty suggestions, instead of proactively making these our core design pillars and building bottom up from there.
- Get to the first build as soon as possible: Its must easier to iterate and build on top of something than it is to build something completely new. We ended with our first build quite late into the semester and this caused a lot of time management problems for us. Pushing for the first build as soon as possible is crucial.
- Positivity, morale and momentum are extremely important and must be cultivated: This semester, we had a stark difference between the first and second half of the semester in terms of the morale of the team. Although some things went wrong for us during our early weeks, no one blamed anyone else and we all quickly accepted our situation without resentment. We were all positive about our ability to deliver something good. Everyone was well intentioned and looked towards the future. That is why we were able to quickly switch ideas and immediately started work on our next idea.
- If mobile apps are the target (iOS or Android), get them on the Playstore/Appstore as soon as possible: Doing this ensures that when you do have to do playtesting, at least the logistics are not a challenge. When your app is published, it becomes extremely easy to send a link for playtesting. There is a huge quality-of-life difference between sending out .apk files and a Google Playstore link. Once on the store, it is also extremely easy to get previous users to test newer versions because they can simply go on the store and update the app.
If we had one more month
- More playtesting: If we had another month, one thing that we would definitely want to do is more playtesting, especially with our target demographic of 13-15 years old. At this point in our project, one of our biggest weaknesses is that we never tested the accuracy of our transformational content – are kids really getting inspired to take up STEAM careers in the future by playing through our game? While we have observed that kids get engaged with our numbers and rhythm game, it is quite hard to tell if the experience is memorable for them and if it inspires any real change.
- Scoring mechanism for the different minigames: The current version of our rhythm game lacks a scoring mechanism which really takes away from the ‘game’ part. The same applies to the glasses design experience and a little bit to the numbers game. Although we have a STEAM scorecard right now, the experience does not really show how well the player did on the different aspects of the game. What could be really nice is to gamify each minigame with a scoring system and then show the player’s performance with each game at the end. Maybe the scores could be relative in order to ensure that the player gets full points for at least one and the others scores are relative to it.
- Better Glasses Design experience: Something that we all agree on is that the glasses minigame experience feels lacklustre. It was pulled together at the last minute because our original design for the third minigame did not work out. We needed to have an experience inspired by Wole’s glasses design and we chose what we did because we wanted to quickly finish it. With more time, we would have invested more in its design and development. Since the badges earned from the glasses are the technology and engineering badges, something that is closely related could have been done. We dont really have any solid ideas on how to improve this but with more brainstorming and exploration, maybe we would have.
- Better tutorials for each minigame: Playtesting revealed that kids who play our game do have questions that need to be answered. The implication being that the UI of the game is not self explanatory and hence there is room for improvement. How would we improve it? Well, one simple way would be to add better tutorials. Right now we have textual tutorials where kids have to read instructions. Playtesting also revealed that kids are not keen to read a lot of text. A better option could be to have video tutorials with vocal instructions. We never really got to explore this part and with another month, that would be another thing that we could try.
Conclusion
One thing for certain is that this project was an excellent learning experience for all of us on the team. Although there were technical learnings about building an Android application, there were a lot of project and team management learnings. After all, we ended up in a rough situation because of our actions and came out of it (with support from client and faculty) because of our actions too. We are glad we got to learn important lessons through an ETC project because it will make each one of us a better worker no matter where we end up after we graduate. And for this reason we feel that being a part of this project was a very valuable experience for us and we are glad we were a part of it.