June 11th, 2009 |
June 10th Sugar collaboration testing session
Starting the session was a little chaotic, as this was the first time we've tried a group collaborative session, and there were no specific goals we had in mind. The idea was generally to see how collaboration worked in a mixed environment (0.82, 0.84, different distros, different network connections, etc)
The good news is, that for the most part, getting connected worked, and once in a collaborative session response times were quite good. This means that the underlying sharing mechanism works, it just doesn't respond very quickly. The bad news is that the server load is much worse than originally thought and expected.
From our initial experiences, it was clear that the sugar-presence framework had some huge problems in terms of visually representing who was connected, which activities were being shared, and who was sharing these activities. It was not clear where the major bottleneck was in terms of reaction and response, but suspicions lie at the ejabberd end of things. In future sessions we will have to restrict connections and individual details to the point that we can make proper measurements, and thereby find out what is going wrong, and at what point it is going wrong. Suspicions are that the jabber server in question (jabber.sugarlabs.org) didn't have gadget enabled, and was therefore broadcasting the list of all registered users continously, which would burden the server severely. The lag and server load also affected the visual clustering of users around specific activities
Though reaction times were very slow, the underlying sharing framework clearly works very well. Once users were connected, their connections were stable, and within specific activites, reaction times were fast and reliable. We were able to test a fair set of activities, some of which had better implementation of collaboration than others, and some of which didn't seem to have collaboration enabled at all.
We started off with the chat activity, which took a good 10 minutes before people started being able to connect to the initial shared session. Once connected, reaction times were pretty decent, and the frame showed all the connected users. There was a large variance between the shared buddies shown. Some users reported seeing 5 buddies, some 3, some 7, and some even saw buddies with a ??? as their handle. The screenshot below shows how it looked:
Speak was another interesting activity to share, as it allowed multiple people to join a session where the computer speaks out what's typed in the accent of the user's choosing. The choice of accent is used for the proper pronounciation in different languages normally, though there was much fun to be had speaking English words in the various accents. Below is a screen shot:
Reaction times were again very good once users had joined the activity. Buddies connected was highly variable from user to user again, and though clustering around activites did take for ever, it did eventually start to happen, as can be seen from the screenshot below:
Etoys was a surprisingly good collaborator. Once users were connected they were able to create various items, even animated and custom coded, and then send them through to the connected buddies. We just scratched the surface of this activity, and it was clear that some really interesting things are possible with collaborative etoys:
Other activities that worked quite well were Cartoon builder, connect, Maze, Colors, and Tam Tam. We were unable to get write or paint to collaborate, and are unsure as to why. Talking with the authors of these programs seems appropriate, though it has been verified that write, at least, does collaborate. Below is a screenshot of what it looked like when multiple activites were being shared:
