Functioning in the Wireless Classroom

Shelley V. Goldman, Roy Pea, Heidy Maldonado, Lee Martin, Toby Whiteand the WILD Team @ Stanford University 1

Stanford Universitysgoldman@stanford.edu, roypea@stanford.edu, heidym@cs.stanford.edu, lmmartin@stanford.edu,

twhite@stanford.edu

Abstract

Code It! fosters mathematics learning environmentswhere pre-algebra students use handheld technologiesto explore and learn about functions. The resourcesdeveloped—server-based and handheld software andpaper-based student and teacher texts—werepackaged as a 20-session unit on code making andbreaking and designed to boost students’understanding of functions and their facility with themultiple representations of tables, graphs andsymbols. We field tested the wireless system with twoteachers and 120 students during summer school, andconducted studies on the features and function of thetechnology as a learning and teaching resource. Wereport on project development and research, focusingon lessons learned about the strengths and difficultiesof wireless, handheld technology in the mathematicclassroom.

1. Need

This is a particularly important time to develop andresearch technologies for math learning. Across theUS, there is a push to raise lukewarm achievementresults on standardized tests and internationalcomparisons. The Code It! materials––technology andreal world based––were designed to address thischallenge, capitalizing on developing technology forstimulating high performance while providing asatisfying, successful math learning experience.

Technology should be providing tools to supportthe activities of mathematics classrooms, yet manyproblems have accompanied classroom computer use:prohibitive cost, use models that do not mesh withclassroom structure, and a learning curve for teachersthat has been too high for too little gain. Even whenresearchers developed compelling exemplars [1,2],changes in organizational, social, and pedagogicalpractices with computers produced high hurdles [3,4].The combination of increased access, increasingteacher knowledge, decreasing technology costs, andnew portable devices is creating a synergy and newpossibilities for mitigating problems.

Early studies of handheld technology use aremodest yet suggestive of how they might best beapplied [5, 6, 7, 8, 9, 10] These are promising trends,and to tap the potential, we developed an applicationfor enhancing students’ math learning by providingrepresentations that are easily manipulated, and bycreating a context for learning formalisms [11,12]. Theproject enabled us to addresses three research areas:

1.1. Enhanced mathematics learning.

Do the materials and wireless tools enhance studentlearning of algebra concepts and skills? What progressdo students make in reasoning with representations ofpatterns and functions? In communicatingmathematically? Do we see increases in productivitywith this approach? Is engagement with math high?Do the materials boost student achievement?

1.2. Enhanced teaching.

Through partnerships with teachers we learn aboutconditions for success and needs for furtherdevelopment. Will teachers benefit from unit teachingtools and access to server-based group and individualdata? What are the critical issues in teacher learningand appropriation of this technology?

* WILD Team@Stanford members contributed to the Code It! workreported herein. Thanks to Sarah Walter, Gloria Miller, Mike Mills,John Murray, Nicolai Scheele and Wolfgang Effelsberg. Specialthanks to our partnering teachers and their students, the StanfordTeacher Education Program and the Stanford student teachers, andthe Santa Clara School District. This project was supported byStanford Center for Innovation in Learning (SCIL) and theWallenberg Global Learning Network. We also thankfullyacknowledge an HP mobile wireless computing equipment grant toSCIL.

The results stand to influence the design of ageneration of math tools by indicating ways thatserver-based communication, data tracking andstorage capabilities can enhance the teacher’s role.

1.3. Productive tool use.

How well do wireless handhelds or desktopcomputers work as a tools for math learning? What arethe resources and obstacles to use of the handhelds,network infrastructure, and collaborative activitystructures for learning mathematics?

2. Our Response and Approach

The project was structured around three strands ofactivity: materials development, work with teachers,and field test research. Each is discussed in turn.

2.1 Materials development.

We created a technology-integrated 20-sessioncurriculum unit on linear and quadratic functions, witha code making and breaking theme. The unit placesalgebra learning in a real-world context—making andbreaking secret codes [13]. Students can challengeothers to break their codes to determine messagecontent. Students must examine properties of functionsin general, learn to distinguish among “families” offunctions (e.g., linear vs. quadratic) as well as learnproperties of each family (effects of changes inconstants to graph, for example). Connections amongsymbols, tables and graphs are emphasized.

