Group 20 — Name Redacted

Brian, Ed, Matt, and Josh

Sum­mary: Our group is cre­at­ing an inter­ac­tive and fun way for mid­dle school stu­dents to learn the fun­da­men­tals of com­puter sci­ence with­out the need for expen­sive soft­ware and/or hardware.

Introduction: The purpose of our system is to introduce students to the basic concepts and principles of computer science and to teach them in a fun, intuitive, and interactive way. The purpose of this experiment is to gauge various aspects of our system such as intuitiveness, ease of use, and difficulty, and to ascertain any changes we could make that would improve the user’s overall experience.  In particular, we want to see how easy or hard each of the three tasks are and whether or not the tasks were intuitive.  Our bigger concern is that the tasks are not intuitive.  Every student of computer science will think that different topics are of varying difficulties, but if our system is not intuitive, no study will be able to learn from it.

Implementation and Improvements:

• Since P5, we created a better debugging mechanism and initialization feature, which we have now made into our easy task.

• There are no wizard-of-oz techniques in P6 whereas there were those techniques in P5.

• The TOY Program has a compilation phase and a running phase to allow jumps to future labels.  The user does not notice the difference between the two phases to provide a better level of abstraction.

• The TOY Program goes line by line waiting 1.5 seconds during execution so the users can see how the registers, etc. change.

• The TOY Program has error messages where there is either a runtime or compile time error.

http://blogs.princeton.edu/humancomputerinterface/2013/04/22/p5-name-redacted/

Method:

Participants: Our participants were all Princeton University students with varying degrees of computer science backgrounds, ranging from no background to only two introductory courses.  We chose these participants because they did not have a lot of computer science background, and our target audience are people who are trying to learn computer science but do not have much formal training.  The participants ages ranged from 19 to 22.  One came with an engineering background, one with a social science, and one with an anthropology background.  All three participants were male and each had some prior level of teaching experience.  When choosing participants, we wanted students who also had taught, so that we could simultaneously test both groups in our market.  With only three participants, we really did not have a lot of opportunity to create a diverse group of participants.

Apparatus: Our project uses paper tags with the corresponding text labels, a projector, a webcam and a laptop.  In a school, the projector will already be connected and set up to a laptop, so we set that up for the testers.  We asked the users to connect the webcam and then follow the initialization instructions so that the program can map the webcam coordinates to the projector coordinates.  The paper tags already had tape on the back of them so that the users could easily put the tags onto the wall.  We conducted the test in an eating club since there was a space about as large as a classroom that allowed us to project on a large open wall.

Tasks:

Program Initialization (EASY):  This task is the initialization of the program that requires the users to initialize the webcam and projector space.  This task also includes key commands that allow the users to debug their own code, by showing them which lines are grouped together as rows.  Part of the idea from the task came from an expansion of the Tutorial feedback, since the tutorial should really begin when the program is first loaded on the teachers laptop and be geared towards helping users debug their programs.

Numbers (MEDIUM): In this task, users will be introduced to number systems and learn how to convert between them. Users will be able to make numbers in binary, hexadecimal, octal, or decimal and see the number converted in real time into the other number systems.

TOY Program (HARD): In the TOY programming environment, users (primarily students) will be free to make and experiment with their own programs. Users create programs by placing instruction tags in the correct position and sequence on the whiteboard. The program can then be run, executing instructions in sequence and providing visual feedback to users to help them understand exactly what each instruction does.

Task Selection: We chose the “Program Initialization” task because it is the first step in using our system and every user would have to complete this task. Once this step is completed, it makes sense to have the user try out each of the applications we developed for the platform.

Procedure: We made sure each participant consented to the study with knowledge that their image and or video with them may be published on a blog post on the publicly searchable web.  With each participant we introduced them to the goals of the project as stated in a previous section of this write up.  We then gave the participants a high level introduction into the system, explaining how the tags are used as well as what the tasks entail.  We introduced the participant into each task and asked them to perform the task.  We offered the participants a post-survey questionnaire which is in the Appendices section  of this write up.

Test Measures: We asked the participants to fill out a questionnaire that asked them to rate our program on a scale from 1 to 5 on several different aspects.  These aspects were Overall Ease of Use, Overall Intuitiveness, Initialization: Difficulty of Task, Assembly: Difficulty of Task, and Numbers: Difficulty of Task.  We also analyzed how users interacted with the program by taking less quantitative measurements about how much it seemed that they struggled with a given task, or how easy a task was, etc.

Documentation:

Each tag has a unique visual marker.

Participant 1 Using “Numbers” Program

Participant 2 Performing the Initialization Task

TOY Program

Results and Discussion:

