New UI-component "Launcher" proposal for JF decision

[catkrahl]

The newly proposed top-level component "Launcher" should be used for launching a object or a process. It can display general and status information, can contain inputs and consists of a primary button to execute an action.

It may substitute e.g. the info-tab when starting a test or a survey.

Following the basic concept of UI-components in general, it can be used nested in other components or wrapped inside a modal depending on the intended purpose.

As a starting point we propose two derivations of the Launcher: an "Inline Launcher" and a "Modal Launcher". But when it comes to other areas of application, more derivations are conceivable ...

Sceenshot(s) will follow and we would like to discuss this proposal at the next Jour Fix.

Hier ein erstes Mockup zum "Modal Launcher" am Beispiel "Test":

[Amstutz]

Hi @catkrahl

Thx a lot for this important contribution. Note that we can only review this thoroughly, once the complete interface is available. However, since this is under some rather tight timeline, we will give some early feedback nevertheless.

I really do like the name "Launcher", good choice, kudos.

Maybe Change or gives some reason why not:

• [ ] Taxonomy: I am uncertain if "Launcher" really deserves a unique position at the very top of our Taxonomy. To me, it might be the first of several main content areas serving a very specific user intent (here, "Launch something"). It does not seem to belong to Layout, since Layout components carry certain structural decisions, they are also about the "where" of elements as opposed to the exclusive "what" in many other components. Launcher is clearly about "What". Maybe add a family "Views" would work (I was browsing through: https://github.com/ILIAS-eLearning/ILIAS/pull/4916/files, to get some inspiration). "View" seems to work, since it could be used to map some specific user intent to some specific View. E.g. "Launch Something" → "Launcher View".
• [ ] A11y Rule: One of the reasons, such a "Launcher" would also be of high benefit in terms of a11y, is that we can arrange the items in a fashion, in which screen readers can properly work with. For the current launcher like info screen, we got the feedback that we need to place information necessary to read before launching the object above the launching button. Therefore, Maybe add something like: "All information required before launching the object MUST be placed before the Primary Button Launching the Object, so users working with screen readers will not miss it.

Please change:

• [ ] Typo: The Launcher is a component which contains general → general.
• [ ] Rules Wording: Instead of "it" use "The Launcher"
• [ ] Rules YAML Structure: Check out the YAML structure for the rules in other components and adapt:

     * rules:
     *   usage:
     *     1: ...

Thx a lot @Amstutz

[catkrahl]

Hi @Amstutz,

thx a lot for your instant and helpful feedback! @nhaagen and me will construct the interfaces today and hopefully we'll finish them during the day. Regarding to your taxonomie-comments i think your are right. During my first attempts to sort it under an existing component categorie, i had the same thoughts and problems. Even my early naming ideas had the namesuffix "view" ...

@A11y Rule: you are right, i will integrate your suggestion!

Thx a lot and best wishes @catkrahl

[alex40724]

Hi @catkrahl,

thanks for the proposal. This might be used for starting e.g. surveys, if I understand the concept correctly.

How would the consumer process the input data, e.g. the checkbox input in the example above?

Thx

[klees]

Hi @alex40724,

yes, exactly, this could be used for the survey.

You could consume the data by constructing a form with the very fields that you have passed to the Launcher and provide them with the data in POST. The data would be POSTed against the $target asynchronously and then redirect to the target afterwards on HTTP-status 200. Does this sound plausible? If so, we will elaborate =)

Thanks for the feedback!

[matthiaskunkel]

Jour Fixe, 17 OCT 2022 : We highly appreciate the suggested Inline Launcher and accept it for trunk. Alexandra Tödt has some concerns about the Modal Launcher that should be written down here before a final decision about implementing also this modal version could be made. The button "Launcher starten" is not needed (at least for the Inline Launcher).

[alex40724]

Thanks again for the proposal. I also see great value in the inline variant.

But I still struggle with the use cases for the modal variant, too. This might still be a misunderstanding on my side.

During the JF the mentioned main use case was the learning sequence, where users would like to start the object most of the time. Thus, the modal launcher should be featured.

I can't see any difference to the survey or test scenario (where the inline version on a start page has been proposed). To me all three object types should use the same process. At least for learners I assume that they want to start a test or a survey in most of the cases, too. Similar to the learning sequence. For other roles (tutors) this might not be the case, since they might want to configure the objects. But again this is similar for all three object types.

We are working very hard on consistency when it comes to processes, since this greatly supports the learnability of the system.

[klees]

Hi @alex40724,

I still owe you an answer here. I'm sorry it took me so long, this always fell down behind.

As you see in the follow up PR, the inline variant carries some visual weight. IMO it works well, if there are one or two of these Launchers on a page, since the Launcher carries some visual weight. In the JF I tried to bring up a case, where there would be multiple launchable objects or processes on one page. My example was a list of "all uncompleted learning sequences". With the Modal Launcher these could be presented in a way that gives more overview, e.g. in a table, and the "Launch" would only be represented by a Button. The info would then be shown in a modal. Consistency and learnability would then be implemented by the "Launch"-glyph and the similar look of the information in the Inline Launcher and the Modal Launcher. So the difference here is not which object/process is launched but from where the object/process is launched: Is there a single (or maybe two or three) launchable processes on the page (e.g. the Info tab)? Or are there multiple launchable objects/processes on the page?

In a discussion with @atoedt we in fact found an example where a that "multiple launchable process"-case already exists: As far as I understood, in a 360 feedback I might be asked to give feedback for multiple other users. With the Inline Launcher I would have one of these components per other user, which might become overwhelming at some amount of other users. With a Modal Launcher, we could instead display a list of users, with each having one Launch Button only and the detail information in a Modal.

I think it's fine to start with the Inline Launcher, but perhaps we just keep that idea of a Modal Launcher in mind if we find other instances of that "multiple launchable process"-pattern.

Best wishes!

[klees]

I close this one, as this is superseded by #5558.