Re: [Sugar-devel] Collaboration support for sugar web activities
Collaboration means exchanging data between activities. It's the easy part because we could found lot of technologies that could do that: webRTC, web sockets or any higher layer API on top of it (like the nice TogetherJS API). BTW today collaboration in Sugar means also: - include a button share in the toolbar of the activity, - see shared activities in the network view near the buddy icons, - join a shared activities in the network view so Sugar could launch it in the shared context, - send invitation that Sugar will put in the border of the invited users. None of this features will come easily if we don't reuse Telepathy in Sugar web collaboration because all of these features are handled by Sugar core. It's what I called degraded collaboration experience: Sugar web activities will have to implement invitation outside Sugar core. Because, by definition, Sugarizer can't use Telepathy, it's a place where I hope to reproduce the full experience on top of the collaboration API we'll decide to choose. Lionel. 2014/1/11 Daniel Narvaez dwnarv...@gmail.com On 11 January 2014 12:19, Lionel Laské lio...@olpc-france.org wrote: 1) Sugar Web collaboration should be different than Sugar Collaboration. I think that trying to join both will expand complexity. Plus I don't see any use case where a Sugar Web Activity need to communicate with a Sugar Python Activity. 2) Of course if Sugar Web collaboration is different from Sugar Python Collaboration, it ask the question how to handle network view, activity invitation, join an activity, ... So invitation has probably to be handle into each web activity and we'll have a degraded collaboration experience - except in Sugarizer (see below). Not quite understanding this. Are you saying that when running inside Sugar web activities will provide a degraded collaboration experience? Why? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Minutes of #fedora-qa meeting future of soas spin and sugar-desktop in fedora
On Mon, Jan 6, 2014 at 5:49 PM, Thomas Gilliard satelli...@gmail.com wrote: Minutes of #fedora-qa meeting: Meeting ended Mon Jan 6 17:05:52 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.log.html Summary: Fedora is in the process of setting up a split into 3 distros: ( fedora.next) #fedora-base #fedora-server #fedora-workstation pushing to a gnome3 (workstation for administrators) There is a push to drop the DVD and only do lives. I am worried that the soas spin and sugar-desktop may get lost in the shuffle. We need to participate on #fedora-qa and lobby for our fedora future. While we should actually be actively participating in Fedora QA anyway because we derive a lot of value from the work Fedora QA does the point you make is completely incorrect and invalid. There is no threat to sugar from being dropped, in fact the only threat of it being dropped is the Sugar communities lack of general involvement other than a few people. Thomas please get your facts remotely close to being correct before posting something that is completely false and misleading. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Physics-13
Activity Homepage: http://activities.sugarlabs.org/addon/4193 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28875/physics-13.xo Release notes: 13 ENHANCEMENTS: * Added palettes to set density, bouciness, and friction (w/Sai Vineet) * Added palette to set motor speed, rotation (w/Sai Vineet) * Added chain tool (w/Sai Vineet) BUG FIX: * Updated Box2d version to eliminate some memory leaks (Sai Vineet) 12 ENHANCEMENTS: * Added option to joints to set collideConnected = False * Added clear_all (Sai Vineet) * Added tracking (Sai Vineet) * Added tracing (Sai Vineet) * Added erase traces (Sai Vineet) * Added save/restore of pens and traces (Sai Vineet) BUG FIXES: * Removed cjson dependency for elements * pep8 cleanup (Sai Vineet) Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Server-devel] The quest for data
Just to add my $.02, I agree with Walter and Claudia's approach in this paper. Making the specifics of learning visible to teachers and students, and doing the development from this perspective, I think is the best way to go. Thanks. Gerald On Sun, Jan 12, 2014 at 9:33 AM, Walter Bender walter.ben...@gmail.comwrote: On Fri, Jan 10, 2014 at 3:37 PM, Sameer Verma sve...@sfsu.edu wrote: On Fri, Jan 10, 2014 at 3:26 AM, Martin Dluhos mar...@gnu.org wrote: On 7.1.2014 01:49, Sameer Verma wrote: On Mon, Jan 6, 2014 at 12:28 AM, Martin Dluhos mar...@gnu.org wrote: For visualization, I have explored using LibreOffice and SOFA, but neither of those were flexible to allow for customization of the output beyond some a few rudimentary options, so I started looking at various Javascript libraries, which are much more powerful. Currently, I am experimenting with Google Charts, which I found the easiest to get started with. If I run into limitations with Google Charts in the future, others on my list are InfoVIS Toolkit (http://philogb.github.io/jit) and HighCharts (http://highcharts.com). Then, there is also D3.js, but that's a bigger animal. Keep in mind that if you want to visualize at the school's local XS[CE] you may have to rely on a local js method instead of an online library. Yes, that's a very good point. Originally, I was only thinking about collecting and visualizing the information centrally, but there is no reason why it couldn't be viewed by teachers and school administrators on the schoolserver itself. Thanks for the warning. In fact, my guess would be that what the teachers and principal want to see at the school will be different from what OLE Nepal and the government would want to see, with interesting overlaps. You left out one important constituent: the learner. Ultimately we are responsible for making learning visible to the learner. Claudia and I touched on this topic in the attached paper. Just to place all my cards on the table, as much as I hate to suggest we head down this route, I think we really need to instrument activities themselves (and build analyses of activity output) if we want to provide meaningful statistics about learning. We've done some of this with Turtle Blocks, even capturing the mistakes the learner makes along the way. We are lacking in decent visualizations of these data, however. Meanwhile, I remain convinced that the portfolio is our best tool. regards. -walter cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Minutes of #fedora-qa meeting future of soas spin and sugar-desktop in fedora
On Sunday, 12 January 2014, Peter Robinson wrote: On Mon, Jan 6, 2014 at 5:49 PM, Thomas Gilliard satelli...@gmail.comjavascript:; wrote: Minutes of #fedora-qa meeting: Meeting ended Mon Jan 6 17:05:52 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . Minutes: http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.html Minutes (text): http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.txt Log: http://meetbot.fedoraproject.org/fedora-meeting/2014-01-06/fedora-qa.2014-01-06-16.00.log.html Summary: Fedora is in the process of setting up a split into 3 distros: ( fedora.next) #fedora-base #fedora-server #fedora-workstation pushing to a gnome3 (workstation for administrators) There is a push to drop the DVD and only do lives. I am worried that the soas spin and sugar-desktop may get lost in the shuffle. We need to participate on #fedora-qa and lobby for our fedora future. While we should actually be actively participating in Fedora QA anyway because we derive a lot of value from the work Fedora QA does the point you make is completely incorrect and invalid. There is no threat to sugar from being dropped, in fact the only threat of it being dropped is the Sugar communities lack of general involvement other than a few people. Thomas please get your facts remotely close to being correct before posting something that is completely false and misleading. From the little I've seen this seems actually something could favor Sugar rather than hurting. The Fedora rings talk was very interesting https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
It might not come that easily but I think we need to support non-degraded collaboration between web activities inside Sugar. We don't need to interact with telepathy to do that, just with the UI layer. Telepathy and a new API can co-exist pretty easily. On 12 January 2014 11:20, Lionel Laské lio...@olpc-france.org wrote: Collaboration means exchanging data between activities. It's the easy part because we could found lot of technologies that could do that: webRTC, web sockets or any higher layer API on top of it (like the nice TogetherJS API). BTW today collaboration in Sugar means also: - include a button share in the toolbar of the activity, - see shared activities in the network view near the buddy icons, - join a shared activities in the network view so Sugar could launch it in the shared context, - send invitation that Sugar will put in the border of the invited users. None of this features will come easily if we don't reuse Telepathy in Sugar web collaboration because all of these features are handled by Sugar core. It's what I called degraded collaboration experience: Sugar web activities will have to implement invitation outside Sugar core. Because, by definition, Sugarizer can't use Telepathy, it's a place where I hope to reproduce the full experience on top of the collaboration API we'll decide to choose. Lionel. 2014/1/11 Daniel Narvaez dwnarv...@gmail.com On 11 January 2014 12:19, Lionel Laské lio...@olpc-france.org wrote: 1) Sugar Web collaboration should be different than Sugar Collaboration. I think that trying to join both will expand complexity. Plus I don't see any use case where a Sugar Web Activity need to communicate with a Sugar Python Activity. 2) Of course if Sugar Web collaboration is different from Sugar Python Collaboration, it ask the question how to handle network view, activity invitation, join an activity, ... So invitation has probably to be handle into each web activity and we'll have a degraded collaboration experience - except in Sugarizer (see below). Not quite understanding this. Are you saying that when running inside Sugar web activities will provide a degraded collaboration experience? Why? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Minutes of #fedora-qa meeting future of soas spin and sugar-desktop in fedora
There is a push to drop the DVD and only do lives. I am worried that the soas spin and sugar-desktop may get lost in the shuffle. We need to participate on #fedora-qa and lobby for our fedora future. While we should actually be actively participating in Fedora QA anyway because we derive a lot of value from the work Fedora QA does the point you make is completely incorrect and invalid. There is no threat to sugar from being dropped, in fact the only threat of it being dropped is the Sugar communities lack of general involvement other than a few people. Thomas please get your facts remotely close to being correct before posting something that is completely false and misleading. From the little I've seen this seems actually something could favor Sugar rather than hurting. The Fedora rings talk was very interesting https://lists.fedoraproject.org/pipermail/devel/2013-July/186323.html We need to keep an eye on it but in general I agree that it's primarily a positive move for Sugar on Fedora whether it be for general development, use of sugar on Fedora, XOs or SoaS. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
About the telepathy part to send only the invites and establish the connection: I can't seem to be able to complete the invitation accepted process. Sometimes it works, sometimes not (mostly not). For normal sugar activities it's the same (with the exception that with them it mostly works, at least I think it works). Exchanging the TogetherJS ID is not a problem. The invited user can't seem to connect to the telepathy channel properly. As you noted above, it's a protocol mess. If telepathy is completely dropped for web activities, then a question arises: how to send the invite with the unique ID? Also, I still don't like using 1 server and having everything else depend on that 1 server. The server would most likely have to process a lot of traffic. Would it be possible to use a peer to peer connection with web sockets? Browsers don't support this, with reason. But if sugar's core is used, it should be possible. Emil Dudev On Sun, Jan 12, 2014 at 7:01 PM, Daniel Narvaez dwnarv...@gmail.com wrote: It might not come that easily but I think we need to support non-degraded collaboration between web activities inside Sugar. We don't need to interact with telepathy to do that, just with the UI layer. Telepathy and a new API can co-exist pretty easily. On 12 January 2014 11:20, Lionel Laské lio...@olpc-france.org wrote: Collaboration means exchanging data between activities. It's the easy part because we could found lot of technologies that could do that: webRTC, web sockets or any higher layer API on top of it (like the nice TogetherJS API). BTW today collaboration in Sugar means also: - include a button share in the toolbar of the activity, - see shared activities in the network view near the buddy icons, - join a shared activities in the network view so Sugar could launch it in the shared context, - send invitation that Sugar will put in the border of the invited users. None of this features will come easily if we don't reuse Telepathy in Sugar web collaboration because all of these features are handled by Sugar core. It's what I called degraded collaboration experience: Sugar web activities will have to implement invitation outside Sugar core. Because, by definition, Sugarizer can't use Telepathy, it's a place where I hope to reproduce the full experience on top of the collaboration API we'll decide to choose. Lionel. 2014/1/11 Daniel Narvaez dwnarv...@gmail.com On 11 January 2014 12:19, Lionel Laské lio...@olpc-france.org wrote: 1) Sugar Web collaboration should be different than Sugar Collaboration. I think that trying to join both will expand complexity. Plus I don't see any use case where a Sugar Web Activity need to communicate with a Sugar Python Activity. 2) Of course if Sugar Web collaboration is different from Sugar Python Collaboration, it ask the question how to handle network view, activity invitation, join an activity, ... So invitation has probably to be handle into each web activity and we'll have a degraded collaboration experience - except in Sugarizer (see below). Not quite understanding this. Are you saying that when running inside Sugar web activities will provide a degraded collaboration experience? Why? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
On 12 January 2014 19:01, Emil Dudev emildu...@gmail.com wrote: About the telepathy part to send only the invites and establish the connection: I can't seem to be able to complete the invitation accepted process. Sometimes it works, sometimes not (mostly not). For normal sugar activities it's the same (with the exception that with them it mostly works, at least I think it works). Exchanging the TogetherJS ID is not a problem. The invited user can't seem to connect to the telepathy channel properly. As you noted above, it's a protocol mess. If telepathy is completely dropped for web activities, then a question arises: how to send the invite with the unique ID? I don't know the details of the current invitation protocol. I suppose you could register a private activity with the server and then send a token to the invitee. Making this up as an example, not really well thought :) Also, I still don't like using 1 server and having everything else depend on that 1 server. The server would most likely have to process a lot of traffic. Would it be possible to use a peer to peer connection with web sockets? Browsers don't support this, with reason. But if sugar's core is used, it should be possible. Did you investigate WebRTC? If nothing else I suspect it would allow to exchange data between peers. I'm not sure if it provides any facility that we could use to share presence information, i.e. a shared buddies+activiities list. That's the really hard problem to solve if you want fully p2p communication. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Collaboration support for sugar web activities
Nice. It's why I think we need to separate the data exchange part of the API to the network handling (invitation, ...) part. Suraj and I worked on a first functional overview of what the presence API mean [1]. We hope to start a first implementation of a prototype of both the backend and the front end of this functional API using Web Sockets. Regarding webRTC peer to peer is theoretically possible but, in practice it need a least a signaling server. The only true peer-to-peer webRTC implementation we've found is from Chris Ball (an old OLPC guy !) [2] but it need to use a specific Firefox version and don't work on Chrome. Lionel. [1] https://docs.google.com/document/d/1FZRv0gSV--5Y4dvV9C9dk9K-LT7kEQEwQmX_xVX9H-s [2] http://blog.printf.net/articles/2013/05/17/webrtc-without-a-signaling-server/ 2014/1/12 Daniel Narvaez dwnarv...@gmail.com It might not come that easily but I think we need to support non-degraded collaboration between web activities inside Sugar. We don't need to interact with telepathy to do that, just with the UI layer. Telepathy and a new API can co-exist pretty easily. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The quest for data
On Sun, Jan 12, 2014 at 6:33 AM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jan 10, 2014 at 3:37 PM, Sameer Verma sve...@sfsu.edu wrote: On Fri, Jan 10, 2014 at 3:26 AM, Martin Dluhos mar...@gnu.org wrote: On 7.1.2014 01:49, Sameer Verma wrote: On Mon, Jan 6, 2014 at 12:28 AM, Martin Dluhos mar...@gnu.org wrote: For visualization, I have explored using LibreOffice and SOFA, but neither of those were flexible to allow for customization of the output beyond some a few rudimentary options, so I started looking at various Javascript libraries, which are much more powerful. Currently, I am experimenting with Google Charts, which I found the easiest to get started with. If I run into limitations with Google Charts in the future, others on my list are InfoVIS Toolkit (http://philogb.github.io/jit) and HighCharts (http://highcharts.com). Then, there is also D3.js, but that's a bigger animal. Keep in mind that if you want to visualize at the school's local XS[CE] you may have to rely on a local js method instead of an online library. Yes, that's a very good point. Originally, I was only thinking about collecting and visualizing the information centrally, but there is no reason why it couldn't be viewed by teachers and school administrators on the schoolserver itself. Thanks for the warning. In fact, my guess would be that what the teachers and principal want to see at the school will be different from what OLE Nepal and the government would want to see, with interesting overlaps. You left out one important constituent: the learner. Ultimately we are responsible for making learning visible to the learner. Claudia and I touched on this topic in the attached paper. Thanks for the paper. While we did point out to Portfolio and Analyze Journal activities in our session at OLPC SF Summit in 2013, I didn't include it in the scope of the blog post. I'll go back and update it when I get a chance. Just to place all my cards on the table, as much as I hate to suggest we head down this route, I think we really need to instrument activities themselves (and build analyses of activity output) if we want to provide meaningful statistics about learning. We've done some of this with Turtle Blocks, even capturing the mistakes the learner makes along the way. We are lacking in decent visualizations of these data, however. I haven't had a chance to read the paper in depth (which I intend to do this afternoon), but how much of this approach would be shareable across activities? Or would the depth of analysis be on a per activity basis? If the latter, then I'd imagine it would be simpler for something like the Moon activity than the TurtleBlocks activity. Meanwhile, I remain convinced that the portfolio is our best tool. I think the approaches differ in scope and purpose. In the RFPs I've been involved in, the funding agencies and/or the decision makers either request or outright require dashboard style features to report frequency of use, time of day, and in some cases even GPS-based location in addition to theft-deterrence, remote provisioning, etc. The same goes for going back to an agency to get renewed funding or to raise funds for a new site expansion. In a way, the scope of the learner-teacher bubble is significantly different from that of the principal-minister of edu. One is driven by learning and pedagogy, while the other is driven by administration. Accordingly, the reports they want to see are also different. While the measurements from the Activity may be distilled into coarser indicators for the MoE, I think it is important to keep the entire scope in mind. I am mindful of the garbage in, garbage out problem. In building this pipeline (which is where my skills are) I hope that the data that goes into this pipeline is representative of what is measured at the child's end. I am glad that you and Claudia are the experts on that end :-) cheers, Sameer regards. -walter cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The quest for data
On Sun, Jan 12, 2014 at 3:32 PM, Sameer Verma sve...@sfsu.edu wrote: On Sun, Jan 12, 2014 at 6:33 AM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jan 10, 2014 at 3:37 PM, Sameer Verma sve...@sfsu.edu wrote: On Fri, Jan 10, 2014 at 3:26 AM, Martin Dluhos mar...@gnu.org wrote: On 7.1.2014 01:49, Sameer Verma wrote: On Mon, Jan 6, 2014 at 12:28 AM, Martin Dluhos mar...@gnu.org wrote: For visualization, I have explored using LibreOffice and SOFA, but neither of those were flexible to allow for customization of the output beyond some a few rudimentary options, so I started looking at various Javascript libraries, which are much more powerful. Currently, I am experimenting with Google Charts, which I found the easiest to get started with. If I run into limitations with Google Charts in the future, others on my list are InfoVIS Toolkit (http://philogb.github.io/jit) and HighCharts (http://highcharts.com). Then, there is also D3.js, but that's a bigger animal. Keep in mind that if you want to visualize at the school's local XS[CE] you may have to rely on a local js method instead of an online library. Yes, that's a very good point. Originally, I was only thinking about collecting and visualizing the information centrally, but there is no reason why it couldn't be viewed by teachers and school administrators on the schoolserver itself. Thanks for the warning. In fact, my guess would be that what the teachers and principal want to see at the school will be different from what OLE Nepal and the government would want to see, with interesting overlaps. You left out one important constituent: the learner. Ultimately we are responsible for making learning visible to the learner. Claudia and I touched on this topic in the attached paper. Thanks for the paper. While we did point out to Portfolio and Analyze Journal activities in our session at OLPC SF Summit in 2013, I didn't include it in the scope of the blog post. I'll go back and update it when I get a chance. Just to place all my cards on the table, as much as I hate to suggest we head down this route, I think we really need to instrument activities themselves (and build analyses of activity output) if we want to provide meaningful statistics about learning. We've done some of this with Turtle Blocks, even capturing the mistakes the learner makes along the way. We are lacking in decent visualizations of these data, however. I haven't had a chance to read the paper in depth (which I intend to do this afternoon), but how much of this approach would be shareable across activities? Or would the depth of analysis be on a per activity basis? If the latter, then I'd imagine it would be simpler for something like the Moon activity than the TurtleBlocks activity. Meanwhile, I remain convinced that the portfolio is our best tool. I think the approaches differ in scope and purpose. In the RFPs I've been involved in, the funding agencies and/or the decision makers either request or outright require dashboard style features to report frequency of use, time of day, and in some cases even GPS-based location in addition to theft-deterrence, remote provisioning, etc. The same goes for going back to an agency to get renewed funding or to raise funds for a new site expansion. In a way, the scope of the learner-teacher bubble is significantly different from that of the principal-minister of edu. One is driven by learning and pedagogy, while the other is driven by administration. Accordingly, the reports they want to see are also different. While the measurements from the Activity may be distilled into coarser indicators for the MoE, I think it is important to keep the entire scope in mind. Don't get me wrong: satisfying the needs of funders, administrators, etc. is important too. They have metrics that they value and we should gather those data too. My earlier post was just to suggest ultimately we need to consider the learner and how making learning visible can be of use. That theme seemed to be missing from the earlier discussion. I am mindful of the garbage in, garbage out problem. In building this pipeline (which is where my skills are) I hope that the data that goes into this pipeline is representative of what is measured at the child's end. I am glad that you and Claudia are the experts on that end :-) cheers, Sameer regards. -walter cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] The quest for data
Agreed. On Sun, Jan 12, 2014 at 6:02 PM, Walter Bender walter.ben...@gmail.comwrote: On Sun, Jan 12, 2014 at 3:32 PM, Sameer Verma sve...@sfsu.edu wrote: On Sun, Jan 12, 2014 at 6:33 AM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jan 10, 2014 at 3:37 PM, Sameer Verma sve...@sfsu.edu wrote: On Fri, Jan 10, 2014 at 3:26 AM, Martin Dluhos mar...@gnu.org wrote: On 7.1.2014 01:49, Sameer Verma wrote: On Mon, Jan 6, 2014 at 12:28 AM, Martin Dluhos mar...@gnu.org wrote: For visualization, I have explored using LibreOffice and SOFA, but neither of those were flexible to allow for customization of the output beyond some a few rudimentary options, so I started looking at various Javascript libraries, which are much more powerful. Currently, I am experimenting with Google Charts, which I found the easiest to get started with. If I run into limitations with Google Charts in the future, others on my list are InfoVIS Toolkit (http://philogb.github.io/jit) and HighCharts ( http://highcharts.com). Then, there is also D3.js, but that's a bigger animal. Keep in mind that if you want to visualize at the school's local XS[CE] you may have to rely on a local js method instead of an online library. Yes, that's a very good point. Originally, I was only thinking about collecting and visualizing the information centrally, but there is no reason why it couldn't be viewed by teachers and school administrators on the schoolserver itself. Thanks for the warning. In fact, my guess would be that what the teachers and principal want to see at the school will be different from what OLE Nepal and the government would want to see, with interesting overlaps. You left out one important constituent: the learner. Ultimately we are responsible for making learning visible to the learner. Claudia and I touched on this topic in the attached paper. Thanks for the paper. While we did point out to Portfolio and Analyze Journal activities in our session at OLPC SF Summit in 2013, I didn't include it in the scope of the blog post. I'll go back and update it when I get a chance. Just to place all my cards on the table, as much as I hate to suggest we head down this route, I think we really need to instrument activities themselves (and build analyses of activity output) if we want to provide meaningful statistics about learning. We've done some of this with Turtle Blocks, even capturing the mistakes the learner makes along the way. We are lacking in decent visualizations of these data, however. I haven't had a chance to read the paper in depth (which I intend to do this afternoon), but how much of this approach would be shareable across activities? Or would the depth of analysis be on a per activity basis? If the latter, then I'd imagine it would be simpler for something like the Moon activity than the TurtleBlocks activity. Meanwhile, I remain convinced that the portfolio is our best tool. I think the approaches differ in scope and purpose. In the RFPs I've been involved in, the funding agencies and/or the decision makers either request or outright require dashboard style features to report frequency of use, time of day, and in some cases even GPS-based location in addition to theft-deterrence, remote provisioning, etc. The same goes for going back to an agency to get renewed funding or to raise funds for a new site expansion. In a way, the scope of the learner-teacher bubble is significantly different from that of the principal-minister of edu. One is driven by learning and pedagogy, while the other is driven by administration. Accordingly, the reports they want to see are also different. While the measurements from the Activity may be distilled into coarser indicators for the MoE, I think it is important to keep the entire scope in mind. Don't get me wrong: satisfying the needs of funders, administrators, etc. is important too. They have metrics that they value and we should gather those data too. My earlier post was just to suggest ultimately we need to consider the learner and how making learning visible can be of use. That theme seemed to be missing from the earlier discussion. I am mindful of the garbage in, garbage out problem. In building this pipeline (which is where my skills are) I hope that the data that goes into this pipeline is representative of what is measured at the child's end. I am glad that you and Claudia are the experts on that end :-) cheers, Sameer regards. -walter cheers, Sameer ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel
Re: [Sugar-devel] The quest for data
On Sun, Jan 12, 2014 at 3:02 PM, Walter Bender walter.ben...@gmail.com wrote: On Sun, Jan 12, 2014 at 3:32 PM, Sameer Verma sve...@sfsu.edu wrote: On Sun, Jan 12, 2014 at 6:33 AM, Walter Bender walter.ben...@gmail.com wrote: On Fri, Jan 10, 2014 at 3:37 PM, Sameer Verma sve...@sfsu.edu wrote: On Fri, Jan 10, 2014 at 3:26 AM, Martin Dluhos mar...@gnu.org wrote: On 7.1.2014 01:49, Sameer Verma wrote: On Mon, Jan 6, 2014 at 12:28 AM, Martin Dluhos mar...@gnu.org wrote: For visualization, I have explored using LibreOffice and SOFA, but neither of those were flexible to allow for customization of the output beyond some a few rudimentary options, so I started looking at various Javascript libraries, which are much more powerful. Currently, I am experimenting with Google Charts, which I found the easiest to get started with. If I run into limitations with Google Charts in the future, others on my list are InfoVIS Toolkit (http://philogb.github.io/jit) and HighCharts (http://highcharts.com). Then, there is also D3.js, but that's a bigger animal. Keep in mind that if you want to visualize at the school's local XS[CE] you may have to rely on a local js method instead of an online library. Yes, that's a very good point. Originally, I was only thinking about collecting and visualizing the information centrally, but there is no reason why it couldn't be viewed by teachers and school administrators on the schoolserver itself. Thanks for the warning. In fact, my guess would be that what the teachers and principal want to see at the school will be different from what OLE Nepal and the government would want to see, with interesting overlaps. You left out one important constituent: the learner. Ultimately we are responsible for making learning visible to the learner. Claudia and I touched on this topic in the attached paper. Thanks for the paper. While we did point out to Portfolio and Analyze Journal activities in our session at OLPC SF Summit in 2013, I didn't include it in the scope of the blog post. I'll go back and update it when I get a chance. Just to place all my cards on the table, as much as I hate to suggest we head down this route, I think we really need to instrument activities themselves (and build analyses of activity output) if we want to provide meaningful statistics about learning. We've done some of this with Turtle Blocks, even capturing the mistakes the learner makes along the way. We are lacking in decent visualizations of these data, however. I haven't had a chance to read the paper in depth (which I intend to do this afternoon), but how much of this approach would be shareable across activities? Or would the depth of analysis be on a per activity basis? If the latter, then I'd imagine it would be simpler for something like the Moon activity than the TurtleBlocks activity. Meanwhile, I remain convinced that the portfolio is our best tool. I think the approaches differ in scope and purpose. In the RFPs I've been involved in, the funding agencies and/or the decision makers either request or outright require dashboard style features to report frequency of use, time of day, and in some cases even GPS-based location in addition to theft-deterrence, remote provisioning, etc. The same goes for going back to an agency to get renewed funding or to raise funds for a new site expansion. In a way, the scope of the learner-teacher bubble is significantly different from that of the principal-minister of edu. One is driven by learning and pedagogy, while the other is driven by administration. Accordingly, the reports they want to see are also different. While the measurements from the Activity may be distilled into coarser indicators for the MoE, I think it is important to keep the entire scope in mind. Don't get me wrong: satisfying the needs of funders, administrators, etc. is important too. They have metrics that they value and we should gather those data too. My earlier post was just to suggest ultimately we need to consider the learner and how making learning visible can be of use. That theme seemed to be missing from the earlier discussion. Agreed. In fact, down the road, if the data gathering can be sourced in one, focused manner, that would help us in the long run in supporting the goals of both the learner space and the administrator space. As an interesting aside, I see similar challenges on my campus with systems for the learner space and the admin space. The sad part is that the decision makers usually begin with the vendors, and not the users. cheers, Sameer I am mindful of the garbage in, garbage out problem. In building this pipeline (which is where my skills are) I hope that the data that goes into this pipeline is representative of what is measured at the child's end. I am glad that you and Claudia are the experts on that end :-) cheers, Sameer regards. -walter cheers, Sameer
Re: [Sugar-devel] New year, new testing image
Sorry for the long delay, I started a draft response on a tablet that I didn't pick up for some time. On 01/05/2014 08:33 PM, Matthew Ciao wrote: Hi Bernie, how are you going there? Lng time no see, hope you're doing well mate! :) So I'm still here in Cambridge MA, enjoying the freezing weather of New England. And you're enjoying the nice, mild weather of Sydney, I suppose? Can I ask to what degree you're planning to use AU images? Would it be for testing only (yourself?) or actual major deployments? I've installed the oz images on all my XOs. I've setup a mini-museum of OLPC at Google's Cambridge office. People passing by sometimes stop and play with the laptops, so I want them to see the best version of Sugar available. Sorry I couldn't find the time to test properly and file bugs. Very briefly, the AU software now includes a statistics-collection software that sends data to our servers matching the serial number of the XO against our local serial-numbers database. This means that if you're going to deploy the image on, say 100 laptops, those will then sync data to our db which results in serial numbers not matching. I am worried about the scale of this issue, which might fill our db with incoherent data so perhaps (Martin, Gonzalo?) we should think about a way to prevent any confusion in case the AU image is used somewhere else around the world. Have you thought of asking for permission to send statistics as part of first-time setup? Then I'd just answer no and be done. Moreover, it's standard industry practice to obtain explicit user consent for data collection, and if you don't do that soon or later someone might get upset. -- _ // Bernie Innocenti \X/ http://codewiz.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
