To summarise my thoughts from Discord: I welcome trying to improve the structure since it is pretty much stuck in 2000s but I don't think a proper table structure can ever work on that page or elsewhere. First, users typically value high-information density there, second, there are a lot of elements that can take up a lot of space and still be valuable (edit summaries are up to 500 characters now, every single tool adds edit tags now, etc.). You can achieve a table-like structure, like what grouped/enhanced mode currently provides, but table is probably unachievable.

Some elements can definitely be improved and some better structure can be provided. Ideally, you would want to make it so ‘grouped by page’ mode actually becomes just a ‘grouped by page’ mode, and not ‘provide a bunch of enhancements not available by default’ mode like it is now. Compare:

‘Ideal’ grouping IMO would be something like (not thinking of logs yet):
— time
— diff link
— page markers (minor/Wikidata/etc.)
— page title, diff change
— history link, thank link, rollback link
— user links
— edit summary, edit tags

Though maybe others might disagree, especially with putting thank/rollback earlier. Some of these can be in ‘columns’ but others cannot and won’t ever be possible to put in columns due to the changing nature of wikitext (page markers, diff change, page titles, usernames, edit summaries, edit tags can all be different widths, especially between languages). There are also a number of additional settings like colour coding, watchlist addition/removal, etc. that have to be accounted for.

I think people might welcome some structural/design changes that will improve the readability of these lists but pretty much everyone (me included) will be not a fan of changes that would decrease current information density. Mobile design is great for someone who doesn’t have to actually use those pages (and hardly anyone uses mobile for recent change patrolling). Given the volume of edits in most wikis, decreasing the information density is unlikely to be well-received. Additionally, RecentChanges and Watchlist should look the same even with the changes.

For future reference, Discord discussion started here, in the General Technical Discussion thread.

do away with date-based headings?

This is the subject of T10681: Do not group changes by day in enhanced recent changes with attendant linked tasks of interest, all more or less focused on "I want one diff, not 2-N". (Probably one not linked there is something like T21247.)

Moving on to larger discussion:

Probably this could be done but it needs to 1) be more flexible than an html table and 2) have the information density that Wikimedians all know and love. The current list structure does allow both 1 and 2 a bit more freedom than a table would. CSS subgrid could be used to extend the current list display without particular loss of accessibility (relative to a table) while also allowing the flexibility that a table disallows, with fallback to display: inline-block or some such for elements in the grid for older browsers. In the limit you need that fallback in some way anyway if you want to support mobile resolution watchlist systems properly. And would allow enhanced RC to scale down - Minerva just gives up on this mode of display and Timeless hacks on the table to some degree. I would guess Vector 22 and Monobook mobile styles have their own hacking on enhanced RC. (Obligatory ping for @Jdlrobson perhaps.)

This does require some thought about how to deal with both legacy display of RC/Watchlist and enhanced view. I think the former is actually easy to deal with without too much further consideration. At various resolutions either employ a subgrid of whatever size (could even adjust the number of columns per resolution) or below it display inline/inline block/block. Since edit summaries often have a variable length, below say 1500px you could have them in a second row per line item. Enhanced view would I presume just have the internal list with its own grid to pay attention to in each internal list.

I do seem to recall one or another of our changes pages having been a table before, maybe it was history view, and there were cries of sadness when it was changed to a list. No, I don't remember which and when I went history diving I couldn't find it, so I may be hallucinating.

Though maybe others might disagree, especially with putting thank/rollback earlier.

There is a task lying around for some adjustments of order but now I seem to have lost it in the couple hundred watchlist/RC tasks.

In discussing this and our other potential priorities around the Recent Changes UX, we identified that we should consider a Codex migration, rather than implementing new interfaces in an old UI framework. This might be a big lift in terms of community engagement and buy-in (we would almost certainly want to feature flag/beta this), but we're being encouraged to upgrade to Codex when we touch existing interfaces. Let's start by doing some explorations and see where they take us.

I'll file followup tickets for designing the JS and no-JS views for RecentChanges.

In T380387#10396139, @Samwalton9-WMF wrote:

I'll file followup tickets for designing the JS and no-JS views for RecentChanges.

T328706: Port RCFilters to Codex already existed and is the obvious place to start - this is the most substantial UI on the page.

Unclear that we should do anything with the no-JS page, it's a low priority UI due to the low number of users.

I think they mean a different component by RCfilters, though (only the top part). I do agree that it needs to be ported to Vue though since currently the performance of it is awful (which is why I personally do not use it at all).

Thanks @Samwalton9-WMF for mentioning this task back in December while I was complaining on Discord about our special pages, one of my perennial activities. I actually started producing something to reply with back then but various factors got in the way, so here I am now!

A good presentation of this kind of information clearly distinguishes its component elements while retaining a visual relationship between them. It also maintains those properties across viewport sizes. Here's a wireframe to demonstrate the kind of thing I'd expect from a modern Special:RecentChanges. It isn't perfect, just a sketch, plus I'm not a designer. But it scales fluidly and is usable whether viewed in a very wide browser on a big screen, or on a phone at only 250px wide.

