Show Advanced KnowledgeHide Advanced Knowledge

View Service

1 Initial Problem

Particular cases of editing-, learning- or assessment-settings but also the new suggested LTI feature require a special (kiosk) user-interface on ILIAS:

• LTI Kiosk Mode
• kiosk mode for all ILIAS objects
• KIOSK Modus
• Safe-Exam-Browser Plugin
• Preview as Learner

Most of the features are realized as a UIHook Plugin, some of them are “patched” into the Service or Module classes. But with the introduction of LTI we realized that we need a scalable and sustainable solution for such requirements. Above all we cannot add a Service into the trunk with dependencies to a plugin. Modifying all relevant classes (p.e for the LTI kiosk mode) is just as well unattractive and unsustainable.

2 Conceptual Summary

Therefore I would introduce a new view concept. In contrast to a skin which defines a system wide customized ILIAS design, a view offers (in most cases) a functional reduced or customized user interface that can be switched on and off by special trigger like service and environment settings but also button events which are defined by the appropriate service or module. A view may be a part of a Service or Module. For example:

• The LTI Service activates a reduced LTI view on user LTI sessions by checking the appropriate auth_mode and the required SESSION variables.
• A (prospective) Safe-Exam-Browser service or a generic exam service may activate its exam kiosk-view by checking the environment variables (a specific browser-key and user-role combination)
• The course module may offer a specific learner preview for course admins (Memberview) which can be triggered by clicking on a button.

1. In detail what else should be controllable via views? In functional reduced views like LTI or E-Exams the following modifications are essential:

• Hiding and modifying several GUI items (header, footer, content and desktop components or blocks)
• Offering a reduced navigation concept, at least jumping back to a home entry (LTI, E-Exam)
  • controlling the presentation of a tree view (show, hide, modify root entry)
  • controlling the presentation of the locator (show, hide, modify root entry)
    • just hiding navigation elements is not recommended: for example a tree may be switched on via another request (view_mode=tree whis is stored in the session) and if the view disabled the tree icon the user cannot hide the tree anymore, its freezed. Maybe we can discuss to completely disable the creation of a tree view. But thinking about usability a tree view may be very reasonable for navigation in huge container objects. I would recommand to ensure the setting of a propper root folder and the treeicon or the locator can be supressed anyway.
  • Breaking out a home repository folder (Container or Module Object) the navigation may offer a link for jumping back to the home (similar to topbar_back_url concept in memberview, whereas in a memberview the topbar_back_url finishes the view and in a LTI or Exam context it jumps back to the home folder).
• Injecting css files into the header
• Injecting inline css stylesheets which are interpreted at the very end (insert just before the </body> end-tag)
• Injecting javascript files into the header

 
2. These modifications are not really essential but conceptual reasonable:

• A Service may define a repository folder within navigation is allowed. The RBAC controls anyway the access via user role and a view may additionally restrict the navigation and the object view for a (temporary) functional purpose. Breaking out the restricted view context could produce an error message similar to the RBAC messages. We can discuss this concept against the background of RBAC. But we should consider that RBAC access-controlling always requires specific user roles, whereas a view may be temporary switched on and off within the same user and role context. For example using the RBAC only for a temporary member preview for course admins would be very expansive, this would require temporary role creation and assignments.
• A Service may define a fix repository folder for tree and locator.
• A Service may define obj_type(s) for tree and locator root folder. For example: ILIAS creates a new LTI session with a reduced view into a course as entry point. The LTI users should also access linked learning materials in other courses within the same LTI session. On accessing external course items the navigation (locator or tree if enabled) switches always to the superior course object as root entry. Another example is that an e-exam view (controlled by a specific combination of Browser Client / Key and User role) always shows course or only test objects as navigation root entries and offers a home button to an entry exam object or a reduced desktop.
• A Service may forbidd access to the desktop.

 
Conceptual issues

• The basic idea is that only one view can be active at the same time in a user session ($DIC[$_SESSION[‘il_view_mode’]]). If there are views like Exam and LTI which are checking their activation early in the initialisation state, they may compete against each other and the last registered view will win. But in practice it is not reasonable to use a SEB or generic Examview in a LTI session context (if not explicitly implemented as a feature!). Btw every service should provide a way to enable/disable the view. It is not necessary to enable the exam view in a pure learning environment, this could be disabled by default. But we must have this issue at the back of our minds, if we are talking about other upcoming views, which can be activated in the early state.What about other views which are activated later on demand or service trigger like the memberview? If the factory controls all view activation and deactivation there will be a global and transparent view control flow. For example: If we are in a LTI Session as course admin (not really the default case) and we switch on the member view (with its own red main menu and topbar, backurl and so on), this could be done only by the factory and after leaving the memberview the factory ensures the reactivation of the last view (in this case the LTI view). Should memberviews get their ownl look and feel in a LTI environment the LTI Service may define its own memberview for LTI sessions.
• Views should be able to produce their own messages. UIHookPlugins make use of the ilUIPluginRouterGUI to hook into the ilCtrl command chain and a view can use the same concept with ilViewRouterGUI defined as baseClass in the Services/View/service.xml.

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, please provide a link to separate feature wiki entries for each of them according to the kitchen sink template.}

