Feature Wiki
Tabs
Implement Kiosk-Mode for Test
Page Overview
[Hide]1 Initial Problem
General Kiosk-Mode aims at introducing a general solution for displaying ILIAS-objects in a Kiosk-Mode. This solution should be implemented for the Test.
2 Conceptual Summary
The Kiosk-Mode should be implemented according to the General Kiosk-Mode.
In order for the test to be integrated correctly into the learning sequence player, some controls have to be "exported" as controls (buttons, viewcontrols) in the learning sequence tool bar. Besides there are some screens that produce their own "underworlds" which need to be dealt with since there are no tabs (and thus no "< Back to ..." tabs) in the learning sequence player.
These underworlds will be tackled by control buttons.
The general idea is:
- question + answer options und shy action menu of question is displayed in central main area
- question list is displayed as local navigation on the left (or slate)
- next / previous buttons move to the top tool bar
- buttons like "Show Questionlist" move to top toolbar
- tab "Results" and its subtabs each get a button in the top toolbar
3 User Interface Modifications
3.1 List of Affected Views
Learning Sequence > Play / Start
3.2 User Interface Details
Screenshot 1 - Start-Page Test in LSO
Screenshot 2 - Test sequence in LSO
Screenshot 3 - Test results in LSO
Screenshot 4 - Detailed test results in LSO
Screenshot 5 - Detailed test results in LSO 2
Screenshot 6 - Competence results of Test in LSO
3.3 New User Interface Concepts
{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}
4 Technical Information
Heyser, Björn [bheyser] Some technical aspects I need to point on.
IMHO I will need to rewrite the codebase since I need to make nearly anything my testplayer does differently. Since the test itself also provides a kioskmode called exam-view, it makes a lot of sense to rewrite the player component with the strategy kiosk view first. Even the regular test player that is rendered within the regular ilias screen should be implemented as kiosk mode player. Only this way we can avoid multiple implementations that needs to be maintained.
Another point is that the kioskmode within the test itself does behave differently to the the kioskmode view concept here. The test internal kiosk mode does not start with the info screen, but with the first question or the question list. Also it does not end with presenting the results, but with a redirect to the results screen within the regular test object context.
My kiosk mode view impementation will need to detect the object type for the current ref_id. As an alternative the general kioskmode could be extended to push the object type of the player to the kiosk mode view.
I also studied the implementation of the content page kiosk mode view and I stumbled over an overwritten method of ilPageObjectGUI that does reparse the complete page to add _blank targets to all kind of links to avoid navigation to outside the learning sequence. Either the Assessment Question Service maintainer will need to do the same, or the Content Page Service could be extended to accept an external link builder. Also TinyMCE contents need to be transformed with a target _blank for all links. These transformations will need to be done on every page load. Either way the Assessment Question Service needs to be extended to get any information passed that the question is to be played within a kiosk mode view.
Also the presentation of tables will be a problem. Currently I am using ilTable2GUIs all over the test. I comes with the depency for a parentObjectGUI and the kiosk mode view cannot provide such a GUI. I could implement a ilTable3GUI that gets rid of this requirement within the constructor. I could than call the parent constructor with any pseudoObjectGUI. Luckily most of my tables does not come with sorting, pagination or coulumn selection features. But this also means, that when I need to attach such functionality in the future I will need to overwrite all methods that render links (column headers, pagination, column selector) to get the url builder used for generating links. An alterntive could be the migration to modern UI tables. At the moment I dont know wether it comes with similar depencies or not, since I did not get in contact with them, so I am unexperienced.
The last point is about requirements to the navigation and the submission of formdata within the test player. The documentation says that controls rendered by the kiosk mode player must only trigger GET requests. At the time beeing all these controls get a javascript event listener attached that triggers a form submission as a POST request and adds a next url parameter that is used for a redirection. With a planed fix of this open redirection vulnerability this behavior will change a bit. The form submission will be done as an ajax request and the callback will trigger the GET request the control was provided for.
Nevertheless the implementation for a test kiosk mode view needs to attach eventlistener to the controls that are rendered by the kiosk mode player. I am able to do this by finding the buttons with jQuery and attach my javascript code. But I ask my self if this is the correct way. Everytime the rendering of controls may change in the future I would need to repair my javascript event attachings. As an aternative the general kiosk mode interface could be extended in any way to handle this kind requirements.
5 Contact
- Author of the Request: Richard Klees and Marko Glaubitz
- Maintainer: Heyser, Björn [bheyser] for Test Player and Klees, Richard [rklees] for LSO
- Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}
6 Funding
If you are interest in funding this feature, please add your name and institution to this list.
7 Discussion
Kunkel, Matthias [mkunkel], 14 AUG 2019: Thanks for this suggestion. I fully support to get more object types into the LSO. Just one tiny suggestion for modification: We could reduce the number of shown buttons on screens 3 to 6 - and save some space in width and have less clutter - by using a split button for "Ergebnisübersicht" (default), "Detaillierte Ergebnisse" and "Kompetenzergebnisse". This would also be a good moment to get the Split Button into the Kitchen Sink.
Strassner, Denis [dstrassner], 14 AUG 2019: Just so I understand: this is just the test kiosk implementation for the LSO?
Falkenstein, Rob [rob], 14 AUG 2019: yes
Heyser, Björn [bheyser], 23. August 2019 : In the background it is also the implementation for the kioskmode within the test itself. It does not make sense to not use the general kioskmode interface also within the test, because the testplayer needs to be fully refactored either way. But for the test internal kioskmode there is no need for any conceptional discussion, it will be present as usual.
Glaubitz, Marko [mglaubitz], 2019-08-23: I don't really know, whether I get what you (Heyser, Björn [bheyser]) are aiming at exactly. Our goal is for the test to snuggle nicely into the Learning Sequence Player (as we have discussed already in numerous sessions). I unserstand that there is already something like a kiosk mode (not quite in our sense of the word) that has been implemented for the LTI interface, which (sadly) is not really reuseable for the Learning Sequence.
However, we are aware that some parts of the test player need to be refactored in order to work properly within the Learning Sequence. We fully accept this fact and we have funding to implement this feature. We really want to see this in ILIAS 6.1 (since 6.0 was not possible due to the huge Question Service refactoring).
Are there any open conceptual questions as to how the test integrates itself into the Learning Sequence GUI?
Heyser, Björn [bheyser] 23. August 2019: I have thought about fullfilling the requirement described above a lot this week and I came across several aspects I need to point on. One aspect conceptional aspect is descibed below. Some further implementation-related technical issues came up that I documented within chapter 4 (Technical Information).
One conceptional point is the question list positioning as well as the presentation. The feature request Continuous Testing Mode Usability Improvement will change both. The question list will be presented as a workflow on the right side of the screen. The current concept described above is based on the former concept of the question list. We need to talk about this, I currently have no idea.
JourFixe, ILIAS [jourfixe], 26 AUG 2019 : We highly appreciate this suggestion and schedule the feature for ILIAS 7. Richard, Björn, Martin (and Alex for COPage) will discuss implementation-related issues directly.
8 Implementation
{The maintainer has to give a description of the final implementation and add screenshots if possible.}
Test Cases
Test cases completed at {date} by {user}
- {Test case number linked to Testrail} : {test case title}
Approval
Approved at {date} by {user}.
Last edited: 26. Aug 2019, 17:23, Falkenstein, Rob [rob]