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 + theese 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 propper 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 managment 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 begining + 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 + begining 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.