1 / 17

The Problem – Learning to Program

The Programming Playground Mike Hobbs Marie Gordon, Elaine Brown Department of Computing Anglia Ruskin University Cambridge and Chelmsford UK. The Problem – Learning to Program. 'Good' computing Students get into programming try things out and experiment complete and extend examples

zelenia-workman
Télécharger la présentation

The Problem – Learning to Program

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Programming PlaygroundMike Hobbs Marie Gordon, Elaine Brown Department of Computing Anglia Ruskin UniversityCambridge and Chelmsford UK

  2. The Problem – Learning to Program • 'Good' computing Students • get into programming • try things out and experiment • complete and extend examples • can't be stopped • 'Poor' computing students • find programming hard and boring • use rote learning and/or cut and paste • do not engage with exercises • can't get started

  3. Solution? – student learning focus • Don't 'teach' programming – encourage: • exploration and discovery • peer to peer learning • social constructivism • Other approaches • reusable learning objects • online tutorials • games • competitions

  4. Why Use a Virtual World ? • Engagement • Increased feedback from environment • ‘Rich’ environment manipulated by user • More customisable = more ‘ownership’ = greater engagement • Constructive • egalitarian approach to learning • remove teacher learner barrier • student contribution equally valued

  5. Features of Second Life • A kind of MMORPG? • Not a game but uses game technology • no theme • no levels , no goals, no challenges • no rewards, no penalties • no end point • Content provided by residents for residents • create themes, set goals, provide rewards • build communities • Strong SL – RL links • Music, art, movies, business, retail, news, educational resources, SL campus

  6. The learning advantage • Use SL to facilitate • An open ended environment away from the classroom • More ‘realistic’ task based activity • Appeals to different learning styles • Support a student led exploratory approach to learning • Programming and design • can only be learned by doing • grammar + syntax ≠shakespear

  7. Initial project idea • Create a 'playground' of artefacts for novice programmers e.g. • Swing – will swing ‘n’ times demonstrating a for loop • Round-a-bout – will rotate ‘while’ an avatar is sat on it. • Slide – one ladder gives access to a number of different slides – demonstrating choice • Objects to have both obvious and 'surprise' behaviours • Students input parameters to objects • Students 'discover' properties of objects

  8. Developing learning outcomes • BUT • limited range of actions for objects • demonstrate rather than participate • need to teach concept of 'algorithm' • So, extend the learning • create building blocks for a task • clearly outline the requirements of a task • students assemble elements to achieve task • e.g. sorting different sized and coloured objects.

  9. Realisation • Second level computing students • Already program (mostly) • need to link design and implementation • project re-cast to support program design • Get students to create playground objects • introduce lsl via tutorials and examples • 'jumping box' and 'rotating object' examples linked to UML design exercises

  10. Linden Scripting Language • LSL is a 'C' like Language - Not Object Oriented • State based • Restrictions on data storage • limited IDE, quirky • Using non OO language for pure OO simulation • Avatars = Actors • Objects = Objects • Programming details 'hidden' • Interaction via message passing

  11. Student activities • Registration and orientation in SL • Technical issues - firewall and port ids) • Orientation island - keeps changing) • Help island – has building and scripting demos • Getting started • Find the Anglia Ruskin Computing land, join group. • Further orientation tasks – treasure hunt • Set up reporting process (Moodle, snapzilla, photbucket, blogger, multiply)

  12. Designing and using lsl • My first object • Introduction to lsl – jumping box. • Playground artefacts • each student has a go at building one playground object • Car park Scenario • groups pick an aspect to model and implement: • vehicle • ticket machine • barrier • parking space(s) • Different objects have to interact...

  13. Initial results – user interaction types • Different types of interaction with SL • Superficial - user does not engage • Realistic – Behaves in SL as they would in RL • Empowered – Realistic but empowered to be more adventurous • Fantastic – SL regarded as a game, bold social behaviour. • Different types of learner – (Honey and Mumford) • Theorist – rational and structured learning • Reflector – learn by observation and review • Pragmatist – seek practical applications • Activist – learn by experiencing

  14. Superficial Realistic Empowered Fantastic Theorist Pragmatist Reflector Activist Initial Results: Learning Styles

  15. Initial results – learning behaviours • Learning from each other • Students can see the effect of their actions • Learning through student discovery • peer to peer • online / in-world tutorials • student decides what they need. • Highly personalised – each has own point of view • Classroom communication preferred to in-world instant messaging. • Blurring of SL / RL barrier.

  16. Questions? ... Answers?

More Related