Notes

Notes

Mon 4 Dec

Discussion

• ACTIVITY PACKAGE

  • Stian implemented type checking of activity packages
    • avoids breaking activity packages when modifying some of them or the engine
  • Keywords attaching to activity package? attaching to activities? They cannot be attached to the activity package iframe. It brings us to the problem of external activities. WE decide to keep using iframe to not close too many options. Better try to keep more control rather than open too many options
  • Understand the point of view of the designer/instructor
  • Example the weighting for argueGraph: at the activity level? At the operator level? A quiz activity with a lot of config? A specific type of activity?
  • The code of an activity package defines an activity type

• TRACES

  • Where do we specify which trace we collect? When I am the designer, should I care, should I know? Does the designer need to specify the traces?
  • The activity package defines the traces
  • In the future we would allow the teacher to have some control on the traces and filter them
  • Products are traces, but not traces are products
  • Currently, the logger, can collect whatever can be collected easily, where student click, what they type.
  • Experience API (XAPI) for traces of online users. Very popular

• DASHBOARD (-> renaming Orchestration tool)

  • It is supposed to help the teacher decide to take action on the course or not
  • Changing look and feel from an activity to an other?
  • Making dashboard more uniform? Moving dashboard out of activity packages?
    • Default dashboard for word clouds, media playing with progress bar, students status (active/inactive)
    • Plugin/Play approach with specific components
  • Visualising the graph: students moving, data moving, . . .
  • The need for simplicity is higher than the need for configuration

• OPERATOR PACKAGE

  • Pretty similar to activity packages.

• TEACHER ORCHESTRATION

  • Mixing inside the activity dashboard?
  • Thanasis wants the orchestration to be operated by the teacher manipulating the graph
    • More clean
    • The teacher would never interact directly with the Engine
    • Ending up with original graph and an executed graph
    • Need versioning of the graph?
    • Small changes not considered as changes? -> Micro regulations
  • Logs should include the teacher actions.
  • Possible operations:
    • end
    • skip
    • warn
    • pause
    • resume

• ARTIFICIAL INTELLIGENT AGENT

  • That would imitate the teacher, take decisions depending on the choices of the teacher
  • Inside the Engine -> Smart Engine?

### Open questions

• DATA CONSISTENCY

  • How does operator handle lack of data, termination send by teacher?

• LIFETIME OF ACTIVITIES

  • example: 15 minutes activity over a period of a week
  • How do we handle it theoretically and in the implementation?

• CONCURRENT ACTIVITIES

  • example: forum in MOOCs
  • complete freedom? if yes, no need of OG. Freedom with constraints?
  • A should be done before B?

• PREREQUISISTS

  • weights to describe the importance of the sequencing of activities
    • weights set by teacher? intelligent engine?

Quotes

Pierre:

Could we have a human readable description of the architecture ?

Pierre:

I have the immense honour to disagree with both of you.

Thanasis:

I am still not really comfortable with the fact that we define the type of an activity by its implementation

Pierre:

Are you taking notes?

Pierre:

Macro micro macro meso nano picto meso