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.

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.

I don't think it would make sense to rewrite PageTriage in Vue without Codex. You'd have to do extra work to reimplement a bunch of things that Codex already has (like buttons, checkboxes, dialogs, etc), only so that PageTriage can look deliberately different from the rest of the UI, which is at odds with our goal of using a consistent design system across the Wikimedia-verse.

In T208256#8439996, @egardner wrote:

In T208256#8439915, @Novem_Linguae wrote:

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.

Nowadays Codex's Dialog component is flexible enough that I think this could be built locally in PageTriage first, then upstreamed to Codex later. Codex probably should have "multi-page dialog with navigation on the left" as a component, but I don't think it's too hard to build outside of Codex first.

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.

I agree. I would also point to the toolbar that floats on the right-hand side of the screen as another example of a complex component that should either be changed to something else, or should be implemented as a custom component in PageTriage, because I think it's unlikely that it would be used by enough other things to live in Codex.

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 fully agree with this. Wikilove is a much simpler feature, and especially now that Codex has a more flexible Dialog component, migrating Wikilove to Codex should be very doable.

If there are concerns about community pushback to Codex then perhaps a sensible first step is to create a mockup of a codex implementation of one or more of the interfaces and see what folks think about it. It seems unclear to me exactly how different it would be in terms of layout and how positive/negative the reaction would be.

Vue only:

• A volunteer already started the rewrite. Did the entire Special:NewPagesFeed, which may even be 50% of the work. (The other 50% is the Page Curation toolbar.) - T324914: Add [[User:DannyS712/VueNPP.js]] to PageTriage repo
• No changes to visual appearance of extension, so no need for designers, community consultation, etc.

Vue+Codex:

• 100% front end rewrite needed
• Designer needed
• Community consultation needed, which may end with a consensus that they don't like it

Vue+Codex seems like a rabbit hole to me that could eat up a lot of time and resources.

I'll go ahead and edit this ticket to be about picking a front end framework, and I'll split the "Vue only" tasks into a separate ticket.

I do agree that the Vue+Codex approach would require more resourcing and effort upfront, but I think that might be worth it depending on what the goals are of the rewrite. Just rewriting everything in Vue doesn't automatically make it more maintainable or extensible. If the goal is to get the feature to a point where it is easy to change existing functionality or add new functionality, then just going with the T324914 approach (respectfully) might not help us with that. It might work, and it might be written in Vue, but will it now be that much easier to make improvements?

As has already been pointed out, using Codex would provide out of the box well-researched, tested, accessible, and consistent components that would benefit from system-wide improvements over time. Ultimately it is the decision of whoever chooses to make these changes. I understand the desire to move faster by not having to consult design and community input, but it's a potential tradeoff to long-term gains. Either way, the Design Systems Team is open to discussing how we can support.

Picking which front end frameworks to use for the PageTriage front end rewrite appears to be complete. We landed on Vue with a little bit of Codex. Closing this ticket as complete. Further work can be tracked in T335074: Rewrite PageTriage front-end in Vue.js