Can you point me to the extension or MediaWiki.org that discusses enhanced recent changes? This sounds fascinating :)

So, I imagine that, before switching "Enhanced Recent Changes" (ERC) on for all users, we would need to ensure that there is some form of graceful degradation from ERC to simple old "Recent Changes" (RC) for users without JavaScript.

ERC dates from when we couldn't expect a user's browser to necessarily support JavaScript, which is why it wasn't the default when we rolled out in 2003 or whenever(?), but in general we don't require it even now. What's the current behaviour for ERC when you don't have JavaScript?

Also, both RC and ERC are quite ugly, and I think we should separately look at improving their design so they are a little cleaner/prettier, and so that it is more obvious how to use them. But that should be a separate bug. :-)

(In reply to comment #1)

Can you point me to the extension or MediaWiki.org that discusses enhanced
recent changes? This sounds fascinating :)

https://meta.wikimedia.org/wiki/Help:Enhanced_recent_changes

(In reply to comment #2)

So, I imagine that, before switching "Enhanced Recent Changes" (ERC) on for all
users, we would need to ensure that there is some form of graceful degradation
from ERC to simple old "Recent Changes" (RC) for users without JavaScript.

ERC dates from when we couldn't expect a user's browser to necessarily support
JavaScript, which is why it wasn't the default when we rolled out in 2003 or
whenever(?), but in general we don't require it even now. What's the current
behaviour for ERC when you don't have JavaScript?

It just shows the list of changes for a page (brouped but) uncollapsed. Many think this is better and prettier than standard RC anyway. There's indentation, so it's quite clear what pages the changes belong to.

Also, both RC and ERC are quite ugly, and I think we should separately look at
improving their design so they are a little cleaner/prettier, and so that it is
more obvious how to use them. But that should be a separate bug. :-)

Indeed.

Given all the AJAX improvements we'll have in 1.21, it would be nonsense to have such a basic and vital JavaScript feature still hidden: setting milestone.

The path forward for this bug is unclear to me. What's needed here, exactly? Just a flip of a global configuration variable in DefaultSettings.php? If so, which one? If not, what needs to be done in order to resolve this bug?

Sorry, I thought it was obvious: what wikis currently have to do is $wgDefaultUserOptions['usenewrc'] = 1; .
This is a default that makes sense to change also for old wikis upgrading and for old users, but if another method is preferred that's not a problem.

Change 49082 or whatever.