Code It! was inspired by a curriculum unit, Codes,Inc, developed by the Middle-school Mathematicsthrough Applications Project (MMAP), which wonrecognitions as a promising middle schoolmathematics curriculum by two US Department ofEducation expert panels. Evaluation showed teachersfound the MMAP codes unit helpful for transitioningto technology use and reform-based curriculum [14].Teachers saw real values for the unit to aid learners’development of needed algebra skills and concepts.

2.1.1 The change from desktop to WILD. Theadvantages of the wireless version of the software overthe desktop version seemed obvious. With hand-helds,students can create and exchange codes easily, andrecords of their work and solutions can be captured onthe server. We hoped the technology could leverageincreased interactions with mathematics andembedded assessment activities. In the desktopsoftware developed by MMAP, exchanging the codes

was based on cumbersome e-mail, now supplanted bywireless communications.

Code It! software is built around an in-roomwireless network which allows students to work oncodes together and to share codes between groups.Each PDA is connected wirelessly to a teacher'sstation in the room. The station runs administrativesoftware that allows the teacher to control and monitorgroups in a variety of ways. The teacher can monitorwhich students are logged into the server, placestudents into groups, create and distribute practiceproblems, and open observer windows that display agroup's current state. In addition, the server logs eachgroup's activity, allowing for a teacher or researcher toreconstruct the precise ways that students were usingthe software and solving problems. The server also is arepository for text and codes created by the teacherand students, providing a way to share codes amonggroups and to distribute practice problems.

Image 1: Graphical screen view of a codesolution.

Each PDA runs Code It! software that allowsstudents to create plaintext, to make and break codes,and to upload and download text and codes from theserver. When making or breaking codes, the student’sscreen displays the encoding function (or currentguess) and the graphs and tables that represent thefunction and the coded text.1 These representations

1 For this implementation of the software, these variousrepresentations are displayed on a single long, scrollingscreen for bringing the representations into view. While itproved less than ideal, our focus was on ensuring that thesoftware was robust, and the design generally functionedwell. This interface issue will be corrected in future versions.

include a graph of the function, a function table, andword and letter frequency tables, selected in order tofoster particular kinds of learning, rather than to createan ideal coding tool. All of the PDAs within any givengroup are bound together via the server. A changemade by one student propagates to the other studentsin his or her group, so the PDAs within a group alwaysdisplay the same function and text. Students in a groupcould each view a different representation of thefunction under consideration. The goal is to fostercommunication among group members and increasethe diversity of information available for the coding ordecoding task. When a group successfully breaks acode, it instantly receives a congratulations message.

2.1.2. Instrumentation. Beyond its use forsynchronizing the students in collaborative groups, theserver stores all messages being worked on bydifferent groups. It also provides administrativefunctions. Teachers may define groups and assignstudents to groups. It allows both teacher and studentsto write and edit plain text messages with a normalkeyboard, not just the restricted keyboard of the PDA.The server also logs communications to and from thePDAs that later recreate the PDA display for anygroup at any particular time.

2.2. Work with teachers.

The professional development component turnedout to be as important as the materials and software inensuring that students get a well structured, engagingand deep mathematical learning experience. Teachers“choreograph” the performances of classroom tasksand activities to enable students to engagemathematical ideas, language, and practices. Teachersare also faced with supplementing their adoptedmaterials to meet students’ needs, adjusting to increasecoverage, and to emphasize particular kinds ofthinking, problem solving, and communication.

We know that teachers must do a great deal ofwork to arrange productive participation structures intheir classrooms, and we need to learn about how theycan incorporate wireless technology. For their part,teachers need time to learn and develop both teachingsensitivities and practices with technology. Theirprofessional development is crucial.

Professional development included three days oftraining and planning with the teacher partners as wellas just-in-time, in-class support. The workshopincluded:• Time for being introduced to the technology

including PDA use and the teacher station.• Early access to review of the curriculum unit,

and discussion and revision of each activity.

