[FEATURE] UI: add Listing\Inline and Listing\Entity\Grid component.

[thibsy]

Hi all,

This PR introduces some new features to the UI framework. At its essence, the PR

• adds a new Listing\Inline component
• adds a new Listing\Entity\Grid component
• adds a new Entity\Entity::withWorkflow() functionality

This was spawned by the following background / motivation:

• the Entity\Entity::withWorkflow() functionality was our solution for the problem we see during object (or entity) creation, where an entity is created kind of as a skeleton, which is filled with content, configured, published, etc. only at a later point – maybe even stretched across several days. What becomes clear is that the object/entity-creation is actually a workflow most of the time. This is why the new functionality now combines these components to speak about this process semantically. The entity will derive "unfinished" steps from this workflow and present them to authors in a structured way. To implement this a new Listing\Inline component was spawned as a byproduct (for horizontal display of properties).
• the Listing\Entity\Grid component was our solution for the realisation that user expectations for entity listings are different depending on their use-case. "Consumers" of an entity need a lighter, less detailed view than authors, who may need to see what steps of the entity creation workflow are still unfinished.
• both of these solutions integrate nicely with the ILIAS repository. Object creation is a multi-step process and authors have the ability to toggle between a view/manage screen. This means the PR already lays some important groundwork for when the repository is finally migrated towards Kitchensink components during the LUI project.

Why we propose to integrate this for ILIAS 10:

We do not have everything in place to fully migrate the repository yet. Making these solutions available for plugins from ILIAS 10 will allow us to gather information for this migration beforehand. Namely this will be the OpenCast plugin, which provides its own sophisticated view inside the repository – making it the perfect candidate to test this before moving forward in ILIAS. There are no breaking changes for any usage of the components affected by the changes of this PR. However, there would be breaking changes for custom version of affected components, implemented by the plugin.

Kind regards,
@thibsy

[matthiaskunkel]

Jour Fixe, 27 APR 2026: We highly appreciate this suggestion and see it as a very ambitious and promising improvement of the UI framework. Until a final decision about this PR it would be great to have some screenshots to visualise the suggested changes. We also wait for the feedback from our accessibility expert and comments from Oliver. In general, we do not see a reason not to accept these changes also for 10 as no breaking changes will be expected – simply because none of these features are used until now.

[thibsy]

Hi folks, here are some screenshots:

---

Grid Entity Listing:

---

Inline Listing:

[Annett7811]

Thank you very much for this very well thought-out proposal. The presented components appear highly promising, and in particular the attached screenshots as well as the presentation within the KS Examples greatly help to better understand the proposed changes and their potential use cases.

From an accessibility perspective, the new workflow-related information offers significant potential — especially if editing states, open steps, and status information are also made programmatically available to assistive technologies. In addition, aspects such as responsive design, different zoom levels (e.g. 200% text zoom and browser zoom up to 400%), as well as possible impacts on reflow, should be considered and tested early on to ensure that the new components remain robustly usable under magnification and on smaller viewports.

The different orientation of the listing variants towards distinct usage contexts (consumer vs. authoring) is particularly interesting. This could also contribute to a clearer and more focused presentation of information.

Overall, I see this as a very exciting and forward-looking foundation for the further development of the UI framework and look forward to the upcoming discussions as well as practical experiences from the planned implementation scenarios.

Best regards,
@Annett7811

[matthiaskunkel]

Jour Fixe, 18 MAY 2026: We highly appreciate this suggestion and accept already the interface changes offered in this PR. A final approval of the PR depends on the official feedback from Oliver Samoila as responsible authority.
The mentione issue about keyboard navigation will be fixed.
Triggered by the different image ratios of the above shown example we agreed that the UI component itself should show a provided image as it is given and decide about its sizes and ratios.
Having this new/extende UI component does not relieve us the obligation to define a strategy for how this UI element will be implemented in the future by the different components in ILIAS. But this is not related to the acceptance of this PR.

[oliversamoila]

Hello @thibsy,
Thank you very much for this extensive work.
I have taken another close look at the latest status and would like to raise a number of questions about it:

Content-related questions on the these UI components:

