[Sugar-devel] scalability in the neighborhood view

[Eben Eliason]

On Wed, Mar 24, 2010 at 8:32 AM, Martin Langhoff
<martin.langhoff at gmail.com> wrote:
> On Wed, Mar 24, 2010 at 3:28 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> 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