Experience with projecting student screens?
I wonder if anyone on edu-sig has experience in classrooms that allow switching any student's screen to become the projected screen, even dividing up the projected screen among students (as in some Xbox games). I find students don't always like having their privacy disturbed nor the big brother feel, but understand multi-user game play. With Twisted on the school server, it's increasing easy to devise these multi-user exercises involving teams in a competitive relationship. Not saying every school uses Twisted, duh, just that we have that freedom in some academies, where CP4E type kids get a green light to geek out. The more common design pattern these days is for students to share whats on screen more asynchronously, by swapping YouTubes around. Kirby
Not so much the split screen, but we have started using iTalc to share/monitor/etc student screens. That lets an arbitrary student screen appear as the projected screen. iTalk is controlled from the teacher's computer, so it's not really spontaneous or student controlled. On a similar theme, I've also had kids in Python classes write IRC clients and bots and interact on an inhouse IRC server. That's actually loads of fun, particularly when they start trying to construct bots - lots of thinking that goes beyond bare syntax and coding and the like. Cheers, Vern kirby urner wrote:
I wonder if anyone on edu-sig has experience in classrooms that allow switching any student's screen to become the projected screen, even dividing up the projected screen among students (as in some Xbox games).
I find students don't always like having their privacy disturbed nor the big brother feel, but understand multi-user game play.
With Twisted on the school server, it's increasing easy to devise these multi-user exercises involving teams in a competitive relationship.
Not saying every school uses Twisted, duh, just that we have that freedom in some academies, where CP4E type kids get a green light to geek out.
The more common design pattern these days is for students to share whats on screen more asynchronously, by swapping YouTubes around.
Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
On Thu, Aug 14, 2008 at 8:44 AM, Vern Ceder <vceder@canterburyschool.org> wrote:
Not so much the split screen, but we have started using iTalc to share/monitor/etc student screens. That lets an arbitrary student screen appear as the projected screen. iTalk is controlled from the teacher's computer, so it's not really spontaneous or student controlled.
Do you have an iTalk link handy, one that describes capabilities in detail?
On a similar theme, I've also had kids in Python classes write IRC clients and bots and interact on an inhouse IRC server. That's actually loads of fun, particularly when they start trying to construct bots - lots of thinking that goes beyond bare syntax and coding and the like.
Yes, I think we do too little with bots or "active agents" as some call them, e.g. web crawlers that go out at night and come back with loads of goodies. If anyone comes across a good Google Video on daemon architecture, I'm looking for animations that will help students visualize multiple processes staying resident in memory. That helps with the bot concept as well, although some bots are no more than listeners on a channel, not much autonomy after the lights go out. Kirby
Cheers, Vern
kirby urner wrote:
I wonder if anyone on edu-sig has experience in classrooms that allow switching any student's screen to become the projected screen, even dividing up the projected screen among students (as in some Xbox games).
I find students don't always like having their privacy disturbed nor the big brother feel, but understand multi-user game play.
With Twisted on the school server, it's increasing easy to devise these multi-user exercises involving teams in a competitive relationship.
Not saying every school uses Twisted, duh, just that we have that freedom in some academies, where CP4E type kids get a green light to geek out.
The more common design pattern these days is for students to share whats on screen more asynchronously, by swapping YouTubes around.
Kirby _______________________________________________ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
-- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
kirby urner wrote:
Do you have an iTalk link handy, one that describes capabilities in detail?
http://italc.sourceforge.net/ and the wiki at http://italc.sourceforge.net/wiki/index.php?title=Main_Page
If anyone comes across a good Google Video on daemon architecture, I'm looking for animations that will help students visualize multiple processes staying resident in memory. That helps with the bot concept as well, although some bots are no more than listeners on a channel, not much autonomy after the lights go out.
Actually, I've discovered that you can't really write an IRC client without dealing with threading, at least in a light-weight sort of way. Cheers, Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
Hi Vern, On Aug 14, 2008, at 12:29 PM, Vern Ceder wrote:
Actually, I've discovered that you can't really write an IRC client without dealing with threading, at least in a light-weight sort of way.
could you elaborate a bit on this? I'm curious. Cheers, -- Ivan Krstić <krstic@solarsail.hcs.harvard.edu> | http://radian.org
Hi Ivan, Ivan Krstić wrote:
On Aug 14, 2008, at 12:29 PM, Vern Ceder wrote:
Actually, I've discovered that you can't really write an IRC client without dealing with threading, at least in a light-weight sort of way.
could you elaborate a bit on this? I'm curious.
I should have made that clearer - it's way too broad as I said it. I had them writing *terminal* based chat clients, since we hadn't done much with GUI's at that point. And under those conditions threading is the easiest way (or at least the easiest way I could think of) to write a client that behaves the way we're used having a chat client behave - with messages streaming by as you enter your own messages. I was actually happy about this, since it was a way to introduce the topic as a solution they needed to a problem they were trying to solve (i.e., "my current client really sucks"), rather than just another topic that would be good to know some day. Cheers, Vern -- This time for sure! -Bullwinkle J. Moose ----------------------------- Vern Ceder, Director of Technology Canterbury School, 3210 Smith Road, Ft Wayne, IN 46804 vceder@canterburyschool.org; 260-436-0746; FAX: 260-436-5137
participants (3)
-
Ivan Krstić -
kirby urner -
Vern Ceder