The imsld package provides an IMS LD viewer that will have two modes for the professor: off-line mode and on-line mode.
In the off-line mode only the professor will have access and he/she will be able to see all the plays, acts, properties, conditions, etc. Definitively, all the things that are described in an IMS LD document. But this information of the XML package will not include the mapping between roles and members of the .LRN course or community. It is the professor who must do this association before running the IMS LD for concrete students. The interface will allow to select the students inside a concrete .LRN course. This tool will allow assignate students and professors (or other groups if exists) to the roles defined in the IMS LD file.
On the other hand, in the on-line mode, it is visualized the IMS LD when it is running. It will give to both the teacher and the student (staff and learner) an overview of the activities in the workflow, i.e. the visualization of the play, as well as their current status.
For the teacher, the viewer also offers in on-line mode the possibility of seeing the properties and conditions, tracking the students, watching the users in every activity of an act, etc. The teacher is able to view more details in every act and see who has done what. He/she can verify if a given test is too difficult and the students can't continue with the flow of the course, or if the teaching method is not working as planned. The viewer shows the list of acts that conforms the play, as well as the activities that conforms each act, the list of students that are part of that given course, etc. It display this information in a graphical way, in order to make the information easy to understand. It will also display links to the .LRN services involved, in case the teacher wants to make use of the functionalities of that specific package (because eventhough we make use of them, it doesn't mean that we are replacing them). In the future the teacher will be able to edit the sequence of activities from the viewer, when the editor is finished.
On the other hand, the viewer offers the possibility to the students to see their status inside the play. They can see how much have completed and how much they have yet to complete. Of course, when viewing the IMS LD level B, this current status is not that easy to see nor to reproduce, because the workflow can depend on the students themselves because of the properties and contitions. Even more, there can be sometimes that this status is impossible to represent (we mean, the exact path that the student has not completed yet), because the conditions change during the lifetime of the course. This gets even more complicated when viewing IMS LD level C, because it adds the notifications, wich combined with the conditions and properties of level B, can make the play to follow a path impossible to represent. But no matter what level the student is viewing, he is able to see what he or she have already done.
The player is the part of the IMS-LD package that present to all the + roles of the unit of learning the different activities in a sequence + ordered way based on the properties and conditions.
When deciding how the player should interact with the user, we + thought two different implementations:
Show a little portlet to the user that indicates the next + activity to complete, showing the corresponding link to the + appropriate .LRN package.
Render all the information in a single window, in a centralized + way. Something that the LORS package currently do when playing an + SCORM document.
After analyzing each one of these approaches, we concluded that + rendering all the information in a single window was the better option, + because we think is more simple for the users (teachers and students) to + centralize the visualization instead of following different links, and + also it can give us some kind of control of what the user is doing, and we + can be sure of what the user is actually seeing on his/her screen.
Also, for example if the activity is a forum and we redirect the + user to this forum, the user can easily get distracted and end up reading + a forum that does not form part of the activity. In the other hand, if we + render the forum inside a centralized window, we have the control on the + user's window, and by using some kind of frame, we can easily show any + important message to the user and be sure (well, not entirely), that + he/she read it. Besides, in this centralized window we can show in the + bottom the activities that are completed and, when possible, the ones that + are yet to complete.
Therefore the selected option is the single window. The users + (students, professors, etc.) will see in the single window in a concrete + moment of time, some resource associated with an activity. The user will + have at the left hand a list of the possible activities that he/she can + see in a concrete moment (this depends on the design of the course). The + student can select between the activities presented. Also for each + activity it will be a description that will be shown always if the current + activity is selected by the user (this description will appear in a little + space), and also the user will be able to choice between the different + resources of the associated environment of the activity. Therefore the + student will select between the given resources for the activity. These + resources can be any of the .LRN services or learning objects as files + that comes for example in the IMS CP.
The activities presented to the different roles will change in the + time depending on the different properties and conditions. For example, it + can change depending on the evaluations of the professors, on the results + of the assessments, on the user models, etc. Therefore not all the users + will see the same information because it is personalized depending on + conditions. Also different paths in the workflow can be defined based on + roles.