Overall we felt that the tests were rather successful in not only reinforcing the feedback that we had received in previous iterations of the prototype but also in showing us how to further improve our system.  To start, the feedback was extremely positive.  We received an overall average “Ease of Use” rating on our anonymous survey of a 4.66 out of 5.  On the “Intuitiveness” of our system, we received an overall average rating of 4.33 out of 5.  Both of these numbers were high both for users of moderate and limited CS background.  This tells us that we were able to provide users with an interesting an intuitive educational experience despite the fact that they had very limited training and knowledge of CS concepts.  Users had very positive verbal feedback.  One of the users who had no computer science background even remarked upon the “theme of rows” that seemed to be going across our different applications. This was really interesting because horizontal tag rows is a fundamental metaphor built into the system and it is something that someone could pick up without seeing a line of code.  Of the three tasks, it was clear both from their self reported values and from observing the users that the “Numbers” task was clearly the most confusing. They primarily seemed to take issue with the location of where numbers were displayed in relation to the ID tags placed on the board. We will focus more energy on cleaning up that task and making it more visually intuitive and appealing.

Going forward from the positive information given, much of the constructive criticism that we received centered around the depth of the product.  Our users seemed to grasp the fundamentals of putting tags on the wall.  Our users even started to develop different user patterns.  One user, for example, would constantly “compile” his assembly code to check for errors while most just wrote the program and compiled once at the end.  The place where they struggled was with the tasks being too “abstract.”  This idea of abstractness has been on our minds since our first contextual inquiry when it was suggested to us.  Users wanted to know “how the initialization step worked.”  They wanted more information about the conversion process from binary to hex.

Jumping off from comments like these, we have ideas of specific changes we want to make to the system to help increase its connection with the users.  We are going to change the number system a little so that we display exactly how the numbers are generated (2^0 + 2^1 + 2^3 = 11).  We are going to include more documentation for each of the three tasks.  It was a little confusing where to put the base tags for the numbers method.  We may create rows for the number method so that the user knows where to put the hexadecimal, decimal, and binary tags.  It was also unclear that the base numbers had to be to the far left of each row, so that would be included in the documentation.  Similarly, the testers asked what the arguments for various commands were and this needs to be cleared up in the documentation about the program.  All of these specifics boil down to two main themes.  We need to cater the UI to make visual suggestions to the user as to what they should do next (i.e. how many arguments does print take with visual boxes).  We, also need to increase the visual documentation so that the user can ask the questions about what’s going on “behind the curtain.”

We are also working on tag persistence.  Users don’t understand that if they walk in front of the camera, they block it’s field of view so we want to make the camera less vulnerable to view blocking but having it remember tags for a few seconds.  We also learned a few things about the space that our project needs to be in to work.  The sunlight was causing problems for the camera since the black and white tags were not being picked up by the software.  We needed to move the projector closer to the wall, which created a smaller output image.  The code section for the TOY Program was a little small for fitting three tags on one row

Appendices:

Consent form – Updated from P4:

https://docs.google.com/document/d/17J1J9EMwjDzunhS-5s4-L517EtXTwkqsPd7rr3VfHc

Interface Feedback and Demographic form –

https://docs.google.com/forms/d/1xOa9_gey2mPCII_JeCPdjFmfMKsI_x2r1eScCl1P2Es/viewform

https://docs.google.com/a/princeton.edu/forms/d/1xOa9_gey2mPCII_JeCPdjFmfMKsI_x2r1eScCl1P2Es/edit

The demographics are on the second page of the form.

Group 20 – Name Redacted

Brian, Ed, Matt, and Josh

Summary: Our group is creating an interactive and fun way for middle school students to learn the fundamentals of computer science without the need for expensive software and/or hardware.

Description of the tasks:

Binary: In this task, users will be introduced to number systems and learn how to convert between them. Users will be able to make numbers in binary, hexadecimal, octal, or decimal and see the number converted in real time into the other number systems.  The program will shows the users how the octal, hexadecimal, and binary numbers are created (i.e. 2^0 * 1 + 2^1 * 1 = 3).

Tutorial: In order to introduce teacher to the basic of the TOY programming interface, they will be guided through a basic tutorial teaching them how to use the features of the system while making a simple program. Users will be guided through the process via on screen text, drawings, and animations that will explain what the onscreen information means, what to do next, and how to interact with the system.

TOY Program: In the TOY programming environment, users (primarily students) will be free to make and experiment with their own programs. Users create programs by placing instruction tags in the correct position and sequence on the whiteboard. The program can then be run, executing instructions in sequence and providing visual feedback to users to help them understand exactly what each instruction does.

Program Initialization: There is also a fourth task that we have created while developing our working prototype.  This task is the initialization of the program that requires the users to initialize the webcam and projector space.  This task also includes key commands that allow the users to debug their own code, by showing them which lines are grouped together as rows.  Part of the idea from the task came from an expansion of the Tutorial feedback, since the tutorial should really begin when the program is first loaded on the teachers laptop.

Choice of the tasks:

