Copy as per sceenshot. Ready to be implemented.

Hello hello! Before moving forward with this task, I wanted to suggest a couple of small opportunities, and hear your thoughts!

1. Instead of 'Add a function', 'Add alternative function name(s)', 'Input label', and 'Output label' we could opt for a real-world function example to be used in the text fields placeholders. For now, I used a celsius to fahrenheit function, but we could choose something more specific to our products.
2. We usually mark optional fields instead of mandatory fields. By default, everything that is displayed is required, while all optional things are marked as such.
3. What if we include the 'See list of input/output types' link in the helper text?
4. For the input an output helper texts, what if we opt for a different noun instead of input/output, maybe 'data'? It's important to use synonyms in helper texts so that it can improve the clarity of the text field labels.
5. If we think the page is too verbose for power user, we could hide those helper texts behind a info icon on the n 1 visit.

Most of these suggestions drive inspiration from the 'Create a new repository' page on GitHub, which overlaps quite well with our own proposal.

{F35962273}

Looks good to me, with minor changes. Yes to all changes in copy, yes to the examples, that looks good.

re 1) Yes
re 2) Sounds good
re 3) Sounds OK. For now the link can go to Special:ListZObjectsByType/Z4
re 4) Sounds good
re 5) let's make this optional

Minor changes:
A) There is no output label, only an output type. The output does not have a label.
B) Aliases are currently not separated by commas but by pressing [RETURN]

Description updated with the recent suggestions. The task is up for grabs!

@JKieserman while I was working on T320410 I realized that now that we use an example for the text field placeholder (instead of 'input label') it might not be clear that the text filed is expecting an input label, because (no pun intended) a label is missing. What if we add a label next to the type selector, and next to the text field?

On desktop we could opt for something like this

Looks good! I'll include that in this patch.

@AAlhazwani-WMF would this just be on top of the first input? Or every input (in the case there are multiple)

In T322132#8502547, @JKieserman wrote:

@AAlhazwani-WMF would this just be on top of the first input? Or every input (in the case there are multiple)

only on top of the first input (:

@JKieserman Geno told me that the only required field on the function definition page is the 'Output' type field. I'm going to update the screens and the task description accordingly.

Understood!

Also - I actually think maybe the Type and Label descriptions should be on every input? Certainly on mobile, since an input group can be collapsed, but even on desktop if there are ten inputs, scrolling all the way to the top might be a little annoying. What do you think?

For mobile yes! Since the inputs are displayed in separate sections it's necessary to repeat the input fields label.

For desktop I'm not sure. Let's try to think for scenarios: you land on a function definition page whose window width is >720px (desktop layout), with a 800px window height. In this use case you can fit ca. 6/7 input fields. My assumption is that by the time you add the 5th, 6th, or 7th input is not necessary to remind you that you need to specify an input type and an input label. What do you think?

On scroll there's even more real estate for the input fields, here an example on a 13" screen, 1280x800px.

Yeah okay that does seem reasonable for desktop! Thanks for confirming