• Practical planning advice and session-by-session planning time for implementingtechnology, including management oftechnology issues such as battery life, the classactivity schedule and student roles.

• Just-in-time daily consultations on math andtechnology while implementing the unit.Our time with teachers was extensive, but crucial

for helping us to uncover the strategies they used toorchestrate the use of handhelds, and identify theobstacles and affordances they inherited.

Image 2: Function table view of a codesolution.

2.3. Project questions and methods.

Our research goal was to test the usefulness of thematerials and to generate knowledge about the ways inwhich they were effective. We collected several datastreams, including observational data, videotapes ofteachers and the four-member student groups in theclassrooms, problem-solving and informationalinterviews with student dyads, and pre- and post-testsof mathematics knowledge. These methods, ofobserving and videotaping classroom field tests ofmaterials and feeding back results into the design,enabled our development team to define areas forrevision based on the use of the materials under realclassroom conditions [15,16,17]. The cycle ofdevelopment and field test supported our learningabout how teachers and students received the materialsand how best to iteratively improve the design forachieving the teaching and learning goals.

It is part of our method to track topics and issues asthey emerge in field tests and teacher workshops, and

to then interview, videotape, and interrogate. We lookfirst for obvious patterns of structure such as who isinvolved in planning and activities, how the space isset up and how and when people move around in it,what the flow of activities is from start to finish, whatmaterials and resources are used, how and whenteachers and students talk, what they talk about. Aftersearching for some of these basic structures, orbecause of “noticeable” events, other areas foranalysis emerge. These methods are complimented bythe use of problem-solving tasks and pre-and post-testswith students and interviews and surveys of teachers.

The research process is characterized by an inter-relationship among field-testing, development, andevaluation. For instance, prospective materials emergefrom focus groups, get written, and get put into thefield test, after which they are evaluated and revised.

We partnered with the Stanford Teacher EducationProgram and the Santa Clara, CA Schools to use CodeIt! with all of the district middle school students intheir five week summer school program. Each teacherhad 60 students split between two consecutive 100minute class sessions: one teacher used handheld iPaqcomputers (PDAs); the other used Compaq TabletPCs. This analysis focuses on the PDA classrooms.

Image 3: Student group working on Code It!

We pre- and post-tested students with mathematicsvocabulary items, short answer problems based on unitconcepts and representations, and released pre-algebraand algebra items from the California High SchoolExit Exam. We collected video on 120 hours ofclassroom time, using two cameras in the PDAclassroom each day. This enabled us to “follow” theactivities and progress of four groups of students in theclasses. We also interviewed twelve pairs of students(N=24) from those groups. For students in our focusgroups, we have pre- and post-tests, an interviewwhere they were asked to problem solve and break a

code, and a video record of their activities andprogress through the unit. In addition, the serverprovided a record of process steps for each group.

3. Lessons Learned

Analysis is preliminary, yet we have someencouraging results on how our learning technologydesign functioned, and the ways in which teaching andlearning were affected. Whereas we have outlined theproject with three categories of interest, our resultsreinforce the synergistic nature and interactions of thetechnology, the teaching and the learning. We do notreport on them as if they were mutually exclusivebecause we observed them in the flow of classroomactivities where their affordances and constraintsmelded into resulting situations and events. So wepresent here observations where the constellationcame together in mutually reinforcing ways or innegative ways. We are able to offer some next stepsthat we have identified to improve the Code It!experience and some of those steps point to specificsof students’ math learning, how teacher can make themost optimal use of the materials, and how the designof the Code It! technology itself might change.

3.1. Students and math.

Two aspects of student work dominated ourattention. The first was meeting our goals of gettingstudents to interact with, discuss, and use themathematics. The second was the establishment of thesocial arrangements needed to support working withthe tools to meet the math engagement goals.

3.1.1. Students’ interaction with mathematics. Todate, we have analyzed results of the pre- and post-tests in the PDA class with our targeted student groupsand the results were promising (N=45). The meanincrease from pre- to post tests was eight percentagepoints; in four of six focus groups, students madesignificant gains, in some cases raising their scores by15-30%. The PDA students showed significant gainson items relating to evaluating exponents and thegraphs of functions. On one graphical item, 44% ofstudents answered correctly on the post-test, ascompared to only 13% on the pre-test. What isexciting about these trends is that these results werefor students in grades 6-8 who were placed inheterogeneous groups regardless of their previousschool math course achievement. Many students in theclass had done poorly in sixth or seventh grade math,while some students had completed the first year ofalgebra. The algebra students were encouraged to help