We decided not to change our tasks significantly from P4 to P5.  Starting with P2, we received feedback from students and an instructor suggesting that binary and visualizing memory were the two hard (and very important) concepts when first learning computer science.  There was a general consensus that binary was easier than visualizing memory and coding in TOY.  Thus, we really want our tasks to include these two concepts from computer science.  Our third task is focused on the teachers who will use our project.  This is a logical last task since our user group is both students and teachers.  Teachers will need to learn TOY before teaching their students, and thus we need to provide a simple interface to teach them the main concepts in the TOY language.  We also cannot assume that every teacher will have an advanced computer science background, so the tutorial has to be simple enough and yet still explain the details of TOY.  However, we created a fourth task given the feedback from P4 and the information gained while building the prototype.  We are going to provide a simple interface for teachers to learn how to initialize our system.  This is very simple, and just requires the teacher to push “i” to map the webcam space to the projector space, but is still very important nonetheless.  It will also require telling the teacher how to put tags on the board to switch between TOY Programming, the tutorial, and binary.

Revised Interface Design:

The big push of our work this week was to try and fit the design aspiration of the projects to the realities of the technologies.  At the core of our project is a fundamental platform we created that allows developers to write applications on top of it.  Before talking about the specific applications that we implemented, I want to touch on the design choices that we had to make for the platform itself.  These are design choices that we couldn’t have conceived of while doing the paper prototype because the reality of the technology did not exist.  Our fundamental platform interface is this: Users boot the program on a computer attached to a monitor.  Two visualizations are rendered on the screen.  The first is the projector space.  This is where applications can write.  The second is the monitor space.  This is where the camera image is displayed.  The camera is then pointed at the projector and the “i” key is pressed.  This starts our “initialization mode,” where we align the projector coordinates with the camera coordinates and calculate the appropriate translation.  After the system has been initialized, you can then press the “u” key to display debug information on the projector.  When tags are placed on the screen, their corners are highlighted by the projector showing that it is properly aligned.  Also, when tags are organized into rows, those rows are highlighted to show that they tags are semantically connected.  The debugging information is a UI that we expose to Applications developers so they can see visually, how the framework is interpreting the images on the screen.

Moving on to some of our applications, the first application that we implemented is assembly.  We stuck with the same general layout as our paper prototype.  We had iterated through where we were going to place the “code,” “output,” and “registers” sections previous to the final paper prototype.  Given the feedback that we received during prototype testing, we felt that this final layout (code on the left, registers and output on the right) was the most effective.  We did play around with various output types.  This is again something that didn’t come up as much during the paper prototyping phase.  Now output needs to scroll.  We also dealt with the clearing of the output field when programs were re-launched because that was something that our testers had found confusing.

Our second application that we implemented with our number base conversion application (We call it “Binary”).  This is where the user can see how different number representations might display the same numerical value.  Our paper prototype was very free-form and allowed for users to place the tags anywhere on the board.  This lead to confusion, where users would either place too many tags on the board or place tags in the same row when they did not mean to.  We therefore altered our design so it was more constructive.  We created a grid that the users could populate with values.  This suggests to them that they need to separate the rows spatially and also helps them to understand that they should only fill in a single field at a time.

Moving forward, we have a couple of interesting features we have yet to implement.  I think the biggest place where UI design will have to play a role is error messaging.  With the complexity of our Assembly application, we saw that users are already prone to creating erroneous and nonsensical programs.  This is not a problem with our application.  Some of the greatest “teachable moments” in computer science come not out of writing correct programs but realizing why a given program is incorrect.  We therefore want to make sure that the user gets the most informative UI possible when an error is received.  This will include syntax highlighting and visual feedback.  We have created a few sketches of possible designs in the slideshow below.

This slideshow requires JavaScript.

Overview and Discussion of Prototype:

i) Implemented Functionality

Our  project can read in the AR Tags with a webcam, and apply the correct homography translations to map the webcam space to the projector space.  This allows us to circle tags with the projector that are on the wall.  We used this functionality to create our debugging API which allowed us to get the extensive backend code fully operating.  Our debugging API also gave us greater insight into the limitations of AR Tags.  Namely, AR Tags on a screen must be unique.  There are 1024 different possible AR Tag combinations, and so we are in the process of creating multiple tags for register names, TOY labels, and integer literals.  We also have a TOY to Java compiler and interpreter that allows any sequence of the commands to be read and executed.  The debugging API that we have been using for development will evolve into a debugging API for the students using the program, where incorrect syntax will be highlighted and errors shown on the output side.  The big hurdles when creating the backend and preliminary front end interfaces were getting familiar with Processing, determining the limitations of Processing and AR Tags, and creating a suitable abstraction that will allow for easy proliferation of tasks.  We have created a very simple abstraction that would allow programmers to easily create new applications, as well as allow us to create new applications.  No matter what the frontend application, we have created an interface that the backend can interact with, so that a new application would require no new backend programming.  Overall, both the frontend and backend code together are more than 1300 lines of code, almost all of which we wrote (tutorials borrowed from listed below).  We wanted to talk extensively about the backend functionality because it required a lot of work and hours, but it enabled us to create an interface that will make finishing the project much simpler.  Although the frontend programming is not completely done (and most of the “wow” factor comes from the frontend features), the backend is certainly the hardest part of the assignment and it is nearly complete for the project.  The TOY Program is also nearly complete, and the binary program should not take much more time given the interfaces and abstractions that we created.  The Tutorial is just an extension of the TOY Program.

