Page MenuHomePhabricator

Decide what to do about the edit-form's hidden categories list
Closed, ResolvedPublic

Description

When editing and previewing a page (with non-live, live, or realtime preview) a list of hidden categories is displayed below the editing form (with a heading such as "This page is a member of a hidden category:"):

hiddencats.png (627×732 px, 75 KB)

There are a couple of issues with this feature, and this task aims to describe these and propose a few different solutions. The issues are:

  • Unlike the template list and profiling data, the hidden category list is not updated during preview, and only ever shows the list of categories that the page (as currently saved) already belongs to.
  • Hidden categories can also be shown in the main category list at the bottom of the page, if the "Show hidden categories" (showhiddencats) preference is enabled. The bottom category list is updated during preview (including the hidden categories). This means that the two lists can show different hidden categories.

Related tasks:

Possible fixes:

  1. Fix the hidden category list to dynamically update on preview.
  2. Remove the hidden category list entirely, and rely on the main category list (i.e. people would enable the preference if they want to see hidden categories). One problem with this is that the main category list is not shown without previewing.
    1. Perhaps also force the display of hidden categories while editing (i.e. not while viewing, unless showhiddencats is enabled).
  3. Remove the main category list, and expand the below-form list to show all categories. This would make things more consistent with e.g. the template listing, but it's also less consistent with other page elements such as display-title and indicators (which are only shown on preview).

One issue with relying on the preference is that people may not know about it, and there's no indication while editing that not all categories are shown.

Event Timeline

Personally, I think we should get rid of the hidden templates list, and rely on the preference. A nice addition would be to add a hide/show toggle to the main categories box, that would work while editing or reading (and would set the user preference).

Personally i always thought this made sense for the original use case of hidden categories being maintenance warning type things that editors would care about but dont want displayed on the real page.

I think this option makes sense: remove list and "force the display of hidden categories while editing (i.e. not while viewing, unless showhiddencats is enabled)"

Personally, I think we should get rid of the hidden templates list, and rely on the preference. A nice addition would be to add a hide/show toggle to the main categories box, that would work while editing or reading (and would set the user preference).

I think this would be ok only with your addition to be honest. Without it I don't think many people realize that something like hidden categories even exist. And that being hidden in the preferences isn't helpful.
Otherwise I'd go for option 3.

Thanks everyone, this is super helpful.

I was going to suggest that the easiest fix that satisfies all this might be: remove the hidden cats list, and force showhiddencats while editing. But that doesn't account for how things work for the non-preview state — when the edit form is first opened, the hidden category list is shown, but the main category list isn't. However, that's also the case for other page elements such as display-title, indicators, and language links.

I think that removing the main category list is be too big of a change. And updating the hidden cats to be dynamic is a larger task than overriding showhiddencats (which might just be a reasonably small CSS change, if we don't have to account for non-previewing).

Change 931601 had a related patch set uploaded (by Samtar; author: Samtar):

[mediawiki/core@master] EditPage: Remove hidden categories list

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

And a gem that is probably of related interest to @Samwilson T211142: Do readers use categories, or just editors?

That query should probably be ran again now that bots are more reliably filtered out (ref).

Coming to this a bit late, but I'm in favor of removing the hidden cats list and just relying on the preference instead. I don't think I've ever uncollapsed it. (By contrast, I always have used templates displayed.)

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/931601/ PS3 is a reasonable middle ground for me though.

@Izno one issue with that approach is that it doesn't show the categories without previewing (whereas it does show the template list). Does this matter? I feel like it's not too bad, because the non-hidden categories aren't visible on first load anyway, but it is a difference from the status quo.

Please do not remove the hidden category list in the edit form. It is probably helpful to most editors with the preference disabled, since it is disabled by default, and removing it just because it is technically inconvenient to update it on preview is not a good way to do this. If it is not updated during live previews or something, it (the edit form list) can be hidden during live previews.

Showing it only if showhiddencats is off would make the most sense, though I don't see how outright removing it would be disruptive (if a category is hidden it's hidden for a reason, and there's an option for registered users to see it). If it's kept, however, it should be shown before previewing just like transclusions.

@Izno one issue with that approach is that it doesn't show the categories without previewing (whereas it does show the template list). Does this matter? I feel like it's not too bad, because the non-hidden categories aren't visible on first load anyway, but it is a difference from the status quo.

I think this is totally acceptable, which is why I referenced the patch directly. :) Clearly opinion is generally split on all of this task. :')

