[FEATURE] UI: add UI\Component\Transfer component family

[thibsy]

Hi folks,

This PR implements a feature request to visualise the permanent-link inside the footer as a QR-code, in addition to the copying mechanism.

To implement this we propose a new transfer UI component family, whose purpose is to provide components which allow users to transfer specific information from one medium or context to another. The first of which is a UI\Component\Transfer\Link component, for transferring a link such as the permanent-link.

We propose a new component family instead of a new UI\Component\Link\Sharing component, because a family allows for variety in information, whereas a new link component would have only allowed us to transfer links. We believe transferring information will also be useful for different purposes, like inline- or multiline-text (notes/messages), inline- or multiline-code (KS documentation), tokens (anonymous access), etc. The new family allows us to provide semantic descriptions of these transfers in the future.

With that being said, lets dive into the new component. Since the relevant semantic description etc. can be found on the corresponding factory methods, I will focus on what I have implemented and why:

• UI\Component\Transfer\TransferMechanism: instead of implementing dedicated mutators on our composable DTO, I have used an enum to describe the different transfer mechanisms. This allows us to be very flexible in terms of what instance of a transfer provides what mechanism in which order. Mutators would not have allowed to accept different primary mechanisms for example.
• Feedback as button labels: I implemented the feedback which is conveyed to the user as the label of the triggering button elements. This should be an appropriate solution in terms of accessibility, however there is one caveat mentioned below. I do believe a solution using tooltips would be more user-friendly, especially for sighted users, but the way tooltips currently work is not flexible enough.
• Primary transfer mechanism: since there will be cases where only one transfer mechanism is provided, it made sense to use a visible button label then. Since there could potentially be many mechanisms (even more than 3), it does however stop making sense to provide one for all of them. This is why I decided to highlight the primary transfer mechanism by adding its visual label in all cases, while leaving it for optional additional mechanisms. This is however what led to the caveat mentioned below, deciding to show this label only to screen-readers would solve this problem – but I'm actually happy with the result and would try to solve this using CSS first.

Known caveats:

• The label of the permanent-link inside the footer is added using <strong> tags. This is done to match the current "headings" inside the Footer and works for now, but it will break once we introduce proper headings there. A viable solution is not implemented here, but could be done via context rendering.
• Buttons of primary transfer mechanisms (the ones with label) change in size while a status message is temporarily displayed. This is due to different text lengths. @BettyFromHH is this something we can solve?
• Images with an action obtain weird borders if focused using the keyboard. This is a general issue, see https://mantis.ilias.de/view.php?id=47812
• Symbols inside buttons become unrecognisable while hovered. This is a general issue, see https://mantis.ilias.de/view.php?id=47806

Not yet finished:

• Php unit tests covering the new components and features, as well as to amend some existing ones, mostly due to the introduction of the refinery to all component renderers.
• JavaScript unit tests covering the new components and features.
• Rounding some last corners and adding some polish in (S)CSS and templates.

I'm looking forward to the initial feedback from all assigned authorities. The most important input will be from @Annett7811 regarding accessibility, as this will influence the next steps.

Kind regards,
@thibsy

[thibsy]

[BettyFromHH]

Hi @thibsy,

Wow - that's realy cool stuff. 😎👍

I'd like to point out a few minor things:

1. In my opinion, the copy button (like the other two) shouldn't have any text (like the other two). @Annett7811 , what do you think?
2. The text box should be to the right of the buttons and span the entire width so that the link is fully visible.
3. Clicking the text box shouldn't trigger a selection; instead, the link should be automatically copied to the clipboard - just like with the copy button.

Furthermore, I have the following questions regarding the QR codes:

• What format will the QR code be generated in? SVG?
• Are the size (e.g., 1000 x 1000) and the QR code parameters (round dots, colors, error correction) adjustable in the php code via variables?
• Is it planned that the QR code will also integrate the favicon in the center?
• Will there be a "Copy" button in the QR code modal? Because one of the most points QR codes are use is in presentations oder prints. Therefore it schould be possible to copy it.

Regarding your questions:

• We'll certainly get the issue with the primary buttons sorted out quickly. I don't foresee any problems there.
• We will fundamentally solve the border issue with ILIAS 12. The same goes for the problem with the symbols when hovering.

Please let me know, if you need assistance on SCSS.

PS: I realy like that. 😊

[thibsy]

Hi @BettyFromHH,

Thx for your feedback, much appreciated!

Let me try and answer your questions / remarks:

• Just for clarification, the label will be added to the "primary transfer mechanism", especially for the scenario where there is only one (I imagine there will be cases). IMO it makes sense to provide the label then, so the act of transferring is conveyed to the user very clearly. We could arguably do this only if there really is just one mechanism. But I have no strong opinion here.
• Regarding your suggestion to place the input after the actions, doesn't it make more sense for sighted and non-sighted users alike, to show them the information which should be transferred before giving them the option to perform said transfer? During my research, I never stumbled over a feature where the actions were presented first. But it may not have been the most thorough research =). Nonetheless, I agree that it would probably make sense to give the input more width in general.
• Regarding your suggestion about the input behaviour: I wouldn't change the browsers default behaviour. Its only the representation of the payload that matters to me. I am therefore open to change element there, maybe a differently styled span also works. But I think using an input there provides users with the possibility to interact with the payload – basically for free. And since users can interact with the payload there, I would also not bind any transferring logic to it.
• The QR-code functionality was actually added in a separate PR, see [FEATURE] Data,Refinery: add QR code support #11391. It allows us to transform an URL into an SVG-QR-Code, which is ultimately transformed to a Data-URI that is embedded directly as the images source. It is possible to change its size in pixels and error correction level. It is however not possible to e.g. include the ILIAS logo inside of it.
• Regarding the copying action of QR-codes, I think this is a good idea. I will check if there is still capacity for this after the unfinished tasks are done.

Kind regards,
@thibsy

[BettyFromHH]

Hi @thibsy,

Thanks for your explanations.

Yes, regarding the point about "displaying the link first, then the buttons," you are right that this order makes more sense. However, if we widen the input field, the buttons would end up positioned at the far right edge. From a UX perspective, that could be rather suboptimal. That is where the idea came from.

Theoretically, we could also simply omit the input field - as was done in ILIAS 10 and 11 - and instead display the text "Permanent Link:" followed by the three buttons. After all, I am not sure whether displaying the actual link provides any real benefit to the user.

But as I always say: Implement it, test it, and then tweak the parts that aren't working well.

[Annett7811]

Hi @thibsy!

I’m thrilled—it really turned out beautifully. Thank you for all your work and careful thought. 😊
As for the labeling, I completely understand your point of view.

In this case, however, I would argue for consistency: either all buttons should have visible text (e.g., below the icon) or none should.

From an accessibility perspective, visible text would of course be the best solution. Then the function would also be immediately clear to sighted users—even if the meaning of an icon isn’t immediately obvious. In this case, the icon would be decorative (aria-hidden=“true”), while the text provides the actual meaning.

If, on the other hand, you decide to use icon-only buttons, they absolutely must have an accessible name (e.g., via aria-label or visually hidden text) so that screen readers can correctly describe the function.

I would also recommend displaying the information itself first and only then offering the options for further processing or the actions. If the order is reversed, I initially have no idea what, for example, is being copied, saved, or transferred via a QR code.

Best regards
@Annett7811