On Wed, Mar 24, 2010 at 8:32 AM, Martin Langhoff <[email protected]> wrote: > On Wed, Mar 24, 2010 at 3:28 AM, Tomeu Vizoso <[email protected]> wrote: >>> Yep - no prob for me. The GUI side probably needs a bit of extra >>> thinking so that it avoids being specific to the backend works (moodle >>> in this case)... >> >> I was thinking that Moodle would put contacts in groups in the server >> side and Sugar would just use the standard Telepathy interfaces. > > Yep. Agreed, same here. > > What I was thinking about was the UI design... for example, just one > very obvious case we have to deal with: it is a good idea to design > the UI so that we have a metaphor to edit groups (create, add/remove > users). This can work server-less or with XMPP/Moodle backends -- we > have to define a "lowest common denominator" and aim to use just that.
Yeah, definitely. We did a lot of thinking on this topic way back when, so there is some documentation already describing a proposed model: http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups We also have a first series of mockups of how this might look in the UI, though I'm not sure that those are posted anywhere, and they might need some tweaking in any case. Agreeing on the behavior is key, though. > For the initial implementation we are discussing, I would avoid > implementing the client-side editing, and go instead for something > easy: just read the groups via Telepathy -> Gabble -> XMPP (which in > turn is controlled by Moodle). But if we have a plan for the "full" > interaction, we can start implementing the basics. Agreed. We can start by basically just adding the filter to the UI for now, and add any creation/management UI in the future. > Without looking at the long term UI, maybe we implement something and > then... have to change the UI significantly in the "next stage". Yeah, I think that's a great goal; I also think it will be relatively easy to succeed in doing so, especially if the only core UI added for now is the group filter (in the Groups view, in the Journal, for various actions eg. Share with, Send to, etc.) > It's not a big deal... I just think it would be good to have a chat or > two to define some of those "lowest common denominators" strategies, > and some key "features". I look forward to hearing feedback on that draft spec in the wiki. I just read through it again, and from my perspective it still sounds pretty solid. I know little of moodle, so I'd be curious to know how well it integrates there, but it seems like a fairly basic set of parameters and actions that will still provide a great deal of versatility. > An example on the 'feature' side: one of the strongest requests from > the field I have is something I don't think we ever thought about -- > teachers want to set a mode in Moodle that forces all kids' XOs to > only show _this_ group/course/classroom members. Not sure how that'd > work but I get that request from several independent deployments. Would you like to add a section to the wiki page entitled something like "Other Requested Features" to track any specific details like this that the current proposal doesn't cover? > I probably need to think these ideas through, and throw them in the > collective pot... if you're interested... Definitely. Eben _______________________________________________ Server-devel mailing list [email protected] http://lists.laptop.org/listinfo/server-devel
