1. multiLearn toby Escarez ethan Faust jacob Mrozek ji Mun chris Patterson anirudh Srinivas calder Thami

2. The Problem In 2008, the national average ratio of students to computers was about 3.8 Teachers have difficulty gauging student performance over time Parents would like to know how their kids are doing more regularly

3. Introducing multiLearn Educational program Originally developed for use in India o Allows 4 students to use a computer No way to view statistics…

4. Target Users Teachers in Seattle schools o Internet connected computers o ~3.8 to 1 ratio (students to computers) 4th - 5th grade students o Experienced with computers Seattle parents o Home internet access

5. Built based on feedback Online access is essential Feedback is more important than grading Info provided by current systems can be overwhelming Current online feedback from games is not reliable Teacher want to see whole class stats o Problems the whole class are missing

6. Related Work MultiMouse (~2006) –Allowing computer to recognize different users Metamouse (~2009) –Legacy computer programs Mouse Mischief (~2010) –add-in for Microsoft PowerPoint 2007, 2010 –Simple short-term score page “One Mouse per Child”

7. Related Work Student Response System –“Clicker” price –Increase engagement and motivation –Presenting data: Historical Report, Comparison Report –25.1% of teachers use response to adjust instruction (The Effect of SRS… 2007)

8. What we’ve accomplished so far Web Application o Implementation  PHP, Javascript, & MySQL o Teacher interface  Teacher class list  Overall class statistics  Individual student view o Data conversion & DB management

9. Teacher Interface Class view o Add classes o View class list o View Individual Classes o Add Students o View Overall Stats

10. Teacher Interface Overall Statistics o Class Percentages  Color coded o Student Table  Sortable o Student Graph  Color coded

11. Teacher Interface Individual Student o Ability to add comments for himself/herself, the parent, or the student o Allows parents to gain an insight into how their child is doing, and allows teachers to communicate easily to the childs parents o Students can see what they could work on and what they are doing well

12. Teacher Interface

13. Data Conversion & DB management Client Side Application uses SQLite, Web Application uses MySQL PHP script converts SQLite file into MySQL tables that are automatically updated in our database MySQL database can be created with a PHP script. Allows for the database to be modular and easily deployed

14. Changes from original plan Graphs Then: Now:

15. Changes from original plan Database Schema o New types of questions called for new schema o Much of the data was going unused  Exact problem not important  Type of problem important o More work done client side  Quicker, less complicated queries

16. Changes from original plan Rewriting multiLearn o Given buggy code  Crashed when certain pin numbers were typed o Poorly documented  ~5 lines of comments total  No documentation of Windows API usage  Compiling 32 vs 64 bit systems o Written for.NET 3.5  Not supported by most computers  Used unreliable ADO database calls

17. What we’ve accomplished so far Client application o Implementation :  C# and SQLite o multiLearn o Error Handling  Degrades gracefully if computer is disconnected from internet o Automated data upload & download

18. Arhitecture - Principles Architecture - Principles Components should be as general (reusable) as possible It should be easy to modify the program to add new types of questions Export summary data instead of detailed data for every question o We’ve reduced the number of SQL rows to merge as well as the complexity of server-side queries Documentation is not optional!

19. What we wanted o Client Application  Curriculum assessment tool  Data stored in SQLite database  Automated data upload o Web Application  Displays statistics  Accepts upload of usage data  Allows teachers to customize what kinds of questions are asked  Makes it easy to deploy these customizations to many classroom computers instantly Architecture - The Big Picture

20. "The Big Picture"

21. About that rewrite: More coding than expected But worthwhile because we could customize every aspect of the application o Added games o Exporting of summary data o Automatic uploading/downloading of user data o Control over what questions are selected  Previously done by AI

22. Usage

23. Prototype Demonstration

24. What’s Left - Server Side Parent and Student access Refining the interface Additional graphs & charts State/National Standards

25. What’s Left - Client Side Support for proxies o Many schools use these to implement content filtering Add additional types of questions Add additional teacher customization o Teacher customizable parent/student views Ensure it is fun for students

26. Timeline for remainder of quarter Additional functionality (Week 9) o Parent/student login o Use of MultiSpell data o Printing Paper/poster (Week 10)