(In reply to comment #8)

Change 49082 or whatever.

Aka I7c2a27b4d.

Would that change make it the default for new accounts, or for all accounts that have not actively set a preference?

From what I understand both. MediaWiki isn't smart enough to differentiate between those, nor, perhaps, ought it.

It'd be nice if it did from a data POV, actually. I worry that this is going to unleash a mountain of unexpected hurt and shock from people who have seen their UI suddenly change overnight with little/no warning.

I've got no issue if you want to be proactive and tell people this is coming, mind.

Aye, I'd like to, but how?

(In reply to comment #12)

I worry that this is going to unleash a mountain of unexpected hurt
and shock from people who have seen their UI suddenly change overnight
with little/no warning.

Yes, this.

I'd recommend a slow roll-out of this feature, with notification to the projects, but more importantly, some kind of Google-esque "we've changed the UI... don't like it? [click here] to change your user preferences back to the old UI" temporary notice. Temporary being a month or so.

I'd also probably not take two shots at once, particularly as the second shot is so unexpected. This bug is about Special:RecentChanges only, as far as I can tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both Special:RecentChanges and Special:Watchlist. Ouch.

sumanah wrote:

I'm asking Guillaume Paumier to opine regarding how to communicate about this suggestion with the Wikimedia user community,

(In reply to comment #14)

I'd also probably not take two shots at once, particularly as the second shot
is so unexpected. This bug is about Special:RecentChanges only, as far as I
can
tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both
Special:RecentChanges and Special:Watchlist. Ouch.

If anything, I think it would be more confusing if one was changed but not the other, since they now look pretty much the same by default.

(In reply to comment #16)

(In reply to comment #14)

I'd also probably not take two shots at once, particularly as the second shot
is so unexpected. This bug is about Special:RecentChanges only, as far as I
can
tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both
Special:RecentChanges and Special:Watchlist. Ouch.

If anything, I think it would be more confusing if one was changed but not
the
other, since they now look pretty much the same by default.

Sure, in the sense that the UI would be marginally more inconsistent for some users. But Wikipedia's UI is always inconsistent, in some way/shape/form: the problem is that by changing both at once you're going to hit more users, and you're going to hit some of them twice.

Most power users don't use recentchanges. /all/ power users use the watchlist.

(In reply to comment #14)

I'd also probably not take two shots at once, particularly as the second shot
is so unexpected. This bug is about Special:RecentChanges only, as far as I
can
tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both
Special:RecentChanges and Special:Watchlist. Ouch.

Ouch? These should not be separate preferences items at all. My interest in this bug came from the watchlist side, and while I was later surprised to find this did not actually cover that, there is no good reason not to keep these things together. Be consistent and such.

(In reply to comment #17)

Most power users don't use recentchanges. /all/ power users use the
watchlist.

Depends on the wiki. On larger Wikipedias, it's not that useful but on smaller wikis like Wikinews, we use it quite a lot.

extendwatchlist is *not* the same thing as usenewrc: usenewrc applies to both Special:RecentChanges and Special:Watchlist, which are both instances of recent changes; extendwatchlist shows, on Special:Watchlist, all the edits to a given page in the defined timespan, rather than the last one only.
extendwatchlist is actually the most impacting change in the patch and I didn't propose it, althought it *might* make sense; probably better on a separate bug.

(In reply to comment #14)

I'd also probably not take two shots at once, particularly as the second shot
is so unexpected. This bug is about Special:RecentChanges only, as far as I
can
tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both
Special:RecentChanges and Special:Watchlist. Ouch.

See also Bug 35768.

(In reply to comment #19)

(In reply to comment #17)

Most power users don't use recentchanges. /all/ power users use the
watchlist.

Depends on the wiki. On larger Wikipedias, it's not that useful but on
smaller
wikis like Wikinews, we use it quite a lot.

I confirm this is true.

(In reply to comment #17

Sure, in the sense that the UI would be marginally more inconsistent for some
users. But Wikipedia's UI is always inconsistent, in some way/shape/form: the
problem is that by changing both at once you're going to hit more users, and
you're going to hit some of them twice.

Most power users don't use recentchanges. /all/ power users use the watchlist.

Both changes at once would mean it hits everyone at once, and only once - otherwise we'd just wind up in arguments about the same thing twice for no good reason.

(In reply to comment #20)

extendwatchlist is *not* the same thing as usenewrc: usenewrc applies to both
Special:RecentChanges and Special:Watchlist, which are both instances of
recent
changes; extendwatchlist shows, on Special:Watchlist, all the edits to a
given
page in the defined timespan, rather than the last one only.
extendwatchlist is actually the most impacting change in the patch and I
didn't
propose it, althought it *might* make sense; probably better on a separate
bug.

If the rc one changes the watchlist format as well as a sort of halfway change, then all the more reason to change both things at once, since otherwise people will only wind up even more confused about the intermediary watchlist state.

(In reply to comment #22)

Both changes at once would mean it hits everyone at once, and only once -
otherwise we'd just wind up in arguments about the same thing twice for no
good
reason.

There's no way to separate, no matter what.

(In reply to comment #23)

If the rc one changes the watchlist format as well as a sort of halfway
change,
then all the more reason to change both things at once, since otherwise
people
will only wind up even more confused about the intermediary watchlist state.

It's not really an intermediary state, but yes, of course very big wikis would benefit from the change less; this doesn't mean that it wouldn't be an improvement for them and for everyone (WL looks better with usenewrc even when "grouping" only a single edit per page).
Given that the default for wllimit is 250, changing extendwatchlist will probably not affect users that much; the worse that can happen is that they need to click the selector to have more changes, and go to the preferences to make it permanent. It needs no special magic to change preferences, if we feel like changing it.
usenewrc is even less impacting than that.

In short:

1. if you care about en.wiki, keep extendwatchlist onboard;
2. just add release notes and a section to the wmfN page and communicate it with the usual crosswiki messaging sending people to the release page etc.

wmfN?

(In reply to comment #25)

wmfN?

E.g. 1.21wmf10 -> [[mw:MediaWiki 1.21/wmf10]] or whatever.

How do you do that release notes thing, and such? Is there good documentation somewhere?

Just add an entry to the RELEASE-NOTES-1.21 file.

Note: As this has the 1.21.0 target milestone set, somebody would have to decide on the patch in Gerrit which is awaiting more reviews / merging. If this does not happen in the next weeks, the Target Milestone will likely get removed.

I'm happy to merge this if Isarra (or someone) is going to do the leg work of informing the community about this change.

(In reply to comment #30)

I'm happy to merge this if Isarra (or someone) is going to do the leg work of
informing the community about this change.

Wonderful! I can do that, in case Isarra doesn't want. Of course Isarra (or anyone) would be better than me at it, but I should manage too.

Pulling from 1.21.0 and pushing to 1.22.0 as bug 44874 is a critical dependency, as highlighted by MatmaRex.

I'm switching the milestone back to 1.21 for now, since the dependency is set to 1.21 as well. Hopefully we can make it.

Fixing this bug itself is just a matter of two-line change and two-paragraph changelog ;) once the dependency issue is solved. (As well as forwarding that changelog to all the Wikimedia wikis' communities.)

Maybe we could even just change the default in 1.21 release, and keep the old setting on the WMF cluster until the dependency is sorted out?

The enhanced changes code is truly awful, but i am working (and have preliminary working code) to get it good enough so that Wikidata can hook into it and support it.

It will take a little bit longer to get it finished, code reviewed, merged and deployed.

To work around the awfulness, the CleanChanges extension, for example hooks into the FetchChangesList hook and replaces the enhanced changes class with a different class. That *sucks* if each extension has to do that and doesn't allow multiple extensions to be compatible and hook into the same code.

(In reply to comment #30)

I'm happy to merge this if Isarra (or someone) is going to do the leg work of
informing the community about this change.

I suppose this would include an e-mail to the wikitech-ambassadors mailing list and possibly a global message delivery. Perhaps more, perhaps less.

There's also the question of whether we want to include a "don't like this change? here's how to switch back" temporary message.

We could have a preference for users to use the *old* format, if they really want.

(In reply to comment #36)

We could have a preference for users to use the *old* format, if they really
want.

Erm, what format are you talking about? The non-JS RC/WL is just usenewrc preference set to false and we're only changing the default here.

@Nemo: exactly. we can keep the preference and allow people to use the old non JS format.

(In reply to comment #38)

@Nemo: exactly. we can keep the preference and allow people to use the old
non
JS format.

Nobody has yet thought or proposed to remove this preference. If someone thinks it should be removed at some point, they should propose it at [[mw:Requests_for_comment/Core_user_preferences]].

What would get anons if usenewrc is made default?

We should probably want to add another link to the options in Recent Changes to switch from enhanced recentchanges to old recentchanges (where there are links to show/hide anons, registered users, bots, etc) so anons can switch back if they prefer the old one, or a user that can't log in, etc

No. Option bloat is enough of a problem without adding yet more cruft like this. If people want non-default interaction mechanisms with MediaWiki, that's what an account is for.

Affectionate anons can always use newrc=0 parameter.

There are valid use cases for both grouped and ungrouped recentchanges and at some point I would like to see a toggle added as Ciencia Al Poder suggests, but the options interface in general really needs an overhaul first - it's bloated already and as it is there is nowhere to put it that wouldn't just add to the bloat and get lost in it.

Meantime, what Nemo said, I suppose.

(In reply to comment #42)

Affectionate anons can always use newrc=0 parameter.

Is newrc=1 supposed to work? I can't seem to make it working on wikipedia as anon (to activate newrc, where it's currently off by default) And if I log in, using newrc=1 doesn't work neither to switch back to the old rc.

Even if a new option is not added to the interface, having the possibility to switch from one to another with a URL parameter would be great

It appears to either be the wrong parameter or be broken. I know it (or something very similar) worked a couple months ago...

Extension CleanChanges implements newrc=1, oldrc=1 and cleanrc=1 which causes this confusion.

(In reply to comment #32)

Pulling from 1.21.0 and pushing to 1.22.0 as bug 44874 is a critical
dependency, as highlighted by MatmaRex.

I no longer think the dependency is really such. In principle, WMF-specific problems mustn't block MediaWiki development, but we're used to that. However, there also isn't any proof that changing the default would really cause disruption, and I think the dependency should not be readded until there is such a solid indication:

1. bug 45892 means that very few people are seeing Wikidata changes in the watchlist anyway as of now;
2. most users caring about Wikidata changes are already using enhanced RC, as shown by anectodical evidence on it.wiki discussions when Wikidata was enabled and how only a query such as https://jira.toolserver.org/browse/DBQ-205 could disprove.

(In reply to comment #21)

(In reply to comment #14)

I'd also probably not take two shots at once, particularly as the second shot
is so unexpected. This bug is about Special:RecentChanges only, as far as I
can
tell, but https://gerrit.wikimedia.org/r/49082 is currently changing both
Special:RecentChanges and Special:Watchlist. Ouch.

See also Bug 35768.

(In reply to comment #19)

(In reply to comment #17)

Most power users don't use recentchanges. /all/ power users use the
watchlist.

Depends on the wiki. On larger Wikipedias, it's not that useful but on
smaller
wikis like Wikinews, we use it quite a lot.

I confirm this is true.

As someone who edits mostly on Meta-Wiki, I use RecentChanges much more than my watchlist (which I've cleared several times).

mr.heat wrote:

I strongly *not* support this.

The extended stuff is a gadget for power-users. That's why it's called "extended". Power-users don't have a problem with editing their preferences. There is no need to make this the default. Change your preferences but don't force all other users to use the same preferences as you do. Most users are not like you.

The extended script is very slow on older computers. It adds slow and time-wasting animations instead of loading instantly.

It adds a lot additional dependencies. It does not work well with JavaScript disabled, for example. You will see a huge page with many duplicate entries. This renders the page almost useless.

Most important: It's not possible to enable it without also changing the watchlist. The extended watchlist is bogus and useless, in my opinion. It has more bugs than the regular watchlist. On the regular watchlist an article is hidden when I made an edit. On the extended watchlist my own edit is hidden but the previous edits are not. This is confusing. I can't see if I added an answer to a discussion or not. The same discussion is shown forever not matter if I added an answer or not.

It's not true that "most users" are using the extended watchlist. Most users use the regular watchlist. I know multiple users that tried the extended watchlist and disabled it because it was worse. But even if a significant amount of users had enabled the extended watchlist, what's the problem then? These peopel are happy with their extended watchlist. Everybody else is happy with the regular watchlist. No need to change the preference of everybody else.

Also it's simply not possible to change something like this without asking the community. It does not matter how many users here in the bugtracker want to change this. This is a bugtracker. Only power-users know about this discussion. Start a RFC ("Meinungsbild" in the German Wikipedia) and ask the community first if you want to change a preference for all users.

Please close this bug as "WONTFIX".

http://datahub.io/en/dataset/wikipedia-user-preferences/resource/16deba1d-ce88-4431-a0e7-5cb9a4aa0252
(In reply to comment #49)
(...)

It's not true that "most users" are using the extended watchlist. Most users
use the regular watchlist.

This seems consistent with this data from 2012, about active users:

• http://datahub.io/en/dataset/wikipedia-user-preferences

Setting milestone to "Future release" as it's clearly not gonna happen in time for 1.21, and changing it in point version is a bad idea.

At this time the Design group does not have a stance on this issues, removing tag

So, after comment 52 (and comment 47) it seems this bug has nothing left to wait for, correct?
The patch needs to be updated (release notes for 1.22, not 1.21) but that's easy if someone's available to approve it.

Enhanced recentchanges preference and the jquery.makeCollapsible module it uses still have a couple of outstanding issues that would be good to get fixed before wider deployment (some of them might have been overlooked earlier).

I've been working on them slowly, I'll mark them all as blockers to this.

I disagree on bug 44874, see comment 47.

While it's not a dependency to enabling enhanced RC as default in MediaWiki core, it surely is a blocker to enabling it on Wikimedia wikis, and I think we're all interested in this as well (if not primarily).

(In reply to comment #56)

While it's not a dependency to enabling enhanced RC as default in MediaWiki
core, it surely is a blocker to enabling it on Wikimedia wikis, and I think
we're all interested in this as well (if not primarily).

I disagree on this as well, I don't see it as a requirement for this improvement of RC/WL. Most people did or have been doing without them in their watchlists for a long time now and since phase II arrived on the first wikis I only saw users using enhanced RC who kept them, nobody who migrated to old RC just to see Wikidata changes.

mr.heat wrote:

(In reply to comment #53)

So, after comment 52 (and comment 47) it seems this bug has nothing left to
wait for, correct?

Erm, no? Read comment #49 and close this as "WONTFIX" please. Enable the setting in your settings if you like the so called "enhanced" watchlist but don't force all other users to use this over-complicated monstrosity. 99% of the users are happy with their settings.

(In reply to comment #58)

99% of
the users are happy with their settings.

Wow, can you hand me your happiness-meter? Seriously, source?

mr.heat wrote:

(In reply to comment #59)

Wow, can you hand me your happiness-meter? Seriously, source?

Do a poll. This is not my job. You are the one who wants to change a setting for each and every user without asking them.

I'm sorry, but this is definitely not a WONTFIX. Restoring.

mr.heat wrote:

(In reply to comment #61)

I'm sorry, but this is definitely not a WONTFIX. Restoring.

For what reason? What's going on here? Change your settings in your account details but don't touch the settings of all other users! Not without asking them first! Manipulating other users settings is neither a bug nor a feature request. It's simply invalid.

A(In reply to comment #62)

(In reply to comment #61)

I'm sorry, but this is definitely not a WONTFIX. Restoring.

For what reason? What's going on here? Change your settings in your account
details but don't touch the settings of all other users! Not without asking
them first! Manipulating other users settings is neither a bug nor a feature
request. It's simply invalid.

As well as being not a WONTFIX, this is also not INVALID. Changes to MediaWiki's default options are entirely in-scope for bug reports. Please do not abuse Bugzilla.

TMg: Please take care of your tone and keep arguments neutral and technical. Again, this seems to be a valid request and neither invalid nor wontfix.

mr.heat wrote:

(In reply to comment #64)

Please [...] keep arguments neutral and technical.

But this is not a technical request. It's a request to change the settings of each and every MediaWiki user without asking them and without any community consensus. This is a social thing. It's about keeping things simple at a level that each and every user can understand and grow up from. There are lots and lots of reasons (both technical and social) to not do this but only very few (if any) valid reasons to do it.

While this report is about "recentchanges" only it will change both recentchanges and all watchlists. I'm pretty sure only a few experienced users care about recentchanges. This report would be very different if you are able to split this. But it's a big issue if it will affect the much more important watchlists. Almost all users use their watchlists but only a few use recentchanges. Reventchanges is the same for all users anyway.

The enhanced stuff is a tool for power users. It's an opt-in feature. It always was an opt-in feature and always should be. Every user that really wants to use it had it enabled already. There is no need to change anything from this perspective. If you want to change your setting then change your setting. You don't need to change the settings of everybody else to do this.

The enhanced stuff is supercharged with lots and lots of informations and links. This is a good thing for power-users but confusing for new users. The default lists are a lot easier to manage and to understand. Changing the default setting will affect mainly new users. Power-users had it enabled already. Again, from this perspective it doesn't make sense to change the default setting from "easy" to "hard".

The basic lists don't rely on JavaScript. The enhanced stuff doesn't work well with JavaScript disabled. It's not that it's a complete mess (like LiquidThreads is) but it simply doesn't make much sense with JavaScript disabled.

The scripting stuff feels clunky and slow, even on current machines. The animations are unnecessary and disturbing. They are actually *broken* (see bug #31832). Collapsing elements is *not* animated, it's just delayed for no reason. It feels like my mouse click was not recognized. I click again and this *collapses* the list immediately the moment it opened. Such bugs make me feel like I'm to stupid to use a computer. Like I'm spastic and unable to do a decent mouse click. I hate such bugs. Recentchanges and watchlist don't need to be animated at all. Both are tools to get things done. Most animations add nothing to these workflows. All they do is wasting time.

The scripting stuff is so bad, the watchlist becomes completely unusable for some users. See the depending reports (e.g. bug #34876).

The enhanced stuff actually removes features. One is that the "hide my edits" setting becomes pointless. If this setting is enabled and I edit a page, that page will be completely removed from the basic watchlist. This is a useful feature. For example, it's like I got a notification about a change on a talk page, I added an answer and that's it. It's like a check mark. Done and gone. My watchlist gets cleaner this way. The enhanced stuff not only removes this feature, it gets completely confusing. If "hide my edits" is enabled only my last edit will be hidden. Instead it shows the previous edits again. There is not even a hint that there was a later edit. No "current" indicator or something. It looks exactly the same like I never added an answer to that talk page. This is confusing and makes the "hide my edits" setting completely useless. Same problem in combination with other settings but that's the most important for me.

Issues with the implementation of enhanced recentchanges can be marked as bugs which block this bug. The presence of them does not inherently make this bug a WONTFIX or INVALID.

On bugs, comment 66 says it all. Some bugs you mention are actually features, and some features you mention of the default RC are actually bugs; more above.

(In reply to comment #65)

I'm pretty sure only a few experienced
users care about recentchanges.

This is true only on biggest wikis.

The enhanced stuff is a tool for power users.

The opposite is true. Quoting myself

(from comment #0)

the old RecentChanges [...]
ok only for few people who are not scared for instance by a page cluttered
with
hundreds of edits to a particularly active page of the moment, and so on

Every user that really wants to
use
it had it enabled already.

By this reasoning we should never even try to make default settings saner.

The enhanced stuff is supercharged with lots and lots of informations and
links.

I never saw them, what are you talking of? The information is the same.

The enhanced stuff doesn't work
well
with JavaScript disabled. It's not that it's a complete mess (like
LiquidThreads is) but it simply doesn't make much sense with JavaScript
disabled.

I sometimes use enhanced RC without JS and I think they make sense, grouping is very useful; those who disagree can change the settings, only a minuscule minority (in which I'm included ;) ) disables JavaScript and they surely know what consequences that has.

The enhanced stuff actually removes features. One is that the "hide my edits"
setting becomes pointless. If this setting is enabled and I edit a page, that
page will be completely removed from the basic watchlist.

This is a bug.

This is a useful
feature. For example, it's like I got a notification about a change on a talk
page, I added an answer and that's it. It's like a check mark. Done and gone.

There are watchlist markers for a reason.

(In reply to comment #67)

This is a useful
feature. For example, it's like I got a notification about a change on a talk
page, I added an answer and that's it. It's like a check mark. Done and gone.

There are watchlist markers for a reason.

TMg might be used to the English Wikipedia where they are disabled by default for some bizarre reason, for both old and enhanced RC/watchlist :/

(In reply to comment #68)

TMg might be used to the English Wikipedia where they are disabled by default
for some bizarre reason, for both old and enhanced RC/watchlist :/

See e.g. bug 30295 and bug 33123.

mr.heat wrote:

(In reply to comment #67)

some features you mention of the default RC are actually bugs

If a behavior is used as a feature it is a feature no matter how you call it. When I want to hide pages I edited last from my watchlist I check "hide my edits" and use this as a feature. Simple as that. This very feature is completely missing in the so called "enhanced" watchlist.

The opposite is true.

No, it's not. Ha, now I said it. What now?

By this reasoning we should never even try to make default settings saner.

It's not "sane" to turn a "simple and easy to understand" mode off and make an "expert" mode the default.

I never saw them, what are you talking of? The information is the same.

No, it's not. It's almost the same if you compare
http://en.wikipedia.org/wiki/Special:RecentChanges?extended=0&enhanced=0
with
http://en.wikipedia.org/wiki/Special:RecentChanges?extended=1&enhanced=1
There is no big difference. In my test these pages are each 150 KiB big (counting the HTML only). Both contain 700 links and about 740 tooltips in title attributes.

If you compare
http://en.wikipedia.org/wiki/Special:Watchlist?extended=0&enhanced=0
with
http://en.wikipedia.org/wiki/Special:Watchlist?extended=1&enhanced=1
it's horrendous! The basic watchlist is 84 KiB big and contains 380 links and 416 tooltips. In comparison the very same watchlist, if enhanced, is 416 KiB big and contains 2077 links and 2117 tooltips. Two thousand (!) compared to four hundred! Thats 5 times bigger! 5 times more links! 5 times more information! The download is 5 times slower every single time a user wants to look at his watchlist. The browsers needs a lot more power and time to parse and render a page that is 5 times bigger. Scrolling is slower. And that's still not counting the slow JavaScript stuff.

It's completely counterproductive to enable this horrendous monstrosity for each and every user without asking them. New users must start with simple settings and grow up from there.

As I said I don't really care about recentchanges. It's the same for every user anyway. But I care very much about our watchlists. Watchlists are very personal. If you want to change recentchanges then you need to split the setting and change recentchanges only.

(In reply to comment #70)

When I want to hide pages I edited last from my watchlist I check "hide my
edits" and use this as a feature. Simple as that. This very feature is
completely missing in the so called "enhanced" watchlist.

Wrong, you only have to disable extendedwatchlist.

The opposite is true.

No, it's not. Ha, now I said it. What now?

I gave reasons for my statement, you didn't for yours.

By this reasoning we should never even try to make default settings saner.

It's not "sane" to turn a "simple and easy to understand" mode off and make
an
"expert" mode the default.

Again, you're falsely assuming what you're supposed to prove, i.e. that enhanced RC are for power users only.

If you compare
http://en.wikipedia.org/wiki/Special:Watchlist?extended=0&enhanced=0
with
http://en.wikipedia.org/wiki/Special:Watchlist?extended=1&enhanced=1
it's horrendous! The basic watchlist is 84 KiB big and contains 380 links and
416 tooltips. In comparison the very same watchlist, if enhanced, is 416 KiB
big and contains 2077 links and 2117 tooltips.

Again, this is extendedwatchlist, not enhanced RC. Of course if you show more edits there are going to be more links. For people already using extendedwatchlist, enhanced RC is going to make it more readable, so if you dislike the mass of links in extendedwatchlist, by logic it should follow that you support enhanced RC.

mr.heat wrote:

(In reply to comment #71)

I gave reasons for my statement, you didn't for yours.

I'm sorry? Did you read my posts? I can say the same. I gave lots of reasons why it's a bad idea to manipulate the personal settings of all your users.

you're falsely assuming what you're supposed to prove, i.e. that
enhanced RC are for power users only.

Again, I can say the same. It's your job to prove that a majority of the users wants their settings changed. In community projects like all bigger MediaWiki projects we call this "consensus". We do RFCs and polls before we touch the personal settings of our users.

if you dislike the mass of links in extendedwatchlist,
by logic it should follow that you support enhanced RC.

What ...? Enabling the "enhanced" stuff (also known as "usenewrc") that works with JavaScript only does not make the watchlist smaller or load faster. The opposite will happen.

Again, this is extendedwatchlist, not enhanced RC.

Maybe you should clarify what this report is about. As I said: If you split the settings for recentchanges and watchlists you are free to change the default settings for recentchanges. I don't care. Recentchanges is not personal anyway. But changing all watchlists of all users without asking them is a no-go.

There are two main problems:

1. The setting affects both recentchanges and all watchlists of all users.

2. The "enhanced" JavaScript stuff (also known as "usenewrc") does not make any sense without enabling the "extended" version the same time. "Extended" replaces the "basic" watchlist with a monster that is (in my test) about 5 times bigger, slow and clunky and confusing for every user that is either familiar with the "basic" watchlist or new to MediaWiki.

If there is nothing to collapse the "enhanced" setting does not add anything. Neither to recentchanged nor to the watchlists. If there is something to collapse this will hide stuff the users most probably dint wanted to hide. If a user wants to hide parts of his watchlist he would have enabled the setting ages ago. Enabling additional JavaScript will make the page load slower on all computers. It will make it completely unusable on some computers.

Also the so called "enhanced" stuff (also known as "usenewrc") looks worse. It uses teletype fonts for no good reason. The font is way to small and very hard to read in some browsers (which is another dependency: fix the broken CSS first).

Changing a setting adds no benefit but adds lots and lots of confusion and makes all users angry at the developers and the Foundation. Stop this! Don't change the interface if your users are not asking for a change. Especially never ever change the personal settings of your users. This is simply impossibly. I really don't understand why we have to discuss this.

(In reply to comment #72)

TMg, could you please file bugs for particular issues and mark them as blocking bug 51942 ("Watchlist and recent changes usability issues")? I'd like to work on this a little, and having a todo list is always useful :)

https://gerrit.wikimedia.org/r/#/c/49082/ has received -1s and needs either rework or abandoning.
Not convinced if this should have a 1.22 target milestone.

Change 49082 abandoned by Isarra:
(Bug 35785) Make enhanced (collapsible) recentchanges the default

Reason:
Okay.

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

PATCH_TO_REVIEW --> NEW && 1.22.0 release --> Future release

Updates? Will you still work on this?

(In reply to Gerrit Notification Bot from comment #75)

Change 49082 abandoned by Isarra:
(Bug 35785) Make enhanced (collapsible) recentchanges the default

Reason:
Okay.

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

I think matmarex was working on some of the dependencies, but at this point I really have no idea what is or isn't done. I wouldn't even know what to work on.

My opinion right now is that we should replace both modes with a new one, but that's not something I'm willing to or able to accomplish myself.

(In reply to Isarra from comment #78)

I think matmarex was working on some of the dependencies, but at this point
I really have no idea what is or isn't done. I wouldn't even know what to
work on.

Dependencies were all solved. I propose that we do this in 1.23, it fits well with the preferences revamp and it would look very good after this section: https://www.mediawiki.org/wiki/MediaWiki_1.23#Notifications
We need to have something to boast about in release notes or nobody will upgrade to 1.23 and we know how much devs hate additional work for legacy releases. :)
I'll submit a patch for the Wikimedia projects to be unaffected by the new MediaWiki default in a minute, as we did for all others.

Nemo: As 1.23.0 isn't too far away, a patch is needed.
Would that mean restoring https://gerrit.wikimedia.org/r/49082 ?

Change 124302 had a related patch set uploaded by Nemo bis:
Make enhanced recent changes and extended watchlist default

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

(In reply to Bartosz Dziewoński from comment #79)

My opinion right now is that we should replace both modes with a new one,
but that's not something I'm willing to or able to accomplish myself.

I agree. Merging this as-is is an awful idea...enhanced RC is a disgusting minefield of usability.

Not that the old RC is better, but let's stick with what we've got until someone can come up with a better idea.

(In reply to TMg from comment #70)

(In reply to comment #67)

some features you mention of the default RC are actually bugs

If a behavior is used as a feature it is a feature no matter how you call
it. When I want to hide pages I edited last from my watchlist I check "hide
my edits" and use this as a feature. Simple as that. This very feature is
completely missing in the so called "enhanced" watchlist.

https://xkcd.com/1172/

(In reply to Chad H. from comment #83)

I agree. Merging this as-is is an awful idea...enhanced RC is a disgusting
minefield of usability.

Evidence please.

Not that the old RC is better, but let's stick with what we've got until
someone can come up with a better idea.

CleanChanges has existed for many many years. I claim it is better, but not necessarily good either. It feels like we are aiming too high here and getting no progress.

(In reply to Niklas Laxström from comment #84)

(In reply to Chad H. from comment #83)

I agree. Merging this as-is is an awful idea...enhanced RC is a disgusting
minefield of usability.

Evidence please.

Well I've been using MediaWiki for about 9 years now and I still can't make heads or tails of the page. The collapsed sections make no sense to me and simply require opening all the time to see what's actually happening.

Not that the old RC is better, but let's stick with what we've got until
someone can come up with a better idea.

CleanChanges has existed for many many years. I claim it is better, but not
necessarily good either. It feels like we are aiming too high here and
getting no progress.

Crappy interim solutions like changing preferences based on some non-objective hand-waving about it "being better" aren't an improvement either.

(In reply to Chad H. from comment #85)

Well I've been using MediaWiki for about 9 years now and I still can't make
heads or tails of the page. The collapsed sections make no sense to me and
simply require opening all the time to see what's actually happening.

And I'm using the enhanced/clean rc without about as long without issues. These are just personal opinions which are not evidence.

(In reply to Chad H. from comment #85)

The collapsed sections make no sense to me and
simply require opening all the time to see what's actually happening.

Aha! You need this code, in your global/vector/common.js
It auto-expands all the arrows. (I think it should be default.)

// Expand all grouped RC/Watchlist entries. (Credit to [[User:PiRSquared17]])
$(window).load(function() { $('.mw-enhancedchanges-arrow').click(); });

(In reply to Gerrit Notification Bot from comment #82)

Change 124302 had a related patch set uploaded by Nemo bis:
Make enhanced recent changes and extended watchlist default

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

The patch for changing the default settings has one +1 and is not merged yet, however there are some concerns in comment 85 how to judge whether this is an improvement.

As the 1.23 Target Milestone was set here in comment 80:
It's probably up to the tarball release managers to judge whether they want to include this change of default settings for the 1.23 LTS series, or whether to be conservative for this LTS release and consider this for 1.24 instead.

(In reply to Andre Klapper from comment #88)

As the 1.23 Target Milestone was set here in comment 80:
It's probably up to the tarball release managers to judge whether they want
to include this change of default settings for the 1.23 LTS series, or
whether to be conservative for this LTS release and consider this for 1.24
instead.

I'm going to err on the side of conservatism here -- moving target to 1.24 so there is six more months to come to a decision since it looks like consensus isn't likely soon.

Note: There will be the same situation a few weeks before 1.24.0 (=potentially being conservative and keeping the old default) if those interested in replacing the "old" default view do not faciliate a broader discussion early enough.

Change 124292 had a related patch set uploaded by Nemo bis:
Enhanced recent changes: explicitly disable by default

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

Change 124292 merged by jenkins-bot:
Enhanced recent changes: explicitly disable by default

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

Change 124302 merged by jenkins-bot:
Make enhanced recent changes and extended watchlist default

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