ii) Left Out Functionality

We decided to leave out the error messages that the TOY Program generates for a few reasons.  Firstly, all of the code is there to implement the feature, but we are currently focusing on our debugging and thus we have made the output images projected help us rather than a potential future user.  However, the red boxes seen in the images in the next section are essentially the same as the error messages that users will see in the final product, but for now we were more concerned with debugging the back end and extensive tag libraries that we had to write.  In a similar fashion, we left out some of the messages that will appear during the tutorial, but the messages will appear in the output section of the TOY Program, which is already set up to print the desired tutorial messages.  In the meantime, however, we wanted to use this section for our own debugging purposes.  Now that we have basically finished the backend, we can start specializing these parts of the code to focus on the user.  The functionality that we decided to leave out is very easy to add, but for the time it is more important to create a debugging framework.

iii) Wizard-of-Oz Techniques

There are no wizard-of-oz techniques for the TOY Program.  However, the output for the binary program is hard coded in for now, while we further develop that individual program.  We are also going to accept the advice of our paper prototype testers and put more information about how we calculate the binary output.  Also, at the time we only have one tag corresponding to each command and number.  By the final prototype we are going to have multiple tags for each command and number so that the programs can be more complete.  We only have one tag corresponding to each number since it took so much coding on the backend and the debugging API to be completed before realizing that limitation of the AR Tag library.  We decided to have the output for binary hard coded in for now since we wanted to really finalize the backend of the application with a layer of abstraction that would make coding the rest of the binary program very easy.  Thus, we decided to focus much more on getting the backend complete than on the frontend applications.  This makes sense, since the frontend could not run without the backend basically completed.

v) Documented Code

For the AR tag detection, we are using the NyARToolkit, a Java implementation of the ARTooKit Library, available at http://nyatla.jp/nyartoolkit/wp/. For calculating homography, we are using the homography library created by Anis Zaman Keith O’Hara, available at https://code.google.com/p/the-imp/source/browse/src/PCLT/src/edu/bard/drab/PCLT/Homography.java?r=7a9657a65e976ac38b748b35fa7b36806326011d. We used a Processing and ARToolKit tutorial to get started, but only small elements of this tutorial remain in our current code. This tutorial is available at http://www.magicandlove.com/blog/research/simple-artoolkit-library-for-processing/.

Documentation

Testing setup.

Toy Program. The red boxes are for debugging, showing that the homography is working and the tags are correctly identified. The output correctly shows the results of the program (which has been run multiple times).

Monitor display. Shows tag debugging information and camera view.

Testing system on a projector screen.

Example of the Binary program. Currently hard-coded values used. However, building the application in our framework will be a relatively simple task.

Group 20 – Name Redacted

Brian, Matt, Ed, and Josh

Project Summary: Our goal is to teach students the fundamentals of computer science without the need for expensive and elaborate hardware or software.

Description of the Test Method:

Consent Form:

To obtain consent, we explained the three tasks to the participants.  We made sure that they understood that their participation was completely voluntary and that at any moment they could stop participating.  We asked the participants to sign a simple consent form that can be found here.

Participant Selection:

Since the user group of our project are students with limited computer science background, we got three participants who had only take introductory computer science courses.  One of our participants had taken COS 109, and the two other participants have taken COS 126 only, and are in non technical majors.  We wanted our participants to have some experience with computer science so that we would not need to teach TOY in a thirty minute block, but also not enough experience to have learned assembly language.

Testing Environment:

We tested our project in a classroom setting.  All four group members helped go through our written scripts and watched as the user interacted with our system.  We  only have one participant at a time to make the participants feel more comfortable.  We attached pieces of tape to the AR Tags so that the participants could tape the tags onto the board.  We used a blackboard to emulate a projector and we drew the output.

Testing Roles:

Matt led the discussion and task on binary, Ed led the discussion and task on the TOY Program, and Brian led the discussion and task for the tutorial.  Leading the task included saying our scripts as well as “being” the projector and drawing the appropriate output on the board.  Josh said the demo script and obtained consent from each of the participants.  He also recorded notes during the testing phase.  We all helped with the write up and discussion after the testing.  Here is a link to our demo and task scripts.

Summary  of Results:

We ran our demos with three separate users who each had little experience with computer science. Overall the demos went very smoothly, and after our introductory explanation of each task, users had little trouble interacting with our system. We also were able to get good feedback from our users on things that work well in addition to things that could be improved.

In general, users thought the interface was simple and intuitive, and they were easily able to use it after being given a brief block of instruction. In both the binary and toy program demos, users said that they would like to see feedback as to what is actually going on when the program is running or how the numbers are being converted. Some users were also confused about where exactly they were supposed to place the data cards in relation to each other. In the toy program, some users were unsure if the results of the instructions were supposed to be displayed immediately or after the run data card was put up.

Discussion of Results:

