Page MenuHomePhabricator

Add a drop-down list for the tags in Special:Newpages, Special:Log and Special:Contributions
Open, MediumPublic

Description

Original description
After an idea of [[:fr:User:Padawane]]¹ it would be great to add a drop-down list for the tags in Special:Recentchanges and Special:Newpages instead of an edit box. This would help users who don't know what are exactly the tags and users who use intensively the tags.

[[:fr:User:Dr Brains]] proposes to add two system messages to give the ability to the sysops of customizing the tags useful for Newpages and Recentchanges, possibly like the one in Special:Block.

¹ http://fr.wikipedia.org/w/index.php?title=Wikip%C3%A9dia:Demande_d%27intervention_sur_un_message_syst%C3%A8me&oldid=59019598#Sp.C3.A9cial:Nouvelles_pages

The RecentChanges part of this is done in T161650: Replace "Tag filter" input with a dropdown+lookup widget in RCFilters.


See Also:
T23383: Suggest tags for tag filter at Special:Contributions, Special:NewPages, Special:RecentChanges, and Special:Log

Details

Reference
bz25909
Related Gerrit Patches:

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

The list includes all tags "maintained" by extensions (VisualEditor, MobileFrontend and GettingStarted use these, VE 2, the rest 1 each), as well as all active AbuseFilter tags (hopefully not more than a dozen or so, depending on the wiki). Should be acceptable for a dropdown list.

Will this dropdown menu be cluttered by inactive tags and tags from deleted filters (bug 18908)? E.g. the "link vandalism" from English Wikipedia, which is not used anymore:
https://en.wikipedia.org/wiki/Special:Tags

Helder, no, assuming I understand how this works. Special:Tags and this would use different methods - the special page shows all tags that were ever used, while the dropdown would only use the ones explicitly defined using the ListDefinedTags hook.

I asked Reedy to check this on en.wp and the total there is 40 active tags - a little long-ish for a dropdown, but manageable. It's surely shorter on saner wikis.

