[Sugar-devel] Buddy Tagging (Was: GPA Goals Status)

[Gary C Martin]

Hi Eben,

On 25 Jul 2009, at 03:01, Eben Eliason wrote:

> On Wed, Jul 22, 2009 at 1:17 PM, Gary C Martin<gary at garycmartin.com>  
> wrote:
>> On 21 Jul 2009, at 23:51, Caroline Meeks wrote:
>>
>>> On Tue, Jul 21, 2009 at 4:15 PM, Gary C Martin
>>> <gary at garycmartin.com> wrote:
>>>
>>>> Hi Greg,
>>>>
>>>> On 21 Jul 2009, at 14:51, Greg Smith wrote:
>>>>
>>>>> I may also add a feature to share a file from one
>>>>> computer to another. I want to see a lesson plan needing that  
>>>>> first.
>>>>> Then I'll try out the suggestions recently posted to the list
>>>>> before I
>>>>> ask for a new feature.
>>>>
>>>> Have you tried using the "Send to --> friend" Journal feature?
>>>> Obviously you need local collaboration working first, and added  
>>>> some
>>>> friends:
>>>>
>>>>
>>>> http://wiki.sugarlabs.org/go/ 
>>>> 0.84/0.83.5_Notes#Journal_entry_palette
>>>
>>> Send to sends to one person and we need to have one person (the
>>> teacher in
>>> this use case) send to everyone in the class/neighborhood.
>>>
>>> That said, I wonder if we can use this as a work around while we
>>> wait for
>>> designers and programmers to figure out the usecase.
>>>
>>> Is there a clever human engineering solution that would quickly
>>> allow each
>>> kid to send it to two other kids and get full coverage quickly?
>>> sort of
>>> like a calling tree?  I think what I'm asking is how could I in a
>>> classroom
>>> management situation set up file sending tree quickly that includes
>>> everyone
>>> and doesn't cause too much chaos and is resilient to kids being
>>> absent and
>>> some kids being socially isolated.
>>
>> One of the 0.86 roadmap items was buddy tagging, but think it may  
>> have
>> slipped:
>>
>>        http://wiki.sugarlabs.org/go/Tagging_Proposal
>>
>> Here's some random misc. thoughts -----
>>
>> Buddy tagging questions:
>>
>> 1) Can only add tags to myself?
>>
>> In this, case a teacher would need to get each of her class to add a
>> specific unique tag themselves "class_greentree7" (or she could add  
>> it
>> before handing out the sticks). This tag would be visible/searchable
>> in the neighbourhood by anyone on the same network/server. Anyone on
>> the same network/server could use the "send to --> class_greentree7"
>> to send items to the whole class. Other people could potentially tag
>> themselves as class_greentree7, the teacher could see this in the
>> neighbourhood, if she checked, but class_greentree7 could potentially
>> not be exclusive if she isn't watching.
>
> Have you read the design specification for groups as they were
> initially envisioned? (some details may have changed since this was
> written, but I think you'd find it useful background, and it answers
> some of your questions.)
> http://wiki.laptop.org/go/Specifications/Groups

Thanks for the reminder :-) yes I'd read this a while back (but wasn't  
sold at the time, though it's a good starting discussion). FWIW this  
document is over on SL as well:

	http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups

> I still think that adding groups is a logical and even necessary
> extension of Sugar as it exists now, so I'd urge you not to try to
> solve all the problems that groups are designed to solve with tagging
> alone. Or, perhaps an early implementation of groups can come out of
> your work as well.

OK, so I'd suggest my 1) above description of self tagging (a personal  
profile), replaces the use cases for "Open groups". The "open groups"  
will naturally form by users self tagging their interests, projects,  
or being asked to enter some after school club name, etc.

>> Pro: Clean design. I can search the neighbourhood to find other's  
>> tags
>> (social network). Individual kids can form groups by agreeing to use
>> matching tags ("school_play").
>
> I think this is definitely the place to start with tagging.
>
> I'd like to see the ability for kids to provide tags for themselves in
> a "profile" of sorts. It would also be nice to expose these profiles
> in the secondary palettes for people in the UI. Perhaps one's own
> palette allows editing. We could also expose even more details in the
> "about me" section of settings.

+1

>> Con: I can't make my own ad-hoc tag lists of friends
>> ("friday_art_club", "people_who_helped_me"), I have to rely on each  
>> of
>> them to self tag.
>
> I think this con is acceptable, for now. I understand the desire to
> allow anyone to tag anyone, but it's not clear how to expose this in
> the UI clearly, and it moves into the realm of "groups". Of course,
> groups are also mutual sets of people, rather than local labels for
> people.



>> Equivalent to: Joining (or leaving) mail lists (ie. you can join/
>> leave, you can't force others to join/leave)
>
> Again, this kind of membership issue is really a feature of groups,
> and I think the proposal I linked to handles it rather well. In most
> cases membership is at will, but there are special provisions in the
> UI for, say "class_greentree7" so the teacher can manage the class
> group as needed.

I'm beginning to see the case for "Closed groups" as being local to an  
install of Sugar – like the 2) case below (i.e a way of creation a  
group and assigning buddies to it for your own use). So by treating  
this as the Groups feature we can keep a clear separation from self  
tagging.