We gained some very valuable insights from testing our tasks with three different users.  Firstly, all three of the users would like a more in depth number base lesson.  All three suggested outputting how to get from binary from a decimal number (i.e. 1 + 2 + 8 = 11 for 1011).  Before these testers, we did not really consider changing the binary lesson, and we think that we can make some great improvements in the future with our binary lesson.  Looking back on our introductory CS days, these testers are absolutely correct in terms of how to think about changing numbers between different bases.  For our tutorial task, none of our testers could really provide too much insight in terms of learning how to teach students but they did like the level of detail that we provided the teacher in terms of learning about TOY.  In fact, one of the testers suggested that a similar level of detail be output when the students are coding.

Going along with this, there was some confusion about what the arguments should be for each command.  It is also a pain to write out the code for a program and then find out that the commands are all wrong.  We might be able to add a component to our program that outputs the various arguments for the six commands.  One of our testers asked if it is “mov src dest” or “mov dest src” which is not at all obvious even for computer science majors (since there are different standards).  Since we are accustomed to the intel format, we just assumed that everyone would see the command as “mov src dest”, but that is not a good assumption.

Future Test Plan:

It is time to start building the higher-fidelity prototype.  Our idea requires a significant amount of coding, computer vision, and design decisions for the output of the projector.  It is thus very important that we start creating our actual prototype if we hope to finish before Dean’s Date.  Some of the difficult design decisions will come from the coloring scheme that we use and our display of error messages.  In the future, we will test our prototype with an actual projector  and then we can get valuable feedback about how we display information.  Also, since we want our product to appeal to middle school students, it is important that our project looks nice, and we cannot provide a good visual reference for testers if we are just drawing on a whiteboard.

We have already made significant progress on reading the tags from a webcam and projecting an image.  In the next couple weeks we will show the projected images to other students to receive aesthetic feedback as well as feedback on the overall design decisions.  We will be a good place then to make these changes to the projected output.

Group 20 – Name Redacted

Brian worked on the project summary and the discussion of the three prototypes.

Ed worked on the prototype that modeled the TOY programming machine.

Matt worked on the prototype corresponding to the binary lesson.

Josh worked on the prototype for the tutorial to teach instructors how to use this system.

We all worked on the mission statement.

Rational for the Assignment: Most school districts do not teach computer science and are constrained by technological costs and teacher training.  Our project hopes to rectify these two problems by creating an easy to use, fun, and interactive computer program that allows students to learn the fundamentals of computer science without the need for expensive hardware and software.  Our end goal is to create a project that allows users to “code” without typing on a computer.  Thus, this prototype gives us a great opportunity to test the feasibility of this design.  From a user perspective there is very little difference between taping paper to a whiteboard and having us draw in the output from putting magnets on the whiteboard and have a projector show the output generated by the computer.  Thus, we hope that the low-fidelity prototype can give us not only an accurate depiction of how the user will interact with the final system but also provide valuable insight into how to improve the overall user experience (especially since the goal is to create fun and interactive experience for middle school students).

Mission Statement:  Our group strives to provide every student with a method to learn the fundamentals of computer science in a tangible, fun, and interactive way.  Most schools in the country do not teach computer science because of resource and financial limitations.  However, computer science is one of the fastest growing industries, creating a wide gap between the supply and demand of computer programmers.  By creating a cheap and effective way to teach  the fundamentals of computer science, we hope to give students from all socioeconomic backgrounds the ability to become computer programmers.

Updated Task: We switched our difficult task from the Simplified Turtle Graphics to the teaching of the TOY Lesson to instructors.  Since interviewing an instructor in P2, we realized that a large part of the success of our project relies on teaching instructors how to use the system.  Thus, since our user group expanded from only students to students and teachers, it made sense to focus one task on how instructors would use our interface.

Description of Our Prototype: Our prototype uses paper cards with “fake” AR Tags and labels that look similar to those in a real system.  We used tape on the back of the cards to mimic how users will put magnetic or otherwise adhesive cards onto a whiteboard.  Our prototype obviously does not rely on a projector or web camera, and so we used whiteboard markers to emulate the information that the program would project onto the whiteboard.  For the tutorial we drew what the whiteboard would look like as the user stepped through the program.  We have 16 number cards (for 0 to f) and labels for binary, octal, hexadecimal, decimal, LABEL, MOV, PRINT, ADD, SUB, JNZ

Completed program

This is where the program outputs.

This is where the memory is displayed. Our interviewed potential users said that understanding memory was a very difficult concept to grasp.

Completion of program with output.

This is where the code goes (the students places the magnetic blocks here).

Task 1 – Teaching Binary:

The objective of this task is to provide a simple, clean, and interactive teaching environment for students to learn the difference between different number bases (specifically binary, octal, hex, and decimal).  For user testing, we would approach this from two angles.  First, we will test what it is like to teach with this tool.  For that, we would have the tester imagine they are teaching to a classroom of students and using this as an aid in the lesson.  Second, we can see the test through the eyes of the students.  Our tool is meant to be interactive, so after a quick lesson on what the tool is and how it works, we might ask students to complete quick challenges like trying to write 10 in binary.  The point of this system in both cases it to try and simplify the teaching process and increase engagement through interactivity.

