Feature Wiki

Information about planned and released features

Tabs

Study Programme: Introduction of Object Type

Page Overview

[Hide]

1 Requirements

1.1 Definition of a training program

1.1.1 Tree

A training program is created in the ILIAS Repository.

Training Program
In the above example BSC Mathematic and BSC Informatic are two different training programs. In both of these programs 180 units have been defined, which must be reached to achieve the program. A training program summarizes the entire training, which must be taken.
 
A training program is completed when ...

  • ...the training program directly associated nodes are completed and the sum of these nodes is equivalent to the units of the training program.
In BSC Mathematic these are Introduction to Mathematics and Applied Mathematics. In the above example, the training program in this form can not be completed because the two directly associated nodes together result in only 30 units.
 
 
Nodes
A training program essentially consists of nodes. At each node is defined how many units must be achieved until the node will be achieved. If a node has been achieved, the units of this node will be taken for further calculation.
 
 
Obligation / Elective / Optional
Obligation, elective and optional areas are defined by the units to be achieved.
  • Optional: 0 units are required.
  • Elective: Less units are assigned, as would be possible with completion of all assigned courses.
 
Course Reference
A node can contain another node or a course reference. A course reference is the final level of a training program. Course references are links to regular ILIAS courses that are equivalent. In the above example, these are Algebra 1 October 2014 and Algebra 1, December 2014
 
 
Reuse of nodes
Nodes can be reused in othert raining plans. In the above example, these are the grayed out areas of the BSC Informatic.
 
 
Status of a node
The following statuses are available for a node:
  • New
  • Active
  • Outdated
Outdated nodes will not be considered for new assignments of employees. Outdated nodes are shown "crossed out" in the above figure.

1.1.2 Settings

1.2 Training program employee

An employee can be assigned to several training programs. When assigning a training program, an instance of the training program will be created for the employee.

Employees instance of a training program

  • References to the training program definition nodes
  • References to the employee account
  • A copy of the required units of each node of the training program definition
  • Completion status (Not Relevant, Accredited, Passed)
    • NotRelevant: If a node marked as Not Relevant, the training program is marked as invalid. For a valid training program the units need to be adjusted.
    • Accredited: The units will be accredited.
    • Passed: This status is automatically and exclusively set via the associated rules.

1.2.1 Manage trainig programs

It's possible to assign members to each node of a training program. Normally a member is assigned to the root of a training program. The assignment node of a user is shown with the Belongs to column.
 
The Completion By column shows you how the node has been completed. E.g. by associated nodes or by accredition of a specific user.

1.3 Personal Desktop

The User has access to his Training Program via the Overview of his Personal Desktop

To dig deeper into its progress at the progress, the user can expand the items of the program.

1.4 Data Model

1.5 Pro-Contra-Interesting list for "Training Program in Repository"

To structure the discussion about whether the Training Program should be an object in the repository or not (started by CK on 28 Dec, see Discussion section) the arguments are collected in form of a Pro-Contra-Interesting list. Every item on the list has to be marked with either (+), (-) or (i). (+) stands for "Pro", that is an argument for the Training Program being in the repository. (-) stands for "Contra", that is an argument against the Training Program being in the repository. (i) stand for "Interesting", that is an argument which is neither pro nor contra, but captures a fact to consider when balancing the other arguments.

  • (-) It does not make much sense to embed the program tree into the repository (locally), because the program tree has a potential ‘global’ scope with regard to the repository. The program tree is a kind of specialised view / layer on top of the repository.
  • (-) The separation (on the other hand) would emphasize the importance and very different mean of this new idea. I think program management is soon going to be a key feature and not just “yet another repository object” tool – like “skill-management” isn’t a repository object for good reason either.
  • (-) The separation would also lead to “one tree only” – always. Not many trees, not zero trees, but exactly one program tree (although it may be empty of course). This tree may of course be structured like the repository or org-units are. This would make it much easier for other (potentially new) services to depend upon the program tree – because it will always be uniquely defined.
  • (-) Also imagine new requirements in the future: Keeping "things" (i.e. trees) separate allows for a much greater flexibility to develop the logic of repository and program individually – if needed – while keeping all that’s common in a shared codebase.
  • (+) If Training Programs are located in the repository tree, they could be discovered by users in the same way as every other repository object and there is no need for a new way to find them. They then could also use familiar mechanisms for joining and leaving.
  • (+) Having Training Programs in the repository would lower the barrier to use them, as there's no need for a plattform wide commitment.
  • (i) It seems to depend on the use case whether one program tree or many program trees are the right fit.
  • (+) In the repository the Training Program could easily be extended to contain other repo objects. Think of stuff like a Wiki for all people in the Mathematics Program.