(For reference, en.wp's Special:Tags shows 90 tags right now.)

90 tags seems like too much for a popup. What about a form field or a combo box with type ahead.

It's 40 for the "popup" (actually a dropdown), 90 only on the special page.

HTML form dropdowns (<select>s) also support search-by-typing in all browsers I'm aware of.

40 or 90 feels overwhelming in a popup on some browsers that is going to take up the full height of the screen. Scrolling in popup can be very difficult for some users.

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for tags seems silly. I'd suggest autocomplete (suggestions).

(In reply to comment #37)

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for
tags seems silly. I'd suggest autocomplete (suggestions).

I disagree - autocomplete is great where the search-space is huge and rapidly-changing, but in a restricted (and externally-set, relatively-static) context, it's better to provide some form of latent discoverability than expect users to know what it might be called (or start with).

Created attachment 13275
jquery.chosen() applied to the tag selector dropdown

Maybe we could use jquery.chosen to get the best of both worlds (screenshot attached). The implementation would be trivial (on top of what I proposed it amounts to adding the jquery.chosen ResourceLoader module and calling $('.mw-tagfilter-input').chosen()).

I don't think this is used in core already, but it is definitely included and supported (some of the Labs management extensions use it, I believe, and support is integrated in HTMLForm as well).

(I'm leaning towards a simple select box myself, but this could be a compromise.)

Attached:

(The particular graphical elements it adds are almost all configurable, see the gallery at http://harvesthq.github.io/chosen/ .)

(In reply to comment #38)

I disagree - autocomplete is great where the search-space is huge and
rapidly-changing, but in a restricted (and externally-set, relatively-static)
context, it's better to provide some form of latent discoverability than
expect users to know what it might be called (or start with).

A full index (e.g., [[Special:Tags]]) allows users to browse through all tags (in the same way that [[Special:AllPages]] allows users to browse through all page titles). The solutions being proposed here seem short-sighted. While there may "only" be about 90 tags today (which is an overwhelming number in a drop-down menu), does anyone expect this number to stay relatively low or decrease in the future?

The reason autocomplete (or suggestions) are already used within MediaWiki for page titles apply to this input field as well. We should also note that Bugzilla itself uses an autocomplete/suggestions system for its keywords field. A drop-down menu seems like a non-starter to me.

To continue with the best of both worlds idea, why not supply the list of tags for the dropdown if the number of tags is lower than X, otherwise use only auto-completion API?

(In reply to comment #42)

To continue with the best of both worlds idea, why not supply the list of
tags
for the dropdown if the number of tags is lower than X, otherwise use only
auto-completion API?

Yes, we only need something to implement it. MatmaRex is right that we already use it successfully elsewhere: Rillke added it to Translate, for instance.

Change 80781 abandoned by Bartosz Dziewoński:
Add a dropdown list for the tag selector

Reason:
Needs to be done differently.

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

More reasons to first use autocompletion where possible: bug 64829 comment 8 on bug 21383.

TTO added a subscriber: TTO.Feb 4 2015, 12:19 PM

This should happen.

The issues I see are:

  • Performance. I have a suspicion the reason werdna used a free text field to begin with was because of the performance issues (there is no neat way of listing the tags without hitting the DB and running a bunch of hooks). I think this can be overcome by using memcached with a long expiry time (what's considered long? 1 hour? 1 day?).
  • Which tags to show. With the work on T20670 this is less of an issue - we can simply show all tags considered "active".
  • UI issues:
    • Personally I think a <select> dropdown with 80 or so items is fine, so long as they are sorted. However, emitting a HTML <select> and then applying jQuery Chosen to it is a good compromise. Hopefully it doesn't give rise to client-side JS performance issues.
    • We probably want to show the tags' friendly names (not code/internal names, which is what has to be used at the moment). But the friendly names are wikitext, so we would have to strip out links and such for display in a <select>. Not sure what exists in MediaWiki for doing that type of thing.

I was going to claim this task, but that last issue is kind of a blocker for me.

FYI, auto-suggestion/completion was requested in T23383.

(In reply to comment #37)

I think bug 48243 is almost a duplicate of this bug. A drop-down menu for
tags seems silly. I'd suggest autocomplete (suggestions).

I disagree - autocomplete is great where the search-space is huge and rapidly-changing, but in a restricted (and externally-set, relatively-static) context, it's better to provide some form of latent discoverability than expect users to know what it might be called (or start with).

If a user selects the tag input, couldn't we start displaying autosuggestions below with the first tags from Special:Tags ? At the end of the listing we could provide a link to Special:Tags, displayed as 'more tags'. Having to navigate a very long drop down menu isn't user friendly, smartphone contact lists use autosuggest to narrow down the displayed list for example.

In T27909#1014161, @TTO wrote:

The issues I see are:

  • Performance. I have a suspicion the reason werdna used a free text field to begin with was because of the performance issues (there is no neat way of listing the tags without hitting the DB and running a bunch of hooks). I think this can be overcome by using memcached with a long expiry time (what's considered long? 1 hour? 1 day?).

A few hours would probably do. But we can have a longer cache if it is cleared when performing management operations on tags. We may even have an action that purges this cache available for tag managers (since extensions might not clear the cache).

  • Which tags to show. With the work on T20670 this is less of an issue - we can simply show all tags considered "active".

Active tags may be too restrictive, since we may want to filter contribs, page histories or logs with no-longer-active tags. I'm slightly in favor of autosuggestion, listing all of the tags from Special:Tags, sorted by tag usage statistics (as cached).

  • UI issues:
    • Personally I think a <select> dropdown with 80 or so items is fine, so long as they are sorted. However, emitting a HTML <select> and then applying jQuery Chosen to it is a good compromise. Hopefully it doesn't give rise to client-side JS performance issues.

I would still favor autocompletion sorted by tag usage statistics.

  • We probably want to show the tags' friendly names (not code/internal names, which is what has to be used at the moment). But the friendly names are wikitext, so we would have to strip out links and such for display in a <select>. Not sure what exists in MediaWiki for doing that type of thing.

The solution is to make user friendly the tags' name themselves. They also appear at Special:Tags, having a different one for filtering would create more issues IMO. And this would also require changing the way the filtering occurs in many contexts (when appending &tagfliter=) to be compatible.

This seems like a perfect use for capsule input (you can see this currently in use with Hotcat, and in the category interface in VE)

Deskana removed a subscriber: Deskana.Mar 3 2015, 11:51 PM

This would require a distinct cache for tags that have been applied at least once. There should be a separate cache for tags that have never been applied, so that we don't have to hit the valid_tag table and the hooks just to get tags used at least once.

I also think that we should have a cache for each tag hitcount instead of one for all of them. This way, we just increment the hitcount cache for added tags (the incr function is built in memcache and very fast), instead of purging the whole thing.

We could have a cache of 24 hours. Operations on the valid_tag table would purge the cache. AbuseFilter should also purge the cache when a filter including a tag action is updated, and other extensions that cannot wait 24 hours to see it defined at Special:Tags.

Does that sound good ? I could rewrite the tag usage statistics function for this. Capsule input sounds good, but it looks like it uses javascript, I don't know enough about that to implement it.

I've uploaded a patch set for T91535.
This creates in particular a list of tags applied at least once, cached for 24 hours, that can be further filtered by 'active' or 'problem' status.
I'd suggest no extra filtering for logs and histories, 'active' filtering for Special:RecentChanges, and 'problem' filtering for Special:ProblemChanges.

Change 211497 had a related patch set uploaded (by Cenarium):
Drop down menu for selecting tags

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

Does this task cover everything in T23383? Maybe it can be closed as duplicate.

matej_suchanek set Security to None.

Does this task cover everything in T23383? Maybe it can be closed as duplicate.

In https://gerrit.wikimedia.org/r/#/c/211497/, I've implemented a basic html drop down. I think people were concerned with the high number of tags on some wikis.
The possibility to exclude tags from the drop down (by entering an empty appearance) mitigates this concern greatly (tags with few hits or very old but non-deletable could be hidden).

We might leave T23383 open for a while in case people aren't satisfied with a drop down and still want a suggest form or some fancy javascript. If a simple drop down turns out to be enough, then we'll close it.

Restricted Application added subscribers: TerraCodes, Luke081515. · View Herald TranscriptApr 30 2016, 10:16 AM

Change 211497 had a related patch set uploaded (by Cenarium):
Drop down menu for selecting tags

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

How will this work in combination with T105189?

https://gerrit.wikimedia.org/r/#/c/218265 ensures that the issues of T105189 will not occur by providing a new cache.
Besides that, I don't think that there is interaction between RTRC and the drop down menus added here.

matej_suchanek removed a subscriber: wikibugs-l-list.
Krinkle removed a subscriber: Krinkle.Jul 15 2017, 4:05 AM
Restricted Application added a project: Growth-Team. · View Herald TranscriptAug 14 2018, 7:09 PM
kostajh added a subscriber: kostajh.

Growth team discussed this today in our triage meeting. The Special:RecentChanges page has this feature now, although Special:Newpages does not. Our team won't have the capacity to work on a patch for Special:Newpages but volunteer contributions would be very welcome.

kostajh renamed this task from Add a drop-down list for the tags in Recentchanges and Newpages to Add a drop-down list for the tags in Special:Newpages.Sep 18 2018, 7:49 PM

Change 211497 had a related patch set uploaded (by Matěj Suchánek; owner: Cenarium):
[mediawiki/core@master] Drop down menu for selecting tags

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

Revived and rebased patch, tagging Core Platform Team for review

Re: user-notice - please help drafting a 1-2 sentence simple summary for Tech News. IIUC it would be something like this:

"[[Special:NewPages]] has a new drop-down menu interface for selecting the Tag filter. You do not need to type the tag from memory anymore."

(corrections welcome!)

"[[Special:NewPages]] has a new drop-down menu interface for selecting the Tag filter. You do not need to type the tag from memory anymore."

Since @daniel on Gerrit wanted clarification on the scope: The patch will actually change this on all special pages that use the same input as Special:NewPages. It should be also Special:Log and Special:Contributions at least. The interface will be different from that on modern recent changes and watchlist (it will just allow for single tag and won't display additional description). Not sure now what happens to the old interfaces which are still supported, I will try to keep in mind to check them.

matej_suchanek renamed this task from Add a drop-down list for the tags in Special:Newpages to Add a drop-down list for the tags in Special:Newpages, Special:Log and Special:Contributions.Jan 6 2020, 4:56 PM
matej_suchanek updated the task description. (Show Details)