Feature Wiki

Information about planned and released features

Tabs

Add QR Code Button to Footer for Page Permalink

1 Initial Problem

Sharing and typing links is cumbersome on desktop PCs and notebooks, but especially on mobile devices. Over the years, QR codes have proven to be highly effective for sharing links and other digital content, particularly for mobile usage.

2 Conceptual Summary

Add a button in the ILIAS footer next to the existing permalink copy button that opens a modal displaying a QR code. This would allow users to directly participate in surveys and polls by quickly accessing the object, or obtain a direct link to a course or a group they can join.

There are already several feature requests that align with this proposal and can be linked:
  1. QR-codes to sign up for courses
  2. QR Code for Poll
  3. Better Connect Classroom and Mediacast
  4. Info Page: QR Code for Permanent Links

 

3 User Interface Modifications

3.1 List of Affected Views

  • Footer

3.2 User Interface Details

According to the Footer KS Documentation, "section 1 (permanent-link) is composed only of a link to the current page, which can be copied by users." This rule would not be violated, as the proposed feature still only provides the link—this time additionally in the form of a QR code.

The mock-ups demonstrate two options: a standard button and a shy-button for displaying the QR code.
The documentation states under the Purpose of the Footer: "shy-buttons for triggering internal dialogs." Using a shy-button would be particularly effective, as it could incorporate an icon (see Screenshot 2) that visually indicates the button's function. Or you can simply use the icon itself as a button to trigger the modal (see screenshot 3).
However, the shy button is somewhat inconspicuous compared to the standard button and might be perceived less clearly, which is why a standard button, even without an icon, could be the better choice. Here, the UI/UX experts should be consulted.

The last mock-up shows the QR code containing the permalink to the object displayed in a modal triggered by the button. The Lightbox Image Page Modal was used for the presentation, shown in light mode rather than dark mode, as the QR code displays better in light mode.

Footer including a button for QR codes
Using the standard button
Footer including a shy button for QR codes
Using the shy button
Footer including a shy button for QR codes
Using the shy button only as Icon
Display a modal containing the QR code for the object's permalink
QR code in modal

3.3 New User Interface Concepts

A new KS component 'QR Code' is required. It should take a string as input, and return the corresponding QR code as an image.

3.4 Accessibility Implications

{ If the proposal contains potential accessibility issues that are neither covered by existing UI components nor clarified by guidelines, please list them here. For every potential issue please either propose a solution or write down a short risk assessment about potential fallout if there would be no solution for the issue. }

4 Additional Information

4.1 Involved Authorities

  • Authority to Sign off on Conceptual Changes: {Please add related profile link of this person}
  • Authority to Sign off Code Changes: {Please add related profile link of this person}

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

QR codes should be generated server side, e.g. using endroid/qr-code. A variety of similar libraries is available, so there is no risk of getting locked into a dependency.

The QR code KS component should offer options for different error correction levels and sizes for the generated code. Reasonable values of those parameters depend on the expected length of the string, and of the context of its usage (QR codes that are printed on paper benefit more from a higher error correction than those shown on a screen, for example).

4.3 Privacy

{ Personal data that will need to be stored or processed to implement this feature have to be listed here. For each date give a short explanation why it is necessary to use that date. }

4.4 Security

{ Does the feature include any special security relevant changes, e.g. the introducion of new endpoints or other new possible attack vectors. If yes, please explain these implications and include a commitment to deliver a written security concept as part of the feature development. This concept will need an additional approvement by the JourFixe. }

4.5 Contact

Person to be contacted in case of questions about the feature or for funding offers:  {Please add related profile link of this person}

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

5 Discussion

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.

Last edited: Yesterday, 14:54, Becker, Matthias [matthias.becker]