others, and the pre- and post-test results indicate thatthese interactions may have had an impact.

3.1.2. Focusing on the Curriculum. Keeping theattentions of students on the mathematics took a greatdeal of social engineering on the part of the teachersand the development team. The team had to mitigatethe effects of the widely heterogeneous groups and theconstraints that the Code It! tool entered into theequation. We treated these as both challenges andopportunities. During the teacher workshop, wediscussed these constraints and decided to introducerotating social roles inside the groups in order to makesure all students had a chance to work with all aspects,tools and representations during the problem solvingprocess. Once the students started learning how tocode and decode using the PDAs, an anarchisticatmosphere emerged in the classroom. The teachermentioned the group roles, yet students forged aheadwithout obvious attention to them.

We saw “stylus wars” break out among studentswho were vying for control of their group’s PDAs andcommunication with the server. Heated discussionsarose and the chaos and discontent led us to work withthe teaching staff to enforce roles that would fostergroup collaboration, rather than competition. Linkingthe process roles of (1) recorder, (2) presenter, (3)publisher and (4) equipment manager to the differentcode representations in the software, and rotating theseroles avoided much of the inter-group conflict, butalso contributed to more engagement on the part ofmore students in code analysis and breaking activities.In addition to group roles, the teacher and summerinterns instituted and enforced a rule stating that “allstudents in a group must be able to explain thestrategies and routes to solutions in order to receivecredit.” That meant that if the more skilled andexperienced students in the group solved a code beforeothers, the entire group had to review the steps taken,the strategies used, the solution, and be able todemonstrate it using a PDA. This increased teamcooperation, and resulted in a practice of questions andexplanations across group members. Teams spent timeworking together to make sure they could each explaintheir problem solving if asked informally by a teacheror if asked to present to the entire class.

Due to the social engagement rules, we saw moreconsistency of performances on the part of thestudents over time. Early on we observed a full rangeof performances, from students engaging in someextremely rich and iterative collaborative problem-solving processes, to students relying on simpleguessing strategies, to students avoiding workaltogether. After instituting the social rules for“student roles” and the “explanation rule for credit,”

new patterns emerged, and we observed multipleinstances of the students who took problem-solvingapproaches talking with those who usually guessed orseemed uninvolved. The social engineering improvedgroup relations and engaged students more deeplywith the software and the mathematics.

Image 4: Teacher’s view (server screen).

3.2. Teachers.

Findings about teachers and their work fall intothree categories: (1) teacher training and teacherknowledge; (2) teachers’ appropriation of thetechnology; and, (3) teachers’ “workarounds” for thetechnology’s shortcomings.

3.2.1. Teacher training and knowledge. Even thoughteachers participated in three days of teacherprofessional development that included explorations ofthe unit and the technology and individually practicedusing the teacher station and the PDAs, the situationsthat developed when twenty-five to thirty studentswere using the system in class outstripped their noviceknowledge. While the teachers were clear on the basicoperations of the PDAs, they were caught by surpriseconcerning student engagement and in the ways thesoftware could be used to pose or solve particularcoding problems. As the days of the field test went byall three of these teacher practice areas improved. Ourcontinued work with the teachers on a “just in time”basis addressed some of the teachers’ lack of priorexperience. During the first two weeks of the unit, theteachers grappled with understanding the potential ofthe technology to help students problem solve. In oneof several meetings between a math educator on ourstaff and the teachers, the strategies for working todecode were explored. An outcome of the meeting wasto have our staff member co-teach one lesson to

demonstrate a systematic way to use Code It! to crackmore difficult codes. Once this happened there was anincrease in student productivity in code breaking. Werealize in analyzing this incident that we were unableto have predicted the teacher’s need for scaffolding inorder to use Code It! effectively with the students.Next steps will include more classroom problemsimulations for the teachers to work with that can befashioned from this year’s field test. This will helpteachers to learn how the tools are best used forproblem solving affiliated with the unit.