4 Technical Information

How could services and modules be enabled for the registration of a specific service / module view?
Service and module views can be registered in a View Factory (/Services/View/class.ilViewFactory.php, similar to the registration of specific Service AuthModes in the AuthFactory). A new function “initViews()” just before initStyles() in the class.ilInitialisation.php/initHTML calls the factory init function which initializes all registered views and if checkActivation of a view returns true (for example LTI view/service checks for an existiing lti auth_mode) a global ViewObject is created and available for other components. The administration of a service should support a feature to enable/disable a view. For example: Examview is not needed in pure leraning environment. We could think about defining the standard ilias as the default view as well? So we do not need to distinguish between is there any SESSION[ 'il_view_mode'] or not. The factory may activate the default view as first object and the appropriate classes process the object for the gui modifications. For example the ugly switches for processing the gui modifications like the topbar mods in class.MainMenuGUI.php could be cleaned up.

How do we ensure, that a view object contains all the necessary properties and functions for the appropriate classes which process the view object?
Services and modules views (which are located in their services|modules class folder) must extend the abstract class /Services/Views/class.ilBaseViewGUI.php. In this class all necessary properties and functions are (pre)defined or abstract. The advantage over an interface design is that the views do not need to implement all the (predefined) funtions and settings. For example the base class could support most of the default ilias view settings (showTree=true, showMainmenu=true...), so the default view instance could be defined with minimal code and it is not epansive to define a lite view which just needs a modification of the topbar (like the memberview).

In which way a view can modify the gui components?
with the introduction of the UIHookPlugin we got a powerfull tool for gui modification. For the first implementation of a generic view service a view should be able to process the same UIHooks as a Plugin. We have to discuss the duplication of the plugin hooks to the view service... is there any way to merge these requirements? How we can reduce the payload of a duplicated hook design:

• If a view do not need the uiHook it can be switched off
• standard modifcations like injection of css or javascript or a "topbar only view" or disabling the tree or desktop should be supported in a generic way by the view settings (=> classes which processes the view object need to be modified, for example ilTemplate should support adding css files from the view object.)

We need to discuss the different approaches. I would at least recommand the outsourcing of some blockvariables into blockfiles like the "USERLOGGEDIN" or "HEADER_TOP_TITLE" "HEADER_BACK_BL" from the tpl.main_menu.html but we should discuss the issues of a modular design for particular gui components in detail. For example all views which needs a reduced topbar like E-Exam, LTI, Memberview need to replace the whole main_menu.html template output and have to reimplement such things like the userloggedin or language menus in customized template files, changes in the core templates needs to be reimplemented. Enabling or replacing only small parts of the template instead of reimplementing the whole html output reduces the risk of disfunction. Another advantage of smaller functional blockfiles makes this parts available for processing via UI addBlockfile hooks from the template engine.

5 Contact

• Author of the Request: Schneider, Stefan [sschneider]
• Maintainer:
• 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

Schneider, Stefan [sschneider] 13.03.2017: If i understand the concept of the ILIAS UI Framework in the right way, i don't think such a View Service should be a part of it. The View Service should not define any new UI/KS components, but we can discuss this issue in the View Service Workshop.

Killing, Alexander [alex], 13 Mar 2017: Some thoughts:

• The determination of the "view" (however this will work) should be done during initialisation process. There might be some handling of conflicts if multiple components can/try to affect the "view". Once the flow of control is being forwarded by ilCtrl, this should be settled and unchangeable. 
• Extending ilAccessHandler could be a way to achieve the limitation on repository subtree navigation. RBAC would not need any modifications imo.
• I think there is also a part that should go to the UI Framework: A top level container defining header, footer, content, ...

Amstutz, Timon [amstutz] 13. March 2017: If I understand this FR correct (of this I am not sure), this service describes only how ILIAS decides in which context/case which screens in ILIAS should be used. It does not describe what those screens are or how they look.

E.g. Context course has setting XY (Kiosk Mode) -> Test tells to view Service to generate a test in the kiosk mode -> view Service generates this view (e.g. by using several UI Components from the framework). Correct?

