Learning Software

Okay, so there's nothing really exciting about being Pre-Alpha.  It merely means that we haven't even built an official version of the 5.3 code, but it definitely does not mean that we haven't been working (I can't believe you'd even think that).  Since everything is at such an early stage, I simply don't know what will be in 5.3 next year, but I do know what I've been working on lately so I'll talk about that.

This week I've been knee-deep in bandwidth issues as we work on adding a screen broadcaster feature to DyKnow Monitor.  Screen broadcaster has been a Vision feature for years now given the dividing line traditionally has been classroom management = Monitor and classroom interaction = Vision.  But many of our newer features in Monitor have begun to blur that line.  In many ways, I'm beginning (hoping) to see Monitor as a way to engage your students as opposed to merely ensuring they're engaged.  I'm getting ahead of myself.  So what does Screen Broadcaster mean for Monitor and why am I worried about bandwidth?

I'm glad you asked.

Firstly, lets define why anyone (Vision or Monitor) would want to broadcast his or her screen by looking back at my Computer Science (CS) classes at DePauw.  CS is a major that necessarily requires multiple tools.  Much of the theory and concepts were discussed using DyKnow Vision thanks to its collaborative notetaking features, but try as you might, you can't compile and run a program with DyKnow.  So in order to participate in class labs and paired programming exercises we had to use a compiler.  It would be nice if everyone was completely fluent in whatever program they're using at all points in time, but reality has shown that you have to show people how to use tools.  Broadcasting your screen to your class allows you to demonstrate how to do an action to your entire class at once without needing a projector (or students being in the same room).  

So why am I worried about bandwidth?  It's because images are very large.  Ted Stevens famously received the ire of the Internet by calling the "internets" a "series of tubes."  His metaphor wasn't entirely apt in the situation he described because he thought an email was being delayed by a matter of days due to increased network traffic.  Despite the famous faux pas, the series of tubes metaphor does make sense when talking about general bandwidth concerns.  Only so much water can flow through a tube before it starts getting congested.  The same is true with your wireless router.  If you try and push too much information through the router, eventually some or all the programs you're using for class will stop working (at least the connected ones).  

Additionally, we're not just talking about one classroom, but there will be some effect on your entire network.  On the other hand, you don't want to send too little data or you won't be able to effectively demonstrate (earlier today I ran and subsequently failed a test that looked like I was trying to redraw the screen in MSPaint).  One thing we do in Vision (and will also do in Monitor) is to allow the user to broadcast in a "Low Bandwidth" mode.  This way users are able to govern the wireless usage, but given that this also comes with a loss of quality, not many people will opt into this option.  

So obviously, there's a lot to think about still, but I am pleased with the progress we're making.
_________________________________________
tweet this!