D3 — Bit-sized Story: Teaching children simple computational concepts and coding
Team Members: Noel Vashishtha, Ella Cai, Lily Zheng, Sujay Kakkirala, Mario Maroto Jimenez
Introduction
The focus of our design project was to teach children simple computational concepts and coding. As our lives become increasingly digitized and computing becomes involved in many aspects of our lives, code literacy is now an important skill for students to develop. It is becoming increasingly helpful to learn coding from a young age as it is a growing field with many opportunities, and helps develop problem solving skills.
While there are many applications which teach coding, we feel they do not meet the needs of young students. We wanted to create a platform targeted towards children that balances educational content, user engagement, learning support, and accessibility. Throughout our design process, we envisioned the tools and resources we wish we had when we were younger, and tried our best to incorporate them into our solution.
We decided that the most impactful way to teach children coding is to integrate it with their school curriculum. Two of the biggest challenges we faced are how to keep young students engaged in learning, and how to assist teachers who are likely not computer science experts.
Our solution was to create an application that gamifies learning how to code, called Bit-Sized Story, that is intended to be a supplementary resource for students and teachers in or out of the classroom. One key insight was that the flow of the app should be simple to understand and navigate because users want to feel pride in their accomplishments, and receive clear feedback about their progress.
Background
This article outlines our complete design process to build an application that teaches children simple computational concepts and coding. At first, we performed thorough pre-design research by reading academic research papers by Sangho Suh on how comics can help teach programming concepts. It was interesting to see how real-life comic stories made abstract coding concepts clearer and easier to understand. These research papers have inspired us to add similar features to our product with a twist. Our product will be a tablet app, allowing anyone with access to technology and the internet to become potential consumers.
The most prominent existing solutions in the market are WhiteHat Jr, Scratch, Hour of Code, and the Grasshopper app. These solutions differ widely in teaching style, design, and ultimate goal an end-user can achieve by using it. All of the solutions that offer interaction with a real person/teacher are paid services, making them less accessible to kids. One of them does simple 1–1 lectures with a predefined schedule, while another implements high-level block programming that avoids all the syntax and details to make life easier for kids. Even though each product tries to address some issues, we believe that all the identified pain points from our personal experiences and interviews are not appropriately addressed in a single solution. We want to keep children fully engaged by using gamification techniques that are inspired by comics, and real-life stories that connect abstract concepts to the tangible.
Context Study
Profiling Users: Personas and Empathy Maps
Initially we considered two target audiences: children, and teachers and parents. From our interviews, we gathered that teachers and parents understand the importance of code literacy and want to encourage kids to learn programming. Many children are also interested in learning because they enjoy playing video games and want to create their own. We determined two sets of value propositions:. Parents and teachers have a need for this application because they understand the importance of code literacy and problem solving. For children, the application would introduce them to computer science and may spark an interest. We identified three personas: an elementary school teacher who teaches computer science, an elementary student enrolled in a computer science class, and a child who is motivated to learn coding out of personal interest.
We discovered a few key observations. Elementary school teachers vary in age and some may not be very well-versed in technology. They would like their students to be successful and want to help them as much as they can, but their unfamiliarity with technology would be a pain point. We also learned that some of the self-motivated learners may want to create games or apps that they find exciting, but don’t know where to start learning. The students enrolled in a computer science class may have difficulty staying engaged. We took these observations into consideration when designing our solution and it gave us the opportunity to reflect before creating the designs.
Illustrated below are our three personas and their respective empathy maps.
Exploratory Study: Interviews, Affinity Diagrams, and User Tasks
Although we were not able to interview children directly, we did interview teachers and gained valuable insight about students’ and teachers’ needs. We found that many teachers are not familiar with coding and may not feel comfortable using technology. A common concern was that technology would distract students, and they believed that students would prefer lessons from their teacher, compared to virtual lessons from a stranger. We realized that although teachers may use external resources, they still want to be able to interact directly with the students since they believe it is the best way to keep them interested.
The interviewees also pointed out some traditional teaching challenges, such as the uniqueness of each student, and that many children have difficulty remaining focused and engaged in their learning. The usual solution to these challenges is to provide a more personalized education, but this can prove to be difficult in a virtual classroom. The interviewees expressed concern for the quality of student-teacher interaction and communication in a virtual setting, as well as the possibility of an excessive use of technology.
We organized the information gathered from these interviews into an affinity diagram illustrated below.
From our affinity diagram we derived some key insights. We learned that if teachers were to use technology in the classroom, they would want an application with interesting visuals to keep children engaged in learning. Since teachers are not very knowledgeable about coding and computational concepts, there is a knowledge barrier that we have to help overcome. Additionally, it might be helpful to design an interface similar to technologies that they are familiar and comfortable with, such as Microsoft PowerPoint. Lastly, we can make our solution cater to diverse needs by using different teaching styles such as group projects, videos, and incentive-based activities that appeal to different students.
With these guidelines in mind, we devised a set of steps that the student needs to follow to fulfill the objective of the application. We broke down the challenge of teaching kids coding and computing concepts into three user tasks.
- Learning a new computing concept
The first milestone to achieve the objective is to learn basic computational concepts. For this, children need to be able to discover new concepts, find useful resources, and create connections with previous concepts.
2. Learning a coding topic
Once the students are familiar with computational concepts, they are ready to be introduced to actual coding, having the students complete a coding exercise involving that concept to ensure they have learned it.
3. Ask and receive help
To satisfy the need for direct teacher-student teaching, the student needs to be able to ask for help from a tutor. This tutor will then help them identify the misunderstanding or problem and explain the concept in greater detail.
After proposing these three high level tasks, we have finalized a set of challenges to solve: How will the student find new concepts and how will they be taught and tested? How can we motivate students to stay focused? How can the student engage with their teacher, mentors, and peers in a way that is satisfying and helpful?
Design
Storyboards, Sketches, and User Flows
We discovered that the features we brainstormed could be grouped into categories, which we consolidated into five key features: a video game story mode, a built-in code editor, a way to contact teachers for help, accessibility options, and a final project to apply the skills they have learned.
- Story mode
Our first feature is a video game story mode, where each lesson follows a story and students can apply what they have learned to solve in-game challenges. If we develop a story that students are interested in, we can keep them engaged and motivated. This also connects the abstract concepts to concrete real-world applications. Each student can explore the game freely to solve challenges and progress the storyline. There is a quests menu, a world map, interactable locations and objects, a catalogue of lessons, and a navigation bar. In addition, students are able to interact with their classmates in the multiplayer game via the world map and global chat, which makes learning more fun and engaging.
The feedback we received challenged our assumption that students want a multiplayer feature, and pointed out that the features were limited and did not contribute much to the learning experience. We decided that multiplayer was a feature we valued and wanted to include, since we learned from the pandemic that interacting with peers and learning in a classroom environment is much more engaging than learning in isolation. In response, we decided to allow teachers to personalize the story, such as substituting a student’s name in a mission. We also want to include collaborative achievements, such that students must work together to accomplish their missions if they want to unlock new regions, minigames, etc.
2. Built-in code editor
Our second feature is a built-in “block programming” code editor. This solves two obstacles for students learning to code; deciding on a programming language, and setting up a development environment. A typical user does not want to download any languages, packages, extensions, or code environments on their computer, and these cannot be downloaded on a tablet device. In addition, block programming offers an easier alternative to traditional programming. Users can browse blocks, and drag-and-drop them in the code editor. These blocks are designed to fit together like puzzle pieces, so the coding process is more guided and less likely to cause errors. The code editor also provides the ability to execute the code, stop execution, and receive immediate visual feedback. In our sketches for this feature, we designed a simple layout that displays the editor workspace, a library of blocks, and an output display.
The feedback we received was that if we relied heavily on block programming, students would not understand the underlying data types and data structures such as integers, booleans, arrays, etc. that are fundamental for learning more advanced coding concepts. While this is a valid point, we decided that the benefits of block programming outweigh the potential consequences. Since this application is targeted towards elementary school students, some of which may struggle with spelling and typing, block programming is the more intuitive and accessible option. Additionally, almost every Introduction to Programming course covers the fundamentals, so if a student uses our app and develops an interest in coding, then learning about the underlying code will be easier because they are already familiar with the abstract concepts.
3. Contact teacher button
The third feature is a Contact Teacher button, where students can request help. We want a button that opens a popup text messaging window. Since this application is designed to be used during class, the student will receive help quickly. We designed this feature to allow the student to see what they were having a problem with while talking with their teacher.
4. Accessibility features
The fourth feature is a set of accessibility features such as voice command, narration, video transcripts, and text-to-voice. This is intended to make our application accessible for blind, hard of hearing, and injured users. We designed an interface that can be activated in the settings, and lights up upon hearing voice commands, processes it, and performs the corresponding actions. The layout also displays suggestions for commands to increase the discoverability of this feature.
5. Final project/Knowledge tree
The fifth feature is a final project, which aims to motivate students by allowing them to showcase the skills they’ve learned. We decided to represent a user’s chosen topic as a tree, so that they can see the sub-tasks and monitor their progress and growth. Upon completing the final project, students will have something they can be proud of and can show their family and friends.
As we received feedback and iterated on our design, we decided to redesign the final project tree into a knowledge tree instead, where users can view their completed lessons which are represented by leaves and clustered by tree branches. We wanted to use the metaphor of a tree to represent personal growth and to visually display learning progress to keep students motivated. Additionally, it made sense to split the final project into multiple, smaller projects that are unlocked as the skills required to complete the projects are learned.
Final Design
Implementation and Testing
Low-fidelity Prototype and Evaluation
For our paper prototype we wanted to highlight the most crucial features of our application. We choose to include several features: a landing page that displays the map and quests, a demo mission called Stop the Hackers, and accessibility features.
Our Stop the Hackers mission features a detective who is trying to crack a lock. We add this mission in the quest log so it feels like an adventure. In order to crack the lock, they must solve a puzzle. This transitions to a mini-lesson. We thought this would be an interesting way to keep students engaged.
We received helpful feedback from prototype evaluation. We found that the user wanted more guidance on what to do next. When a mission is completed they would prefer if there is a message that tells them they are done. They also told us that they want navigation buttons to travel to the previous or next page. Based on this feedback, we added more navigation buttons in the missions. We also added more instructions in the knowledge tree to indicate how users can interact with it. We decided to reduce the number of command prompts visible at once in the accessibility features so it is easier for the people who are hands-off to understand the screen. Furthermore, we made it so the user can easily go back and choose any mission they like.
High-Fidelity Prototype and Evaluation
We developed a high-fidelity prototype, and also made several design decisions such creating a logo, name, color scheme, and mascot for our application. From the feedback above, we decided to add a mascot/narrator to guide the user and make suggestions at key moments when the next step is unclear. We added a mascot to the quests menu that the user can interact with for tips about learning, gameplay mechanics, and next steps in story progression. We believe that a talking animal will appeal to kids and make asking for help easier. In the story, the mascot finds you and your classmates shipwrecked and guides you through the storyline and missions.
From the evaluation of our high-fidelity prototype, we learned the user enjoyed the creatively designed visuals, think the missions are interesting, and that characters such as the detective will make the kids more engaged. However, some of the features could be more detailed to provide clarity. For example, they want a video tutorial on how to use the code editor, or comments walking them through the starter code code.
Our heuristic evaluators believed that our design excelled in flexibility and efficiency of use, and user control and freedom. Our error messages were also simple to understand and easily help users to recover from errors. We could improve the visibility of system status, since some buttons and interactable items blended in with the background, and quests are not visible outside of the map interface. In addition, some pages are too text-heavy.
In response to this feedback, we standardized the navigation buttons, increased contrast between buttons and the background, included the option to skip story panels, and shortened the length of certain texts.
Conclusion
Through this design project, learned how to take a problem and develop a solution step-by-step. As we learned more about our users and received feedback on our designs, we adapted our understanding of the problem and what our users required. Some of our key insights were that people have varying comfort levels with technology, and children learn differently from adults. Children learn more effectively when they are visually and mentally fascinated by a story. Our prototype evaluations showed us that it’s essential for our application to flow smoothly. We responded to feedback from each design iteration to make our application more polished and complete. We learned to map out the needs of our customers, and gain feedback during multiple steps while we improve along the way. We think for the future designers and developers should make their applications as intuitive as possible- people should know the steps to be taken next, and also accommodate the needs of individuals using their work.
Despite our best efforts, there are some limitations to our design. We do not have a way for the user to save their progress in the application or calculate high scores. Some students may want to compete with their peers because that human interaction motivates them to improve. We have also designed the application for tablets, but some students may not have access to tablets so we should add support for computer-users. We also only support English currently, which makes learning difficult for children who are not fluent in English. Our future plan is to make the app compatible with various different platforms such as desktop and add support for different languages. We also hope to keep track of high scores and make it more competitive for children who are interested. We plan on expanding the code editor to support both block and traditional programming.