3.2.2. Teachers appropriated the technology. Theteachers actually did a great deal of work to make thetechnology useful for meeting the curricular goals.Code It! presented them with a set of challenges andcomplexities to manage and, in some instances,overcome. We saw the teachers appropriate thetechnology into their teaching practices. One teacherfound a way to use the blue and white circles thatshowed the active status of every student in eachgroup on the teacher station screen as a classroommanagement tool, keeping track even from across theroom of which students were on-line and whichgroups were most active. This enabled him totroubleshoot for students who were having log-onissues as well as to visit groups that were laggingbehind in the activity. The same teacher used theteacher station to develop activities and code breakingproblems when he saw the need for more scaffoldingbetween simple and more complex codes. One studentteacher in the classroom used the teacher’s station todevelop problems and lessons. This gave teachers theopportunity to assess students’ work and needs, tocreate hand-tailored activities and problems, and toorganize them so they were available to the students.Both teachers used projection equipment so they andstudents could discuss with visual aids the variousstrategies for code breaking as well as demonstrate theuse of the different Code It! tools. This demonstratedhow the system was robust in use and how teachersmade it compatible with their teaching practices.

3.2.3. Teachers worked around technologyshortcomings. Some constraints in the technologycaused rifts in the smooth flow of classroom activityand the teachers found themselves compensating whenneeded. The constraints were many and ranged fromoverload during whole class log-on, to the lengthyscrolling screen with multiple representations of data,the fact that some of the representations of coded datawere more useful to students than others (e.g., as thesystem could only handle short codes they could notbenefit much from word frequency analysis data), tothe fact that the system could log only group work.

The teachers created short codes when they providedsupplementary activities, shared strategies for workingwith all of the representations, reminding students ofhow to find them, and established and enforced aseries of roles and expectations about the sharing ofcode breaking solutions to mitigate the fact that butone PDA in each group could communicate with theserver at a time (and return new results in a graph ofthe function entered, for example) as Code It! trackedonly group activity.

Together, these findings about teacher workindicate that, although the technology introduced aneed for all kinds of management of instructionalactivities, the teachers demonstrated a steep learningcurve and an ability to strategize, plan and respond tostudent and technological difficulties, and to capitalizeon the tools to facilitate math learning.

3.3. Technology design and performance.

Three features of Code It! were shown to needreworking during the classroom test: (1) the waysmathematical representations and tools are organized;(2) the choice to base the system on group activitiesand interaction over individual acts; and, (3) thedesign and usability of record keepingfunctions—potentially so promising with wirelesstechnology. Each is discussed in turn with examples toillustrate reconsideration of the design. Our originalgoal was to produce a first, yet functional and robustversion of Code It! in a twelve week developmentperiod to have it ready for the summer 2003 classroomtest. We accepted the short development time linebecause we were interested in partnering with theteacher education program and the summer school. Tous, this was both a service and an experiment. Thattime line resulted in several design compromises andissues to address in the next iteration.

3.3.1. The organization of mathematicalrepresentations. The ways that students came tointeract with the multiple tools and representations forunderstanding and finding code keys revealed sideeffects of our choices. The first representational issuearose from the choice to employ the lengthy scrollingscreen for accessing different representations insteadof using a multiple windows approach. While thescroll function was easy for students to learn and use,it gave prominence to the first representation showingon the screen (the graph), with other representationsabsent from view without scrolling. We worried thatgiving prominence to the graph would signal ahierarchy to students, and it did. We constructed thecurriculum materials and a process for introducing theother tools and representations (a function table, letter

frequency and word frequency tables). The groupprocess and daily rotation of assigned roles thatattached students to one of the function representationswas a compromise between the constraints of thesystem and the ways students could best benefit fromthe representations available. Although the system ofeach student having a portion of the data displayed forinterpretation on his/her PDA encouraged groupcollaboration, it meant that on any given day a studenthad the responsibility to relate to only one view of thedata. We were able to deduce that the multiplerepresentation capabilities of the software is a strengthand real resource for mathematical work and learning.A question that now remains for investigation is howstructured or unstructured students’ access to thoserepresentations should be.