In T380387#10521712, @Hex wrote:

Thanks @Samwalton9-WMF for mentioning this task back in December while I was complaining on Discord about our special pages, one of my perennial activities. I actually started producing something to reply with back then but various factors got in the way, so here I am now!

A good presentation of this kind of information clearly distinguishes its component elements while retaining a visual relationship between them. It also maintains those properties across viewport sizes. Here's a wireframe to demonstrate the kind of thing I'd expect from a modern Special:RecentChanges. It isn't perfect, just a sketch, plus I'm not a designer. But it scales fluidly and is usable whether viewed in a very wide browser on a big screen, or on a phone at only 250px wide.

special-recentchanges-adaptive-layout.html23 KBDownload

Very interesting, thanks for sharing! Pulling out a couple of screenshots for quick reference:

Not to shutdown the enthusiasm, but that mockup is exactly what should not be done if we want widespread adoption of new interface instead of it being opt-in forever. Previously compact interface became thrice as large while readability in fact decreased in some ways because the eyes have to travel more to read essential information about the edit.

At some point the advocates of "compactness" are going to have to accept that wanting to use something that looks like a telephone directory circa 1984 is a position held by a minority of users.

Wikimedia way is about doing improvements that improve the life of volunteers, not about saying ‘if you don't like it, go somewhere else’. If you look, for example, at community-developed tools like https://meta.wikimedia.org/wiki/SWViewer, they try not to waste space unnecessarily but still help the user. RC/watchlist in particular are pages that are used by many people for labour-intensive edit monitoring, so having a lot of info presented there is a benefit to that work and not a hindrance. Of course, that info still has ways to go in terms of presentation.

Funny how you could have been that constructive with your commentary the first time around and yet chose not to be.

I put together that food-for-thought wireframe in very short order, to demonstrate how little effort it would take to move away from the 20-year-old embarrassment that our users have to suffer through using currently, and presented it with a significant caveat. If it manages to stoke a little more fire under this issue then I've achieved my goal. I have no desire to remain in a discussion with someone who alternates between heckling and lecturing, so good luck to the team on this one.

I thought my initial commentary was constructive. I said that a mockup like that would not be agreed upon by a majority of users because it is too large in comparison. I should’ve clarified more that I was basing this on feedback to previous OOUI/Codex conversions of forms. I also mentioned a specific issue with the layout: eyes have to go back and forth to read the most important information. I could’ve expanded it more but I meant no ill will (and I apologise to Hex if it read that way), and I agree that the layout should be improved. I’ll try to do a mockup myself so that others can constructively criticise it.

Made a mockup: https://test.wikipedia.org/wiki/User:Stjn/sandbox

This is by no means a responsive layout or flawless CSS code, but it is a more structured version of the current layout. I was debating whether to put user links even closer to page links, but there are plenty of longer titles in many wikis, so I decided against it. To be clear, I am sure someone would hate even this layout for not being compact enough, especially when no edit summary is provided (second to last row), but I feel like this is the sort of adjustment that most users could live with.

@stjn Having it that far of the title makes it harder to keep track of which user did what row. It's easier to go one up or one down accidentally. What about adding at the start instead? Maybe even hiding the links to the talk and contribs inside a dropdown, because I don't think they are used that much (I assume most people only use them while patrolling when they see something "bad" which would decrease the noise while keeping the compactness).

Even if their approach decreases compactness too much I liked the approach Hex took for the Tags, at least for me it's clear that those are tags and being each of them in one "pill" it makes it easier to see how many they are and which ones are there and for me it's easier to scan than the current comma separated list. I also liked it for the m, N and ! ones. Not that much for the diff size, because in that case we lose the extra information we have in the current recent changes with the bold text meaning that the change is big. Maybe one with just the border and the text if the change is small and the ones with the background for the cases when the change is big would be better?

Also if the plan is to update the interface to make it look more modern we can't just leave responsiveness out of the design. The current layout has a lot of information, and it's not feasible showing all of that information in a mobile phone while keeping the data compact. At least it would be nice knowing what info is required, what info is nice to have and what info could be hidden in a dropdown without that decreasing the usefulness of the page (probably even hiding the less used ones in big screens too).

@Agabi10: first off, I think you misunderstood my point about responsive design. This layout can be made responsive since it is built using CSS grid, I just focused on structure for desktop for initial mockup. My main focus was to think about how elements could be placed in a sensible, more consistent way, not on what the complete look should be (in regards to your points on style of tag/marker pills).

To your points on the structure:

1. This is a trade-off with any table-like layout, IMO. The only way you can make it not a problem is either 1) by making this an actual table so the column width adjustment happens automatically, or 2) putting user links in an inconsistent position based on the width of the title. Not sure what you mean by adding them at the start: in a separate row? in the same row as comment? just before the title? (if the latter, IMO that might be too disruptive for power users)
2. I think hiding any currently available links like you propose with talk/contribs would go down badly with the community and brings no benefit other than designers thinking that this is ‘more clean’. What could be explored is switching those links to be icons. But IMO they don’t waste space anyway and going to someone’s contribs or talk from these sorts of pages is a really common UX workflow which should not be made harder.

