Presumably this would get rid of the jQuery.UI usages?

I tried turning off jquery.ui in PageTriage just now. Looks like PageTriage uses jquery ui features .button() in 39 spots, and .draggable() in 1 spot. There may be some other uses as well.

Is there a suggested way to refactor this without changing the appearance or behavior of anything? That'd be the quick fix for getting off the deprecated, unmaintained library jquery.ui.

Actually looks like jquery.ui is not unmaintained. They appear to be putting out security and maintenance patches every six months.

https://github.com/jquery/jquery-ui/releases
https://blog.jqueryui.com/2022/07/jquery-ui-1-13-2-released/

Anyone know why it is marked as deprecated in MediaWiki, emitting a JavaScript console error?

@Novem_Linguae jquery UI is deprecated in Wikimedia production code since 2017. Using it in MediaWiki provides inconsistent user experience as well as requiring the user to download unnecessary code. It's not clear how much longer this will be maintained but we should work towards moving away from it towards Codex (via OOUI if necessary).

Coming back to this task a couple of years later: IMO it would make sense to decline this task and just go directly to Codex. PageTriage is a good candidate for that (cc @egardner), as there is no server-side rendering of the Special:NewPagesFeed nor the page curation toolbar.

@kostajh thanks for the heads up. Would it be possible for someone to add a few screenshots of this feature to the task description? That would give me a quick sense of what components would be needed for a Codex implementation.

Screenshots added.

Please get consensus for any major changes to the visual appearance of the app before spending a bunch of time on it. English Wikipedia new page patrollers who use this app are happy with the current look of it, and big visual changes may not be well-received.

Things I am concerned about (things I don't think we should do) include adding a bunch of padding/margin, and changing icons.

That red bar doesn't look good. I'll make a ticket for that. T323533

In T208256#8411285, @Novem_Linguae wrote:

Screenshots added.

Thank you! @egardner you can also visit en.wikipedia.org/wiki/Special:NewPagesFeed to see the UI in action.

Please get consensus for any major changes to the visual appearance of the app before spending a bunch of time on it. English Wikipedia new page patrollers who use this app are happy with the current look of it, and big visual changes may not be well-received.

Yeah, I think we might need to propose some design rather than building first, though I don't think the overall structure (headers, rows of data, buttons, etc) needs to change. It's just that we would propose to use the standard, supported, official toolkit for building the UI, Codex (https://doc.wikimedia.org/codex/main/). You could have a look at the components and design tokens to see what that looks like. The major benefit of using this is that 1) it brings PageTriage's UI into alignment with the appearance of other front-end applications on-wiki and 2) it uses the same underlying technology (Vue JS) that would make it easier to contribute, as it's more commonly supported than the libraries PageTriage currently uses.

I don't think it would make sense to try to rewrite PageTriage to use Vue and mimic the existing styles; that seems like a lot of extra effort, and the end result would again not be in accordance with the broader Wikimedia design style guide.

@Novem_Linguae thanks, very helpful to have UI images here! I agree that some discussion with the community will be necessary before this project could move forward.

I wonder if it would make sense to start with a mockup of how PageTriage would look if it followed the styles found in Codex and the WMF style guide, without otherwise changing the layout or behavior of the tool much. Most of the icons being used here have counterparts in the Codex iconset already. In terms of other UI elements, we have the standard things like buttons, checkboxes, etc. The filter menu and the "Add Tags" sub-nav area don't have existing equivalents so some custom elements would need to be created there. A static UI mockup could then be circulated as part of a proposal.

I do agree with @kostajh that continuing to maintain / update this tool in the existing jQuery UI is not really something we want to do – we want to move away from jQuery UI generally, there is an added maintenance burden to managing multiple UI frameworks, the visual experience is inconsistent, etc. I think it would be possible to update the UI while preserving the workflow that editors using this tool are accustomed to.

I wonder if it would make sense to start with a mockup of how PageTriage would look if it followed the styles found in Codex and the WMF style guide, without otherwise changing the layout or behavior of the tool much. Most of the icons being used here have counterparts in the Codex iconset already. In terms of other UI elements, we have the standard things like buttons, checkboxes, etc. The filter menu and the "Add Tags" sub-nav area don't have existing equivalents so some custom elements would need to be created there. A static UI mockup could then be circulated as part of a proposal.

@egardner do you think it is feasible to create a mockup with Codex in a static HTML/CSS/JS repo with fake data, or is that too much overhead, and using Figma would be easier?

If we rewrote this in Codex, would we be able to keep a similar look and feel for the extension? How much would visual elements such as the below change?

I think 1) keeping the current look of the extension, and 2) doing the rewrite incrementally (even if Vue/Codex and Backbone/Underscore are both being loaded side-by-side for awhile), are going to be important for a successful front-end rewrite.

In T208256#8439915, @Novem_Linguae wrote:

If we rewrote this in Codex, would we be able to keep a similar look and feel for the extension? How much would visual elements such as the below change?

I think 1) keeping the current look of the extension, and 2) doing the rewrite incrementally (even if Vue/Codex and Backbone/Underscore are both being loaded side-by-side for awhile), are going to be important for a successful front-end rewrite.

This feature is complex enough that I think we'd need a few new components in Codex before porting it over would be feasible. For example, your last screenshot includes a layout with a navigation sidebar on the left. OOUI has a BookletLayout that's pretty similar to this, but we don't have anything like this in Codex yet.