This is significant because we also discovered thatrepresentations were unequal in their familiarity andusefulness. The graphical tool was extremely powerfulbecause the data window automatically fits to thevalues of the coded text. This enabled students to do akind of curve-fitting that usually got them close to acorrect code. Many of the students could determine thepresence of an exponent in the code graphically, andoften the lead coefficient as well by adjusting thegraph. The function table was just as powerful, thoughfar fewer students learned how to use it well (at leastpartly because of a programming error that wecorrected for halfway through the course). Thefunction table was two tools in one, because it had aninverse function table embedded in it. That table wasconfusing to most students, and even those who hadalready taken first-year algebra operated withmisconceptions. The word frequency table was usedeven less due to the fact that our coded text passageswere short due to the software slowing down with longpassages. Students rarely used it, except to guesswhich numbers might be representing the single-letterwords “I” and “a”. These differences inrepresentational placement, form and usefulness hadconsequences––the students assigned to the graph andthe function table were able to be most involved.

It is not clear from our field test that our work onrepresentations was completed to satisfaction. Wecame away from the field test questioning whether themultiple representations provided an appropriate levelof scaffolding for the students' understanding. Somegroups quickly found simple strategies that led them tocrack codes without improving their knowledge offunctions. For example, some students consistentlyand repeatedly used the graph of a function aspredictors of the range and domain of the encodingfunction, methodically changing values in the functionuntil the axis labels came within the range of theletters of the alphabet. Others consistently sought out

single, two, and three- letter words, as well asmappings for the most common letter in the Englishlanguage ("e") as a path for breaking codes. We havediscussed incorporating a prediction capability to thesoftware, which could alert the teacher or team itselfwhen a group is in danger of depending solely on aparticular pattern of code breaking.

3.3.2. The choice for group over individual. Ourdesign decision was to bias the function of the systemto support groups over individual students. This was achoice we made early on in order to be able toexperiment with the capabilities of the teacher stationdata collection. This decision proved to be extremelyconstraining in the classroom, and needed manysocially engineered workarounds. Students wanted toplay and explore when they had PDAs in their hands,but were unable to do so unless it was their assignedrole to communicate for their group. They had troubleorienting to these rules, and often competed for controland communication with the server. Many cursor warsbroke out in groups. When the wars were resolved infavor of strict, daily roles, some students becamealienated. They were discouraged, and some werebored. This led them to discover other features of thePDAs such as appointment books, animated messages,and games such as Solitaire. Our desire to have thegroup at work and record all group transactionsresulted in some students tuning out when they had aless-than-critical role assigned. Schools also rely onindividual accountability, and the system was unableto account for individual problem solving activity. Asa workaround, we sought to set up a group for eachstudent, but the system could not handle 30 groups.

3.3.3. Rethinking record keeping functions. Whenwe designed Code It! we were pleased to experimentwith the kinds of information and data that the servercould provide to the teacher. The server did keep trackof a great deal of information about group problemsolving. Unfortunately, these records were notimmediately recoverable by the teachers and morework will have to be completed to develop a useableinterface on student work. We discovered that studentsalso needed access to records of their problems andsolutions. It became a whole class activity for studentsfrom groups to share with the entire class the waysthey approached and broke codes. Even though groupskept notebook records of their strategies, studentsfound it difficult to make use of them after the fact.

We plan for the next version of the software tosupport easy access to records of problem solving bythe students. We seek to address the ideal balancebetween scaffolding for collaboration and individualexploration of the encoded functions, within the Code

It! software environment, so as to lessen opportunitiesfor disruptive stylus-wars. Our upcoming iteration willincorporate a flexible grouping mechanism, whilemaintaining both the appeal of collaboration andsoftware robustness that made this first experiencewith Code It! successful. We are also consideringways to decouple the individual PDAs from thesystem. This would allow for students to explore andproblem-solve individually as well as in groups, aswell as provide opportunities for “anytime, anywherecomputing”. These home and family connectionswould capitalize even more on the potential ofportable, wireless technology.

