FinalReport-Group:Team Pint
From CS 160 Fall 2011
LINK TO TEAM PINT FINAL PRESENTATION
Contents |
Team members
Each team member’s name and role in this assignment
- Sakura Reyes: Physdom lead UI designer, final report Design Evolution section
- Markus Geyer: Write Up and Poster Pitch
- Mano Pagalavan: Write Up and Prototype Updates
- Liu Chao coder
Problem and Solution Overview
Learning physics can be a hard and arduous process. It often requires the learner to contradict his/her preconceived notions of how the world works. Not only this, but many students are faced with the boring learning process of solving one word problem after the next. These word problems often fail to stimulate the learner and tend to leave them without a proper mental model of how the laws of physics actually work.
Our solution to this problem was to create an application that would both excite users and give them a visual presentation of how physics concepts operate in the real world. Our application formulates physics problems into mini-games/puzzles that the user can solve to earn points and advance the game. Each of these games will demonstrate a certain concept of physics, either alone or in tandem with other previously acquired concepts. The visual format will allow the learner to see exactly what happens if they make a mistake while solving a problem; for example, using too much or too little force. Our application will also contain multiple tools such as calculators and tutorials that will aid our users in learning basic level physics. We believe that by drawing entry level physics learners in with games and puzzles the process of learning will become easier and more enjoyable.
Target User Group
Our application is designed primarily for High School/College students that are having difficulty in intro-level physics courses. This allows us to assume that the user has some experience with physics before our application. By making this assumption we can allow our games/puzzles to incorporate concepts such as force and acceleration without forcibly making the user go through tutorials before each level. Although our target user group consists of students that have some knowledge of physics already, our application is designed to be friendly to new learners as well. People with no previous knowledge of physics will have tools such as tutorials at their disposal to learn all the required concepts to complete each level. By extension, our application can also be used by people who have learned basic level physics earlier on in life, but need a quick reminder on the math behind certain concepts.
Tasks
Task #1: Select Settings (Easy) The settings screen is important to the game in that it allows the player to select whether they'd like to play with metric or imperial units. Though important, the task is relatively easy, as you can get to the settings screen with one touch, and make a selection with another.
Task #2: View Tutorial (Medium) Before you can play the implemented game, you may need to know more about the Physics topic at hand. For this, we have a dedicated Tutorials section for each topic, just so that the player can familiarize themselves with the topic before playing the game. In this case, we have a tutorial in place for Projectiles. We chose this to be our Medium task because it is essential to know how to go through a tutorial and learn the material before playing the game. The tutorial starts with 4 essential formulas needed in learning Projectiles. Then the tutorial continues with text and accompanying pictures, which are meant to teach the player.
Task #3: Play Projectiles, Level 1 (Hard) The Projectiles, Level 1 game consists of two sliders with corresponding text boxes, a Shoot! button, and a video box. These are the main components of this screen. Given a distance of 10m and either an angle or velocity, it is up to the user to use the formulas they know to figure out the missing variable. If the user's answer is correct, our basketball player will make the hoop in the video box. This is a hard task, simply because playing the game actually requires having gone through the tutorial page and knowing the material before being able to solve the problem.
Design Evolution
Initial Sketch Version
The initial sketch version of Physdom was very simple, and comprised a single-screen game in which one would fire a cannon at a target. The overall ‘feel’ was intended to be similar to the popular application ‘Angry Birds’, with cartoony graphics and a general aesthetic scheme that would make it appealing to high school students. Very few sketches were produced for this early version, and included nothing other than illustrations of the ‘bare bones’ functionality for an exemplary level of that genre of game.
Low-Fi Version
This was the first version of the game in which the full application interface was fleshed out. After the the game screen proper, standard title and settings screen concepts were added, as well as a section for ‘tutorials’ which would help the player to learn physics concepts before playing levels in which they were to be applied. In addition to this simple interface, this version of the app included the concept of covering various areas of physics other than projectile motion such as pulleys, springs, and friction. These categories were mentioned in the tutorials and level selection menus, although without any content generated for them.
The game screen itself was also refined slightly, with the measurements necessary to calculate the solution to the level provided in the diagram. Rather than a ‘physical’ interface like a dial or slider, a text box with an accompanying pop-up keyboard was provided for the purpose of entering solution value, under the concept that it was important for a learner of physics to think of things in clear numeric fashion rather than proceeding ‘by feel’.
This version of the interface was very rough and simple, with plain depictions of buttons, no color or aesthetic suggestion, and very little in the way of layout design. The one major UI decision was in the tutorials section, in which the screen was split into two panes: a ‘diagram’ area above and a ‘text’ area below. These two panels were intended to each contain several pages which could be independently navigated through on each pane. In this version of the application all screens were portrait-oriented except the game proper, which was in landscape mode under the assumption that this orientation would make it easier to display all the necessary information.
Notably, the low-fi version of the application expected players to use physical paper, pencil, and calculator to solve the levels, with no internal support for these functions provided. This proved to be one of the principal weaknesses of the design, and was the primary issue paving the way to the pilot test version of the design.
Pilot Test Version
This version marked the first iteration in which the UI and features of the application began to be polished, rather than simply being idea development and proofs of concept. The development of this version also encountered constraints on time and resources as a major factor, and as a result the version that was developed was markedly different from the initial designs for this prototype stage.
Because of this, this section will cover the initial design and implementation separately.
Pilot Version Design
The most notable changes from the previous version were the addition of the concept of on-board support features such as a notepad, calculator, and equation reference available from the game screen itself for use during play. The tests performed with the low-fi version brought up the lack of these features as a core complaint, with testers commenting that the necessity of using pen-and-paper made the app “unfriendly”; inconvenient at best and redundant at worst.
Testers also commented on structure of the app being confusing, with separate physics topics all being included in the same menus. This led to the concept of several ‘game modes’, one for each topic. Another option that was explored was to limit the application again to just projectile motion, with other topics being left to future apps in the same series. Ultimately this concept was abandoned in favor of having a top-level menu that served as a gateway to several topics.
UI elements being clunky was another major complaint of testers, with some of the more physics-experienced and learning-theory-experienced subjects commenting that while numeric understanding was important, working with physics also required a more visceral notion of the mapping between equations and the physical effects they model. These complaints led to the design of more fluid controls under the concept of direct-mapping.
The addition of these features required some adjustment of the UI to include room for the new controls, resulting in an update to the game screen layout.
Finally, many testers commented that the paper version of the prototype had some confusing appearances and that it was sometimes inconvenient to determine how to get from one part of the application to another. This resulted in some focus on appearances and application structure, with the major additions being the selection of a possible color palette for the game and the concept of a ‘navigation’ popup that would allow users convenient access to various parts of the application at any time by accessing the popup through a button on the header of the screen. Tutorials were also a source of confusion due to the possibility of the two separately-navigable content panes becomes out of sync if the user went several sections through one pane but did not change the diagram pane above. This led to tutorials being rethought as a series of consistently-laid-out ‘pages’ with text and matching diagrams that changed at the same time when the user moved through them with ‘previous page’ and ‘next page’ buttons.
A final thought added to the design was the concept of an avatar system, in which the player could represent themselves in-game with an appealing animated character that could be customized with items gained from progress through the game. This feature was only partially designed, and was left for later development in favor of spending more effort on core features.
File:TeamPint FinalReport PilotStateDiagram.pdf
File:TeamPint FinalReport PilotSketch1.pdf
File:TeamPint FinalReport PilotSketch2.pdf
File:TeamPint FinalReport PilotSketch3.pdf
File:TeamPint FinalReport PilotSketch4.pdf
File:TeamPint FinalReport PilotSketch5.pdf
Pilot Version Implementation
Due to constraints on the amount of time available for development, the version implemented for the pilot test was much more limited than the initial design intended. The basic application structure was supported, as were the general layouts of each screen, but almost all the functionality was left as ‘stubs’ with little actual feature support. In particular, with no time to implement an actual physics system or animated diagrams, direct-mapped controls had to be left out in favor of sliders paired with the same text-box interface as previously. Additionally, due to limited experience with the Android platform, all screens were left in portrait rather than landscape mode, leading to some cramped UI elements in the game screen proper.
Since the physics engine was unfinished, a placeholder system was implemented using videos of a man throwing a basketball at a hoop. Textboxes for initial velocity and angle were available, and entering the correct value would play a video of the man making a basket, while incorrect values would show misses either by not throwing hard enough or by overshooting. These values had to be provided to testers, since the diagram measurements for calculation were not yet included in the UI.
Various other elements were also left unimplemented for the sake of brevity, including the integrated calculator, scratchpad, and equation reference features and the avatar feature. The tutorial was left to a single screen rather than having multiple tutorials accessed through a menu, and placeholder content and diagrams were included on a single screen with no additional pages.
Finally, because there was not time to produce adequate art assets, rather than go with the ‘sporty’ color palette that had been chosen in design, a simple and neutral black, blue and gray scheme was used along with standard android interface widgets, pending the production of pictorial buttons that would communicate the controls better. This color scheme eventually led to a different impression of the app that testers suggested could be emphasized to result in a ‘classier’ application aimed at more mature users in the college age range.
Final Version
The large project size due to included videos forced us to upload our project to a file server: https://rapidshare.com/files/2225267491/project_cs160v4.zip
Due to the partial implementation of the pilot test version, many of the design issues for the final version remained the same. Subjects brought up the lack of direct-mapped controls as a major concern during pilot testing, and additionally multiple tests commented that several UI elements were clunky or difficult to operate due to size or clarity. This brought up the necessity of making elements larger and spacing them more distinctly apart, as well as the possibility of eventually replacing them with pictorial rather than text buttons. Due to the lack of a completed physics engine, it was unfortunately not possible to fully test the concept of the application, but this also had the side-effect of bringing the traits of the UI itself into sharp relief and making it the focus of the testers’ attention. The results showed considerable variance among subjects, resulting in the realization that the application could be brought in several directions. After running through the various parts of the app, one repeated comment was that between some screens being bright and having images included for appeal and others being plainer with simple lines and no-frills UI, the plain version was preferred. In particular, one of our testers was very adamant that the ‘Angry Birds’ concept was not viable, and that we would be better-served to produce a no-nonsense study aid than ‘trying to convince people that physics is all fun and games’. This was a surprise to us as a design team, and led us to the idea of pulling back from the ‘cartoony’ concept and instead pursuing a ‘clean’ and ‘classy’ feel that would be appealing and convenient for college-level users looking for a study tool. As an adjunct to this cleaning-up concept, the structure of the application’s design was simplified and extraneous features like avatars were removed. The application design was moved back to the concept of multiple smaller applications, each pertaining to a different topic of physics, perhaps with a ‘launcher’ application that would manage all of these applications and provide a place to deal with shared content like settings and social functions. Additionally, more focus was placed on tutorials and interactive diagrams rather than ‘puzzle’ levels, with the idea being to produce a kind of ‘interactive textbook’ that would explain the concepts in an understandable manner and include puzzles as a somewhat less-dry companion to the material proper. It must be noted that implementation time again came into play as a concern for this version, and as a result not all of the ideal concepts could be included in the final version. The actual implementation will be covered in the ‘Final Interface’ section of the report, while a short section that follows will describe the sketches behind an ‘ideal’ version of the application design that went further in the direction of the ‘game’ and ‘fun’ concepts.
Because this version is essentially an expansion of the pilot version, and many of the design issues are the same, there are no sketches specifically for this version. The modifications that would ideally have been made for this version are covered in the 'ideal' version sketches below.
Ideal Version Design
Our ideal version of the app as a fulfillment of the original vision, that of a fun introduction to physics for high-school through early college students who struggle with math and physics, would have been much different than the version that we eventually pursued as a result of time constraints. Rather than go for the clean and mature look that our college-senior-aged testers preferred, we would have liked to pursue the more cartoonish, bright aesthetics that some of our earlier testers supported. In addition to this, various usability changes would have been in order.
In keeping with this change in aesthetics, the application would have its screen layouts simplified such that every screen followed the same basic pattern of an appealing image in the center of the top half of the screen, with controls below and a header above that would provide access to some utility features. Color palettes would be brighter, matched to aesthetic skins varying by topic – basketball for projectiles, rock climbing for pulleys, and the like. As a rule, buttons would be larger, custom pictorial buttons rather than standard text buttons, spaced widely apart for convenience of use. However, buttons as a rule would be avoided in favor of more direct controls, and would be left mainly for app navigation controls rather than actual game play.
In terms of simple functionality, the biggest issue is clearly the graphical representation of a given level. Rather than the sliders and text boxes currently used, direct-mapped controls as illustrated would be superimposed over an animated, interactive diagram. Objects in the diagram would thus have various ‘handles’, with drag-and-drop manipulation being the primary metaphor. For precise numeric entry, selecting a precision-settings tool and dragging it onto an object would bring up an entry popup with a soft keyboard and possibly sliders for gross adjustment as currently exist. Many objects would also include tool-tips on prolonged finger-hovering, and each level would include a popup when beginning the level that would describe that level’s goal and general concept. This description could be accessed again by tapping a question mark button placed prominently near the diagram.
Although the interface layouts themselves would be greatly changed, the application structure would remain largely the same as that planned for the final implemented version of the app, but a few convenience features would be included, such as a ‘navigation’ popup available from all screens that would allow free navigation. Additionally, each subsection of the application would include an ‘About’ page that would provide a brief intro of both the physics concepts being taught in that section and the section’s aesthetic skin.
Further inquiry into the Android platform revealed a rich set of touchscreen gestured recognized by most programs, but our design team did not have time to fully explore this interface option.
Evaluation Techniques
In terms of developing the concept of the application, the technique our team found most valuable was the low-fi testing, the results of which informed our design throughout the rest of the process. User comments about clunkiness and the inconvenience of not having features like scratch-space and calculators integrated into the app itself drove much of our feature design.
On the other hand, in terms of user interface design itself, the actual Android prototype proved invaluable - through our interviews with testers we were able to much better surmise which of our interface decisions had proven clunky, eventually leading us to the conclusion that the best design was to make ample use of the touchscreen for tap-and-drag controls as close to a direct mapping as possible, rather than relying on traditional elements like sliders and textboxes which required keyboard input. The high-fi prototype also brought out some of the places where our design was not clearly defined, such as the relative sizes of UI elements and the proportions of the screen to be used, which affected our eventual UI element layouts.
Despite these insights, our application could not be fully implemented to spec due to time constraints, and it must be said that these constraints also turned out to be critical elements in our design decisions, forcing us to use simpler and easier-to-implement designs that were not ideal, but could be completed within the bounds of the course. This served as a valuable reminder that even while focusing on good design, real-world resource and time limitations continue to be an issue and that it is sometimes better to build a system that is 'satisfactory' and can built to completion rather than insisting on a more optimal design with prohibitive production costs.
Final Interface
Our new version of Physdom launches with the same image of Albert Einstein on the main screen, with "Game Mode" and "Settings" highlighted. The "Settings" button takes the player to a new screen, where they can select whether they want "Sound On/Off", and also whether they would like to use "Imperial" or "Metric" units during gameplay. After hitting back, the player returns to the home screen, and touching "Game Mode" takes the player to a page with a list of topics: Projectiles, Springs, Pulleys. At this time, "Projectiles" appears as touchable, with the other two options greyed out due to lack of functionality. At the "Projectiles" menu, the user can "Choose Level" or go through a "Tutorial". Touching "Tutorial" takes the player to a tutorial on projectile motion. First, we present the user with 4 relevant formulas when talking about projectile motion. Then there are a few paragraphs of information with graphics further exploring and explaining the topic of projectile motion that the user can scroll through. Our goal with this section of our application, the tutorial section, is to provide the user with enough information for them to track back in the game menu and play a projectiles level successfully. Leaving the tutorial and selecting "Choose Level" brings the user to select "Level 1" of 3 levels (levels 2 & 3 not implemented yet). Touching "Level 1" finally brings the user to the main gameplay aspect of our application.
The previous version of our Physdom tablet game for Physics beginners and learners had a somewhat incomplete game implementation. The previous version's gaming aspect consisted of two slide bars, one for angle and the other for velocity. The user's game play would simply consist of changing the sliders until two values worked with each other, making the video of the basketball player making a hoop play. This gameplay does not necessarily encourage studying physics, as there are virtually no physics equations or formulas needed to play. As the creators of the game, we had in mind a version of the game which was not implementable at the time of the last project submission. With this iteration, we bring features which focus on improving gameplay, specifically with the inclusion of at least a few physics principles. First, we have displayed a distance on the game page of 10m, which is the distance between the basketball player and the hoop. Then, instead of leaving the rest of the game open-ended as before by displaying two sliders with empty corresponding text boxes, we have now designed the game so that either an angle or a velocity is given, and the user's task is to calculate and slide the slider for the other variable, given the distance between the shooter and the hoop as 10 m. Though the player can still guess answers, the fact that we have implemented a thin underlying physics system means that the answers are to be more precise. A problem that we encountered with answer precision is that the slider only gives values as integers, while answers can be doubles. Thus, the solution was to do some error checking to make sure that the player is able to round up or round down and still get the correct answer, given that they have done the correct required calculations. Another added aspect of the game is a "Shots Left" counter, which starts at 3 and decreases as the player submits wrong answers. Once the player reaches "Shots Left: 0", they cannot shoot anymore, and must restart the game to play again.
Another feature which we worked hard to implement with little success were popup windows, which would appear when "Calculator", "Reference" or "Scratchpad" at the bottom of the gameplay screen are touched. Android has a Popup Window class with APIs, but most examples we found online were poorly written, or understandable. A solution to this problem we found was to use "Alert Dialogs" which are basically popup windows, with the additional capability of having up to three buttons. This was a neat feature, since our idea was to allow the user to tap "Calculator", "Reference", and "Scratchpad", which would launch a little popup window, to display either a calculator, a reference sheet, or scratchpad. After finally implementing an Alert Dialog to support these functionalities, we faced toubles when trying to close the alert dialog window in order to return to our game. Though the dialog closes when touching the "close" button, most of the game features, including button implementations, do not work. In order to play again, we had to force shut and restart the whole game. After hours of these troubles, we finally opted to leave the "Calculator", "Reference", and "Scratchpad" functions out of our game.
Another feature that we would have liked to have was to have interactive physics features and graphics, such as the user able to drag an arrow in a direction to shoot. But in the interest of time, we still have videos playing to correspond to the entered angle and velocity values. This wizard of oz feature is required in our game as of now, in place of an actual physics engine capable of handling elements such as a basketball with an accurate representation of the physics it requires, given an angle and velocity.
This is the main menu screen for Physdom!. It features "Game Mode" and "Settings" buttons, with an unimplemented "Avatars" button. Selecting "Game Mode" takes you to a topic selection screen, and selecting "Projectiles" lets you either play a level, or go through a tutorial. If you choose to view the projectile tutorial, this page shows:
This tutorial page features 4 important formulas at the top, with a continued tutorial for learning projectiles, with text and images. After the tutorial, you can touch "Back" at the bottom, which takes you back to the "Projectiles" page. From here, touching "Choose Level" will allow the user to select which level they want to play. Selecting "Level 1" brings the user to this screen:
This is the main gameplay window. Here, you will be given either an angle or velocity, and will be required to find the value of the variable not given, using the distance of 10m between the ball shooter and the hoop.