• Entity\Entity::withWorkflow()
  • Shouldn't the Primary Identifier contain a Headline x? – the way Items in Panels or other objects did in the former ListGUI?
  • Why are the glyphs (glyphicon-calendar and glyphicon-user) clickable, and what is supposed to be behind them? Is this meant to be understood as a Key-Value-Pair, and is it understood as such?
  • What leads to the runtime length of the video being a "Main Detail", whereas "upload date" and "publisher" are each a Featured Property? Is this a decision that will, going forward, be left to every object that is to be represented in an Entity?
  • What exactly are 'Show more' and 'show less'? (Apparently not Shy-Buttons, which we — at least in perspective — don't want to scatter ever more across the system.)
  • May I picture it like this: that in the Repository (or in another place) I see several Entities and then have a Workflow below each of them?
    • Or which container structure is used when there are multiple Entities on one page? In my view, the Workflow sits on the same level as the Entity and is apparently not a part of it.
    • Is this really understood/understandable by users (and screen readers) with regard to the information structure and also an information hierarchy?
  • Can users interact with the video in any way?
    • The same question could be asked for images or audio.
    • Or also for representative images of objects, in order to actually open the object.
  • If I see it correctly, we have 736px as a new breakpoint for small mobile views. Does this correlate with any other behaviors at this value?
• Listing\Entity\Grid
  • My most central question for this is: is this intended to replace the previous tile view (Card\Repository Object in Panels) in the future?
  • The images (a 'Secondary Identifier' in the schema of the Entities) introduce a new size. In order to avoid the conflicts during a UI migration already now, these should be cropped in 3:2.
  • In my view, we need a different placement of the Reaction Bar, because the goal "entity need a lighter […] view" is, in my opinion, directly missed again this way.
  • Please remove the il-glyphicon-love in front of the Like button. This will not be able to work plausibly with what the Like service outputs.

Core Usage

I would also like to say a few words on the perspective of its use in the core:

• The two biggest organizational obstacles to switching to Entities are, in my view: a) clarifying the question of what 'Featured Properties' are. This has to be clarified for every type of Entity. In addition there is b) the dependency on reworking and decoupling from the ilObjectListGUI — one may take the wording with a grain of salt, but to my knowledge this is not possible without work in the Object component.
  • To be clear: I believe that defining the information displayed in ‘Featured Properties’ is a highly valuable task for improving the information quality of our system.
  • see also conceptual docs in https://github.com/ILIAS-eLearning/ILIAS/tree/trunk/components/ILIAS/UI/docs
• If the creation of an Entity across its steps is a central problem to be addressed, then it is to be assumed that this is a problem that applies to all types of Entities. If that is the case, then for a consistently appearing system we need Workflows for all types of Entities. In my view, this is even more questionable than the definition of 'Featured Properties'. In my opinion, the question of whether an Entity should have a Workflow should be strongly distinguished from the question of whether it must have a Workflow. I do not believe that this ‚must' exists here.
• When you say: "authors have the ability to toggle between a view/manage screen", then it would be important to know where users do this? And between which representations users toggles? Or we should make it clear that this is a prospective view. That would be completely fine too.
• For the sake of delimitation, I would like to point out that none of the components marked as deprecated in the "Removing LegacyUI" project would necessarily have to be processed via this form of Entities. Work on these specific UI components is not currently part of the project scope, although I wouldn’t rule out the possibility that parts of them might be used in the future – that would after all be highly charming.

I look forward to hearing from you. Not least because I believe that some of the answers are still important for gaining a better understanding of future perspectives – especially regarding the usages and further developments.

Many many thanks and best regards
@oliversamoila (as UI-coordinator)

[oliversamoila]

Just a quick addition: here are some screenshots showing the latest version.
You can already see some further improvements in it, and it might make it easier for some of you to follow the discussion.

---

Entity\Entity::withWorkflow():

---

Listing\Entity\Grid:

[thibsy]

Hi @oliversamoila,

Thx for the elaborate feedback!

Let me respond to your questions/remarks above:

Content Aspects:

• Entity\Entity::withWorkflow():
  • Primary identifier: I think we should, but we also should not do so until we have a centralised solution for this.
  • Clickable Glyphs: that is defined by the consumer. For demonstration purposes, they feature an action. They could do something, but do not have to.
  • Featured properties: since this is a demo, I haven't given it too much thought. But in general, consumers need to think about this carefully and should refer to the paper on repository items. It would make sense to define things like that on a per object basis somewhen in the future. This will help us figure out semantic descriptions and groups.
  • Show more/less: that is actually a (S)CSS-only functionality that truncates long-ish text. It is implemented as a tool that should be used in the future instead (ping @BettyFromHH).
  • Workflow output: the example might be misleading, because the workflow will only be used to talk about the process semantically and programatically. If the entity is provided with a workflow, this workflow will in fact never be rendered. It will be used to derive actions required to complete object creation. I will make this more clear by simply removing this rendering.
  • Interaction: you cannot interact with the entity listed inside this grid other than by its exposed actions. You do not interact with anything inside this listing directly, the listing or the concrete actions will delegate to the responsible endpoint provided by the consumer.
  • Breakpoint: the listing does not change significantly at 736px. Could you explain what felt odd about the responsiveness during your review? The grid works a little differently due to working with rows and columns, which is why this may feel detached to other breakpoints.