Showing it only if showhiddencats is off would make the most sense, though I don't see how outright removing it would be disruptive (if a category is hidden it's hidden for a reason, and there's an option for registered users to see it).

I otherwise agree with this comment. It's not a win to be showing it to people who can't see it anyway in the normal view and likely don't care about the utility. Editors who want it back can be advised to flip the preference back on during a transition.

(There is perhaps a general undercurrent of "maybe we've hidden too many categories" that I've certainly pondered, but I think removing this view here is reasonably appropriate for the utility that hidden categories solve.)

The thing is, hidden categories are a helpful concept for having essentially a list of editor-only errors from the page. But since only the proficient editors can find showhiddencats preference, it makes sense to make them available at least in the edit form. Also, those sublists are persistent and can be shown permanently with mwedit-state-hiddenCategories localStorage variable. I do not agree with the blank assumption that it is unnecessary and unwanted by everyone: we have nothing to prove it. You could, of course, do something like a tech news item to bring attention to this discussion, but right now this discussion hinges on ‘I do (not) use it’.

Of course, I also do not disagree that the technical debt with maintaining this list should be ignored: if that is what prompted this, of course, we can do something to show the page categories in the edit form by default, including the hidden categories, and then remove the list. I would remind though that this is currently not the case, and categories do not get shown when page editing is opened. (And in VE, there is no way to view hidden categories, at all, even with the pref enabled. Don’t know what’s in NWE.)

We have nothing to prove the status quo is superior either. Hidden categories are also shown in action=info so unregistered users and registered users who haven't touched the preferences still have means to see them anyway.

Spitballing: What if we always showed hidden categories at the bottom in preview regardless of showhiddencats? Wouldn't that reduce technical debt because now you'd have one less UI component for hidden cats?

I do not agree with the blank assumption that it is unnecessary and unwanted by everyone: we have nothing to prove it.

My main motivation for bringing this up is that as it stands the hidden-cats list is (in my opinion) just wrong :-) — because it doesn't update on preview. So it's the only part of the editing form that doesn't refer to the current state of the edited page. The visible categories, page title, template list, and language list all update on preview, but the hidden categories just sit there unchanged from when the form was first opened. I suspect most people don't realise this, and think that it does update (especially now that we grey it out during preview loading).

I'm not wedded to any particular solution to this: I tried to list what I think are all the options.

You're quite right about what gets shown when the edit form is first opened: I'm not sure what the best thing to do is. The hidden cats and template lists are shown (but not when you edit a section; then only the hidden cats are shown). The visible categories are not shown until you preview — I wonder why not. Adding that seems like a good idea.

Spitballing: What if we always showed hidden categories at the bottom in preview regardless of showhiddencats? Wouldn't that reduce technical debt because now you'd have one less UI component for hidden cats?

Yep, this is what the above patch does at the moment. It means that there's one place for all the categories, and they're all updated on preview.

Here's a patchdemo of the above patch that adds hidden cats to the main cats list, if anyone wants to have a try of it.

My main motivation for bringing this up is that as it stands the hidden-cats list is (in my opinion) just wrong :-) — because it doesn't update on preview. So it's the only part of the editing form that doesn't refer to the current state of the edited page. The visible categories, page title, template list, and language list all update on preview, but the hidden categories just sit there unchanged from when the form was first opened. I suspect most people don't realise this, and think that it does update (especially now that we grey it out during preview loading).

100% agree! A prime example is trying to fix Lua errors. Say you're trying to work off of Category:Pages with script errors; If you go to such a page, change template params and such to what you believe should fix it, and it's impossible to know if you actually fixed anything until you save. So for this purpose sand similar maintenance categories, showing the hidden categories list as it is now is not only wrong but extremely misleading, in my opinion.

