milsen / learningnet Goto Github PK

The user should not have to know the data format in order to create new learning nets.
The textbox in the edit view should be replaced by a more user-friendly GUI, including:

• controls to add/delete connectives
• controls to add/delete edges
• controls to change condition ids/join numbers
• controls to change the target node
• ...

One also has to decide how the learning net verification can be integrated into this GUI. Should actions always be prevented if they would lead to invalid learning nets?

Some first ideas, including an LGF export function for the frontend, are found in the branch gui.

When sections are added/deleted in Courseware, these should be added/deleted in LearningNet as well.
Changed/added Courseware sections should also trigger the recalculation of the respective cost values. Currently, all cost values are recalculated at once whenever the LearningNet settings are saved (which is inefficient and inconvenient).

This issue probably requires the integration of LearningNet into Courseware or at least some kind of observer-notification functionality in Courseware.

There are several block types which are currently not taken into account when calculating the time it takes to complete a Courseware section in DurationCostFunction.
This includes the PDF block (its word count has to be calculated somehow) and audio- and video-related blocks (the duration of the media has to be retrieved).

Before implementing this, it should be decided whether the development of the DurationCostFunction should continue at all (since it is pedagogically not very reasonable to recommend learning units simply because they are completed quickly).

Stud.IP and Courseware use Less instead of CSS.
LearningNet should do that, too.

Currently, there is a default learning net that is created whenever the learning net of a course is first requested (i.e. when no learning net for the course can be found in the database yet).
This is done by the back end via the switch '"action" : "create"', which results in a call of LearningNet::create() . Since the task of creating this learning net is very simple (much simpler than a recommendation or validation), it could be done by the front end instead. This would require an LGF export in the front end, but that functionality is required by #3 anyway.

Since the current creation of the default learning net already works, it should be decided whether a switch to the front end for this task would have any clear advantages.

Currently, all (two) implemented cost functions are independent of user-related information.
They result in the same recommendation for every person (since they are only dependent on the attributes of the respective Courseware section(s)).
It would be interesting to test whether it is also possible to implemented cost functions dependent on user information.

However, with the current setup, all cost values are stored in the database. User-dependent cost functions would probably require different database tables. Moreover, they would require the storage of a lot of cost values (possibly course x first section x second section x user many). This may be infeasible.

Node pair cost functions calculate cost values for pairs of unit nodes. When a recommended learning path is computed for a node pair cost function, it has to be determined which unit node to start with.
Intuitively, this should be the node v with the lowest cost value for the node pair (u,v) where u is the last completed unit node.
Currently, the last completed unit node is not stored and not passed to the backend. The backend always uses a heuristic to determine the node to start with.

Thus, it may occur that the learning path changes unpredictably while completing the unit nodes it contains. Example:

1. The recommended learning path is 1 -> 2 -> 3.
2. The learner completes 1.
3. The new learning path is 3 -> 2 (because the first node in the learning path is chosen heuristically rather than as the node v with the best cost value for (1,v)).

The last completed unit node could be stored in the mooc_fields table:

• block_id: Id of the last completed block
• user_id: Id of the respective user
• name: 'last_completed'
• json_data: empty (or true or some placeholder value)

I.e. whether the target node is reachable.
It should be more clearly indicated to the learner that he/she is finished with everything.