Final Reflection

At the beginning of the semester, we were all focused on learning JavaScript on our own as a means to develop the apps we chose to prototype as the semester went on. While each of us is still interested in being better programmers, we felt that our inexperience with javascript was precluding us from doing the other things that we were passionate about, namely education and design. As soon as we put the idea of needing code behind us, we were able to examine these topics more thoroughly. By doing this, we were given the freedom to explore the literature around student motivation and actually try to incorporate what we found into our our designs. We made a lot of significant design decisions that we may have ignored if we had focused on coding. In the beginning stages of developing this prototype, we weren’t sure about giving points or badges for skills learned, but the research showed that this wasn’t a good idea.  

In addition, we also were able to think about the situation in schools and why a piece of technology made specifically for the classroom may not be the best approach to solving problems. This is due namely to the lack of proper integration we saw in the classroom and the amount of bureaucracy involved in getting any technology adopted. Teachers needed someone to go in and explain how to turn on the device, how to make lesson plans involving it, etc. This in and of itself isn’t really taking full advantage of the wonderful things these devices can do. Overall, we found that we weren’t particularly driven to try to make something for the classroom.

For many of us, this was the first really research driven designing we’ve done. We noticed that we have definitely grown as designers in terms of processing information and deciding how to use it. This is an imperative skill for any engineer or designer and we’re proud of the way we were able to incorporate what we learned into our final design. Our coding may not be our strongest front, but we’ve certainly learned about many of the difficulties surrounding making apps. As a whole, we would have appreciated a more balanced team formation. Both of the Javascript teaching assistants were placed in the same group making our group start off far behind and with far fewer resources at our disposal. Overall, we learned a lot about design, education, and the introduction of new technology to the educational world.

Our Final Prototype

As we developed our prototype, we began to wonder what happened between childhood and adolescence that caused people to no longer want to learn and explore the world. The classrooms we visited had kids who were really enjoying reading and doing activities, but we know that motivation is a serious issue in later education. What happened? Over the past couple of decades, there has been a significant shift in what researchers know about the roots of human motivation. The most interesting part about this shift is that it counters a lot of the structures that are most prevalent in our society. For instance, giving someone a reward, such as a high grade or sticker, can sometimes be very counterproductive. This is because it shifts the students motivation. Instead of reading a book because they are interested in what it has to say they instead will read it for the grade. In addition, this typically means that they will read less on their own time and cease to explore for fun. Even though this is extremely well tested and heavily researched there hasn’t been a reaction in most of the school systems. Most of this research was started by Edward L. Deci and Richard M. Ryan. Any of their papers on Self-Determination Theory are a fascinating read and leave the reader wondering why more hasn’t changed. Other readings include Drive, by Daniel H. Pink.

We felt that it would be important to motivate students by structuring our games such that users could track their improvement and thus feel competent. This idea was largely driven by the ideas laid out in a paper on Achievement Motivation Theory by John G. Nicholls, which can be found here. This paper explores how humans naturally attempt to improve mastery if presented with tasks that offer a moderate challenge without salient extrinsic factors. By this token, we wanted to allow students to track their improvement and develop their mastery of the skills intrinsic to these games.

On their own, the example games we’ve selected provide logic skill building and have educational value. However, we wanted to provide users with a learning value apart from the gaming experience itself. One example was choosing to provide ways to further explore topics related to these games without feeling bombarded by excess information. To accomplish this goal, we included links in each of the game’s wireframes to material that would relate to the game in an interesting way and engage the player to learn. Our short descriptions capture topics that relate to the games in ways that we believe will push our players to explore, learn, and even see these games in a new light. We also wanted to incorporate interactive components that would enhance the gaming experience itself. In mastermind, this manifests itself as a count of how many possible codes exist with each new clue throughout the game. In minesweeper, this takes the form of an animation that shows the changing probability distribution for each square on the board. Even without curiosity to explore external resources, we feel that these features would help users become better players and thinkers in a very organic way.

Below are example wireframes that explain how we envision our product and its content. We hope that you’ll note some of the motivational and educational design decisions that we’ve incorporated to scaffold the gaming experience.

Our Mockups

These wireframes include the aspects that we think will be most significant in providing our users with the experience we are trying to deliver. Each of the wireframes includes yellow notes that highlight and describe important features. We chose to focus on developing these designs as mockups rather than using our efforts for developing working prototypes in JavaScript.

Sudoku

Our first wireframe shows the screen on which a student could play Sudoku. The main part of the window on the right side includes the Sudoku game. The player can choose their level and hit the “New Game” button to start a game. From there, they can input numbers in squares. It will appear in black if it is correct, and red to indicate that the input is incorrect.

The left sidebar includes things to enhance the game experience and engage the player. On top, under “Become a Master”, will be a link to a page that details advanced techniques for Sudoku. If a player is interested, they can explore these topics and improve their Sudoku-solving skills. We believe that players will naturally feel more inclined to learn about these techniques once they begin to work up to more difficult levels. Underneath this section will be a statistic on how many squares can be filled in with complete confidence. Then on the very bottom, we include statistics on how the player’s average time to complete their past 5 (or however many games they have played total) games. This will allow them to track how they have improved their solving time as they solve more puzzles.

Minesweeper
Next is our mockup for a Minesweeper game. This wireframe focuses on information without bombardment. The box next to the actual game field shows some variable statistics such as height, width, and number of mines. By varying these, one may vary the complexity of the game. If one were so inclined, it is actually possible to use those numbers to do probability calculations, but by offering those numbers and not forcing people to learn about it, we intend people to learn about the probability more organically.

In addition, the bottom region, labelled (5) here is meant to have some additional content about the game and the mathematics surrounding it. Minesweeper has a lot to do with probability and this section will hopefully include a click through animation with the probability showing. The probability shifts with the amount of information known similar to Bayesian Probability. An example of what this might look like is shown below. NP complete problems are a fascinating area of mathematics and it is our intention that through the guise of minesweeper we may be able to incite people to explore the problems more.

A quick example of the shifting probability is minesweeper. If we say that the

one in the figure to the left is the same as the leftmost one in the figure to the right we can see that by the addition of the new information the probability of each square having a mine shifted.

Mastermind
The final wireframe we created was the game of mastermind, a code breaking game. The game itself would have six possible colors and four color codes, with repeating colors allowed. These are considered standard rules, although many versions have variations in the number of colors or length of the code. The left sidebar would have a rotation between a few facts, including the following:

-there are 1,296 possible codes in this game of MasterMind

-There are only 360 codes where no colors repeat

-Learn more about different secret codes here https://sites.google.com/site/codesforscouts/home

Below the facts is a progress bar underneath a count of how many possible codes are left, which updates for each guess. Players could measure their progress throughout the game and see how many possibilities were eliminated with their guess. Finally, the bottom graph displayed would contain their personal stats over the last 10 games, which would hopefully show improvement. This decision was driven by our motivation research.