I've been accepted to Summer of Code with my poposal for the Student Teacher interaction system for the Free Earth Foundation! I’m sure you’ll be hearing a lot more about this, but for now I’ll give you my proposal.
==== Project details ====
Name: Tim van den Hamer
Project name: Student Teacher interaction system
==== Summary ====
A student-teacher interaction system would introduce a way for teachers to effectively use NASA World Wind in the classroom. While the name of the project indicates the main focus, the system can also be used for other scenarios such as conferences, collaboration and even games. This means the client module should be able to be both a receiver and a transmitter, and have varying modes depending on the kind of scenario the host module needs.
==== Detailed description ====
Since the system will potentially be used by people who do not have much knowledge of computers ease of use is a key factor. Both client and host should have no options when starting, they should be set up by an experienced administrator once to avoid confusing less experienced users later on. During use the client should have none or nearly no settings, to be determined during setup. The host interface should be simple and straightforward, allowing access to only certain modes and functions that may be needed for a certain scenario.
Since the client module will potentially be used by (young) students, and some students tend to mess around with school computers, security needs to be added. Most importantly the client needs to have the ability to be locked down so the user cannot change any settings such as the server address. Measures need to be taken to prevent tampering with both code and settings, and even WW itself on the client side, to prevent the student from doing anything but focus on the task at hand.
I plan to support multiple transport protocols to support everything from closed private networks to cross-continent internet connections. This brings with it a way to control the update rate of the data to adapt to the used transport. Planned transports are, at least, jabber and TCP/UDP. Each transport will also come with a set of rules to effectively transfer data since most protocols come with a set of restrictions, such as character usage or message length.
A setup of the system will always consist of a host and one or more clients, along with one or more helper modules to manage traffic. Certain protocols can use the host as a server, while others like jabber require a separate server by default. For some transports it might also be useful to have a (protocol specific) relay module in case a direct connection cannot be established, for example because of NAT. Transports with servers, such as jabber, generally don't need a separate relay server since the server itself will act as one. Of course, considering ease of use and setup time, using a relay server is not recommended unless necessary.
After everything has been setup and connected a teacher can choose a mode which will dictate how clients behave. By default a 'joint goto' mode will be active, meaning all clients will go to wherever the host goes. The teacher can then decide to switch to a 'free roam' mode to have all clients move individually. An extension of this mode is the 'find the spot' mode where clients can move around freely but are supposed to move to a specific spot on the planet. This mode will use feedback to let the teacher know which students have completed the objective and which haven't. Of course many more modes can be implemented, such as giving control to a student or having students complete objectives in teams.
The next step after sharing views would be sharing layers. A common layer contains icons, which are rather easy to transfer since they usually only consist of an image and location so they can be easily serialized into xml and transferred, even if the layer was generated by a plugin. Both student and teacher can also be allowed to create and share icons on-the-fly to easily identify interesting locations. Image layers can also very easily be shared interactively with clients since these generally only consist of xml data. This can be taken a step further by allowing participants to directly draw onto the globe, though this would usually be limited to teachers since it is very easy to generate 'spam' this way. Unfortunately not everything can be directly shared, mainly plugin-generated content will be hard to synchronize, but as a compromise the plugins themselves can be transferred and loaded on-demand. In fact a normal setup will usually only allow the teacher to load plugins (both locally and remotely) to prevent distractions.
Finally some documentation will be needed for administrators, teachers and students. The administrator documentation will have setup instructions for all modules as well as security considerations and tips to help determine the appropriate transport. The teacher docs will consist of a full guide on how to teach using the system as well as a quick reference guide for use during lessons. The student docs will be one or two pages describing general procedures and functions of the client module enforced by pictures to make it easy to distribute the document on paper before starting a lesson.
==== Schedule ====
May 23:
- Work commences
End of May:
- Setup development infrastructure (SVN, wiki, blog)
- Design program architecture/structure and communication protocol
- Begin coding
First half of June:
- Coding client and host modules and a transport
- Start coding security
- Create placeholder graphics
Second half of June:
- Coding additional sharing features
- Bug testing (partially done by other users) and fixing bugs
- Writing comments and (inline) documentation
June 26:
- Mid-program evaluations
July:
- Code additional transports and corresponding servers and/or relay modules
- Code remaining interaction modes and features
- More commenting and documenting
- Replace placeholder graphics with better ones
August:
- Final testing (bugs + load) and fixing found problems
- Create final distributable package
August 21:
- Project deadline
==== Bio ====
I have some early experience in programming UnrealScript, the programming language for UnrealEngine-based games. I never really created anything 'big' with it, but it was fun to change a few things around and see what would happen. After that I started programming in C# around when the first beta of the .net framework was released. So far I've made many small .net applications, of which lots never even left my computer.
I came into contact with World Wind when it went public into the Open Source world, and I was the first non-NASA developer to add to WW's code. I was however never very enthusiastic until the plugin interface came along. Since then however I've made many plugins and helper programs, though most are small and simple, since plugins usually only fulfill one single task.
I recently however worked on a rather large plugin called KMLImporter (http://shrinkster.com/emz) which has taught me about plugin security and working on larger projects. I have also developed a set of programs called WWSCR that allow you to automatically control the views of one or more computers running World Wind as a screensaver. These programs were never used much since they focused on transferring views only and did not target a specific audience.
