Update 7.08.2017

Since a lot of work has happened while Louis was away, and also some while Romain was away, I thought I’d look over the changes, and do a quick recap of what has changed, status of various projects, unresolved questions etc.

Smaller things:

• createActivity became createPackage, and can create activities and operators (needs a bit more testing)
• removed autopublish. However, we're still publishing all collections to all users (only distinguishing between teacher and others), should restrict this further.
• ac/op packages can now export multiple ac/ops in an array

Nicer selector for activities/operators:

• all ac/op have shortDesc and description added to packages. When choosing new ac/op, shortDesc is shown, and can be expanded. Search is also provided (full-text for title/shortDesc/description).

Preview:

• Activities can have exampleData, an array of title + config + activityData, which is used for preview. Activities can be previewed from the selector. ActivityData is run through the mergeFunction. You can also see exactly what the data structure is like (including the reactive data after the merge function, or after interacting with the activity)
• When configuring an activity, you can preview the activity with that exact config, if the activity is “green” (no problems, mainly to ensure that the config is correct). This let’s you merge the config with the activityData from the exampleData

Possible future work

• Currently the exampleData mix config and activity data. This makes it messy when we try to provide different example data in activity-specific preview... One option is to disentangle, provide one list of activityData, and one list of config... Makes preview UI a bit more complex, and also - do all configs go with all example data? So far, I think so?

UI for graph validation

• There are a bunch of different functions that validate graphs, these work on pure data. Some simple ones check that all activity types actually exist in the current FROG instance, etc. Others, like types and social structure are described below.
• Currently the graph validator is called anytime refreshUpdate() or addHistory() is called in the graph (refreshUpdate() is used from the sidepanel, to avoid adding to the undo history of the graph), and the result is stored in the store
• The result is a list of issues, with id: of component involved, severity (error | warning), error text, and error type. The error text does not include the type (operator | activity) and name of the node. This data is reflected in multiple places:
  • a central indicator showing red (errors) or yellow (only warnings). Mousing-over shows a list of all errors/warnings (errors first), with node type and name appended.
  • a similar indicator (same component) is shown in the side panel for operators/activities, showing only warnings/errors relevant to that node
  • nodes (ac / op) have a red border color if there are any warnings/errors associated.

Possible improvements

• The code for the UI (Validator.js etc) is getting quite convoluted, and should be refactored, although not urgent. Not sure it makes sense to use SVG instead of a simple div.
• We're adding a lot of color coding to nodes, and we might add more in the future - should probably rethink a bit at some point. Previously the border color changed to show whether an activity was selected, currently the border color reflects error status, and there's an additional border, a few pixels out, added when selected. Works, but maybe not perfect.
• I am planning to add some highlighting of which nodes are valid drag-targets, when dragging a connection line, once I have the type checking of activityData finalized.

Tracing social structures

• Operators now specify which social structures they produce (doc).
• Config forms can specify that a given field is a social structure, and this is shown as a pull-down with available social structures
• All flow of social structures is verified:
  • Any op / ac specifying incoming social attributes (through groupingKey or in config) should actually have those social attributes incoming
  • The attribute used in groupingKey cannot be used in config
  • If more than one social operators is incoming, social attributes are not allowed to overlap

Future work

• This seems to work pretty well, however more practical testing is needed. The UI of warnings in sidepanel etc might be improved.

Enhanced form / conditional fields

• We have a wrapper around react-jsonschema-form called EnhancedForm (in frog-utils), which for now is able to deal with conditional fields, conditions can be static on a boolean, or a function that takes formData as input. This is used for ac/op config

Future work

• There are a lot of properties in the ac/op package definition, and some confusion about what should be in meta, etc. We should rethink this a bit, and nail it down (and document it)

LTI integration (for Moodle, EdX etc)

• Romain is working on this, I will help with verifying the LTI signature.

Type checking of activityData

• This was a major challenge, but I've made a lot of progress I think. I came up with a format, and a checker (all on branch supertest). I've documented it here
• I'm happy to hear your feedback, but there are some major issues before we finalize this work

Future work

• Do we allow multiple incoming activityData to a product operator? I think the answer must be yes, because I can see many cases where we would need this - but how does this happen in practice, how do we type check this? Do we have multiple type definitions for different slots, etc.
• All my type checking effort was focused on making sure dataUnits were compatible, but I didn't think at all about social structure of activityData... For activities this is fine, since a single activity instance will always receive and produce a single dataUnit. For operators this is more complex. One idea was to have specific subtypes of operators (aggregation/distribution/transformation). Needs discussion!