• Listing\Entity\Grid:
  • Replacement: this listing is meant to replace the current solution of the repository. The card and panel are both weak in semantics and should possibly be deprecated and removed or internalised in the end. If we replace the solution with this grid directly is unknown yet. Maybe we need a higher-order component that gives more semantics to the concrete list type and less opportunity for defining options.
  • Image format: we already discussed this at JF, where we decided to require cropping by the consumers. Otherwise we might crop information deemed necessary. I fixed the images inside the examples though, because they were actually not cropped correctly =). There is a usage rule on the factory now too.
  • Reaction bar: I think you raise two concerns here: one being the placement of the bar and the other about its presence. If you agree, I would like to treat this in another iteration. The current placement was by design, since we found several reactions like this featured in this corner.
  • Like-service: I updated to the "like" glyph instead. I think we should not try to mimic the output of this service inside our documentation though.

Core Usage:

• Organisational obstacles:
  • a) I think the paper on repository items gives us a pretty good idea on what featured properties are. Nonetheless, it would be highly beneficial if one person or small group we would categorise all properties of the different kinds of entities we have in ILIAS.
  • b) You are right about the coupling to ILIASObject.
• Object creation workflows: I do not think that it is necessary to implement the creation of all entities in multiple steps. The goal should ultimately be that those who want to make use of this should be able to use a generalisation of this. This needs to be derived first, of course. I think this should ideally be maintained inside the ILIASObject component. And again, the workflow is only virtual in all this. We could visualise it somewhere, but do not have to. For the entity its only important so we can speak about the creation semantically and derive required actions.
• View/Manage screen: that is indeed correct. This is only a prospect and possible feature for the future.
• Removing LUI: yes you are right, I mistakenly thought that ilObjectListGUI and variations were in this scope – which they are not. But replacing them will be necessary anyways.

I hope this answers all of your questions/remarks. Let me know if you need some more information. Otherwise I would like to integrate this by the end of next week.

Kind regards
@thibsy

[oliversamoila]

Hello @thibsy.
Thank you very much for all your answers and insights. They help me to understand, and perhaps also help those who are reading along or who might look back at the decisions and reasoning at a later date.

Just a quick bit of feedback to work through this:

Content Aspects:

• Entity\Entity::withWorkflow():

  • Primary identifier and headline: I’m completely in agreement with doing these things one after the other. It’s important to me that, when using the Entity, we don’t later end up back in a situation that we’d already resolved for accessibility reasons. Thank you.
  • (Clickable) Glyphs: Thanks also for this explanation. This essentially means we can and should refer to the descriptions and rules of the UI Component Glyph. Many thanks.
  • Featured Properties: Check.
  • Show more/less: Check.
  • Workflow output: Omitting the display of the effectively virtual workflow for the documentation there is also an option. That’s fine by me.
  • Interaction: Check.
  • Breakpoint: I’m actually a bit confused about the pixel value myself now. I’ve had another look at it and must actually have been referring to 768px «» 769px. Should we use the same entity displays in the display area from 769px to 991px (i.e. where the main bar is already positioned at the bottom) as we do in the viewport up to 768px? It’s not a strict requirement, but things like this tend to remain the same for a long time once set. Thanks.

• Listing\Entity\Grid:

  • Replacement: Check.
  • Image format: Check. And thanks.
  • Reaction bar: I fully agree. It might be worth considering a different layout here – perhaps one that saves space or is more familiar from other applications – in the future, not right now.
  • Like service and output: Check.

Core Usage:

• Defining the FeatureProperties: I’d at least like to have mentioned this to @matthiaskunkel. It’s entirely plausible that this conceptually necessary work might be overlooked during the creation of the UI component. We should tackle this conceptual work in the not-too-distant future, so that it doesn’t become a missing bridge when it comes to the UI migration.
• Object creation workflows: check. Thanks again for the explanations and the clarification that “the workflow is only virtual in all this”.

Please feel free to integrate the current status. Many thanks to you and everyone involved.

Best regards
@oliversamoila (as UI Coordinator)

[oliversamoila]

Here’s just a screenshot showing the Breakpoints/Viewports aspect:
It’s all rather tight together. Perhaps adjusting the layout as described above might well make sense. Just a quick suggestion.