Imagine you are teaching a lesson.  The basic idea of our UI is that there are 4 numerical base cards:

And 16 number cards:

They have adhesive on the back and they stick to the white board.  Users then place these cards on the board.  In our real system, we would project output on top of the board and cards, but for this lo-fi prototype, we will use marker, written by the tester, instead.

The first way that you could use the system is to put one numerical base card down and place a string of numbers after it.  The system will interpret that string of numbers in the base and provide a representation of that quantity.  In the below example, it displays balls.

Another way using the system would be to put down more than one numerical base cards and then place a string of numbers following just one of those card.  The system would then populate strings of numbers following the other bases so that they are all equivalent.

If the user places down something that is not valid (such as a value beyond the base), we would use highlighting from the projector to let them know their error.

Task 2 – TOY Programming:

This lesson is used to teach the fundamentals of how all computers work. We provide users cards with a simplified version of assembly language and visual tags printed on them. The teacher or student will use this system to learn about computation and simple logic in a classroom setting. As the user places cards on the board, the projector will overlay syntax highlighting and other visual cues so the user gets feedback as he or she is writing the program. Then, when the user is done writing the program, they place the RUN card on the board. The system first checks if the program is syntactically correct and, if not, displays helpful messages on the board. Then, the system walks through the code step by step, showing the contents of memory and output of the program. As the commands are all very simple and straightforward, there is no confusing “magic” happening behind the scenes and it will be very easy for students to understand the core concepts of computation. However, the language is complete enough to make very complex programs. Our paper prototype very closely resembles the form of our final project. We created the visual tags out of paper and stuck them on a whiteboard using tape. We mimicked the actions of the projector by drawing on the board with markers.

This slideshow requires JavaScript.

Task 3 – Teaching Tutorial:

The purpose of the tutorial would be to familiarize users – the teacher in particular – with the main display interface and teach them how to properly use the instruction cards. Prior to starting the tutorial, the user will need to be given basic instructions on what the system is, why it is useful, and how to setup the system and run the program. Once started, the user should not need any additional help. Text and prompts will be projected on the screen to guide the user through the tutorial, teaching him what the different parts of the display represent and how to properly use each instruction card. The tutorial will advance to the next step when after a certain period of time has elapsed, the user has completed a designated task, or the user presses a continue key such as the space bar the the computer. Mistakes can be recognized and corrected by the system itself if the user does something wrong.

This slideshow requires JavaScript.

Discussion of Prototype:

We made our prototype by first creating blocks that were similar to how they would appear on the magnets that the users will use.  The blocks have AR Tags (which for now we made up), and a label.  There are blocks for all of the numbers from 0 to f,  and blocks with keywords that are supported in the “computer language” we are developing. Another part of our prototype was drawing on the whiteboard how the whiteboard will look during a lesson. This meant creating the three sections that will be projected – code, memory, and output. We wanted to draw these sections on the whiteboard for our prototype since they change real time for our project and thus we could emulate with markers what the user will see when they use our program. By using the whiteboard, we used a new prototyping technique. We believed that it was more suitable than paper because of the increased flexibility it gives us over paper. When we test our prototype with real users, we want the freedom to display the correct output, memory and error messages. This would have required too much paper since we have many different possible values in each of the four registers at any given moment, among other things. Also, since our system will rely on the whiteboard, it made sense to have the users interact with a whiteboard when testing our prototype.

One of the challenges that we had to confront arises from the primary user group being younger students.  Thus, we had to keep the tags simple and few enough that students could reasonably understand what they did yet we still wanted a reasonable amount of functionality.  It was difficult to come up with a good whiteboard interface for the users.  We wanted something simple that still conveyed all of the useful information.  One idea that we considered was an input tag that would allow the user to input data to the TOY program.  We decided however that this made the programming unnecessarily complex while not adding that much benefit.  Most of the difficulty in creating the prototype was similar, and the issue came from deciding what functionality to include that would offer a complete introduction to the material without overly complicating the learning process.  Even though using the whiteboard rather than paper presented some difficulties, I think it works very well in terms of simulating the program.  It was also important that our prototype not lay flat on a surface, since the final project will use a projector image on a whiteboard.  I think our prototype very closely resembles how we currently think the end product will look.

Group Number: 20

Members:

Brian conducted one interview on his own and partnered for another interview and helped write the paragraphs on the interviews.

Matt conducted one interview on his own and partnered for another interview and helped write the paragraphs on the interviews.

Josh answered the 11 task analysis questions and helped Ed write the three storyboards and answer the interface design questions.

Ed helped Josh answer the 11 task analysis questions and wrote the three storyboards and answered the interface design questions.