4. Conclusion

We had a successful field test of the Code It! wirelessapplication under extremely constrained, yet real,classroom conditions. Now that we have an idea ofhow students and teachers actually put such devicesand software to use, we can develop a next version.This will result in a more aesthetically pleasing anduseful application that fits the interaction, content, andassessment demands of the mathematics classroom.

5. References

[1] Middle-school Mathematics through Application ProjectFinal Report to the NSF (1998). Menlo Park, CA: Institutefor Research on Learning.

[2] Roschelle, J., Pea, R., Hoadley, C., Gordin, D., & Means,B. (2001). Changing how and what children learn in schoolwith collaborative cognitive technologies. In M. Shields(Ed.), The Future of Children (Special issue on Childrenand Computer Technology, published by the David andLucille Packard Foundation, Los Altos, CA), Volume 10,Issue 2, pp. 76-101.

[3] Goldman, S. (2001). Technology in the MathematicsClassroom: Guidelines from the Field. ERIC Update. ERICClearinghouse on Information and Technology, 22 (2).(http://ericit.org/newsletter/Volume22-2/goldman.shtml)

[4] Means, B., Penuel, W. R., & Padilla, C. (2001). TheConnected School: Technology and Learning in HighSchool. San Francisco, CA: Jossey Bass.

[5] Soloway, E., Grant, W., Tinker, R., Roschelle, J., Mills,M., Resnick, M., Berg, R., & Eisenberg, M. (1999). Sciencein the palm of their hands. Communications of the ACM,42(8), 21-26.

[6] Curtis, M., Luchini, K., Bobrowsky, W., Quintana, C., &Soloway, E. (2002). Handheld Use in K-12: A DescriptiveAccount. Proceedings of The First IEEE International

Workshop on Wireless and Mobile Technologies inEducation (WMTE'02, pp. 22-30). New York: IEEE Press. .

[7] Luchini, K., Bobrowsky, W., Curtis, M., Quintana, C., &Soloway, E. (2002). Supporting learning in context:Extending learner-centered design to the development ofhandheld educational software. In Proceedings of The FirstIEEE International Workshop on Wireless and MobileTechnologies in Education (WMTE'02, pp. 107-111). NewYork: IEEE Press.

[8] Vahey, P., & Crawford, V. (2002, September). PalmEducation Pioneers Program: Final Evaluation Report. MenloPark, CA: SRI International. (http://www.palmgrants.sri.com).

[9] Roschelle, J., Patton, C., & Pea, R. (2003). To unlock thelearning value of wireless mobile devices, understandcoupling. In Proceedings of The First IEEE InternationalWorkshop on Wireless and Mobile Technologies inEducation (WMTE'02, pp. 2-7). New York: IEEE Press.

[10] Tatar, D., Roschelle, J., Vahey, P., & Penuel, W. R. (inpress). Handhelds go to school. IEEE Computer.

[11] International Technology Education Association(2000).Standards for Technological Literacy: Content for the Studyof Technology. Reston, VA: ITEA.

[12] President’s Committee of Advisors on Science andTechnology and Panel on Educational Technology (1997,March). Report to the President on the Use of Technology toStrengthen K-12 Education in the United States.

[13] Singh, S. (2000). The Code Book: The Science ofSecrecy from Ancient Egypt to Quantum Cryptography. NewYork: Anchor Books.

[14] Lichtenstein, G. Weisglass, J., & Erickan-Alper, K.(1998). Final Evaluation Report: Middle-schoolMathematics through Applications Project. Denver, CO:Quality Evaluation Design.

[15] Brown, A. (1992). Design Experiments: Theoretical andMethodological Challenges in Creating ComplexInterventions in Classroom Settings. Journal of the LearningSciences, 2(2). 141-178.

[16] Cobb, P., Confrey, J., diSessa, A., Lehrer, R., &Schauble, L. (2003). Design Experiments in EducationalResearch. Educational Researcher, 32 (1), 9-13.

[17] Design-Based Research Collective. (2003). Design-based research: An emerging paradigm for educationalinquiry. Educational Researcher, 32 (1), 5-8.