Re: [Server-devel] EduBlog Revised Project Plan
On Mon, Jun 9, 2008 at 1:51 PM, Yama Ploskonka <[EMAIL PROTECTED]> wrote: > Could we have both? Well, it's just more work. If you get into programming, we can do more ;-) We are just prioritising which one to do *first*. If we had abundance of time and programmers, you'd get both and a shiny new iPhone to go with it ... m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] EduBlog Revised Project Plan
> [ from another email now ... ] > > On Mon, Jun 9, 2008 at 12:43 AM, Tarun Pondicherry > <[EMAIL PROTECTED]> wrote: >>> Well, you can't tell what options to remove until you get real users >>> using it, and you spot which options they don't use ;-) >> Thats true, but I'm also concerned we might scare them away! > > Your call there - but you might want savvy users for the early pilots, > so you get good quality bug reports, and intelligent feedback... Maybe I should just go mind the action figures instead of messing with the big boys, but my 1/2 cent: Could we have both? A simple, VERY usable set of options designed as for the clients we don't want to scare away (a very real risk I agree we should beware of), and an area lower in the UI, labeled "advanced", maybe with a disclaimer on the lines that "you mostly do not need to change anything here" for the more adventurous or savyy types to get themselves in trouble in? ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] EduBlog Revised Project Plan
On Mon, Jun 9, 2008 at 7:00 PM, Alexander Dupuy <[EMAIL PROTECTED]> wrote: > Greg Smith wrote: >> For starters, there's no group edit needed. They can share "browse" if >> they want to edit concurrently. I was thinking of just "post" or "start >> over" as the first pass. >> > > Like a lot of people, Greg over-estimates the level of collaboration > possible in shared Sugar activities. While the Edit activity has a > higher level of sharing (all children see the same document, updated in > real-time) this was done as a major feature enhancement (under contract > from OLPC, I believe) by the Abiword developers. Sharing in the Browse > activity is much more limited - you can share links by clicking on the > star at the top of the screen (yes, that's what that mysterious icon is > for) but the browser instances are otherwise totally independent, so > that when one child navigates to another page, the other children will > not see that page, unless the first child shares the link by clicking on > the star, and the other children then click on the thumbnail image of > the shared page that appears in the tray at the bottom. > > See http://wiki.laptop.org/go/Browse#Collaboration for the details. > > Given this limited level of collaboration in the Browse activity, it > seems very unlikely that even some hypothetical enhanced and more > collaborative version in another year would support shared edit boxes of > the sort provided by the Write activity (especially if those boxes have > JavaScript or other features associated with them). > > I'm not sure what impact this detail has on the plan for EduBlog, but if > collaborative editing is desired, there are basically two approaches: > > * Try to build it into the XS server pages - this would be very tricky, > and probably only practical in the given timeframe if you build on an > existing tool like http://www.synchroedit.com/ or > http://code.google.com/p/google-mobwrite/ and that tool works > out-of-the-box with the Browse activity (both tools depend heavily on > JavaScript). > > or > > * Take libabiword and use it in a blog-posting activity that interacts > with the XS (Moodle) server pages. > > Personally, I think the second is a better approach, but given the > server-side-only constraint, this takes collaborative editing out of the > project plan for the initial effort this summer. The second option sounds well to me and may be quite doable, but I would like to take the opportunity to mention one old project of me that didn't got much far: http://dev.laptop.org/git?p=projects/abiword-embed;a=summary This would allow to embed in a web page the same editor widget that Write uses, very similarly to how flash is embedded in web pages, example: http://dev.laptop.org/git?p=projects/abiword-embed;a=blob;f=tests/abiword.html;h=337ab3bd7f95bd3758d384b97baa58f0fba8188e;hb=HEAD If I remember correctly, it was starting to work when I dropped it. Maybe that could give us text boxes with collaboration enabled? Wonder how the UI for such a thing would look like... Regards, Tomeu ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] EduBlog Revised Project Plan
On Mon, Jun 9, 2008 at 12:13 AM, Tarun Pondicherry <[EMAIL PROTECTED]> wrote: > Aside from authentication, I think I can get a basic usable version working > on Greg's schedule. Do you foresee some problems that I haven't thought of? No problems. Sounds reasonable. >> A non-XS-based installation probably means usernames/passwords will be >> required - we can only do magic authentication tricks with the local >> XS. >> > > For the alpha, perhaps we can authenticate by name only w/o a password? Trivial to write an auth module that does just that. If Greg agrees that it's viable... ... > I'll have to look at this more, but, I believe its possible for me to do > deal with most of the Moodle editing and let other LAMP developers make > their classes/functions independent. I've hacked at Moodle before so I feel > comfortable dealing with it. I can then just connect to those other files > from within Moodle. As far as the editor, if we have to support IE and FF, > developers will have to hack on an existing editor, so no change in this > regard. Is that a mutually acceptable solution? Yep. >> - if using oublog, the "sitecourse" which is the frontpage, has an... > > Why does Moodle have two blog modules anyway? Community development. MartinD developed the "core" blog that is always sitewide. Some people want to run course-centered blogs that may aggregate at the site-level, but are managed at the course - so they contracted me to write just that. In any case, there are GSoC projects about making the core blog better, so that's moving forward (after a bit of neglect) so it's a good idea to work on that one (and not on oublog), specially if you can coordinate things with the GSoC project. IF the code is too crummy there oublog is a good fallback. [ from another email now ... ] On Mon, Jun 9, 2008 at 12:43 AM, Tarun Pondicherry <[EMAIL PROTECTED]> wrote: >> Well, you can't tell what options to remove until you get real users >> using it, and you spot which options they don't use ;-) > > Thats true, but I'm also concerned we might scare them away! Your call there - but you might want savvy users for the early pilots, so you get good quality bug reports, and intelligent feedback... >> I wasn't intending to put all of in on your shoulders... > Phew! :-) > Our project will still only focus on three pages (student, teacher and > admin). The teacher page (and functionality) don't exist in either blog or > ou blog, though there is an SoC project that may put some of those features > into the blog module > (http://docs.moodle.org/en/Student_projects/Blog_improvements). So we will > have to add that in, perhaps we can use some of the code from that project. > I've also read your comments about avoiding admin pages, but there some > options like where to post that have to be set on the user side. How can we > implement this without an admin page? I have some ideas here - have the config UI elements, but we may pre-configure it later. There is one thing in this space that is _really_ tricky - We want a solid base to base our work on and aim for a solid release. That means basing your work on the MOODLE_19_STABLE branch - We want to get the code merged upstream for v2.0 (next major release) - that means basing work on HEAD - but that release is far, far away. - We want to take advantage of the GSoC efforts - but they are targeting 2.0 :-( We probably need to review the blog code, see the GSoC guy (gal?)'s plan and see how it all fits. With a bit of analysis we'll find the best path forward. > Can I assume that all the pages will have knowledge of the course and > student name, etc. once that is done? I can hard code some things for the > alpha version to get around this. Yes - in moodle once the user is logged in, you have that data. >>> All html editors have complex UIs. And writing an html editor *is* >>> incredibly complex. > > Agreed, since we must support IE, FF and Browse. Moodle gives the option of > using either HtmlArea or tinyMCE. I think one will likely be removed for > the XS install (don't see the point in sugarizing both) right? Which one > should we modify? I'm with MartinD right now, and TinyMCE is going to be the official one in 2.0. This is - of course - tied to the notes above on versions. >> The blog can be a sitewide blog - either using teh vanilla moodle >> blog, > > Sorry, for my noobness, what is a "vanilla" version? "core" blogs vs oublog. >> or a oublog in the "sitecourse" (aka the front page). IF they >> mainly want to use the blog, it will be right there, no need to fiddle >> w courses... > > We need to associate the blog with the course anyway, but automatically. > So, they shouldn't have to fiddle with courses, it just needs to be > automatically set based on the teacher somehow. If your requirements are for course-based blogs, then oublog is the way. >> (Of course, they'll want to know more about moodle anyway ;-) ) > > That's a bit optimistic, but w
[Server-devel] EduBlog Revised Project Plan
Greg Smith wrote: > For starters, there's no group edit needed. They can share "browse" if > they want to edit concurrently. I was thinking of just "post" or "start > over" as the first pass. > Like a lot of people, Greg over-estimates the level of collaboration possible in shared Sugar activities. While the Edit activity has a higher level of sharing (all children see the same document, updated in real-time) this was done as a major feature enhancement (under contract from OLPC, I believe) by the Abiword developers. Sharing in the Browse activity is much more limited - you can share links by clicking on the star at the top of the screen (yes, that's what that mysterious icon is for) but the browser instances are otherwise totally independent, so that when one child navigates to another page, the other children will not see that page, unless the first child shares the link by clicking on the star, and the other children then click on the thumbnail image of the shared page that appears in the tray at the bottom. See http://wiki.laptop.org/go/Browse#Collaboration for the details. Given this limited level of collaboration in the Browse activity, it seems very unlikely that even some hypothetical enhanced and more collaborative version in another year would support shared edit boxes of the sort provided by the Write activity (especially if those boxes have JavaScript or other features associated with them). I'm not sure what impact this detail has on the plan for EduBlog, but if collaborative editing is desired, there are basically two approaches: * Try to build it into the XS server pages - this would be very tricky, and probably only practical in the given timeframe if you build on an existing tool like http://www.synchroedit.com/ or http://code.google.com/p/google-mobwrite/ and that tool works out-of-the-box with the Browse activity (both tools depend heavily on JavaScript). or * Take libabiword and use it in a blog-posting activity that interacts with the XS (Moodle) server pages. Personally, I think the second is a better approach, but given the server-side-only constraint, this takes collaborative editing out of the project plan for the initial effort this summer. @alex -- mailto:[EMAIL PROTECTED] ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Installing Fedora 7 on V3-M2A690G
Martin, >Ok. so the problem is with our custom kernel, right? What kernel are >you booting with (uname -a)? Linux localhost.localdomain 2.6.21-1.3194.fc7 #1 SMP Wed May 23 22:35:01 EDT 2007 i686 athlon i386 GNU/Linux >Ah, you found a good backport for F7. I'll check the distrubutions to find where the PostgreSQL is coming from. >If the machine can be set to run the kvm-based virtualisation, you can >run both F7 and Debian in separate VMs, providing both environments to >Tarun. You make a good point. I am not familiar with kvm-based virtualization, but I can investigate use of XEN. Currently, the only way to switch over remotely would be to change the "GRUB default" and do "shutdown -r now" as we won't have anyone at the physical machine to choose each OS for us. > Or to make it easier you could run a Debian LAMP stack in a Debian > chroot (see if you can find a howto for debootstrap on Fedora). I will investigate. -- Tony ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] EduBlog Revised Project Plan
Hi Tarun et al, Great work! Thanks for scoping and laying out the pieces. A few comments: 1 - Just to be safe, double the times and see if it still fits. 2 - I don't like the risk in the "group edit and teacher review" section. Let me know what info you need to keep it at 1 week or less. For starters, there's no group edit needed. They can share "browse" if they want to edit concurrently. I was thinking of just "post" or "start over" as the first pass. 3 - I need the UI done first (static is OK). Start with plain text and an image button. No formatting, no video, just flush out the work flow (e.g. create post, click OK, see preview in HTML, click OK again and it goes to teacher queue). Do it in basic HTML to avoid "sugarizing". Let's get something to show and we'll see what people ask for next. I know we want to reduce the risk by doing the other parts but I need to confirm the customer demand. I see the simple front end as the main value of project and we will need a minimum of 4 rounds of review to get it right. Any UI/Web page designers out there who want to help? 4 - I can live with Moodle as the base. My only hesitation is still on config of Moodle. I know people can learn to use/config moodle, but I don't want to force them to do that. It should be easy for any teacher with no sys admin help or even e-mail access to take a default XS with EduBlog installed and starting posting blogs. That is, install then hit EduBlog URL and that's it. Do a full Moodle config later if you want. Let me know if that's possible (can be phase 2). 5 - Leave auth to the end unless there is some trivial way to start. Short term, we only plan to share this app off the hosted site. That's the goal for August delivery and Auth will change a lot after EduBlog is hosted in school. 6 - Put in time for Debian version and XS + Fedora version. I hope I can get someone else to help package if you can create the core code. Video is important, e.g. this site is all video: http://www.sextosdela37.blogspot.com/ If we allow linking to video posted on Internet instead of upload from XO, does that help? BTW even if it's a "must" requirement you don't have to do it. Just get consensus its not possible in the time allotted. Then I have to reduce the forecast :-( Just comment on which requirements you can meet and which you can't and we'll go from there, no need to change the demand level of the requirement. We're on the right track! Don't let the project management overhead get in your way. Do whatever you think is right to be productive. If there is a decision that is blocking you let me know and we'll make a call one way or the other. On customer side, I got some more feedback from Uruguay lead. My impression is that when the Ceibal education committee says its important Latu will install it. If we get a bunch of teachers clamoring for this app then we should be OK. So the focus through August is proof of concept on the hosted XS. Install in Uruguay schools will come later. Nonetheless I want to architect the app to run on Debian and Fedora XS so we are ready. In the mean time, its still hard to get technical details on Uruguay XS with Debian. Does anyone at OLPC have the Uruguay XS config? Let me know who has the info and if you need approval from Latu to share it I can open a thread to get that. HTHs. Comments and input most welcome. One more round and I'll copy it to project page. Thanks, Greg S -Original Message- From: Tarun Pondicherry [mailto:[EMAIL PROTECTED] Sent: Monday, June 09, 2008 9:15 AM To: Martin Langhoff; Greg Smith (gregmsmi) Cc: server-devel@lists.laptop.org; marcel r Subject: Re: [Server-devel] EduBlog Revised Project Plan Hi Martin, Greg, This is my current proposed plan of action. If both of you approve, I will push ahead with coding as well as dividing into concrete subtasks that other developers can help with. We will modify Moodle blog or ou blog for EduBlog. (Only one area of work depends on the blog module we choose). The major changes are as follows: Moodle Modifications: Add Post to remote blog feature (API + Blogger plug in) - use the Blogger.com API with Zend Gdata and ngeblog (needs work to deal with images) - 1-1.5 weeks Simplify UI for HtmlArea - plan to mimic the Write interface - 2-3 days Feature to post for teacher review and group editing - needs more discussion (will try to get more info on SoC project, may need to reimplement with ou blog) - depends on code reuse (1 week at best, upto 3 weeks if none existing) Feature to preview before posting - 2-3 days Create/Simplify Teacher UI - needs more discussion Create/Simplify Admin UI - needs more discussion Authentication mechanism - not in my hands, hard code stuff for alpha I plan to work in that order. The only Moodle pages the end user sees for this are the post to blog page, the admin page (which is blank for ou blog) and a teacher page. Those are the only three Moodle pages that need to be created/modified.
Re: [Server-devel] EduBlog Revised Project Plan
Hi Martin, Greg, This is my current proposed plan of action. If both of you approve, I will push ahead with coding as well as dividing into concrete subtasks that other developers can help with. We will modify Moodle blog or ou blog for EduBlog. (Only one area of work depends on the blog module we choose). The major changes are as follows: Moodle Modifications: Add Post to remote blog feature (API + Blogger plug in) – use the Blogger.com API with Zend Gdata and ngeblog (needs work to deal with images) – 1-1.5 weeks Simplify UI for HtmlArea – plan to mimic the Write interface – 2-3 days Feature to post for teacher review and group editing – needs more discussion (will try to get more info on SoC project, may need to reimplement with ou blog) – depends on code reuse (1 week at best, upto 3 weeks if none existing) Feature to preview before posting – 2-3 days Create/Simplify Teacher UI – needs more discussion Create/Simplify Admin UI – needs more discussion Authentication mechanism – not in my hands, hard code stuff for alpha I plan to work in that order. The only Moodle pages the end user sees for this are the post to blog page, the admin page (which is blank for ou blog) and a teacher page. Those are the only three Moodle pages that need to be created/modified. I will count on authentication and theming being taken care of by the time we need it. However, if it is not done, we can implement a quick working theme in a few days for just those pages. If authentication isn't decided, we can hard code a few things for the beta, or use a name only authentication as a temporary fix if the system is used right away. Greg, I took another look at the requirements, and would much prefer that video is not a must. Everything else I think is okay for August beta. This also requires that the XO be online to use the system. (Unless there are mechanisms in Browse to cache and send post queries later that I am not aware of). Please comment, and let me know if you approve. Thanks, Tarun ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
