4.6 Initial situation

Two types of IDs are currently relevant for online help:

4.6.1 Screen IDs

In the current versions of ILIAS, the current screen IDs (for individual views, e.g. rights tab in a wiki) are explicitly set by the maintainers of the respective components. The functions of the ilHelp service are available for this purpose:

1
2
3

ilHelpGUI::setDefaultScreenId($a_part, $a_id)
ilHelpGUI::setScreenId($a_id)
ilHelpGUI::setScreenIdComponent($a_comp)

These methods must be called manually by the maintainers of a component in order to specify the current view more precisely and thus to be able to offer the online help a screen ID to which the corresponding help texts refer.

If no screen ID is set in a component, there is currently no concrete indication for the online help as to which view the user is on and thus no or only unspecific help texts can be displayed.

4.6.2 Tool-Tip IDs

The tooltips (and in future also other features such as Guided Tour) currently refer to CSS IDs or, since the changeover to UI\Page, to other CSS selectors. Tooltips are always displayed specifically for an element on the current page. Therefore, the HTML elements to which tooltips refer must be clearly identifiable.

With the switch to UI components, more and more specific (self-named) CSS IDs are being dropped. The UI service uses generic CSS IDs and no own CSS IDs assigned by the maintainers are used, e.g. to avoid collisions when assigning CSS IDs and to make JavaScript code not dependent on CSS IDs. The concept and the reasons behind it are generally important and correct, but make the work of the online help or Guided Tour features much more difficult.

4.7 Identifiability of elements and views

4.7.1 Sreen-IDs for all Views

The GlobalScreen service provides an interface between components and the final output and rendering of a page. For example, tools, menu items or other elements of the global page structure can already be supplied by a component, the GS service manages these and passes them on to the rendering of a page.

With the introduction of tools, a so-called ScreenContext was already introduced. This contains information about the current views, but so far only very little and only to give tools the possibility to be displayed context-sensitively.
The ScreenContext should be able to provide much more information to support client-side features such as the online help and Guided Tour, in order to be able to operate the help service with reliable screen IDs that exist on every view. In addition to a unique ID generated for each page, it should also be possible to request further information, such as the RBAC context (does the current user have write or read-only rights?).

For this purpose, the ScreenContext introduces new general pattern called "Purpose". A "Purpose" indicated what an element of a whole view is about. A distinction is made between MainViewPurpose and ViewPurpose.
Some examples:

As long as you are in a Wiki, the MainViewPurpose is the "Wiki". Depending on the view, other ViewPurposes appear below the "Wiki" Purpose, such as "Editor" or "Edit", or "Rights", "Export", ...

A wiki can also be found in the MainViewPurpose "Repository" or within a course. From the point of view of a screen ID, however, MainViewPurposes always represent the first level. A screen ID is therefore composed of

"Last MainViewPurpose (if any)" / "ViewPurpose" / "ViewPurpose" / ...

In principle, this is the same as the previous IDs, although there may be differences due to the implementation.

What mainly changes, however, is that each view must provide such Purposes. This will be taken care of by an interaction of the current routing (ilCtrl) together with the GlobalScreen service.

ilCtrl assigns interfaces for all executing GUI classes (aka CommandClasses and BaseClasses) in ILIAS with ILIAS 9. This interface will not provide any functionality for ilCtrl for the time being, but serves to identify such classes. Using the same mechanism as we implement a PurposeProvider-interface for all GUI classes, we also want to introduce an interface for all these classes in order to be able to request a "Purpose" from them.

In a first step, we will equip each class with a "helper" trait, which already provides a generic Purpose derived from the class name. For example, the ilPermissionsGUI can provide a ViewPurpose('permissions') without further adjustments of the maintainer. In this implementation, we will already take into account that, for example, an ilObjWikiGUI should provide a MainViewPurpose('wiki'), but other classes only a ViewPurpose('xy).
If we already find calls to ilHelpGUI::setScreenIdComponent in a class, we take over this value (in order to get screen IDs that are as consistent as possible).
In a further step, we ensure that the names of the Purposes are unique and that there is no ViewPurpose('permissions') in two different places, for example.

4.7.2 Individual elements such as buttons, MainBar entries, ...

In consultation with Richard Klees in his role as coordinator of the UI component, we would like to be able to implement the possibility of Purposes in the UI service as well. Individual UI components (a list of which is still being worked out, but buttons and slates, for example, must be able to be used) will receive a "withPurpose('specific_purpose_name')".

For example, a MainBar entry can receive the information that it belongs to the Purpose "dashboard_mainbar_item".

In the rendering, this HTML element can then receive an additional attribute data-purpose='dashboard_mainbar_item'. On the one hand, this attribute makes the element identifiable for features such as ToolTips, but on the other hand it can also be used to inform the ScreenContext (see above) that an element with an ElementPurpose('dashboard_mainbar_item') is displayed on the current page. The online help could also refer to this if necessary.

4.8 Types of Purposes