1.6 Related Pages and Documents

There is an older feature request called Series of Courses with similar requests. We continue the discussion on this page and close Series of Courses.

We had a workshop in November 2014 to discuss the requirements and concept of a study programme object in ILIAS.

Documentation of Workshop, November 11, 2014

1.7 Suggestion for Icon

2 Additional Information

  • Idea and concept: richard.klees@concepts-and-training.de, ms@studer-raimann.ch
  • Funding: Customer of CaT Concepts and Training GmbH and Customer of sr.solutions
  • Maintainer: Richard Klees
  • Implementation of the feature is done by (company, developer)
  • Tested by: tbd (possibly Studer+Raimann)

3 Discussion

JF 22 Dec 2014: We support the general idea and open the discussion for the community. Please add your ideas and thoughts up to January 19th. We would like to make a final decision on the feature acceptance for 5.1 on this date.

CK 28 Dec 2014: I very much like the general concept - and so I want to make only one statement / petition.
 
I strongly suggest to separate the presentation and administration of the "program tree" from the "repository tree", although it may use the same logic / codebase under the hood - much like the organisational units, which share quite some logic with the repository tree, but not being embedded into the repository.
 
Reason 1: It does not make much sense to embed the program tree into the repository (locally), because the program tree has a potential ‘global’ scope with regard to the repository. The program tree is a kind of specialised view / layer on top of the repository.
 
Reason 2: The separation (on the other hand) would emphasize the importance and very different mean of this new idea. I think program management is soon going to be a key feature and not just “yet another repository object” tool – like “skill-management” isn’t a repository object for good reason either.
 
Reason 3: The separation would also lead to “one tree only” – always. Not many trees, not zero trees, but exactly one program tree (although it may be empty of course). This tree may of course be structured like the repository or org-units are. This would make it much easier for other (potentially new) services to depend upon the program tree – because it will always be uniquely defined.
 
Reason 4: Also imagine new requirements in the future: Keeping "things" (i.e. trees) separate allows for a much greater flexibility to develop the logic of repository and program individually – if needed – while keeping all that’s common in a shared codebase.
 
IMO this is going to be a very crucial decision for ILIAS and it cannot be made undone easily, which makes it even more important to consider this very carefully – and maybe even postpone a trunk-integration in favour of a future-proof implementation (<- my vote, in case I cannot attend the JF).

RK, 13 Jan 2015: Thanks for your comments Colin, i considered it necessary to structure the arguments a little and therefore introduced a Pro-Contra-Interesting list for your topic. I invite everyone to participate on the list.

JF 19 Jan 2015:

  • We think an implementation as repository objects within the regulare repository has more advantages than disadvantages, mainly because a lot of existing code (e.g. search, move/link/copy) can be re-used without changes and because it offers full flexibility (none, one or multiple programs).
  • We think that "training program" is not the best term for the feature. We would like to get some better suggestions from the community.
  • We accept the general feature and schedule it for 5.1. But we still need to agree on the following open issues
    • Presentation of the program in the repository (learner view / read permission). We suggest not to make every node clickable and just present the direct childs (as it is currently the case, e.g. for categories), but to represent the "whole" program under the top node on one screen (e.g. as "nested divs"). Please try to provide a suggestion as a a mockup.
    • User interface for the learner. The representation on the personal desktop could be very similar, but the current state (progress) must be visualised.
    • In both views more explanatory text should be added (a string "5/10" does not "tell" the user anything).
  • Please use the general learning progress service for the "node states" (a new LP mode would be required).
  • Moving/ordering of nodes should be possible (as long as no use of learners forbids an action). The UI for managing the nodes should re-use existing concepts of ILIAS where possible.

RK 29 Jan 2015:
 
"Study Program" seems to be the appropriate term. Google search yields 1.340.000.000 results. For "training program" Google yields 1.420.000.000 results, but the top results are related to sports.

JF 13 Apr 2015: We appreciate the mockups for the learner view.

  • We agree that the study programs a user is assigned to should be part of the "Overview" screen. However they should be listed above the "Selected Items", since we consider this list being more important and usually shorter. The desktop overview should only have a link to the detailed view where nodes can be expanded. Expansions does not take place "within" the overview screen.
  • We also discussed the permissions of the object. We start with "visible" and "write" permissions. There is no read permission that controls if users can access the learner view, this is only controlled by the assignment of the user to the program.
  • Types of programme nodes are defined in a new admnistration section for "Study Programmes".
  • Richard presented a JavaScript-based tree editing view. We ask to forward this suggestion to the kitchen sink group for discussion.

JourFixe, ILIAS [jourfixe], August 17, 2015: We appreciate the suggested icon but ask all ILIAS users for additional suggestions.

