Table of Contents
There are two main parts of the package, one for the course administrator and the other for the student, and they can be divided in these two sections:
Uploading a UoL
Using the player
The first thing the administrator of the course has to do is to upload a UoL.
This is done from the control panel of the course. There you will find the administrator's interface of the package. Click on "Units of Learning Administration" and you will be redirected to the admin index page.
There you will find a simple interface to upload the UoL. It can be a zip or tar file.
After clicking on "OK", a confirmation screen with a little bit of information about the UoL is displayed. You can cancel or continue.
Finally, the UoL is parsed and the first run is automatically created. The parser will automatically detect if there is some integration with LORS, assessment or with the forums package of .LRN and will do the proper call to each package.
If everything is OK, you will be redirected to the roles management interface. At this time, a default run has already been created and its status is WAITING.
From the same page where you upload a new UoL, you can also:
Create a new UoL: Following the same procedure described above.
Create a new Run for the UoL: A run is an instance of the Unit of Learning (as explained in the specification).
Delete a UoL: Actually, marks the UoL as deleted, so you can make it alive again after deleting it.
Manage the members of a Run: If the roles management of a certain run has not been finished by the course administrator, then a link to the roles management page is displayed here. If the roles management is finished for a run, then there is no link to it, since in the specification is stablished that once the users have been assigned to their roles, there can be no changes.
Delete a Run: The same that deleting a UoL, it is only marked as deleted so you can make it live again any time.
After uploading a UoL you will be automatically redirected to this page, but you can come back to this page anytime from the admin index page of the package explained in the previous section. The run status at this time is WAITING.
From this page you can crate the roles for the run, according to the definition in the manifest of the UoL.
When creating the run, all the users that at that time are associated to the community will be automatically associated to the run, so the course administrator can choose only from those users when creating the role instances. This also means that if after the cration of the run new users are assigned to the community, the run members will not change (as the specification stablishes), and will stay constant for the rest of the run life.
After creatin the roles instances, the administrator must confirm that the roles assignation is finished and all the restrictions of roles specified in the manifest (like the max and min number of members) are validated, and a warning message is displayed if one of them is violated. Anyway, the course administrator can confirm and change the status of the run from WAITING to STARTED.
This is when the properties (if there are some) are instantiated for the run. Each time a run is created the properties (and other specific attributes) are instantiated for each user, role, run, etc, depending on the type of property.
Finally, all the conditions for that run are evaluated for the first time.
NOTE: When a run is in the STARTED status, no changes can be made to it, and currently, the roles are assigned only at the beginning of the run, so no role changes can be made during the life of the run.
A regular user (member in a community or student in a class) can have acces only to the player, which is the main part of the package.
The runs where the user has any participation are displayed in the portlet of the IMS-LD package of .LRN.
From here, the user can select a run and start (or continue) with the run.
The player has been developed according to the specification.
Each time an activity is finished the conditions affected by that property are re-evaluated, and every time a property value is changed, the conditions affected by that property are also evaluated, until we reach an stable point again.
As shown in the image above, the scren of the player is divided in 3 parts:
Activities tree: Is displayed in the box placed in the upper left corner of the screen. Here you can see the activities tree of the UoL. The activities that are finished are marked with a checkbox.
Nothe that there may be activities that are finished from the beginning of the run (according to the specification), so it is not necessary to mark an activity as finished for it to be displayed as finished. Also, when visiting all the resources of an activity, the player can asume that the activity is finished and mark it as finished.
Finally, in this frame only the tree is displayed, meaning that the actual content of the activities is displayed in the activities frame (esplained below).
Environments tree: Is displayed in the box placed in the lower left corner of the screen. Here you can see all the environments associated to the activity that has been selected from the activities tree.
The environments can include associated files, urls, monitor services, imsld content files (used to display and set properties values), forums, emails, etc.
Note that there may be monitor services that requires that you must first have to select the user (from a list of users) in order to monitor that specific user. This is done in the activities frame (explained below). Also, the actual contents of the environments (services or whatever) is served in that frame. In this frame only the tree is shown.
Activities frame: Is the big box at the right of the sreen. Here are displayed the contents of the activity (the resources directly associated to it) as well as the possible prerequisites, learning objectives and feedback of the activity.
When you click on a link in the environments tree, it will also be displayed in this frame.
As mentioned in the previous bullet, in this frame are displayed the monitor services, as well as the email services and imsld content resources. However, all the information that the user has to enter is managed in this frame. For instance, in a monitor service first you must select the user you are going to monitor, so in the top of the frame a list of users is shown so you must first select a user and then monitor the selected user. For the email service you must select the role first and then send the email. All that information (and more) is managed in the activities frame.
There may be points in the life of the run where a user can see the message "waiting for other users". This means that there are some users associated to other role instances in the same run that have to finish a specific activity before the player can continue with the next activity (according to the specification, the acts can be user as sinchronization points). You will be able to continue with the run when the other users finish the required activities.
Finally, when the run is finished by all the users in the run, it is set to the COMPLETED status. When a run is in this status, it can not be "re-runed", it will stay as it is for the rest of the course life. If you want to run the UoL again, you must go to the administration page and create a new run.