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

[Tomeu Vizoso]

On Sat, Jul 25, 2009 at 04:01, Eben Eliason<eben at laptop.org> 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
>
> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
>> 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.
>
> 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.
>
>> 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.
>
>> 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.

Eben, Gary, can you summarize your thoughts on this proposal?

http://wiki.sugarlabs.org/go/Tagging_Proposal

Do you think it's worth implementing as-is? Do you think we should
instead tackle first real groups? Or maybe the "tagging others" part
of it isn't useful?

Please note that the proposal is very limited because it's meant to be
implemented during a single release cycle within our limited
resources. I tried to be very clear in the use cases it supports so it
doesn't get confused with a much broader proposal.

Thanks,

Tomeu

>> Regards,
>> --Gary
>>
>> _______________________________________________
>> Sugar-devel mailing list
>> Sugar-devel at lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>