I wasn't able to reproduce this to understand the issue. When I'm clicking back and forth between the two, focus seems to be working as expected for me.

Our new sidebar design fixes this problem, so I'm lowering the priority of fixing for the old interface.

I think once the VE template dialog updates are deployed, this ticket can be closed as our changes solve the issue.

We reviewed this ticket during demo time. It was implemented according the requirements and can be closed. A few behaviors were noted as confusing and will be dealt with in a follow-up ticket T291059: [DRAFT] Adjust messages for special alias edge cases (currently a draft, ideal behavior TBD).

In this case, should we show the alias error (third attached mock), or the duplicate parameter error (first attached mock)?

After reading through, I think for this case we can simply show the alias error (third mock F34533178). From my understanding, the text still makes sense. I think this resolves all the above issues but if there is still something outstanding, let me know

@thiemowmde

Just disable the button when the input is not even a valid parameter name. Forbidden characters are {, =, |, and }.

If this is another case where the user is blocked, I think it makes sense to include an error message here as well while we are adding the rest. Such as "($symbol) is a forbidden character. Please remove it to add the parameter." Otherwise I'm not sure it would be totally clear as to why the button is disabled.

Re: non-existing templates

In the context of T290140: Handling non-existing templates in the new dialog I just wanted to note here, that we're currently planing on not showing the This template may be intended for use without parameters[2]. If this template does contain parameters, they are undocumented[4]. message for templates that do not exist on the wiki.

Toolbar icons are centered, which looks bad. @ECohen_WMDE button placement in full-width sidebar mode needs design.

Thanks for your patience - this slipped through the cracks a bit! It looks like on beta they were changed to align left. This is what I would have suggested and I think it looks good!

This still needs the text updated from the comment above: T272487#7314421

Ah right, forgot about this case when writing the ticket. In this case I would leave the existing help text as is. Don't remove it.

TemplateData exists and includes a description: show the new help text given here, and the description from templatedata.

Yes. And if TemplateData exists but is missing a description, the description field will be empty but the help text will still show.

@WMDE-Fisch After some thought and talking through with Lena, we will go ahead and implement as-is.

Noting that the "add unknown" input should probably get the same margins:

I think this is correct. We alphabetize the unknown params, rather than show them in the order added or in the order given in the template invocation. (Note that when serialized, the template invocation order / order added are preserved.)

Oh I see! I wasn't part of the sprint review where this was discussed. Feel free to ignore the 'bug report' part of my comment then!

Also after looking on beta, a few notes for the styling:

I've updated the task description and the mock to show the new description based on @awight and @thiemowmde 's feedback. It removes the phrase "existing undocumented parameters" and also removes the double negative from the second sentence:

Documenting the decision here to not re-implement the on-scroll behavior and confirm the requirements as currently written in the task. Focus and sync-scrolling should only happen after a user has clicked somewhere, triggering a change.

Is also missing. I will leave this link out for now.

Ya go ahead and leave out for now. I'm working on this at the moment but will just include this in the follow-up ticket with the others once the documentation has been updated since I'm not sure exactly when that's going to be. Currently have a placeholder but it needs work: T284985: [Placeholder] Add links to documentation throughout template VE workflow

Last comment: I think it would be helpful if the task description helped show the current progress. I'm not sure if the way that you updated it Friday @thiemowmde also reflects the current state?

Just realized I forgot to respond to this one:

Spacebar toggles a checkbox on/off. Should enabling a checkbox with the spacebar move the focus to the content pane on the right? (Note that enter already does this.)

I think it's actually nice that they behave slightly differently, then a user has options. If they want to check a bunch of parameters, then they can move down the list using the spacebar. If they want to turn it on, then directly fill it out, they can press enter. I would leave it as it currently is then.

Thanks @thiemowmde for the detailed breakdown! It's obviously quite complex. I have a few questions below to make sure that I'm clear on the issues before making any recommendations.

How about we start by simply counting multi-template sessions to see how common the use case is. We could easily count these at open and save, which gives us * the percentage of sessions which involve multi-part transclusions, and * the success rate of multi-template sessions.

Sounds good! This seems like a simpler first step that would still give us useful information about that situation.

@awight @Andrew-WMDE @Lena_WMDE
For question #1 I agree that the second option is more meaningful and what we should go with:

"What proportion of sessions had templatedata available?" is answered by |A| / (|A| + |B|) = 99 / (99 + 1) = 0.99

The individual sessions are what we care about because we are tracking the times a user tries to make an edit and if TD supported them in doing that. If it's the same template it doesn't really matter since they want to do something different to it than last time and we just want to see if they can complete that action successfully.

From storytime today:
We’re deciding not to do this research. Instead, the file preview will behave correctly according to which data type is in use. (ie. File type does not expect a prefix but page type accepts prefixes)

This adds very little technical complexity, no worries!

That's great news!

Heads up - design change coming but I'm still working out the details. Would like to discuss the technical complexity (or hopefully not!) of this change. Sorry for the last minute nature, just had the idea but think it has the potential to be a big improvement since we are now showing this input in significantly more situations (based on the decision to show when no params are documented, even if a template has TD).

I wanted to highlight an interaction with T288202: Parameter search also filters main content area: when the content area is being filtered, the undocumented parameter entry is hidden. This feels like an accident, can you confirm the intended behavior?

Writing to confirm the notes - this was my understanding of our decisions as well. For your questions:

Closing this as invalid because the implementation plan has changed. Requirements updated in T272487: New input for undocumented parameters to include this state (template with TD but no documented parameters) to show the undoc param input and associated notice. Wording to be updated there as well to cover this situation better and message to be changed from warning to notice as it's likely that nothing is actually wrong or needs fixing.

In T272487#7262330, @awight wrote:

I suggest that we update the metrics, to record a new event type "show undocumented param input" so we get an idea of how often this logic is triggered.

Resolving this ticket based on our story time discussion yesterday. Created ticket for the follow-up work T288202: Parameter search also filters main content area.
Can the last box under requirements above be checked? @lilients_WMDE