Page MenuHomePhabricator

Suggested edits Community configuration: Autocompletion for the list of templates in template-based tasks is confusing
Open, HighPublic

Description

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.

This can be fixed in several ways:

  1. Temporarily disabling the autosuggestion for those fields: If there is no autosuggestion, then the admin would need to type in the full template name (and hit enter). The confusion is less likely to occur, as the misleading autocompletion will not show. However, this results in degraded user experience (although arguably less degraded than the status quo), as (working) autocompletion is useful to avoid mistakes.
  2. Default to the Template namespace when working with templates: Instead of the main namespace, we can work with the Template namespace as being the default (when no prefix is used). That way, the autosuggestion will primarily show templates, and if the admin uses an explicit prefix, then we would switch to a different namespace. This would've been easy with parametrized widgets, but we currently lack that capability (so we would have to create a whole new widget just for templates, which does not make much sense).
  3. 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.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Sgs and me discussed this problem on Wednesday. We're going to fix this issue using option 1, as it is (by far) the easiest option, and it will allow us to serve a (slightly) better interface to admins on the pilot wikis. Once the stopgap fix is instituted, we can decide between option 2 and option 3, which seem to be the most correct long-term fixes for this issue.

Urbanecm_WMF triaged this task as High priority.
Urbanecm_WMF added a subscriber: KStoller-WMF.

Claiming to implement option 1.

@KStoller-WMF, heads-up about this task – curious to hear whether you have any preference for the long-term solution here.

Change #1043681 had a related patch set uploaded (by Urbanecm; author: Urbanecm):

[mediawiki/extensions/GrowthExperiments@master] SuggestedEditsSchema: Do not use PageTitles control for templates

https://gerrit.wikimedia.org/r/1043681

Putting to Code Review. We will likely need a follow-up task (for later), once we know what the final behaviour should be.

Claiming to implement option 1.

@KStoller-WMF, heads-up about this task – curious to hear whether you have any preference for the long-term solution here.

My initial impression is that option two seems more ideal from a user perspective, but that option 3 also seems reasonable and acceptable if option 2 is considerably more effort or unnecessarily complex to implement. That being said, I'll check in with Ambassadors and Benoît since I'm not as familiar with admin expectations. @Tacsipacsi feel free to chime in if you have a feedback on which option would be more ideal in your perspective.

I'll create a follow-up task once we've reached a consensus. Thanks!

Option 3 should be put forward IMO:

  • Scalability: it will be necessary when other teams start using CC
  • Consistency: other fields will have suggestions, but not for templates