Re: [Sugar-devel] Deployment feedback braindump
On Wed, Aug 12, 2009 at 20:29, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/12 Albert Cahalan acaha...@gmail.com: On Wed, Aug 12, 2009 at 10:16 AM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/12 Bernie Innocenti ber...@codewiz.org: El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. It might be useless, but I don't see why it should be more risky than Javascript in web browsers, which everybody happily accepted without much thought. Is JS in PDF even allowed to make HTTP connections? JavaScript in PDF is more risky because the sandboxing isn't as mature as the one in web browsers. It should theoretically be at least as safe, but in practice it isn't. This is mostly a problem with adobe's implementation, which is an absolute train-wreck, but other implementers without browser sandboxing experience might repeat some mistakes. Anybody sane would just grab a mature engine from a browser. The recent supposed JavaScript problems in Acrobat are nothing more than heap spraying; there are at least two non-JavaScript ways to do that. The exploit was recently redone w/o any JavaScript. Note that PDF, being essentially postscript, already comes with a full programming language. That's what postscript **is**. So what's the point of JavaScript in PDFs then? Lucian, Albert and Bernie, could you please change the subject line when you want to talk about something totally unrelated to the original thread? Thanks, Tomeu How do you dubmit the form? By HTTP? Does the PDF reader tell the user when it's going to make this connection? You would submit the form by sending back the completed PDF file. It's a bit awkward, but it works. Ideally, people should be using HTML forms, those are made to be easily and seamlessly submitted. ... In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? PDF forms often look attractive. HTML forms normally look ugly. This is because PDF is a good presentation format. HTML is not. This of course depends on your browser. I think HTML forms look great, but that's because I use OS X or KDE. Printing a PDF form to fill it out the old-fashioned way is reasonable. You can even fill most of it out, print it, and then sign it or stamp it. With HTML this really isn't practical. You can do it with HTML and it would be perfectly practical if there were a format based on a HTML subset that specified printable forms. That would be moot though, since PDF is much better at printables already. In the case of math worksheets, the child really needs a way to scribble on the document. This is for handwriting practice and to allow arbitrary free-form drawing and layout. PDF can provide this, either via printing or via wrapping extra postscript code around the document. To do this in HTML you'd have to write a custom app in JavaScript, Java, or flash -- none of which is really HTML at all. You could indeed do it on PDF only, like Okular and Preview (OS X) can annotate PDFs. But you could do it with HTML JS, with the html5 canvas (JS is HTML's native programming language, equivalent to PS). The drawback to the second is, as with printing, that HTML is very general. An easily printable subset of HTML would be needed for this. I believe JavaScript in PDF to be useless bloat. PostScript should be enough for all PDF needs. If it isn't, then PDF is probably the wrong format to use. ___ 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] Deployment feedback braindump
S Page writes: On Sun, Aug 9, 2009 at 10:41 AM, Daniel Drakedsd at laptop.org wrote: adding an interactivity component that would be impossible to have when working with paper-based exercise books. And impossible with PDFs. No way. PDFs can be interactive in many ways. First of all, a PDF is pretty much just well-behaved postscript. You can embed that in more postscript. The user can thus scribble all over the document. Second, the PDF format has long had form support. It's pretty much like HTML forms, but much more attractive. I've used this several times in xpdf and/or evince, and it works very well. You get the choice of filling out the PDF form directly, or doing things the traditional way on paper. Finally, you can put JavaScript in a PDF. I'm not sure if any of the free software viewers can handle this yet. In theory you can have all sorts of animations. It's kind of like flash. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
El Wed, 12-08-2009 a las 07:22 -0400, Albert Cahalan escribió: Finally, you can put JavaScript in a PDF. I'm not sure if any of the free software viewers can handle this yet. In theory you can have all sorts of animations. It's kind of like flash. Yes, and it's kind of like SVG, too. And isn't it funny how one company monopolizes *all* these vector graphics standards that were supposed to compete with each other: PostScript, PDF, Flash and SVG. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
Adobe apparently loves vectors. JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. Forms are about as much interaction as PDF get without becoming dangerous or moot. 2009/8/12 Bernie Innocenti ber...@codewiz.org: El Wed, 12-08-2009 a las 07:22 -0400, Albert Cahalan escribió: Finally, you can put JavaScript in a PDF. I'm not sure if any of the free software viewers can handle this yet. In theory you can have all sorts of animations. It's kind of like flash. Yes, and it's kind of like SVG, too. And isn't it funny how one company monopolizes *all* these vector graphics standards that were supposed to compete with each other: PostScript, PDF, Flash and SVG. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ 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] Deployment feedback braindump
El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: Adobe apparently loves vectors. And monopolies. JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. It might be useless, but I don't see why it should be more risky than Javascript in web browsers, which everybody happily accepted without much thought. Is JS in PDF even allowed to make HTTP connections? Forms are about as much interaction as PDF get without becoming dangerous or moot. How do you dubmit the form? By HTTP? Does the PDF reader tell the user when it's going to make this connection? Knowing how proprietary software companies think, I wouldn't ever dare using Adobe Acrobat Reader. But I blindly trust Evince, Okular and all free PDF readers to do whatever it takes to protect my security and privacy regardless of what the document or the PDF standard tells them to do. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
2009/8/12 Bernie Innocenti ber...@codewiz.org: El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: Adobe apparently loves vectors. And monopolies. That too :) But really, they're obsessed with vectors. JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. It might be useless, but I don't see why it should be more risky than Javascript in web browsers, which everybody happily accepted without much thought. Is JS in PDF even allowed to make HTTP connections? JavaScript in PDF is more risky because the sandboxing isn't as mature as the one in web browsers. It should theoretically be at least as safe, but in practice it isn't. This is mostly a problem with adobe's implementation, which is an absolute train-wreck, but other implementers without browser sandboxing experience might repeat some mistakes. Forms are about as much interaction as PDF get without becoming dangerous or moot. How do you dubmit the form? By HTTP? Does the PDF reader tell the user when it's going to make this connection? You would submit the form by sending back the completed PDF file. It's a bit awkward, but it works. Ideally, people should be using HTML forms, those are made to be easily and seamlessly submitted. Knowing how proprietary software companies think, I wouldn't ever dare using Adobe Acrobat Reader. But I blindly trust Evince, Okular and all free PDF readers to do whatever it takes to protect my security and privacy regardless of what the document or the PDF standard tells them to do. In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
El Wed, 12-08-2009 a las 15:16 +0100, Lucian Branescu escribió: In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? Agreed. And, btw, as people are gradually loosing the habit of printing on paper, document formats designed to paging and static layout will slowly decline. How much have you been using OpenOffice Write lately? Or MS Word? Or even TeX? Now compare this with email, wiki and HTML. I think few people will care about PDF 10 years from now -- maybe just 5 years from now. With or without Javascript ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
On Wed, Aug 12, 2009 at 9:38 AM, Bernie Innocentiber...@codewiz.org wrote: El Wed, 12-08-2009 a las 15:16 +0100, Lucian Branescu escribió: In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? Agreed. And, btw, as people are gradually loosing the habit of printing on paper, document formats designed to paging and static layout will slowly decline. How much have you been using OpenOffice Write lately? Or MS Word? Or even TeX? Now compare this with email, wiki and HTML. I think few people will care about PDF 10 years from now -- maybe just 5 years from now. With or without Javascript ;-). i wish i was so optimistic but in some parts of the world the time frame for this change could be higher than 10 years. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ 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] Deployment feedback braindump
Hi Albert, On 12 Aug 2009, at 12:22, Albert Cahalan wrote: S Page writes: On Sun, Aug 9, 2009 at 10:41 AM, Daniel Drakedsd at laptop.org wrote: adding an interactivity component that would be impossible to have when working with paper-based exercise books. And impossible with PDFs. No way. PDFs can be interactive in many ways. Absolutely. I have a point and click graphic (maths) adventure that works fine in Read (though I'd like Read to have a single page mode for better presentation). The adventure is not complete yet, otherwise I'd upload it as example content. First of all, a PDF is pretty much just well-behaved postscript. You can embed that in more postscript. The user can thus scribble all over the document. Second, the PDF format has long had form support. It's pretty much like HTML forms, but much more attractive. I've used this several times in xpdf and/or evince, and it works very well. You get the choice of filling out the PDF form directly, or doing things the traditional way on paper. FWIW, I've not tested PDF form support in evince, but a quick google some seem to suggest it's supported. Finally, you can put JavaScript in a PDF. I'm not sure if any of the free software viewers can handle this yet. I've tested a range of JavaScript PDF examples in Read but with no luck (was hoping to use it to auto generate math quiz like questions for the adventure). So currently the best you can do in PDF seems to be to allow point and click to jump about a document in a non-linear way – still, that alone can be pretty engaging if you put your mind to it. Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
El Wed, 12-08-2009 a las 09:52 -0500, Rafael Enrique Ortiz Guerrero escribió: I think few people will care about PDF 10 years from now -- maybe just 5 years from now. With or without Javascript ;-). i wish i was so optimistic but in some parts of the world the time frame for this change could be higher than 10 years. Surely you mean rich countries where people can afford to waste paper and ink like there's no tomorrow! ;-) Jokes apart, there are intermediate technologies that just get skipped in developing countries. For examples, Nepal is jumping from analogue phones to ADSL without going through the ISDN nonsense that plagued Europe for many years. Will developing countries be lucky enough to skip MS Word and PDF too and go directly to HTML and Wiki? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
On Wed, Aug 12, 2009 at 10:16 AM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/12 Bernie Innocenti ber...@codewiz.org: El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. It might be useless, but I don't see why it should be more risky than Javascript in web browsers, which everybody happily accepted without much thought. Is JS in PDF even allowed to make HTTP connections? JavaScript in PDF is more risky because the sandboxing isn't as mature as the one in web browsers. It should theoretically be at least as safe, but in practice it isn't. This is mostly a problem with adobe's implementation, which is an absolute train-wreck, but other implementers without browser sandboxing experience might repeat some mistakes. Anybody sane would just grab a mature engine from a browser. The recent supposed JavaScript problems in Acrobat are nothing more than heap spraying; there are at least two non-JavaScript ways to do that. The exploit was recently redone w/o any JavaScript. Note that PDF, being essentially postscript, already comes with a full programming language. That's what postscript **is**. How do you dubmit the form? By HTTP? Does the PDF reader tell the user when it's going to make this connection? You would submit the form by sending back the completed PDF file. It's a bit awkward, but it works. Ideally, people should be using HTML forms, those are made to be easily and seamlessly submitted. ... In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? PDF forms often look attractive. HTML forms normally look ugly. This is because PDF is a good presentation format. HTML is not. Printing a PDF form to fill it out the old-fashioned way is reasonable. You can even fill most of it out, print it, and then sign it or stamp it. With HTML this really isn't practical. In the case of math worksheets, the child really needs a way to scribble on the document. This is for handwriting practice and to allow arbitrary free-form drawing and layout. PDF can provide this, either via printing or via wrapping extra postscript code around the document. To do this in HTML you'd have to write a custom app in JavaScript, Java, or flash -- none of which is really HTML at all. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
2009/8/12 Albert Cahalan acaha...@gmail.com: On Wed, Aug 12, 2009 at 10:16 AM, Lucian Branesculucian.brane...@gmail.com wrote: 2009/8/12 Bernie Innocenti ber...@codewiz.org: El Wed, 12-08-2009 a las 13:28 +0100, Lucian Branescu escribió: JavaScript-in-PDF is mostly a joke and a big security risk. It's not something to be relied upon. It might be useless, but I don't see why it should be more risky than Javascript in web browsers, which everybody happily accepted without much thought. Is JS in PDF even allowed to make HTTP connections? JavaScript in PDF is more risky because the sandboxing isn't as mature as the one in web browsers. It should theoretically be at least as safe, but in practice it isn't. This is mostly a problem with adobe's implementation, which is an absolute train-wreck, but other implementers without browser sandboxing experience might repeat some mistakes. Anybody sane would just grab a mature engine from a browser. The recent supposed JavaScript problems in Acrobat are nothing more than heap spraying; there are at least two non-JavaScript ways to do that. The exploit was recently redone w/o any JavaScript. Note that PDF, being essentially postscript, already comes with a full programming language. That's what postscript **is**. So what's the point of JavaScript in PDFs then? How do you dubmit the form? By HTTP? Does the PDF reader tell the user when it's going to make this connection? You would submit the form by sending back the completed PDF file. It's a bit awkward, but it works. Ideally, people should be using HTML forms, those are made to be easily and seamlessly submitted. ... In any case, PDF is a good presentation format. Why make it significantly more complex for small-to-none improvements to its main purpose? PDF forms often look attractive. HTML forms normally look ugly. This is because PDF is a good presentation format. HTML is not. This of course depends on your browser. I think HTML forms look great, but that's because I use OS X or KDE. Printing a PDF form to fill it out the old-fashioned way is reasonable. You can even fill most of it out, print it, and then sign it or stamp it. With HTML this really isn't practical. You can do it with HTML and it would be perfectly practical if there were a format based on a HTML subset that specified printable forms. That would be moot though, since PDF is much better at printables already. In the case of math worksheets, the child really needs a way to scribble on the document. This is for handwriting practice and to allow arbitrary free-form drawing and layout. PDF can provide this, either via printing or via wrapping extra postscript code around the document. To do this in HTML you'd have to write a custom app in JavaScript, Java, or flash -- none of which is really HTML at all. You could indeed do it on PDF only, like Okular and Preview (OS X) can annotate PDFs. But you could do it with HTML JS, with the html5 canvas (JS is HTML's native programming language, equivalent to PS). The drawback to the second is, as with printing, that HTML is very general. An easily printable subset of HTML would be needed for this. I believe JavaScript in PDF to be useless bloat. PostScript should be enough for all PDF needs. If it isn't, then PDF is probably the wrong format to use. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
Hi, some thoughts follow. Please keep in mind that these are just my personal opinions and that not everybody at Sugar Labs share the same idea of what SLs is or should be. On Sun, Aug 9, 2009 at 19:41, Daniel Draked...@laptop.org wrote: Hi, In response to the thread I started recently about feedback from deployments, I've been thinking a lot about specific changes/features that would be a big help for deployments. And even though it only takes 10 minutes in a classroom to see some real potential areas for improvement, actually I am finding the task of selecting a few important features/bugs/changes very difficult, and I keep coming back to various broad questions and loose ideas about Sugar's direction, goals, and SugarLabs' roles. It's great that you are sharing your thoughts on this, hope others will do the same. I'm cc'ing IAEP because this isn't really technical. So I'm afraid that I'm creating another vague, broad and fluffy discussion without any real immediate technically actionable items, but I'm going to try and put my thoughts into writing anyway. Suggestions on how to make some of these ideas actionable would be appreciated. I fully understand that nobody can really define Sugar's direction at the moment since it's all volunteer time, but hopefully we can at least get some objective things written down which will possibly feed the motivation of our valued hackers. And not only hackers, but most of Sugar Labs. Those already working on a deployment have probably little energy left to consider other deployments' needs, but all the rest of the community will be sensible to the needs of the deployments that care to communicate their needs. I'll start with roles. Sugar was born inside the belly of OLPC, and SugarLabs was born out of OLPC, effectively taking some roles of OLPC and further opening them to a community. So, in terms of roles, you might look at this as OLPC being top of the food chain (I'm referring to the times when OLPC had a substantially larger technical team), with SugarLabs below doing some specific subset of OLPC's earlier work (i.e. developing the UI), and finally deployments below being the consumers. I'm not sure I agree with that. I see Sugar Labs as a _place_ where everybody interested in improving learning with Sugar can meet, communicate and work together. As far as I know OLPC has never aimed to be a place, but rather an agent. Who may be taking responsibilities from OLPC are other agents such as OLE Nepal and individual volunteers, who happen to use Sugar Labs to work together. But actually I think it makes sense for this model to be considered differently, as follows: SugarLabs is the top of the chain, it is the upstream that generates the core user experience. One step down, OLPC as an implementation specialist (again referring to the time when the development team was more substantial) takes Sugar from upstream, makes some small customizations to fit the OLPC mission, and fills in some big gaps of OS development and support, deployability and scalability, distribution, hardware work and software to support such hardware, user support, etc. Then the deployments feed directly from OLPC, not sugarlabs. In this model, OLPC performs a huge chunk of support for sugar's users. This makes sense, we are also seeing several other organizations playing that role, but it's also true as you point below that some SLs members prefer to carry these activities as part of Sugar Labs rather than on their own organizations. I hope that this is temporary and that as their deployment activities scale up we'll see new organizations getting formed and their relationship with Sugar Labs formalized as local labs. I think this model was working reasonably well (and was improving over time) but the middle layer (OLPC) has now changed to the point where it is not performing many of the roles mentioned above, or at least not in much capacity. So who can take over this work? It is certainly very important. My gut feeling is that SugarLabs should - but that really is only because (1) a number of the OLPC people who would be involved in the above roles are no longer OLPC people, but they are still sugarlabs contributors, and (2) there are no other good candidate parties that I can think of, so I naturally have desires that the one that I do know of pick up the work ;) Don't think we should see in Sugar Labs more than there really is. It's true that we have a rather broad mission, so most of what can be done with Sugar has a place in SLs, but that broadness of mission also means that we (as a single organization) don't have enough focus to solve every issue that real users find. The broadness of our mission means that everybody who wants to use Sugar for learning has a place in SLs, but that doesn't mean that SLs itself is going to take care of everything. Rather, it means that people who want to use Sugar in their communities should get
Re: [Sugar-devel] Deployment feedback braindump
Hi Daniel., excellent post - skipping to the let's make it deployable part, I have to say I agree with all you say. - Some comments below On Sun, Aug 9, 2009 at 1:41 PM, Daniel Draked...@laptop.org wrote: Secondly, this just won't work for deployments in general. Deployments are really difficult. You don't have enough people, so everyone is Yes. I am looking now at all the barriers to a deployment team, and to teachers in a crowded classroom. My mantra going forward is going to be: - am I knocking down a barrier to deploymeny? - am I simplifying teacher's life in the classroom? - am I giving an average 6~8 year-old a better learning opportunity? - am I significantly cutting the learning curve? If it's not in very concrete terms on that list, then skip to the next task :-) In many of these places it is really difficult to find people with the required computing skillsets, and even if they exist they aren't likely to accept the piddly salary offered by your cash-strapped NGO or govt organisation. Yes. *really* challenging them (and sometimes, excluding them). Most of thetime - excluding them. ... Now moving onto some things more directly related to deployment experience. As I stated in my questions above, I'm not sure, but I'm really hoping that sugar is just as dedicated as it always was to provide a really really simple UI for 6 year old children. Everything is so much harder in a classroom, and every small problem encountered causes significant disruption. Yes. Even if 1 XO doesn't work or one child gets lost in a process, it distracts ~4 users, because humans are social, and the chatter of won't work for me stops progress. It only takes around 5% of users having minor trouble to get 50% of the class distracted. And at that point you have to give up on the XOs and turn to the blackboard. Every little obstacle counts. How about the first boot experience - typing in your name and choosing colours? (...) Sugar 0.84 makes that into every activity... it won't save unless you give it a name for the document. Can we disable that? Maybe not in the official SoaS but can there be a knob somewhere to revert it? We've all heard the problems of children deleting activities by now. I've also seen kids click the disable wireless box and then wonder why they can't get online. I think that this highlights 2 things -- That's been added for G1G1 and power user / developer userbase - Simplifying the user experience is *key* -- sugar has already taken many leaps in this area, let's keep this as a high priority, and make sure that this is communicated. Can I propose Daniel for president? ... Sugar is obviously geared to constructionist learning which is generally carried out differently from normal learning using books, Actually, having books is crucial for social constructionism too -- read it as much as your curioisity drives you to, revisit it as often as you like. And then do the social things you'll naturally do with what you discovered... In short, listen to the man. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Deployment feedback braindump
FWIW, It sounds like you both are pretty much in sync and are providing two much needed voices. The challenge that you both are clearly articulating is that of seemingly unlimited needs and limited resources. The only thing I would like to add is, Please note the tone of this discussion with compared to similar discussion a year ago. This discussion we can build on! I would encourage Tomeu not to take it personally. _Everybody_ all ways wants more from their engineer's. I would encourage Daniel to start breaking down the deployment needs in to items which we can prioritize and implement. david On Mon, Aug 10, 2009 at 11:53 AM, Daniel Draked...@laptop.org wrote: Hi Tomeu, 2009/8/10 Tomeu Vizoso to...@sugarlabs.org: Hi, some thoughts follow. Please keep in mind that these are just my personal opinions and that not everybody at Sugar Labs share the same idea of what SLs is or should be. Thanks for the response. What you are saying makes sense -- it is indeed a nice idea to keep SugarLabs as more of a loose structure, as a place for collaboration on anything that might further the general mission. It is a sensible idea to keep SugarLabs away from doing too much work on the OS building and deployment implementing side of things, because as you point out, even when you exclude those broad topics there is still a lack of resources on the bits that remain. That said, in a way, the gap that we're discussing is in some ways more important than any of the Sugar features currently being worked on, because the large majority of sugar users are currently a long way away from even having access to the features that were finished 6 months ago. Difficult. I disagree about local labs being key to filling the gap. While a nice idea, I think it is necessary for there to be a central and location-independent deployment-focused upstream, otherwise there will be a lack of coordination accompanied by lots of duplication of work. Local labs need to feed into something bigger, which doesn't currently exist, although it could probably sit under the realm of sugarlabs if the right people were to step up. Also, when talking of scale, I am a little wary of local community efforts because they have previously proven disruptive to deployments. The sad reality is that you absolutely require more of a NGO or business setup to be working with the relevant authorities. And when this happens, the community efforts automatically become a bit distanced. For example in many of these places, the official organisation receives permission from the government for their staff to enter government schools - but only their staff (not community volunteers). You mention lack of involvement and feedback from deployments -- why do you think this is? Here are some of my thoughts: - The majority people we're working with are alien to the idea that they might be able to talk to the people who are writing the software that they are using. Since when has anyone been able to do that? Us open source people are still the oddities in the world. - People are afraid or mythed by the idea of this stuff being public and global (why would I want my feedback to be public?), and are confused/challenged by mailing lists. - The people most able to give the kind of feedback you are looking for are the teachers, who are probably even more distanced from these ideas. Many will lack connectivity and english language skills. - Many people who support the project with technical skills (e.g. Linux) come from purely academic backgrounds which means they understand the technical stuff well, but have little interest, experience (and sometimes ability) to become good community members. To put it plainly: in my opinion, wishing for substantially more involvement from deployments is not realistic. SugarLabs would benefit from being proactive here, especially by using the telephone rather than email to contact deployments, but this is of course subject to the where are the resources? question. Hopefully over time a proactive approach from our side would likewise encourage a proactive approach to communication from the deployments, but I suspect we'll have to be patient. and yes, this makes your job pretty difficult. On Sun, Aug 9, 2009 at 19:41, Daniel Draked...@laptop.org wrote: At least from what I have seen, this kind of clarity seems to be missing from discussions that define the Sugar platform nowadays, as well as in the code that is flowing through the system. Does SugarLabs still have a high degree of interest in bigger-than-you-can-believe deployments in remote and really difficult parts of the world on low-spec hardware, or are we moving towards looking at occasional 30-student deployments on powerful computers in schools along the Charles? Or are we trying to do both? Are we still focusing on 6-12 year olds or has that changed? How do you expect that the SLs volunteers know what OLPC
Re: [Sugar-devel] Deployment feedback braindump
On Sun, Aug 9, 2009 at 10:41 AM, Daniel Draked...@laptop.org wrote: Sugar currently doesn't even have support for the library bundle technology which was adopted by various sugar deployments, as it doesn't have a way of accessing the index.html pages short of typing in the file path in Browse. (the functionality of olpc-library needs to become part of the sugar platform, in some form) That's http://dev.sugarlabs.org/ticket/574 The proposed Sugar Labs replacement is quite different , http://wiki.sugarlabs.org/go/Activities/Library and the Unified Browser / Unified Objects proposals. It still seems like the best way to get a class of kids on the same page is to start at some web page, like http://wiki.laptop.org/go/XS_Moodle_design#Straight_into_the_course_and_current_content adding an interactivity component that would be impossible to have when working with paper-based exercise books. And impossible with PDFs. But interactive HTML pages, cached locally using Google Gears or HTML5 local storage so you can work through the exercises in or out of school... it sounds plausible. Never bet against the browser. Cheers, -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