My problems with the javascript UI that keep me using non-JS version are:

1. Content shift after load
2. The namespace filter is really annoying to use/scroll through, especially on wikis that have a bunch of custom namespaces. The old menu, despite its lesser functionality, felt a lot better to use.

A couple issues I have (which I always fix with user css/js):

1. Having an 'edit' button next to each page link is very useful in any report (RCs, category, contributions, individual revisions of a page history) etc. It's true that *usually* from RCs I would click a diff before editing, but sometimes I just need to get back to a page quickly, and pressing alt+Shift+R and then clicking the title/edit link is the easiest way to get there. Here is how my local edit links look:

2. It's too easy as an admin to accidentally rollback. I prefer to hide rollback from RCs but show it in contributions, so when I need to go to rollbacks I do it from a contribs page (which usually I'm not visiting for any other reason). Another solution that I've long thought would be a good idea but haven't bothered to implement, is to hide all rollback links until you click a button or checkbox "Show rollback links" somewhere. Would help with misclicking and accidentally causing panic-inducing notifications sent to contributors as a result of the misclick.

Otherwise RCs work great and I am pretty deeply opposed to any significant visual rework, particularly if it's not optimized for looking at hundreds of changes at a time and scrolling through easily.

Improving JS-based filters seems like in scope for T328706 instead (I do think they are very slow and hard to use, and both issues you’ve raised are why I disabled them, as well as unasked for URL changes). Having edit links is a good idea (though adding them in a way that makes sense would still require a visual rework which you oppose). For (2), there is an option to enable rollback confirmation in the settings, though it is also imperfect.

In T380387#10530769, @RheingoldRiver wrote:

2. It's too easy as an admin to accidentally rollback. I prefer to hide rollback from RCs but show it in contributions, so when I need to go to rollbacks I do it from a contribs page (which usually I'm not visiting for any other reason). Another solution that I've long thought would be a good idea but haven't bothered to implement, is to hide all rollback links until you click a button or checkbox "Show rollback links" somewhere. Would help with misclicking and accidentally causing panic-inducing notifications sent to contributors as a result of the misclick.

In case you didn't know, there is a "Show a confirmation prompt when clicking on a rollback link" option in the Preferences (Appearance menu)

In case you didn't know, there is a "Show a confirmation prompt when clicking on a rollback link" option in the Preferences (Appearance menu)

Maybe we're getting slightly out of scope of this task, but that confirmation has a few problems:

1. I cannot center-click-new-tab-unfocused "confirm rollback" without then having to click again in the new tab
2. Once I have done one rollback I don't want any further rollbacks to need to need confirmation if I'm on the same page load, that makes rolling back 5-10 vandalizing edits (more than one; few enough that it's not worth using any tool for it) way too much work.

The current layout could be improved with some better visual separation within the lines, but the low information-density tables are not the way to go. In these mockups I don't even see revisions with 3,4 or 5 edit tags (they can get long in some languages) or edits with long edit summaries, I don't see Twinkle buttons (love Twinkle), I don't see the possibility of expanding the diff right below each line (inline diffs), coupled with patrol buttons for wikis that use PatrolChanges. Any idea how many user scripts will be broken? Any work done on making the layouts of Recent Changes, Watchlist, Page History, User Contributions the same (for easier scripting at least)?

Noting T397258 which adds some iconography for Wikidata entries.

Our team explored this idea last year, and although we decided not to move forward with any changes at the time, we did create some exploratory mocks and notes, which I realised I never documented here in case this work gets picked up again, so I'm remedying that now! Feedback and thoughts welcome.

We focused on the desktop view, and wanted to solve a few primary issues:

• The list is hard to parse on desktop, with no visual separation between list items
• Separators between data in a given list entry can be confusing, variously being ;, . ., or brackets
• It's hard to vertically scan the list because information isn't aligned
• New users can find it confusing to parse the list, as there is no guidance about what each piece of information is.

We ran a brief Userlytics study with non-editors to learn more about how they interpret the list. Some highlights from the responses:

We asked users to describe what each piece of information in a single row meant. Out of 16, the following plot shows what they got correct:

• Half or fewer of respondents correctly identified what "contribs", the edit summary, "talk" or the byte count change were.
• It's interesting to see some variation here on 'talk' and 'contribs' between German and English respondents. This may be related to localisation and which terms have been used for these links.
• In their own words, respondents noted that they would appreciate having some descriptors for what each piece of information was, and highlighted that words like 'diff', 'hist', and 'contribs' were confusing.

We then played around with a few design mockups which would structure the information more clearly. I'm sharing some of our rough exploratory mocks below, we didn't settle on any design in particular, and if we did come back to this work we'd continue to iterate on these, but I think they're interesting to discuss. We started by focusing on adding columns and separating list items more clearly.