Problem and Solution Overview
Currently, there is very little teaching of computer science fundamentals taught in middle school and high schools. Often, schools are prevented from teaching CS because they have insufficient computer resources to provide each student with a computing environment. Even in college, some students have difficulty learning the basic concepts such as binary number representation, memory, and recursion. The barrier of entry to learning CS is just too high. We are hoping to create an interactive method for teaching the fundamentals of computer science that does not rely on coding software on a computer. We wish to extend the idea of whiteboard programming. Using computer vision and a projector, we want to let users place “blocks” of code on the board and our tool will return visual feedback. Our solution could provide a low cost and interactive interface that could revolution technology teaching to the masses.

Description of Users Observed
Our target user group is divided into two main groups: teachers using our tool for pedagogy and students learning from our tool. We decided to select three users across both of these groups to get the most balanced perspective.

• The first user that we observed created and teaches an introductory CS course targeted at students with almost no technical background (often students from humanities departments). We think that he was a good choice for a user group not only because he has had years of teaching experience, but also because he is often recognized by his students as being an extremely effective and engaging educator. He is extremely interested in CS education although his background and interest tend to be focused on a slightly older age group than we are targeting.
• The second user that we interviewed was a student who took the above course. He had no technical background for the course and had a heavily humanities background. We thought he was a good user to interview because we were able to talk to him about the frustrations and confusions of learning the most simple CS. Also, we were able to compare his interview with the above interview readily.
• Our final interviewee was a member of the school board of a large suburban district near Los Angeles. He is been extremely interested and involved in education reform. We thought he would provide an interesting insight into the backend of education. He helped us to understand how teachers might adopt and use this technology from an institutional standpoint.

CI Interview Description
Our first interview was conducted in the office of the user. We started out by explaining a little about who we were and what the goals of our project was. We then asked him to walk us through a couple of his extremely early lessons to help us get a picture of what current teaching practices are. Our second interview was conducted in a classroom with a student who had taken the aforementioned introductory computer science course. The student is concentrating in a nontechnical field but took the computer science course to fill in a distribution requirement and learn some fundamental computer concepts. We asked the student to walk through some of his previous code in the course, explaining what he did in the assignment. Our final interview took place in a common space. This interview was tricky to take the perspective of contextual interview. As we will discuss later, professional development for teachers is extremely individual and therefore hard to observe. We therefore made sure to talk about specifics from a more distant perspective.

Our first user, the professor, provided us with an outline of the first few weeks of lectures, and discussed how he explains various concepts ranging from binary to memory to logical loops. Our second user, the student, talked briefly about what he liked and disliked about the introductory computer science class he took. In particular, he liked learning about internet security issues as well as computer coding. However, the coding portion of the class was the most difficult for this student to learn. As part of the interview, I asked the student to go through some of his code from the computer science class that he took. When going through the HTML code that he written, he noted in many places where he had to fix syntactical errors. Most of his errors in this particular program came from omitting the ‘/’ character from the end tags. Similarly, his JavaScript errors were almost entirely syntactical, usual because of a missing or extra ‘}’ character. Both the professor and the student agreed that binary was a very hard concept to teach/learn. In particular, the student suggested that most students struggle with the concept of how many decimal numbers can be represented by n bits. Both also agreed that a very difficult concept in computer science is how all computers are actually equivalent, and how languages can all do the same computation. The professor also mentioned that most students have an incredibly difficult time understanding the abstractions of the computer process. In particular, the student had trouble understanding compiling, assembling, and linking because the concepts were too abstract. However, the professor and student disagreed on some issues. Firstly, the professor believed that students struggled most on the idea of memory and more specifically the actual holding of memory. While the student admitted that memory was difficult, he believed that more students had trouble with binary representations of numbers. The student also emphasized that he was most frustrated by the syntax problems that he encountered while coding.

After having looked into a teaching lesson itself, we wanted to take a step back and gain more perspective on what it’s like to be a teacher. This is where we turn to our last interview. Our final interviewee, as a member of a school board, has a big picture knowledge of what fundamentally it is like to learn how to teach. The main takeaway we got from the interview is that current pedagogical education is extremely individual. He walked us through all of the professional development activities that a teacher does in a given year (including professional development conferences and school events). They were very few of them (~5 days per year) and individually focused. Teachers make their own lesson plans and learn new technological tools on their own. He talked us through the process of integrating iPads into his district and how poorly they are used by many teachers. This individuality contradicts our first interview slightly. Our first user actually published the notes of his class in a book so other teachers could use them to shape their lessons. I would explain that difference as being the difference between K-12 and college education. Ultimately, I think that for the context of our project, we have to understand that K-12 teachers wouldn’t have much support in learning how to use our tool. It must be self-contained, self-teaching, and extremely foolproof if we hope to gain traction with this audience.

Task Analysis Questions
1. Who is going to use the system?
Our target audience is the typical classroom. We envision the product being used with about 20 students and a single teacher. The students don’t need to have any background in CS or experience coding.

2. What tasks do they now perform?
Current CS education tends to be done with “whiteboard coding.” This is the practice of writing code on a whiteboard to demonstrate the features. Other practices commonly used is simple lecture style and for certain concepts, teachers use abstract drawings. For example, when students first learn about memory, it is often represented with a box to be filled with data. These abstractions of data are very important, as students can quickly get confused when exposed to the more complicated principles that lie under them.