>> 2) Can I only tag other buddies?
>>
>> These tags would simply be local to my install of Sugar for my one
>> use, with nothing shared.
>>
>> Pro: Simple. Clean design. I can search the neighbourhood for buddy
>> tags I've added. I can make my own personally relevant ad-hoc tag
>> lists to work with those groups of people I want to work with. I have
>> full control over who I tag with what.
>>
>> Con: No sharing of tags with others, no discovery of others through
>> their own tags. Each person needs to create their own tag lists
>> (duplication of effort if, say, each member of the "school_play" each
>> has to "school_play" tag all other members of the school play).
>
> Yes, I don't think this is powerful enough for kids. That is, the
> primary benefit of having a "profile" is that each kid individually
> will want to fill theirs out, and the whole neighborhood benefits as a
> result. I can't expect that many kids will go to the effort of
> individually tagging other people one by one in any meaningful ways,
> plus the loss of discovery of other kids with similar interests would
> be unfortunate.

+1

>> Equivalent to: Creating my own local BCC: mail shot lists, I can add
>> or remove who I want, no one gets to see/use my list.
>>
>> 3) Can I both tag myself (which others will see), and also tag  
>> buddies
>> (which others would not see)?
>>
>> For this there would need to be a clear visual difference between  
>> tags
>> you apply to your buddies, and tags that buddies have applied to
>> themselves. This way, a teacher coul (on her machine) tag her class  
>> so
>> she can send them class work, knowing that the work is just going to
>> those she has tagged. And the individual kids can still share their
>> interests, and form groups (by agreeing to use a matching tag).
>
> This sounds hard to do without causing confusion in the UI. I think
> that tags and groups, while related (as both allow one to find others
> by searching/filtering) should remain independent entities. The
> "closed group" idea specified above would handle the teacher/class
> scenario well, I think.

+1

> I thought I had a series of mockups posted for groups somewhere, but I
> can't locate it. I'll try to dig it up and post it to the design
> section.

Yes I was looking for them as well for reference. From what I remember  
of them, they were a fairly complicated set of formal dialogues that  
felt fairly un-Sugar like at the time. Though perhaps if the "Closed  
group" feature is targeted more at teachers, it doesn't need to be as  
child friendly. i.e. no need for an "Open groups" UI as that's covered  
by self tagging – something, as you say, kids could find quite  
appealing.

>> Example A: A teacher could initially add a tag (local to her Sugar)  
>> to
>> all the kids in her class, and then the "send to --> friend" menu
>> could show a list of her (locally created) buddy tags. The teacher
>> could select "send to --> class_greentree7" and all the kids would  
>> get
>> a download alert in their frame. The kids that teacher tagged, but
>> were not present/off-line during the send, would simply not get the
>> file (I think this would be a case of a manual "send to --> ..." at a
>> later date by the teacher to the absentee, or via some other class
>> mate).
>>
>> Example B: If I tag _myself_ as "geek", that property would be
>> searchable in the neighbourhood views by others on the same network/
>> server. e.g anyone typing a search query of "geek" would grey out all
>> buddies that did not "geek" tag themselves (or hovering over my buddy
>> icon would show "geek" was one of my tags). If I then tag 5 _other_
>> buddies as "nerds", that information is NOT shared with others in the
>> neighbourhood, those are my local tags, only I can filter for those 5
>> "nerds", and only I can "send to --> nerds".
>>
>> Pro: I can search the neighbourhood for self tagged buddies, and also
>> for private tags I have added. I can use tags for working with
>> specific groups of my own choosing and relevance, and benefit from  
>> the
>> self tagging social effect of others.
>>
>> Con: Complicated in design, UI, and implementation. Some behaviour
>> would need very careful work (e.g how should buddy tags others have
>> added to themselves, and buddy tags I've added to others work  
>> together
>> when I search or "send to -->")
>>
>> ----- End of random misc. thoughts.
>>
>> Warning: Each of the above is not fully thought through, as you might
>> have noticed ;-) I'd say 1) is perhaps the most in keeping with Sugar
>> collaboration focused goals (but with a more limited use); 2) is
>
> Agreed! I put a vote in for #1, myself.

:-)

>> useful, the most simple to implement, gives power to owner, but of
>> indirect benefit to collaboration as there is no discovery of others
>> interests; 3) is _one_ example of several ways that both other tag
>> ideas could be combined, but it has a number of UI complications,  
>> lots
>> of behaviours to be clarified, and most complicated to implement –
>> worse, perhaps it's a conflation of what should be two separate
>> features.
>
> Yup, I'd agree there as well. I think that groups (which seems to be
> the direction that option #2 is heading, or serving as surrogate for)
> is a similar but independent feature. Another benefit of keeping them
> separate, by the way, is that we intend to have a "groups" filter in
> the toolbar of the groups view, offering an instant way to see subsets
> of the neighborhood. We'd also like to use group names as sharing
> scopes, etc.

+1

>> Sorry for the rambling thoughts.
>
> Not at all. Good thoughts!
>
> I look forward to hearing more, and seeing your progress. If you have
> UI questions, let me know! As I mentioned, I'll try to pull up some
> old mockups of the groups feature, and I might even have some old
> designs for the profile/tagging feature.

Thanks for all that feedback/discussion! So yes looks like we have 2  
features here.

1) self tagging / personal profile, where a child adds a list of tags  
about them-self that is published along with their colour and nick  
buddy information over telepathy. Primary use would be in  
neighbourhood view searches.

2) groups (was "closed groups"), where a child (or perhaps more likely  
a teacher) creates a named group and assigns buddies to that name.  
Primary use would be for filtering the Group view, and "Send to -->  
group" features.

If you can find your previous group mock-ups, that would be great  
(been googling, wiki searching, and Spotlighting my email but haven't  
found them yet).

If the above is making sense for you, should I look at re-working the  
specification (and adding some pictures), or create some new Groups  
document?

	http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups

Regards,
--Gary