Strictly speaking this view service could make use of ILIAS UI as long as it already exists. However, I would suggest, that if we start refactoring larger parts of e.g. logic around tpl.main_menu.html, we should really think about generating those instances in the new UI-Framework.

I am looking forward to the workshop and I am sure, that those things clarify as soon as discussed.

Schneider, Stefan [sschneider] 21.03.2017: After discussing this feature in the View Service Workshop here a short summary:

• the implementation of a core kiosk concept for the described use cases is appreciated
• introducing a new service with its own control-flow and access handling was rather disclaimed, but we need further discussion how we can approach the requirements of the different kiosk modes.   
• we should separate the access control from the ui kiosk components
• the AccessHandler may be the right place for the access control in a special kiosk session
• we should try to incorporate the new ui framework to define our kiosk components like topbar, footer, mainmenu, desktop elements and how we can use of the new DIC concept in a reasonable way
• the concept of ui hooks should not be involved in a core kiosk feature (bad performance and design)   
• next steps:
  • specifying detailed ui view and access control requirements for discribed kiosk modes (Stefan Schneider, Uwe Kohnle...) and feedback to the whole workshop group and then:
  • exploring AccessHandler, DIC and ui framework for a scalable solution (Alex Killing, Richard Klees, Timon Amstutz...)

Schneider, Stefan [sschneider] veröffentlicht am 27.05.2017:

Protokoll Skype VC am 27.04.2017

LTI-Kiosk / Allgmeiner Kiosk Mode / UI-Framework / ILIAS 5.3

Teilnehmer:
Matthias Kunkel, Richard Klees, Timon Amstutz, Uwe Kohnle, Stefan Meyer, Stefan Schneider

Problemstellung:

Um einen LTI Kiosk oder sogar einen allgemeinen Kiosk-Modus vollständig mit dem UI-Framework in ILIAS 5.3 bis zum Code Freeze Ende August 2017 umzusetzen fehlen die nötigen zeitlichen Ressourcen.
Hierfür müssten große Teile von ILIAS wie bspw. das MainMenu, die Template-Klasse usw. zunächst als UI-Komonenten umgebaut werden.
Trotzdem gibt es einen gemeinsamen Konsens das LTI Feature für 5.3. umzusetzen.

Lösung (als Basis für den JF ggf. 16. Juni):

1. Da das MainMenu eine zentrale Rolle bei Kiosk-Szenarien wie LTI aber auch Examenskiosk spielen, wird versucht bis Ende Juni zu analysieren, ob es möglich ist, bis Ende Juli das MainMenu als UI-Framework Komponente umzusetzen (Richard, Timon). Im August könnte dann die Implementierung eines LTI MainMenus durch den Austausch des Renderers oder einer eigenen Implementierung der Schnittstelle geschehen (Schneider). Sollte dies nicht möglich sein, wird ebenfalls wie beim MemberView die MainMenu Klasse angepasst werden müssen (siehe Punkt 2). Ggfs. werden auch Header und Footer schon als UI-Komponenten zur Verfügung stehen und könnten für LTI Kiosk genutzt werden.

2. Alle weiteren betroffenen UI Bereiche wie Locator und TreeIcon usw. werden, soweit sie nicht als UI-Framework Komponenten bis Ende Juli zur Verfügung stehen, über die bestehende Implementierungen aus dem DHBW Patch / ViewService übernommen (Schneider).

3. Es soll KEIN ViewService als zentrale UI-Steuerungskomponete neben dem UI-Framework als Konkurrenz im Core etabliert werden. Soweit Teile des ViewServices und Klassenanpassungen für LTI in 5.3. dennoch benötigt werden, müssen diese klar im Code abgegrenzt sein und im Rahmen einer definierten Exit-Strategie sukzessive im UI-Framework aufgehen. Ziel ist es, zeitnah einen Workshop zu einem allgemeinen Kisok-Modus zu organisieren um für 5.4. eine vollständige UI-Framework basierte Umsetzung zu erreichen (alle Teilnehmer).

4. Die Kiosk-Zugriffskontrolle soll mit Hilfe einer Erweiterung der AccessControl Klasse umgesetzt werden.

5. Es soll wenn möglich kein UI-Hook zum Einsatz kommen.

Verschiedenes:

- Zum besseren gemeinsamen Verständnis wird der aktuelle bestehende ViewService in einem eigenen Branch als Patch zugänglich gemacht werden (Schneider: Zugang für Richard, Timon).
- Weiterhin sollten Projekte die weitreichende Änderungen in ILIAS nachsich ziehen oder voraussetzen wenn möglich in Zukunft noch früher in der Community transparent abgestimmt werden.

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}.