Here's a patchdemo of the above patch that adds hidden cats to the main cats list, if anyone wants to have a try of it.

I quite like this solution, personally. https://patchdemo.wmflabs.org/wikis/ba5e2e58ca/wiki/Citation_needed_example is an example page to test with, if anyone wants (I made {{citation needed}} and its {{cn}} redirect add [[Category:Hidden category]]). The behaviour now acts like I would personally expect. +1 from me.

Should we reach out to wikitech-l or mediawiki-l to get more opinions?

Should we reach out to wikitech-l or mediawiki-l to get more opinions?

One of those is how I came to know of this task.

Here's a patchdemo of the above patch that adds hidden cats to the main cats list, if anyone wants to have a try of it.

I quite like this solution, personally. https://patchdemo.wmflabs.org/wikis/ba5e2e58ca/wiki/Citation_needed_example is an example page to test with, if anyone wants (I made {{citation needed}} and its {{cn}} redirect add [[Category:Hidden category]]). The behaviour now acts like I would personally expect. +1 from me.

One note: When you open the edit page, without taking any actions, you have an empty catlinks div.

Screenshot 2023-08-09 at 13.13.00.png (418×580 px, 41 KB)

Remove ? or do we add the initial categories in this case ?

Remove ? or do we add the initial categories in this case ?

Good point. I think adding the cats on first load could be good. Although we don't show the templates' list, nor the display title. So maybe better to just hide the empty cats div!

Also, it sounds like we should perhaps add a message to Tech News saying that we're thinking of making this change.

Good point. I think adding the cats on first load could be good. Although we don't show the templates' list, nor the display title. So maybe better to just hide the empty cats div!

What do you mean here? Templates list is definitely shown on the first load.

Oops, sorry, yep it is — but not when editing a section, that's what I was thinking of. I do think the point stands though, because other variable items aren't shown, nor (crucially) are categories. (I think there is a good argument that the categories should be shown on first load, but that seems separate from the current discussion.)

Well, TheDJ was linking to the full-page editor, that’s why I was surprised. I do think that if this is to be simplified, the way the catlinks behave should be the same to the way the previous location behaved in terms of availability, I hope we’re in agreement on that.

I do think that if this is to be simplified, the way the catlinks behave should be the same to the way the previous location behaved in terms of availability, I hope we’re in agreement on that.

I think we are! :-)

Do you mean that this change should also involve making the categories show on first page load? Or rather, not in the same change, but before we remove the hidden categories list the main categories list should be always shown?

Since hidden categories are currently shown on the first load, any change replacing that list should also make them available on the first load. As I described above, that is the easiest way for people without ‘Show hidden prefs’ preference (which many don’t even know about because the prefs are not easily discoverable) to learn about the hidden categories an article has (and potentially fix some of them if they contain error cats).

It sounds like we need to first show the categories on initial load, before moving the hidden categories list into it. I've created a task for this: T345049: Show categories when editing (without requiring preview)

Unification and simultaneous handling of both regular and hidden categories is fine with me.

However, it is crucial that hidden categories are listed separately and obviously. Reason:

  • Most of the hidden categories are maintenance categories and indicate an error.
  • A few ones are for observation and monitoring only.
  • If there is any maintenance category thrown, many experienced authors will take notice of this separated block and try to resolve issues, both during editing and just viewing. By CSS the existence of maintenance issues can be highlighted, even if error messages of templates are not displayed in the article shown to the public. While many category titles are self explaining, on category description page there are further guidance, cause and remedies.
  • If there is no hidden cat, page is fine. If any, I should look for problems.

Thanks @PerfektesChaos that's useful info.

I think the next steps are now clear, and in order are as follows:

  1. T345049: Show categories when editing (without requiring preview)
  2. T345523: Always show hidden categories while editing
  3. Remove the existing static hidden-categories list (this can be done as part of step 2 above I think, to avoid the situation of having two contradictory lists for people who don't currently have hidden categories shown).