Page MenuHomePhabricator

Suggested edits Community Configuration: Improve UX for autocompletion
Open, MediumPublic

Description

User story & summary:

As a Wikimedian editing Community Configuration, I want autocomplete to provide helpful suggestions when populating lists, so that I can easily update configuration.

Related task: T367493: Suggested edits Community configuration: Autocompletion for the list of templates in template-based tasks is confusing, decide on a fix

Current UX:

For template-based tasks, such as copyediting, we allow administrators to define the list of templates that are then used to generate the list of tasks. This is available from Special:CommunityConfiguration/GrowthSuggestedEdits and looks like this:

image.png (336×1 px, 53 KB)

As one can see, the templates are listed without the Template: namespace prefix. This is different from the Infobox templates section, which includes the namespace prefix as well (and often includes non-template pages, such as Lua modules and the like). So far, everything is clear, as the description clearly talks about templates, so the prefix is implied.

However, when I attempt to add a new template, things start to get confusing. After typing in A (as a start of a new template, I see the following suggestions in the autocompletion dialog:

image.png (1×1 px, 131 KB)

Those are articles starting with the letter A, not templates, which is super confusing. If I type in Template:A, the expected list of pages displays:

image.png (1×1 px, 169 KB)

Even with this bug, it continues to be possible to add new templates. Either ignoring the autocompletion and adding another unprefixed entry (which will not be on the list) or adding the prefix for the new entry will work, and there should be no breakage. However, the user experience with this is super confusing.

Solution

Add prefixes to the current entries: Since both unprefixed and prefixed entries work, we can also just add the Template: prefix to the (unprefixed) entries we have right now. That way, admins will know the prefix is needed, and will likely type it out when adding a new template. This is a data migration, but since we have the support for that (almost) ready, it should not be a terribly difficult operation.

Acceptance Criteria:
  • Migration: Add prefixes to the current entries
  • Documentation: Update Community Configuration technical documentation if necessary

Event Timeline

Solution

Add prefixes to the current entries: Since both unprefixed and prefixed entries work, we can also just add the Template: prefix to the (unprefixed) entries we have right now. That way, admins will know the prefix is needed, and will likely type it out when adding a new template. This is a data migration, but since we have the support for that (almost) ready, it should not be a terribly difficult operation.

(Drive-by suggestion from someone who hasn't worked on this code for a few years:) Would it be lower impact to remove the prefix in the UI, instead of adding it to the data? I believe we only ever want these to be templates, and that would help enforce that, and also make it easier for users by not suggesting non-templates that they shouldn't put in there.

In other words, I think it might be better to change the UI to scope the Lookup to the Template namespace, so that if you type "A", you see suggestions like "AFC submission", "Automatic taxobox", etc.

Solution

Add prefixes to the current entries: Since both unprefixed and prefixed entries work, we can also just add the Template: prefix to the (unprefixed) entries we have right now. That way, admins will know the prefix is needed, and will likely type it out when adding a new template. This is a data migration, but since we have the support for that (almost) ready, it should not be a terribly difficult operation.

(Drive-by suggestion from someone who hasn't worked on this code for a few years:) Would it be lower impact to remove the prefix in the UI, instead of adding it to the data? I believe we only ever want these to be templates, and that would help enforce that, and also make it easier for users by not suggesting non-templates that they shouldn't put in there.

Doing so would probably work for the lists of templates that populate the task recommendations. However, it does not necessarily work for all lists of templates. For example, I don't think this solution would work for the Infobox templates list of templates. For example, https://cs.wikipedia.org/wiki/Speci%C3%A1ln%C3%AD:Komunitn%C3%AD_konfigurace/GrowthSuggestedEdits includes Module:Infobox, which is not a template, but it is used in template-like contexts, and it definitely makes sense to include among the other templates.

Personally, I think we should only have a single solution for whatever we use to represent a list of templates, and that solution should work in all contexts it might get used. From that angle, always-prefix seems like a safer solution. It looks like the problem here is that the line between what is a template and what is not is not black-and-white. In fact, MediaWiki happily allows you to use a main namespace page in template-like context via {{:Article}}.

That being said...I also see the UI/UX benefits of omitting the prefix whenever possible. Maybe we should adopt the same solution MediaWiki uses when it expects a template: in that case, we would assume NS_TEMPLATE is the default namespace (when none is explicitly provided), and allow main namespace pages using the colon prefix. This would make the field in sync with what Parsoid does when parsing wikitext. Implementing this solution would imply solving T367494: Community configuration: Add support for parametrised controls before (so that Community configuration would know whether the context is "normal page title" or a "template expected").