Talk:OLPC Human Interface Guidelines/Activities/Activity Basics

A couple of topics that appear to fit on this page, but weren't addressed:

Forking Activities

Can activities be 'forked'? (e.g. starting a new drawing of your own based on an existing drawing instead of resuming the original) What would trigger such forking? (e.g. would going back and resuming a 'kept' version of an activity be enough to create a new fork?)

This is an interesting question. At the moment, I think we're assuming that implicit forking happens if a child edits a kept version without the entire group that originally created it. That is, in order to prevent the need for complex merges, the two versions are treated as independent objects. The question remains, however, if there should be an explicit forking mechanism, through which a single group which is perhaps still within the same classroom, and therefore still connected on the mesh, can force two separate versions and split into two groups. - Eben 10:48, 13 December 2006 (EST)

Regardless if the forking is explicit or implicit, would it be possible to 'force' a merge? For example a group of kids do something together, and then have to split (maybe losing connectivity or availability) but will keep at it individually. When they meet again, they'll probably want to somehow put it back together into a final version probably mixing or cherry-picking the changes...--Xavi 10:55, 13 December 2006 (EST)

In the absence of any good merging algorithms (since this becomes extraordinarily hard with anything other than plain text - and even most plain text merges are optimized for code where the fundamental unit of distinction is one line), we are presently choosing the simple solution, which is to make manual merges by resuming both instances side by side and then copy/pasting the modified parts. A bigger concern, then is to create object formats that support simple copy/paste. With an image, for example, good use of layers (even if they are transparent o the children) allow a nondestructive form of editing that also makes this kind of merge simpler. - Eben 11:09, 13 December 2006 (EST)

Locking Activities

Can activities be locked to 'current members only'? (This would allow the activity restriction to work properly - lock it to current members first to prevent new entries, then narrow the scope further as people leave. Otherwise new members might join as other members leave, making it difficult to narrow the scope of access)

My present thoughts are actually that the scope of an activity can be limited, at any time, to prevent those outside that scope from joining. The scope, therefore, determines who can join the activity, and not who can participate in it. A child outside a newly defined and more limited scope can remain in the activity until they choose to leave, but once they do the new scope will prevent their re-entry. (In such a case, I would imagine an implicit fork would happen if they tried to open it again. They shouldn't be restricted from opening it, since they have a copy of the object, but without permission to join the current group on the mesh, they open a new revision in their own scope, perhaps. We'll need to think this through more.) - Eben 10:48, 13 December 2006 (EST)

smoother continuum from on-line to off-line collaboration

My friend invites me to help her write a document. We have a productive session. Later, she's turned her computer off, but I have an idea. I should be able to edit the document, and she should be able to see my changes. Of course, the journal provides implicit version control, so she doesn't have to worry if she doesn't like my changes.

(Instead of accessing the document from my neighborhood as I would when online, I'd have to access it from the journal. If we hadn't done online collaboration, I'd still have the initial invitation in my journal. But this raises a UI idea: a way to link from a friend's icon, for instance in neighborhood view, to the journal filtered by events relating to that friend.) Homunq 15:19, 29 July 2007 (EDT)

Notifications

Some possible ideas on how notifications could work in Sugar:

1. Notifications are associated to the various icons on the frame:
   • Download notifications would slide out from a permanent Journal icon in the bottom frame
   • Buddy Invitations would slide out of from the Group or Neighbourhood icons
   • System notifications would slide out from the Home View icon
   • The non-transient notifications would remain accessible from the icons rollover menus
2. The top frame stacks all notifications, new ones appearing from the right edge.
3. Home view keeps track of all notifications by either:
   • having a designated area in the home view for stackable notifications
   • having the parts involved (Journal, activities, battery, mesh, AP, XO) show appropriate badges, with their rollover menus closed or extended depending on how critical the notification is
4. Inside activities, notifications are done via a box at the top. Sugar notifications would appear from a box at the bottom of the screen, showing the appropriate information

Bug |2864 has an interesting idea to notify events.