3. What tasks are desired?
Typically, educators are looking for a tool to help boost the understanding of their students in a classroom setting. Having the ability to present basic concepts of CS to students in a way that is easy to visualize, grasp, understand, and interact with is very desirable. Additionally, having a teaching tool that students can use and get feedback from without need to have the teacher on hand to always give direct instructions is very useful as it allows students to continue to learn on their own and at their own pace.

4. How are the tasks learned?
Currently, teaching is an extremely self-taught process. Teachers individually come up with their own lesson plans. In our system, tasks could be learned through a simple tutorial lesson that would introduce the students to the basic operations and principles behind our system. Concepts would be introduced one at a time and the interactions between could be demonstrated as students make progress.

5. Where are the tasks performed?
Classrooms with a projector and whiteboard. Only a few computers for a lot of students. Our system could potentially operate on any smooth surface to which ID tags could be easily attached and moved around.

6. What’s the relationship between user & data?
Users could potentially have personal profiles that track their progress throughout the lessons. When using the system in a group setting, the system could controlled by the teacher to set up lessons and track the progress of the class as a whole.

7. What other tools does the user have?
Textbooks, the internet, Toy programming languages (e.g. Scratch)

8. How do users communicate with each other?
Teachers communicate with their students in a classroom setting. The Teachers can give their students guidance and instructions as they use the system, and the students can freely ask questions about the current lesson.

9. How often are the tasks performed?
Students would go through a lesson about 2-3 times a week. Multiple lessons could potentially be completed in one class session if they are short.

10. What are the time constraints on the tasks?
Class session usually last about an hour. This should be plenty of time to go through most lessons. However, more difficult and complex tasks may need to be broken up into multiple lessons spanning multiple days.

11. What happens when things go wrong?
Ideally, any errors encountered would be a result of improper set up by the user, not flaws in the code itself. If something does go wrong such as the project getting out of alignment in the whiteboard or the camera has trouble reading the ID tags, users could simply tell the system to recalibrate. All data and current lesson progress would be saved. Data should be saved periodically regardless to ensure that if the system fails completely, the users’ current progress is still preserved.

Description of Four Tasks
Tutorial – How to Teach a Lesson (Storyboard not included)
This purpose of this lesson would be to provided a ground work for the teacher and students to build and to teach them the basic principles of using our system. This lesson could include walk throughs of specific lessons they should be teaching. Highlighting blocks and stepping them through each part of the process. Currently, this is an individual learning task done by teachers. They read textbooks and compile a lesson plan. We would hope to significantly reduce the difficulty of this process.

Teaching Number Base (e.g. Decimal, Binary, Octal, Hex)
Our first two interviews both said that one of the hardest things for early tech students to learn is binary. This is something that is fundamental to CS but can be conceptually very challenging to students. We hope to help the students to better understand number base through visualization. We imagine they would place Binary/Octal/Hex/etc. tiles on the board. They would then see how different number systems represent numbers. This would be a moderately difficult task to perform with our system but one that is currently very hard.

Teach First Toy Program (I/O and intro looping)
Another suggested teaching example from our interviews was an extremely simple toy programing lesson. The lesson essentially works through each of the fundamental parts of a computer and provides a simplified example:

Read in a number from input and print (intro. to I/O)
Read in a number from input, do an operation, and print (intro. to processing)
Read in two numbers from input, print the product (intro. to memory)
Read in numbers from input until a 0 is given. Calculate the sum and print (intro. to loops)
We would create these programs with simple code put on the board and inputs placed on the board as well. This lesson (especially memory) is something that is currently difficult to teach and learn but we hope to reduce that difficulty.

Simplified Turtle Graphics
Our final lesson is the most complex. We want to create a tactile version of the Logo programming language library. Users could control the movement of a virtual turtle and see how his path changes as they change various part of code on the board. This would be a great way to introduce functions and show the execution of the program in a visual manner. It would use:

Create “Function” cards that would allow users to define custom operations
Only uses a basic set of commands, such as forward, turn, and pen color.
This language is well established a good way to teach new students about programming but the difficulty is it often requires a computer for each student. We plan to reduce that difficulty by adapting the program to our tool, requiring only one computer per classroom.

Interface Design
The user can teach and interact with a variety of lessons on computer science topics. By placing a “lesson” card on the board, the system reacts and projects the interface for that lesson. Then, the user can add physical cards to the board in the relevant areas (eg. Binary values, Code, Input, etc..) and the system will react by showing the execution and output of the program. Unlike any current solution, our system allows a teacher or professor to visually demonstrate to an entire class these computer science topics. The interactivity of our system allows the teacher to make quick, visual changes to the program or input to demonstrate how the output will change. We believe that this will be an engaging, fun, and flexible way to teach students important topics in CS.

Storyboards
Teaching Number Base

This slideshow requires JavaScript.

Teach First TOY Program (I/O and intro looping)

This slideshow requires JavaScript.

Simplified Turtle Graphics

This slideshow requires JavaScript.

Sketch of the System