Jeff, with all of his experience with Scratch, has come up with a great idea for the further development of the Sugar interface.
Scratch is a programming and animation suite directed at younger children that teaches the basics of programming with a friendly, colorful interface. One of the most important features of this software is its "Share" utility, which allows the user to upload their project to the Scratch website for all to see and comment on, promoting shared learning and communication. When the Scratch file is received on the website, it is then recompiled into a Java applet and is thus usable from the browser.
In addition to the above features, users are then able to take their exploration one step further: by downloading the files for themselves. This allows them to read each other's code and remix each other's projects. This website/client relationship is really the foremost element of the Scratch project, as it provides the users with an integrated, positive environment in which they can share and present. Further, its accessibility over the web allows for what could easily become trans-national, or even global communication, crossing geographical and linguistic barriers with ease.
Jeff's idea is to implement this kind of technology by embedding it in the Sugar interface. Many of Sugar's most prominent activities lend themselves toward sharing and collaboration between children. As such, giving them an integrated collaboration system comparable to Scratch's would only work to expand and support the project as a whole.
Since Sugar 0.84, the user has been asked directly at the end of each session to name and describe each activity they've opened, in order to better organize and save their explorations in the Journal. In an IRC chat with Jeff, it was suggested that the "Name this entry" dialogue box be put to a higher use in setting metadata for works that would be published online, making it even easier for kids to share.
OLPC needs a website comparable to that of Scratch with which to host XO users' projects. This would be the fastest, most reliable method of connecting users and promoting collaboration. Of course, the scope of the OLPC web resource would need to be much greater than Scratch's. Scratch's website only needs to accept and display Scratch files (.sb's), whereas the Sugar site would be able to accept Sugar media of all sorts: "Write" activities, "Paint" drawings, "Physics" projects, and presumably games as well. These different types of media would first be categorized by filetype and then hopefully index by content or topic (Music, History, Science, etc.).
Further, user interaction would have to be both manageable as well as open. For example, students would be able to join Class groups, based on their actual Schools, and Classes. They would thus be able to receive updates about the activities of their group members and collaborate easily as a class. This would be a sort of "Priority" grouping, as the entirety of the user's activities would not be limited to sharing with just their class. In addition to this, users would be able to create groups, invite users, and engage in much of the collaborative networking currently available online.
The homepage of this website could show featured projects of various types, as well as category links, which would lead to content based on filetype (documents, pictures, etc.) or content. This content could of course be searchable, in order to connect the most users to the most relevant content.
The end result of this project would be a web interface, deeply intertwined with Sugar and its activities, that would connect an entire generation and unite them in the spirit of learning.
Thursday, July 23, 2009
Wednesday, July 15, 2009
July 15, 2009 - XS Setup Cont'd.
In order to get the XS to qualify its hostname, its hostname had to be mapped in both /etc/resolv.conf and /etc/hosts. I implanted the following code into /etc/resolv.conf:
search ict.gctaa.net
nameserver 158.59.254.12
nameserver 158.59.255.11
("nameserver" refers to DNS servers, which feed the server web pages. The "search" command above is for the domain suffix, which I believe we needed for network routing.)
The following went into /etc/hosts:
192.168.209.254 schoolserver.ict.gctaa.net
With the hostname now resolved, ejabberd was finally able to run.
Next, we had to setup an administrative account on the Jabber server, via the following command ("admin" is the new username and "password" is the new password):
ejabberdctl --node ejabberd@schoolserver register user admin schoolserver.ict.gctaa.net password
The command given on the OLPC Wiki page didn't have the "--node ejabberd@schoolserver" bit. When I tried it, the command failed. Apparently, the node has to be specified (at least as long as it isn't localhost).
Next we had to grant administrative privileges to our new account (manually). This was done with the following line implanted into ejabberd's config files, /etc/ejabberd/ejabberd.cfg and /etc/ejabberd/ejabberd-xs.cfg:
{acl, admin, {user, "admin", "schoolserver.ict.gctaa.net"}}.
(Don't forget the period at the end of the line.)
For some reason, we couldn't connect to the web interface, albeit that we had an account, and a connection to the XS. Turns out that the hostname also had to be set in ejabberd's config files:
{hosts, ["schoolserver.ict.gctaa.net"]}.
The above line had to replace a similar line that had "schoolserver.random.xs.org" in place of our new hostname. (Again, don't forget the period at the end of the line.)
After all that, we were finally able to connect to the Jabber server via the administrative web interface at the following address (on port 5280, with the administrator's username behind it):
http://schoolserver.ict.gctaa.net:5280/admin/
This opened the (almost useless) Jabber web interface, from which we were able to create a Shared Roster Group with the following attributes:
Name: Online
Members: @online@
Displayed Groups: Online
The above attributes cause the server to show all connected users in a normal XMPP (instant messaging) client, such as Pidgin.
Pidgin really fits the bill perfectly here, since any user (like a teacher using the administrator account) can log on to the XS from their desktop and will immediately be able to see all of the students that have logged on. Furthermore, being that XMPP is a messaging protocol, the teacher can select any student from their "Buddy List" and send them a message over the server. This causes a Chat Activity icon to appear on the student's XO and thus enables private communication. It can then be postulated that the teacher could create a chatroom from Pidgin and invite all of the students to join, thus creating a unified chatroom from the teacher's desktop. The students can communicate and collaborate to their hearts' content, and afterwards a transcript of the chatroom can be saved on the teacher's computer for later reference.
A wee bit of troubleshooting:
Some of the XOs were initially unable to connect to the Jabber server. Connecting to the server requires two elements:
1) The XO must be connected to the same wireless network as the XS (in our case, the "sugar" AP at 192.168.209.1).
2) The XO's collaboration (Jabber) server must be set to the XS's hostname or IP address (schoolserver.ict.gctaa.net, or 192.168.209.254).
The first element can be achieved from the "Neighborhood" window on the XO, by clicking on the correct access point. The second element can be achieved in one of two ways:
From the Favorites (Home) view of the XO, right-click on the stick figure (I don't know a better word for it), and select "Control Panel". Click on "Network" and set the Collaboration Server to the XS' hostname.
OR
From the Terminal Activity, type
sugar-control-panel -s jabber YOUR.XS.HOST.NAME
(But I prefer the GUI tool.)
After ALL that, the majority of the XOs (with one faulty-hardware exception) were visible from a Pidgin client, and were able to receive and send messages to/from the admin account. Success!
search ict.gctaa.net
nameserver 158.59.254.12
nameserver 158.59.255.11
("nameserver" refers to DNS servers, which feed the server web pages. The "search" command above is for the domain suffix, which I believe we needed for network routing.)
The following went into /etc/hosts:
192.168.209.254 schoolserver.ict.gctaa.net
With the hostname now resolved, ejabberd was finally able to run.
Next, we had to setup an administrative account on the Jabber server, via the following command ("admin" is the new username and "password" is the new password):
ejabberdctl --node ejabberd@schoolserver register user admin schoolserver.ict.gctaa.net password
The command given on the OLPC Wiki page didn't have the "--node ejabberd@schoolserver" bit. When I tried it, the command failed. Apparently, the node has to be specified (at least as long as it isn't localhost).
Next we had to grant administrative privileges to our new account (manually). This was done with the following line implanted into ejabberd's config files, /etc/ejabberd/ejabberd.cfg and /etc/ejabberd/ejabberd-xs.cfg:
{acl, admin, {user, "admin", "schoolserver.ict.gctaa.net"}}.
(Don't forget the period at the end of the line.)
For some reason, we couldn't connect to the web interface, albeit that we had an account, and a connection to the XS. Turns out that the hostname also had to be set in ejabberd's config files:
{hosts, ["schoolserver.ict.gctaa.net"]}.
The above line had to replace a similar line that had "schoolserver.random.xs.org" in place of our new hostname. (Again, don't forget the period at the end of the line.)
After all that, we were finally able to connect to the Jabber server via the administrative web interface at the following address (on port 5280, with the administrator's username behind it):
http://schoolserver.ict.gctaa.net:5280/admin/
This opened the (almost useless) Jabber web interface, from which we were able to create a Shared Roster Group with the following attributes:
Name: Online
Members: @online@
Displayed Groups: Online
The above attributes cause the server to show all connected users in a normal XMPP (instant messaging) client, such as Pidgin.
Pidgin really fits the bill perfectly here, since any user (like a teacher using the administrator account) can log on to the XS from their desktop and will immediately be able to see all of the students that have logged on. Furthermore, being that XMPP is a messaging protocol, the teacher can select any student from their "Buddy List" and send them a message over the server. This causes a Chat Activity icon to appear on the student's XO and thus enables private communication. It can then be postulated that the teacher could create a chatroom from Pidgin and invite all of the students to join, thus creating a unified chatroom from the teacher's desktop. The students can communicate and collaborate to their hearts' content, and afterwards a transcript of the chatroom can be saved on the teacher's computer for later reference.
A wee bit of troubleshooting:
Some of the XOs were initially unable to connect to the Jabber server. Connecting to the server requires two elements:
1) The XO must be connected to the same wireless network as the XS (in our case, the "sugar" AP at 192.168.209.1).
2) The XO's collaboration (Jabber) server must be set to the XS's hostname or IP address (schoolserver.ict.gctaa.net, or 192.168.209.254).
The first element can be achieved from the "Neighborhood" window on the XO, by clicking on the correct access point. The second element can be achieved in one of two ways:
From the Favorites (Home) view of the XO, right-click on the stick figure (I don't know a better word for it), and select "Control Panel". Click on "Network" and set the Collaboration Server to the XS' hostname.
OR
From the Terminal Activity, type
sugar-control-panel -s jabber YOUR.XS.HOST.NAME
(But I prefer the GUI tool.)
After ALL that, the majority of the XOs (with one faulty-hardware exception) were visible from a Pidgin client, and were able to receive and send messages to/from the admin account. Success!
Tuesday, July 7, 2009
July 7, 2009 - XO School Server
Today we began work on the XO School Server (XS) which Jeff needs for his students to be able to collaborate on projects. The server runs on Fedora 9 and is available as an integrated OS/XO script ISO image on the OLPC wiki.
The first thing we did was install the server (after much tampering with the box's BIOS). I named it schoolserver.ict.gctaa.net and gave it a static IP address by writing a new network script (ifcfg-eth0-local) and by editing /etc/resolv.conf.
The static IP address was set with the following code in /etc/sysconfig/network-scripts/ifcfg-eth0-local:
IPADDR=192.168.209.254
NETMASK=255.255.255.0
NETWORK=192.168.209.0
BROADCAST=192.168.208.255
GATEWAY=192.168.209.1
For the sake of later convenience, I commented out the original contents of resolv.conf and simply appended the new domain and (school) DNS servers beneath:
search ict.gctaa.net
nameserver 158.59.255.11
nameserver 158.59.254.12
Being that Jabber is going to be one of the main applications of this server, I set the ejabberd daemon to automatically start at boot:
chkconfig --level 345 ejabberd on
When trying to check whether Jabber was actually working or not after applying all these changes to the server, I received an error that I interpreted to mean that Jabber couldn't qualify its new hostname, which I will look into shortly.
Otherwise, everything went very well, and I expect great things for tomorrow.
The first thing we did was install the server (after much tampering with the box's BIOS). I named it schoolserver.ict.gctaa.net and gave it a static IP address by writing a new network script (ifcfg-eth0-local) and by editing /etc/resolv.conf.
The static IP address was set with the following code in /etc/sysconfig/network-scripts/ifcfg-eth0-local:
IPADDR=192.168.209.254
NETMASK=255.255.255.0
NETWORK=192.168.209.0
BROADCAST=192.168.208.255
GATEWAY=192.168.209.1
For the sake of later convenience, I commented out the original contents of resolv.conf and simply appended the new domain and (school) DNS servers beneath:
search ict.gctaa.net
nameserver 158.59.255.11
nameserver 158.59.254.12
Being that Jabber is going to be one of the main applications of this server, I set the ejabberd daemon to automatically start at boot:
chkconfig --level 345 ejabberd on
When trying to check whether Jabber was actually working or not after applying all these changes to the server, I received an error that I interpreted to mean that Jabber couldn't qualify its new hostname, which I will look into shortly.
Otherwise, everything went very well, and I expect great things for tomorrow.
Subscribe to:
Posts (Atom)