The big pop-out filter menu is another thing that doesn't have a Codex equivalent right now. In Commons MediaSearch (which is built with an alpha-version of some of the Codex components), we had a complicated Namespace Filter that we decided to just embed in a dialog. You can see an example here by clicking on the "Namespace" button below the tab bar. If a decision is made to keep the pop-out/drop-down version of this feature, then a custom component would need to be created instead.

Anyway, this project is complex enough that I don't forsee anyone attempting a re-write right away. If jQuery UI is eventually removed from MW core entirely, projects like this one could just provide their own copy of the library and continue to exist in maintenance mode if folks decide that such a re-write is not feasible. Maybe a successor project that provides similar features could also be considered down the road – these are questions for the Growth Team and the community to work out.

Personally, I think that a simpler feature like Wikilove might make more sense when it comes to migrating old jQuery UI features to Codex: T323311: [Proposed Epic] Migrate Wikilove front-end to Codex.

I'm not around enough to tackle this myself, but a while ago I wrote a Special:NewPagesFeed implementation in vue at https://en.wikipedia.org/wiki/User:DannyS712/VueNPP.js that uses WVUI but should be easy to switch to Codex - as far as I recall it results in as close to the same look and feel as the current jQuery version, feel free to try it out by navigating to Special:BlankPage/VueNPP

In T208256#8440168, @DannyS712 wrote:

I'm not around enough to tackle this myself, but a while ago I wrote a Special:NewPagesFeed implementation in vue at https://en.wikipedia.org/wiki/User:DannyS712/VueNPP.js that uses WVUI but should be easy to switch to Codex - as far as I recall it results in as close to the same look and feel as the current jQuery version, feel free to try it out by navigating to Special:BlankPage/VueNPP

Wow, impressive. That's a great reference/starting point. Thanks for linking.

To add a missing step to review this:

• Go to your common.js page, e.g. for me it's https://en.wikipedia.org/wiki/User:KHarlan_(WMF)/common.js
• set its contents to importScript('User:DannyS712/VueNPP.js');
• visit https://en.wikipedia.org/wiki/Special:BlankPage/VueNPP

In T208256#8439915, @Novem_Linguae wrote:

If we rewrote this in Codex, would we be able to keep a similar look and feel for the extension? How much would visual elements such as the below change?

I think 1) keeping the current look of the extension, and 2) doing the rewrite incrementally (even if Vue/Codex and Backbone/Underscore are both being loaded side-by-side for awhile), are going to be important for a successful front-end rewrite.

It looks like @DannyS712's work shows that we could rewrite using Vue and keep the current look. That said, relying on a library using the Wikimedia Design Style Guide has loads of benefits:

• Consistent UX with other features
• Consistent and up-to-date visual style
• Well-researched components for UX and accessibility

Switching to Vue + existing styles would be an improvement over the status quo, but if we had long term view of being on the standard UX library, then doing the conversion with Codex from the start would probably save time and effort. That said, I don't have an objection to Vue + existing styles as an interim step, as it allows us to jettison underscore/backbone.

@DannyS712 's mockup looks great. A Vue and no Codex rewrite is an interesting option, if we think it's worth the time. There's a lot of JavaScript logic that'd have to be ported over or rewritten. We'll have to decide how high a priority a front end rewrite is compared to other things (PHP technical debt, features, etc.)

If it wasn't clear, from what I recall my Vue version has all of the JavaScript logic for the feed, not just a mockup - it actually works

Awesome. Thanks for clarifying that and for doing that coding. Sounds like most of the conversion work has been completed for Special:NewPagesFeed.

The Page Curation toolbar will be the other big piece of this. The Page Curation toolbar has a lot of JavaScript logic, currently contained in the files mark.js, delete.js, and tag.js.

Any objections to renaming this ticket "Rewrite PageTriage front-end with Vue"? I don't think we'll be able to get consensus for a Codex rewrite, since it will change the visual appearance too much. Vue only, based on Danny's rewrite, seems like an actionable middle ground.

In T208256#8442197, @kostajh wrote:

Switching to Vue + existing styles would be an improvement over the status quo, but if we had long term view of being on the standard UX library, then doing the conversion with Codex from the start would probably save time and effort. That said, I don't have an objection to Vue + existing styles as an interim step, as it allows us to jettison underscore/backbone.

I am in agreement on both points here – in the long run it would be great to have more visual consistency across the various tools being used on-wiki. But in the short term I think that upgrading the underlying technology is still beneficial.

In T208256#8445020, @Novem_Linguae wrote:

Any objections to renaming this ticket "Rewrite PageTriage front-end with Vue"? I don't think we'll be able to get consensus for a Codex rewrite, since it will change the visual appearance too much. Vue only, based on Danny's rewrite, seems like an actionable middle ground.

No objections from me. If this goes forward, feel free to ping me in Gerrit and I can try to take a quick look at any relevant patches. Using Vue inside of MW is a little different from the standard approach you might see elsewhere in tutorials or general Vue documentation.

One other consideration to keep in mind: MediaWiki is using Vue 3, which dropped support for IE11. Porting any of these tools over to Vue will mean that they will likewise drop support for IE11. The flip-side is that you can now write your code in ES6. I'd encourage use of native promises, modern array methods, etc. over things like $.extend, $.Deferred, etc.