socialStructure

Introduction

FROG is a social learning system, with activities happening on three social planes, where we often want to put students into different groups, distribute different data to different students, or give some students different interfaces from other students. A naive approach would be to have a simple mapping between student and group, however we often require more complex mappings. An example is a jigsaw-script, where the student is simultaneously member of group 3, but also of an expert group of earthquake engineers. Another example is where a student is a member of group 3, but within group 3 has a specific role.

To express this, we use a set of attributeKeys and attributeValues. In team-based activities, one attributeKey is used as groupingKey, meaning that an instance of the activity is created for each attributeValue matching that attributeKey. (In this way, one could have one discussion activity grouped by the group attributeKey, and a second grouped by the role attribute key). Activities also receive the social structure of their instance members, and can configure functionality based on it. Finally, activityData is mapped to social attributes, allowing activities to display specific information, or behave in different ways, depending on incoming data or configuration.

There is no such thing as a global social structure, rather, social structures are created by social operators, and passed to activities, or to other social operators, which can modify the structures (for example rotate the groups), and pass them on. All operators and activities receive social structures as input, but only social operators can produce/modify them.

Each student has a unique ID, and in the social structure, is always referred to through the ID.

socialStructure

The social structure is expressed as a mapping where each attributeKey has a number of attributeValue: [studentId] pairs.

export type socialStructureT = {
  [attributeKey: string | number]: {
    [attributeValue: string | number]: string[]
  }
};

For example:

{ group: { '1': [ 'aa ' ], '2': [ 'bb' ] },
  role: { chef: [ 'aa' ], waiter: [ 'bb', 'cc' ] },
  color: { red: ['aa'] } }

There is no requirement for any studentId to be assigned an attributeValue for all attributeKeys.

Alternative representation

Some functions will find it easier where the top level object has studentIds as keys, and where each student can have a number of attributeKey: attributeValue pairs.

export type studentStructureT = {
  [studentId: string]: { [attributeKey: string | number]: string | number }
};

For example, the social structure presented above could also be represented as follows:

{ aa: { group: 1, role: 'chef', color: 'red' },
  bb: { group: 2, role: 'waiter' },
  cc: { role: 'waiter' } }

The two functions focusStudent and focusAttribute described below, convert between the two representations of a social structure.

Helper functions

Below are some functions to manipulate social structures, and transform from one format to the other (all exported from frog-utils):

function focusStudent(struct: socialStructureT): studentStructureT

function focusAttribute(struct: studentStructureT): socialStructureT

function mergeSocialStructures(socialStructureT[]): socialStructureT

function getAttributeKeys(struct: socialStructureT): (string | number)[]

function getAttributeValues(struct: socialStructureT): (string | number)[]

The two functions focusStudent and focusAttribute are inverse.

Data flow

A social operator returns a single socialStructure. The attributeKeys produced shall be fixed at configuration time, so that the graph editor can ensure that the social structure matches what is required later in the data flow. If an operator or activity receives more than one social structure from more than one incoming operator, the social structures will be merged. The two social structures are not allowed to have overlapping attributeKeys, and this will be enforced by the graph editor.

Operators and activities receive a single socialStructure as part of their objects.

Grouping attributeKey

Each activity on Plane 2 requires a groupingKey. This groupingKey must be present in the incoming socialStructure, which is enforced at design time. The reactive data structure is specific to the students that share the same attributeValue of that groupingKey. For example, given the social structure above, if an activity had role as groupingKey, aa would be alone, whereas bb and cc would share a reactive data structure (for example a chat). Activities receive the other attributes for the members of its groupingAttribute, which can be used to customize the interaction (for example, someone could be designated author, and have write access, while all others have read access only).

activityData for a Plane 2 activity must be mapped to the same attributeKey as the groupingKey of that activity, or for 'all' students.