Kunkel, Matthias [mkunkel], October 06, 2015: What exactly is the purpose of the VISIBLE permission for study programmes? In the current implementation it makes a study programme visible to a user in the repository. Has it also an effect on the presentation of the study programme on the Personal Desktop? Or does this just require membership in the study programme? And is it intended behaviour that it is possible for my test user (member and visible permission) to click on the study programme's title and to see its courses just on the Personal Desktop but not in the Repository - or is that just a bug?

Klees, Richard [rklees], 2015-10-15: The visible permission should make the programme visible for a user in the repository as well as on the personal desktop. It is intended that the user sees the programme nodes that are relavant for his assignment to the programme, as he needs a possibility to see what he needs to do. The courses references should be displayed, when the user sees the course in the repository.

During the testing of the programme it also became apparent that a "read"-permission might be a good idea as well. Without it it would be impossible for an ordinary user to discover a programme without being assigned, as we would make "read" equal to "write" in that case to make it possible for administrators to modify the programme.

We also found that it would be nice to have a link on the list gui of programmes in the repository when a user is assigned to the programme, that takes him to the detailed view of his progress in the programme on the desktop.

JourFixe, ILIAS [jourfixe], October 26, 2015: We appreciate Richard's suggestion to introduce a READ permission for study programmes which allows to see the content of a study programme without being assigned to it or having WRITE permission.

Klees, Richard [rklees], 2015-11-17: On the last JF we discussed the displaying of Study Programmes on the Personal Desktop and its relations to the permissions on the study programme. The currently implemented behaviour is, that the read permission is not checked when an assigned study programme is relevant for a user. This was criticized as unorthodox regarding other ILIAS objects. If an admin revokes the read-permission on an object, he likely would expect that this object is not visible on the PD, which would not be the case for the SP. On the other hand, respecting the read permission on SPs on the PD could lead to situations where it is hard to correctly set the permission for all users that are assigned to the SP.

Therefore i propose the following changes to the permission handling of the SP regarding the PD:

  • Introduce a new global option for the SP that roughly says "Always show relevant SP nodes on the Personal Desktop." (NO_PERM) or "Only show relevant SP nodes where the user has read permission on the Personal Desktop." (PERM). The setting defaults to the PERM option.
  • If PERM is chosen, the Personal Desktop will show all relevant nodes of a study programme where the user also has the READ permission on the node. If a node contains relevant subnodes that would not be shown according to this rule, the node will get a note, similar to the preconditions, that roughly says "There are invisible nodes below this node.". 
  • If NO_PERM is chosen, the Personal Desktop will show all relevant nodes of a study programme, regardless of any permission.
I discussed the issue with MK, he most likely will be able to answer questions about it on the JF. If this proposal is ok as it is, please decide to do it like described on the JF, as I would be able to finish the implementaion of the SP then. If you still see huge problems, it might be better to wait until next JF when i'm attending again.

4 Implementation

The Study Programme is implemented as a new repository object. The reference to a study programme, as outlined in the concept, is not implemented.

Every study programme can either have other study programmes or course references as children. If a study programme has course references as children, a member of the programme completes the programme when she successfully completes one of the referenced courses. If a study programme has other programmes as children, a member completes the programme if she gathered enough points in the programmes below, where the required and gathered points is the amount of points defined on the programmes.

Thus a programme with two required subprogrammes could look like this:

  • Programme 1 with 100 Points
    • Programme 1.1 with 50 Points
      • Course Reference to Course A
      • Course Reference to Course B
    • Programme 1.2 with 50 Points
      • Course Reference  Course C
      • Course Reference Course D
A member completes Programme 1.1 when she either completes course A or Course B, Programme 1.2 is completed in a similar fashion. To complete Programme 1, the member needs 100 points, where he gets 50 points when completing Programme 1.1 and 50 points when completing Programme 1.2. That also means that Course A and Course B should represent a similar achievment, e.g. "Workshop Foo on 05.04" and "Workshop Foo on 06.04".

A programme where the user could chose which subprogramme she wants to complete would then look like this:

  • Programme 1 with 50 Points
    • Programme 1.1 with 50 Points
      • Course Reference to Course A
      • Course Reference to Course B
    • Programme 1.2 with 50 Points
      • Course Reference  Course C
      • Course Reference Course D
where the rules for completion of Programmes 1.1 and 1.2 are the same as above, but the user only needs 50 points to complete programme 1.

Test Cases

Test cases completed at 2015-08-28 by Klees, Richard [rklees]:

Approval

Approved at August 28, 2015 by Martin Studer.

Last edited: 15. Dec 2021, 09:09, Schmid, Fabian [fschmid]