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

[Gary C Martin]

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.

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").

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.

Equivalent to: Joining (or leaving) mail lists (ie. you can join/ 
leave, you can't force others to join/leave)

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).

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).

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  
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.

Sorry for the rambling thoughts.

Regards,
--Gary