At 6:12 PM +0000 12/26/10, Bjartur Thorlacius wrote: >On 12/20/10, Stephen Bannasch <[email protected]> wrote: >> I've been creating educational science applications which let users collect, >> analyze and share data from probes and sensors. It is a huge plus to be able >> to deliver this type of application and educational learning experience in a >> browser. >> >How so?
Many reasons ... One category is how IT is managed (or not managed) in schools: Our Java Web Start applications range in deployed (across-the network) size from 4 to 30 MB. Schools in the US often don't have the resources to implement fast enough networks. Their connection to the Internet and local-area networks can be slow. The usage patterns in schools often have a load pattern that spikes at the start of a period. The result is that if the local web start caches for the student users are not already filled and a teacher starts the class with one of our activities the delay before the activity starts on all the computers can be five minutes or more. Schools that manage their networks well usually have shared network accounts for the students. This is good ... however unless the local area network is quite fast there is an unfortunate interaction with Java Web Start caching. An application which is 15 MB over the wire (pack200 and gzip compression) might expand to 30 MB in the Web Start cache in the users homefolder.If the users home folder is on a shared network drive then the Java resource data first traverse the network to the computer where they are expanded and sent back across the local area network to be saved in the users home folder. When a student runs one of our Java Web Start activities in period 1 on a computer the resources are cached in their home folder. When another student runs the same activity in period two on the same computer the resources need to be cached in their home folder also. We've created installers that instead cache these resources in a shared location on school computers -- this is a big improvement however the installer must be run by an IT administrator ... it is very difficult for a teacher to get access to an IT administrator. > >> For quite a while we've been deploying these activities/applications using >> Java Web Start. >> >> The code is open source and works with probeware interfaces from five >> different commercial vendors. >> >> However there are many problems deploying Java Web Start applications in >> schools and I'd rather deploy to an application running directly in the >> browser. >> >What problems do you face when deploying Java Web Start applications? >A former school of mine forbade teachers from deploying software for lack >of robust package management. The solution to that problem would be >improved package management, not masquerading applications as web >pages. Continuing with the reasons listed above ... Some schools use a system in which every computer a student uses in the school is wiped and re-imaged every night. To deploy toa school like this we need to work with administrators 3 or 4 months before the semester starts in order to get our application installed onto the "golden" image. A great deal of our work is educational research and development looking at new ways of using technology for learning, mostof our materials have much faster cycles than that. In general deploying an "application" on school computers and keeping it running is either difficult or close to impossible unless the app is considered essential and core. A different category has to do with what our current research interests are which tend more towards students collaborating and sharing work that they have done. It is *much* faster to develop interesting collaborative educational science applications and activities using web technologies. In addition if we want students to be able to easily access their work at school and at home then it is bets to persist these data with web-enabled services. Our Java Web Start activities do this but it is much easier to do this with an apprunningin a browser. In general almost all of the issues I describe above are opaque to normal school users (teachers and students) which means thatwhen problems happen they don't understand the cause or how work-around the problem. In order to make non-educational cost of this experience low for teachers and students we need to spend considerable resources working beforehand with school administrators. This doesn't scale. > > In addition much of our current research is in exploring the learning >> benefits associated with collaboration -- this is much easier to prototype >> and scale-up using web technologies. >> >> Recently I've been able to create a demonstration in a browser that graphs >> data from a Vernier GoMotion USB probe (measuresdistance using and >> ultrasonic ranging device). >> >> If you have a Vernier GoMotion probe plugged in you can just open this page: >> >> http://jnlp.dev.concord.org/goio-motion-graph.html >> >> and be graphing data from it within 30s. >> >> If you don't have this probe here's a screencast showing it working: >> >> http://screencast.com/t/7mmYpknbgoSz >> >> The current implementation uses a Java applet which also includes os and >> arch-specific native libraries (totalling about 500k). >> >If I understand you correctly, your applet is OS and arch-dependant, and >depends on a JRE and a web browser. Why not just use the JRE? The applet has two parts. One is Java, the other is a native library which communicates to the Vernier GoIO sensors via theOS USB HID interface. a JNI interface connects the two. Rougyhly there is about 250 kB of Java and 250 kB of native library however right now there are four different versions of the native library: 32 bit Mac OS X PPC, 32 bit Mac OS X Intel, 64 bit Mac OS X Intel, 32 bit Windows. In order to make the download as small as possible (which makes startup as fast as possible) resources for the native library are not packaged together and are not specified in the applet element in the browser. Instead after the applet starts itjust loads the native library appropriate for the OS, CPU, and architecture. OS and arch-specific resources can be specified more imply by using the jnlp form for describing an applet however this only works in browsers which use the plugin2 architecture introduced in Java 1.6. The way I have implemented this feature it also works in older browsers and in Java 1.5. > > Almost all probeware requires a user to install a driver ... however the >> Vernier GoIO series of probeware interfaces do *not* require installation of >> a kernel driver because the devices register themselves as USB HID devices. >> >> the result is that opening and using the Motion Grapher page does *not* >> require a user to install a driver into the OS -- whichmeans that this can >> normally be run in a school without requiring a user to authenticate as an >> administrator. This is ahuge plus. >> >> Recently I've had interest in extending this system to support Aurduino >> devices. >> >> I'm also interested in having access to BlueTooth sensors so I could create >> a similar experience for systems like IOS and Android which often don't have >> a USB interface. >> >The OS will abstract protocols like Bluetooth and USB from your app and provide >you with the desired data. The OS doesn't do this for probeware devices -- an additional driver or native library is necessary. What is unique about the Vernier GoLink probes is that while right now they do need a native library they do NOT need any driver installed because they already use the built-in USB HID driver. I am working on several projects to get more sense and control IO devices to use the USB HID interface so they can also be easily used with an application deployed to a browser All the other probeware interfaces which use USB require a user with admin access to install a custom driver. I thinking about whether it would be plausible to develop a Probe Data API similar to the work David Humpreys did developing anAudio Data API.
