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

[Eben Eliason]

On Sat, Jul 25, 2009 at 10:59 AM, Gary C Martin<gary at garycmartin.com> wrote:
> 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.

This is an interesting observation, but I think that open groups and
self-tagging are still separate ideas and individually useful.

Self-tagging: allows kids to identify themselves as anything they
choose, allowing others to search for them by topic or interest. Any
number of kids can apply the same tag at will, and there is no limit
to the number or types of tags that one attributes to oneself, so the
possibility of "lying" is present. These tags serve solely as an item
to search on, and don't provide a structure for collaboration or
sharing.

Open groups: allow kids to self-organize into groups in an open but
constrained way. The formalization of the group means that, unlike
tags, any group one is a part of will appear in a filter in the Groups
view. The group creation process enables a single individual to send
invitations to the initial group members, so that only one needs to
actually type the group name (preventing mistakes). Moreover, while
anyone in an open group may freely invite others to it (hence, the
"open" name), no child outside the group can "self-tag" so as to
become a member of the group without their knowledge. The formality
(not the best word, but oh well) of the open group provides a
structure for sharing and collaborating with group members.

So, to conclude: self-tagging is great for search and discovery.
Open-groups are a mechanism for kids to self-organize (eg. for class
projects) in a structured way so that actions like "send to [my
group]" or "share with [my group]" are possible.

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

I'll find them. You're right, we might be able to simplify a bit.
Closed groups were offered as a secondary action, so I think it's OK
for that to be a bit more complex. Perhaps we can still simplify open
group creation.

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

Definitely.

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

Yup, but as I say, I still think that both "open" and "closed" groups
are needed. Given my outlining of their differences between
self-tagging and open groups above, would you agree?

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

Will do. I'll post them before the weekend is out.

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

I'd be happy to see some suggestions for simplifying group creation/management.

Eben

>        http://wiki.sugarlabs.org/go/Design_Team/Specifications/Groups
>
> Regards,
> --Gary
>
>