Page MenuHomePhabricator

Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget
Open, LowPublic8 Estimated Story Points


We currently have two different widgets for editing a list of categories, with different but largely overlapping functionalities. We should only have one.

ve.ui.MWCategoryWidget is used by VisualEditor, in the Page options → Categories dialog. mw.widgets.CategorySelector is used by UploadWizard on the "Describe" step, and in the file upload dialog (mw.ForeignStructuredUpload.BookletLayout, which is used by VisualEditor and WikiEditor).

Widgets usedCapsuleMultiSelectWidgetButtonWidgets+TextInputWidget+Popup
Can set sort key for category
Can reorder categories (requested T108490: Let you drag items in a CapsuleMultiselectWidget to re-order them)
Can edit (not just delete) (requested T67518: VisualEditor: Allow editing of a category link (not just add/remove))
Can view category page (requested T56656: VisualEditor: Category editing tool should preview or at least link to the input categories)
Cross-wiki (hacky)

Event Timeline

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

(Adding a bunch of people who might be interested in working on this. Feel free to unsubscribe yourselves if not.)

There's a couple dozen tasks filed about both of those, which might be interesting to look at before doing this, and which will need to be re-triaged after this is done:

Jdforrester-WMF set the point value for this task to 8.
Jdforrester-WMF moved this task from To Triage to Freezer on the VisualEditor board.

The cross-wiki thing - that's just for uploading to foreign wikis, right? It doesn't sound like something we'd find useful in VE.

The two things that the VE code doesn't have, T67518: VisualEditor: Allow editing of a category link (not just add/remove) and T56656: VisualEditor: Category editing tool should preview or at least link to the input categories, don't sound very difficult to implement.

The two things that the MW code doesn't have don't sound very difficult to implement either, but I'd prefer it if we managed to unify the widgets instead. I guess it's mostly a question of deciding which design we want to go with.

I spoke with @Esanders and @matmarex about this and we feel that it'll be better to get mw.widgets.CategorySelector on par with ve.ui.MWCategoryWidget, and then use it on the Page Settings dialog too. We'll have to-

@Krenair @MarkTraceur would that be alright for your use cases too?

I think that would be fine for our use cases, yeah.

@Pginer-WMF, could you also take a look at this from the perpective of mw.widgets.CategorySelector. Its requirements are listed on T147811: Unify mw.widgets.CategorySelector and ve.ui.MWCategoryWidget, and specifically in my comment.

For tags we may want to keep interactions simple to encourage people to quickly add and change them. Having the triangle indicator makes tags heavier, making them look like a list of drop-down menus which users may not perceive as content elements they can create/remove. I see a couple of options to deal with complexity:

  • Avoid it. Ideally tags should be used for very simple list of concepts without complex interactions. In the case of page categories, maybe a user-defined list where each item has more room for manipulation actions could be more appropriate.
  • Keep it secondary. If we want tags to have associated actions, I think we can still do so without turning them into explicit menus. We can provide related information in a separate area when an item is selected or even use a popover menu without the need of an indicator (as it happens with links in VE).