My vision is that we would create Moodle Classes for all the various groupings that students have throughout the day. Then maybe the Neighborhood view shows only people who share a group with you, or maybe those people get preference if the Neighborhood gets too crowded.
On the Friends view it might be useful to pick just one of these groups. So if I'm in Reading Group A right now I could choose Reading Group A in a drop down in the friends view and it would show only people in my reading group. Later I am in Mr. J's Afterschool club and I pick that so I can work with them. After that I'm in homework time and I want to work on my Reading Group, I can use this to easily see if anyone else from my Reading Group is around to work on the homework assignment with. On Mon, Aug 31, 2009 at 11:46 AM, Benjamin M. Schwartz < bmsch...@fas.harvard.edu> wrote: > Christoph Derndorfer wrote: > > On Mon, Aug 31, 2009 at 5:03 PM, Walter Bender <walter.ben...@gmail.com > >wrote: > > > >> 5. Automatically add anyone with whom you have been collaborating to > >> the Friends view. (Doesn't quite solve the problem Michael describes, > >> but it will result in a populated view. And it is easy enough to > >> delete entries.) > > > > > > Personally I'm very much opposed to doing something like this without the > > user's explicit consent, especially since this is quickly going to result > in > > a very cluttered "friend's view". > > I agree... unless we rename it to something like the "Recent Friends" > view. It could simply show, say, the 20 people with whom we have most > recently collaborated. This would discard existing functionality in favor > of different, new functionality. I suspect that this would still be an > improvement, and that the current Friends view is little-used, but it > would be nice to have confirmation from deployers before tearing out that > feature. > > Ideally, both of these functions could coexist in the context of the > Groups View, but we have only the vaguest mockups of how Groups should > function, and even less of a blueprint for implementing them. > > --Ben > > > _______________________________________________ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
