Show Advanced KnowledgeHide Advanced Knowledge

General Kiosk-Mode

1 Initial Problem

A kiosk mode is understood to be a special mode to display certain applications, or in the ILIAS context, certain views in an application where the user gets less control over the application or feature than usual. This is traditionally used for the unsupervised operation of the application at public locations like museums or train stations, where the user e.g. should not be able to perform otherwise common operations like closing a window or shutting down the system.

Similar requirements arise in ILIAS for different objects and different scenarios:

1. A Test needs to be displayed in a restricted way for the use in an E-Exam.
2. The LTI-Interface needs the ability to display objects in a Kiosk-Mode when it ILIAS is used as a Tool-Provider.
3. A yet to be discussed feature to sequences multiple objects will require a kiosk mode to maintain control over the general display and navigation.

where scenario 1 and 2 are already implemented.

Despite the two existing implementations, a common idea or interfaces for a general kiosk mode is currently missing.

2 Conceptual Summary

We propose to implement a new services and maybe library-like functionality that defines an interface, requirements and maybe tools for a general kiosk mode, open to be implemented and used by all ILIAS-objects.

The Kiosk-Mode then needs to be implemented for the individual objects:

• ILIAS Learning Module
• SCORM Learning Module
• Test
• Survey
• Exercise
• Content Page
• Implement General Kiosk Mode for Files

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

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

Please have a look into this Pull Request.

5 Contact

• Author of the Request: Klees, Richard [rklees]
• Maintainer: {Please add your name before applying for an initial workshop or a Jour Fixe meeting.}
• 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

JourFixe, ILIAS [jourfixe], 16 JUL 2018 : We discussed the related PR and accepted it (incl. change in rule). To schedule this feature finally we would like to have an example of how an object (e. g. content page or test) would look like in the kiosk mode (chap 3.2). We keep the discussion open how a kiosk mode could be used for the current LTI kiosk mode implementation.

VC Meeting 20 July 2018 (Michael Jansen, Björn Heyser, Richard Klees, Stefan Schneider, Alexander Killing (minutes)):

• Goal
  • Make Kiosk view easily usable for LTI, Exam, Wiki, ..
• General Questions
  • Player
    • Current idea is that there will be separate players for LTI, Learning Sequence, ...
    • Player calls Views and their updateGet updatePost methods, delivers state
  • Controls
    • Form Actions can be retrieved via post_link callable
    • there should not be Forms or Tables in the set of Kiosk Controls
    • Content can contain interactive elements but must retrieve link urls and form actions from kiosk service
    • Players will render control different than in the standard feature (e.g. forum tree)
    • It will be different to use current old school elements like ilTable2GUI, since they need special parent GUI classes in the constructor
    • All code that is using ilCtrl for action/links needs to be modified (might result in lots of changes in T&A)
• State
  • "Table of content" node states are handled differently (not persisted in Kiosk state, fed from business logic) from GUI states like show/hideTree (will be persisted by Kiosk state)
  • GUI states are needed by learning sequence to resume with the last state
  • saving last sequenz ID of questions in T&A would be possible, but: View would need to check states from the player agains business logic persistence. Most probable T&A would keep this data in its of persistence.
• Possible Approach
  • Separate Kiosk View (no MainMenu, shorter/no breadcrumbs) from Player (Controls/State) requirements
  • We agree that requirements affect different levels within the UI
  • Important: However the solution is implemented, it should be avoided that components are rendered first and hidden in the output afterwards.

8 Implementation

The actual service was implemented via this PR. Since this is an internal service, screenshots cannot be provided.

The Service is used by the Introducing Learning Sequence Object and implemented by the Content Page

Test Cases

Since this in an internal service, no cases for Testrail can be provided. The functionality of the service is covered by the test cases for the Introducing Learning Sequence Object.

Approval

Approved at {date} by {user}.