Wikipedia talk:Requests for comment/Watchlist survey

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Comments from Spinningspark[edit]

  1. It is not correct that "New functionality has recently been introduced to the MediaWiki software". It has been in the Mediawiki software for a while now. Both Commons and Wikitionary already have it, others as well, they just happen to be the two I use a lot. Commons has had it for a very long while, AFAIK without any complaints. What has actually happened is that it was merely switched on on en.wikipeida.
  2. It might be worth putting in the intro that the feature was recently turned on following a request from the community, but was suppressed following complaints - which is the reason for the survey in the first place. This is important because we need to head off any suggestion that this is an attempt to push through an already rejected change by forum shopping.
  3. I don't think the current kludge of having it turned on and then suppressed should be left indefinitely (which I think - could be wrong, frequently am - option 2 amounts to). Either we should have it on as it is, or, if we don't want it, ask for it to be turned off again, embarrasing as that may be. If it is off (I think this is right) an alternative scheme, such as green stars or whatever, can be implemented either site wide or by individual users (some people seemed to have been doing that already).
SpinningSpark 14:00, 13 May 2012 (UTC)[reply]
Point 1 - yes you are right, wording probably needs adding.
Point 2 - important point, needs including. This isn't forum shopping, there were a lot of complaints, but the supporters are saying that the silent majority support the change. This is intended as an information gathering exercise.
Point 3 - my understanding is that you either get the ability to highlight unread pages plus the formatting or you get nothing. If it's turned off, you can't highlight changes at all. Now I may be wrong on this, so this should be investigated. A lot of people found the default version difficult to read (I did as well) but a different style may be much more acceptable. If that were the case, then probably the best long term option would be to approach the developers to create a new style. Although if you look at MediaWiki:Common.css it already has loads of hacks in it, so it's not an uncommon way of dealing with a sitewide styling issue. Elen of the Roads (talk) 14:43, 13 May 2012 (UTC)[reply]
Interestingly Commons] also has a css hack related to this

/* To color the mention "updated since my last visit" in the history */
span.updatedmarker {
color: #000; background: #99D642;
}

gives green highligher pen effect on the 'since your last visit' notifications in a history tab We have a different hack, which gives the subtle green effect. The default is bold for both. Elen of the Roads (talk) 17:27, 13 May 2012 (UTC)[reply]

Hmm, maybe we should have a screenshot of the standard history page format as well. And a swatch of possible alternatives to both pages. Much easier to choose from pictures than a description. SpinningSpark 17:50, 13 May 2012 (UTC)[reply]
Yes I'm hoping to get a whole set of screenshots. You can't visualise from a description - you have to see it. — Preceding unsigned comment added by Elen of the Roads (talk • contribs) 18:02, 13 May 2012 (UTC)[reply]

Comment from Anomie[edit]

I expect I'll end up with a personal style set to something like this (although I may adjust the color):

And the same for the history page styling, with the current green bit hidden entirely. But this currently requires a bit of javascript to copy the classes to the <li>. Anomie⚔ 03:23, 14 May 2012 (UTC)[reply]

May be just slightly too subtle a shading, but seems a good approach. Rd232 talk 07:29, 14 May 2012 (UTC)[reply]
I don't know that I'd recommend my version as the default anyway, but it's what I'm using. Anomie⚔ 11:40, 14 May 2012 (UTC)[reply]

Thought[edit]

If the major argument for default-on is that new users would miss it otherwise, enable it by default only for new users (who register from now on), but not for everyone else. It would be the most useful for those with relatively few watchlist items anyway, the blowback being from existing users who have enough watchlist items that they generally don't care about checking every single new page change. Not sure if that's technically feasible though. Equazcion (talk) 07:27, 14 May 2012 (UTC)[reply]

It's not just new users, it's also the silent majority who don't log in very often, don't have large watchlists, and don't participate in these discussions. It's much easier to target the subset of users who want this off - they're mostly already aware, and capable of using the CSS customisation, and presumably have already done it. The problem is essentially fixed for them, the question is what happens for everyone else. Rd232 talk 07:33, 14 May 2012 (UTC)[reply]
How about enabling it by default only for users with less than n watchlist items, then? Equazcion (talk) 07:37, 14 May 2012 (UTC)[reply]

The problem is that if we are advancing the argument that newbies/intermittent users won't find where to turn it on - they won't find where to turn it off either. Whatever the outcome, there needs to be readily available direction to how to customise your watchlist...wherever is the most suitable place to put it. --Elen of the Roads (talk) 08:23, 14 May 2012 (UTC)[reply]

Layout[edit]

Rd232 - I've rolled back your changes. I don't think it's a better structure at all I'm afraid, although I can see what you are aiming at. I do expect that we will get dozens of alternative styles offered up - the idea was to separate people who liked the idea but not the bold. I am pretty certain that if you just offer an opt out vs opt in choice, the majority will go for opt out because it's become a bit of a philosophical point now.

One thingI think I've knocked out your comments in the process, so you might need to re-put them in. Your point about new and occasional users not finding this is a valid one, but it is equally valid that if they can't easily find out how to turn it on, they won't easily find how to turn it off if they hate it.

You have made me realise is that it needs to emphasise is that this is a survey, not some kind of binding vote. I think it would be better not to discuss in the survey section - although this being Wikipedia, folks will of course do it anyway :) Elen of the Roads (talk) 08:21, 14 May 2012 (UTC)[reply]

Another thought: Instead of highlighting new changes, fade the old[edit]

Faded old changes.

The problem most people have with this feature is the overwhelming number of watchlist items highlighted by it, most of which aren't worthy of highlighting, especially to an experienced editor with loads of watched pages. Most people don't care to check every change, and so don't need all changes highlighted.

Instead, I propose fading out the changes people have already checked, so they know which items are now "done". I think this is much more useful information.

See the image, and here's a script to try it out. The specific styling here for the fade is just my preliminary take on what it could look like.

Note: If you have another script or CSS in place that disables or alters this feature already, you may need to remove them or comment them out to see this work.

Add this option to the survey? Equazcion (talk) 08:41, 14 May 2012 (UTC)[reply]

Finally a constructive comment! This is what I have been asking for, instead of the outcry demanding opt-in just only because of the bolding/stars. I like the dimming approach (provided accessability is not compromised), and it should definitely be added. Now was that so hard? — Edokter (talk) — 20:49, 14 May 2012 (UTC)[reply]
Not at all. You seem to be under the mistaken impression that I'm against this feature. Rather, I'm for respecting the consensus of the community regarding whether it should be on by default. Since I'm choosing to do that rather than impose my opinion as the end-all, I also know it would not be difficult for you to do the same, and admit what everyone else knows: That default-off is most definitely an option if that's what everyone thinks is best. Equazcion (talk) 20:53, 14 May 2012 (UTC)[reply]
It is not a question wether it should be on by default; it is on by default; it is just supressed because people didn't like the bold. The consensus was against the bolding, but the poorly constructed poll should never have mentioned "opt-in"; that made it appear it should be turned off by default.
On a side note: the dimming proves difficult to do in CSS, and whatever default is chosen, it should not rely on javascript. — Edokter (talk) — 21:05, 14 May 2012 (UTC)[reply]
CSS is impossible because the feature was poorly constructed to be very limiting. It adds a new HTML tag, only around one element, and only for updated lines, rather than a class for the updated line and a counter-class for all other lines, which would've been much smarter (and more standard with the way other visual features get implemented); Yet another reason default-off is reasonable. As for opt-in vs. suppressed, yes, it's suppressed. That's one of the ways the community gets to override people like you who think they know better than everyone else. Equazcion (talk) 21:10, 14 May 2012 (UTC)[reply]
In this case, I do know what's best for all users; not just what's best for the ones complaining. That is usually overlooked. This feature is to usefull to supress by default. Supressing functionality based purely on looks is indeed not open to discussion. — Edokter (talk) — 21:21, 14 May 2012 (UTC)[reply]
Discussion of new features isn't perfect, but it's the best we have. A solution involving an admin declaring that he knows what's best for "all users" despite discussion is not only far less perfect but downright ridiculous, and you should know that. As everyone else does. Equazcion (talk) 21:24, 14 May 2012 (UTC)[reply]
This isn't a discussion; it's complaint-fest. I've seen it before; they die out. And "everyone" who can't see beyond those complaints shouldn't be speaking for the rest of the world. TheOatmeal can explain it better then me: http://theoatmeal.com/pl/state_web_winter/facebook_layout. — Edokter (talk) — 21:33, 14 May 2012 (UTC)[reply]
Yes, see one of the first comments that appeared on this issue. We're in agreement. Where you're off is that we don't get to declare ourselves so smart as to brush off users' complaints outright because we think we know better. Maybe it will die out. Until it does, respect the community. Equazcion (talk) 21:38, 14 May 2012 (UTC)[reply]
That's not hard to fix, though. Anomie⚔ 02:26, 15 May 2012 (UTC)[reply]
Glad to see that, thanks Anomie. Equazcion (talk) 02:40, 15 May 2012 (UTC)[reply]

This is a great idea. Fade the less important rather than highlight the large ammount of things which may be important. A few comments:

  1. I have added the script to User:Yaris678/monobook.js. It doesn't seem to be working. It has removed the green text but not faded anything. Am I missing something?
  2. I notice in your screenshot you use italics on the faded text (but not unfaded). I wouldn't use it on either.
  3. What are we going to do with the article history? Highlighting things that have changed since last visit there is also good... but they will be fewer in number so using fading for everything else makes less sense. Maybe have green stars in article history. It does make the two inconsistent though... but I guess you can't have everything.

Yaris678 (talk) 10:01, 18 May 2012 (UTC)[reply]

I've only tested the script in Vector. I'll work on getting it up in Monobook and report back. The style I chose was the result of some trial-and-error -- the faded appearance alone didn't seem to do enough to differentiate items. My chosen style for the fade was really just meant as a preliminary demonstration of the general reversal I'm proposing, so if there's a better way, we're open to ideas. The script doesn't currently do anything to highlight history items, just watchlist, but that again can be discussed. I think the watchlist changes alone should probably be decided on first, and then a history change that goes well with it can be enabled. Equazcion (talk) 10:12, 18 May 2012 (UTC)[reply]
I appreciate that it is a work in progress. Top marks for sharing it at an early stage.
Some more thoughts:
  • Maybe the fading would be more distinct if you faded the whole line. I notice in the screen shot that the size change number is still in the normal colour. (I appreciate this might be harder with it being red or green, but I thought I'd put the idea out there).
  • Maybe the answer involves fading on the unchanged items and a green star on the changed items. Both of them are subtle.... and the green star might mitigate against the fading going unnoticed... and you could then use the green star on the article history.
Yaris678 (talk) 12:00, 18 May 2012 (UTC)[reply]

How about we propose the fading version as default, via VPT? Seems like everyone agrees it's less intrusive than bolding or symbols of any kind. Steven Walling • talk 18:06, 18 May 2012 (UTC)[reply]

Red herring?[edit]

I'm wondering now if the default on or off is becoming a bit of a red herring? I'll be completely honest and say now that I loathe the bold and the green stars were just as bad but what I have learnt is that it is easy to bypass the default by customisation of personal css. If that is the case, and I would like it confirmed, then it stops being a discussion about default on/off opt in/opt out and instead becomes "this is the default, however you don't have to leave it like this and if you want to change it you can do a), b), c) . . . instead" That moves the focus entirely to communicating about when changes are going to be made and offering out alternatives for those who want to persue them.

I would add that I have yet to see any rationale or benefit (perceived or actual) for the default of bolding other that "it's a good thing" (shades of 1066 and All That) but if that is what WikiMedia have decided upon then who am I to argue and if switching the default bolding on to en:WP brings it in line with the other wikis that would appear to be a reasonable action to take. NtheP (talk) 09:11, 14 May 2012 (UTC)[reply]

Of course it is a red herring. Wanting functionality supressed because of how it looks is a non-issue. The bolding is just MediaWiki's default rendering; we can style it any way we (all) like. It has just been disabled temporarely; there is no question about default on or off. — Edokter (talk) — 20:46, 14 May 2012 (UTC)[reply]
Yeah you've been touting that "no question" thing since the beginning. You're alone there though. Equazcion (talk) 20:48, 14 May 2012 (UTC)[reply]
Except the way you decided to implement the default rendering was without notice, without any alternatives and with an attitude which really did smack of "I know best for everyone and I will brook no argument" You cannot be surprised that there was and is a continuing backlash if you implement change in such a high handed fashion. NtheP (talk) 22:20, 14 May 2012 (UTC)[reply]

Access[edit]

I like the idea of showing the difference, but the various implementations may be problematic.

For one thing, something that doesn't seem to be considered in these changes are those who are visually impaired. (Or other WP:ACCESS-related considerations.)

So while I like the colour idea, it's just not an option.

As for me, I'll say honestly the excessive bolding hurts my eyes (especially when editing at night : )

And the green star merely looks like clutter.

I like the highlighted or the faded text ideas on this talk page, above, but again, we should make sure that they meet WP:ACCESS requirements. Can they be added as options on the survey now? - jc37 10:07, 17 May 2012 (UTC)[reply]

I don't see the green star as clutter. It is the same idea as having an m for minor and a b for bot... and it would appear next to these character if they also apply... which is all good.
Of course, if you can think if a better symbol than a green star then go ahead and suggest it. I guess n would be an option... but we wouldn't want to confuse it with N. Maybe u for updated or unseen.
... or ... maybe it should be a star but just a black star. What does the green mean anyway? Black would be less cluttered I guess, because it would be the same colour as m and b (and the edit summary).
In terms of access... would it be possible to give the green star WP:ALTTEXT?
Yaris678 (talk) 12:15, 18 May 2012 (UTC)[reply]
So you're suggesting a character of some kind (green star for example) to signify that I haven't looked at a particular page on my watchlist? I don't know. To me it would feel like wallpapering (hence why I considered it "clutter").
That said, unlike some of these options, adding a single option under watchlist options to have the green star would seem to be fine, though I wouldn't suggest it to be the default.
I wonder why that idea (having each of these stylistic choices as options in options) isn't listed as an option in this survey.
Making something bold or italic or underlining; or "faded" or "highlighted"; or adding a single character (plus spacing); (or some combination of all of them; sounds particularly simple to add. (Though I'd obviously like a dev's opinion on that of course : )
As the default, I think I like the faded option best (though if given the option in options, I might personally add the highlight option as well : ) - jc37 12:28, 18 May 2012 (UTC)[reply]
Yes, editors who are disabled need consideration in designing and deploying features like this. For example, those:
  • who have poor eyesight (e.g. have trouble distinguishing bold from normal weight typefaces);
  • who are color blind; or
  • who are totally-blind.
Lentower (talk) 15:46, 25 May 2012 (UTC)[reply]

Why no thoughts of the new DIFFs?[edit]

As someone else said, the bolding of the unvisited pages seems to highlight the wrong thing -- I can't say I know what others do but I for one check my watchlist by looking at the new diffs. I tend to wonder what others do but it seems really silly to say "you've visited page x since the last time it changed" because just visiting a page isn't normally going to tell you HOW it changed. If there were a way to make only the diffs you haven't visited change color in some fashion i could get behind that as the difference between visited and unvisited links isn't great. But it's really jarring to see fifteen bolded article titles, especially if there's one or two in the middle that aren't. Some of the other proposed solutions are better but I can't help but think they don't get into the crux of the entire point in the first place. To give a good examples, let's say I'm watching an article. I check my watchlist at 1PM, then someone makes an edit at 1:15PM. At 2PM I decide to go directly to the page because I feel like reading something, or looking for an EL....WHATEVER. I refresh my watchlist at 4PM and that 1:15PM is the still the last edit to that page but none of my other watches were edited between 1 and 1:15. So now it LOOKS like I've 'checked' that page, but I really haven't. I'll grant it's a rare scenario....but again, if I went at 3:30 there'd be one non-bold in a sea of bold, which is also silly and very jarring. There can also be another scenario -- check watchlist, open all the new changes in tabs, take a while to get though and then click the previous edit link. In the time it took you to click said link, a new edit has come, but it's the only one. Check watchlist later? Again, it thinks you've visited the page because of the timing of the new edit compared to the last time you clicked a link leading to that page.

tl;dr - There needs to be focus more on the actual edits as opposed to a generic "this page has been edited since you visited it". ♫ Melodia Chaconne ♫ (talk) 14:20, 18 May 2012 (UTC)[reply]

Hi Melodia,
There are some interesting thoughts there about some potential false negatives. But in implementing them, there is the potential for false positives i.e. you would find that people might have noticed that the new content was added even if they didn't look at the diff. This system already has the problem of highlighting so many things that nothing is highlighted... and that could make it worse. I guess if you were going to do it you would have to do two things:
  1. Say that if you look at the history of the article that also counts - you don't need to look at the diff.
  2. Use a more subtle marker to show the situation where you have looked at the article but not the diffs or the history. e.g. grey star for that, black star for haven't looked at anything to do with the article.
Yaris678 (talk) 16:34, 18 May 2012 (UTC)[reply]
Your #1 is a bad idea. Consider this: I see on my watchlist that WP:VPT has changed. So I click "hist" to use the helpful change indicators to find where to diff from. But in this case, the 63 changed revisions are greater than the default 50 revisions in the history! So I click "500" to show more changes for my diffing, but crap! The change indicators all went away because viewing the 50-revision history page cleared them. Anomie⚔ 01:30, 19 May 2012 (UTC)[reply]

A comment on the "opt-in" option[edit]

It seems to me that many of the people voting for "opt-in" are considering only their personal preference, and not whether the feature might be useful to new editors who are not already used to the status quo (and extremely averse to change).

There also seems to be a number of people voting for "opt-in" just because we don't have an opt-out gadget already. Which we would had some admins not jumped the gun and modified MediaWiki:Common.css to disable it for everyone. Anomie⚔ 16:16, 18 May 2012 (UTC)[reply]

My thoughts exactly. A default core function should never be supressed or made opt-in. I was the first to replace the bolding with stars. (Now I use a small "c"). Hiding functionality solely based on the looks is a very bad precedent, which I regard as a non-option, no matter how hard the community screams. — Edokter (talk) — 17:15, 18 May 2012 (UTC)[reply]
(edit conflict) As far as votes for opt-in seeming to stand on their personal preference, the same is happening for the opt-out side. And as far as the gadget, I see maybe one or two votes based on that. Most people seem to actually be assuming this will be handled with gadgets. PS. The reason we're forced to use gadgets and CSS etc is merely that Edokter stated early that a bona fide preference is "out of the question", but it's frankly not. It should've been there from the start. The assertion that this would suddenly make preferences too complicated is absurd.
My own rationale for opt-in is that's what we do for new features, especially ones that affect such an oft-relied-on tool. Opt-in for a while until the feature is proven widely accepted and then someone suggests enabling across the board. The gun was jumped here in a major way due to the IT-geek-logic that "we know this is the better way and they'll see it our way if we can just force them to keep using it long enough", but we got the foreseeable real-world reaction.
The feature also sucks from a technical standpoint, if you want to get geeky. The code is old and limiting. I wouldn't implement this in any broad way until it's done right, but even then, the usual steps need to be followed. Equazcion (talk) 17:17, 18 May 2012 (UTC)[reply]
There are no 'usual steps' when new features are added/enabled. The only reason there is such an fall-out about the changed-page indicator is because the way it looks. Had it been less-obstrusive to begin with, there would be no fall-out. When the byte-count was added, there was no outcry, becuase it was unobstrusive. The default styling is unfortunate, but fixable. The fact remains that it is core functionality, and as such must not be disabled. I find it even more offensive when people who don't like it feel they should decide wether this functionality is hidden by default or not, without realizing the impact it has on all editors who were never asked, and subsequently are denied access to this feature unless they stumble upon instruction on how to enable it. We want people editing, not go through endless tutorials and pages of options.
I will say it once more, and I don't care if I am taken to arbcom or not: core functionality will not be disabled by default. I have hence restored core watchlist functionality, but rest ashured, without the bolding. I will stand very firm in my belief that some considerations are not to be left left to the community when it comes to the core functionality of this site. — Edokter (talk) — 17:55, 18 May 2012 (UTC)[reply]
You can stand as firm as you like. As long as most people disagree, it won't matter. As has just been shown. Equazcion (talk) 17:57, 18 May 2012 (UTC)[reply]
Yes, there are usual steps. By the way. Big changes are not implemented this way by one person, especially one person who didn't discuss them with anyone. Equazcion (talk) 18:00, 18 May 2012 (UTC)[reply]
It's just bad form to act unilaterally on an issue that's actively under discussion in an effort to reach a consensus, regardless of which side of the discussion you're on.
Turning from bad form to the merits, I don't agree with the premise that "core functionality will not be disabled by default." I don't know what "core functionality" means in this context, but the Watchlist change styling functionality has been in MediaWiki for a while, and it was disabled entirely on enwiki until about a week ago. There are a number of other functionalities in MediaWiki that are not enabled on enwiki, either at all or by default. Is Pending Changes a "core" functionality? Who decides what is "core"? --R'n'B (call me Russ) 18:23, 18 May 2012 (UTC)[reply]
True, not all options are enabled on enwiki; the watchlist change was disabled all this time because of database performance concerns, not because of any stylistic concerns. Now that it has been enabled (on all other projects as well(!)), it has become 'core'. Such functionality should be visible to new users because it provides essential information. The question should be wether new users would object. Anyone knows they wouldn't, so why should the personal preference of a vocal minority trump the benefits for future editors? — Edokter (talk) — 09:45, 19 May 2012 (UTC)[reply]
Whether or not it is "essential" is debateable but I'll go along with there was a decision to make pages on watchlists that have changed since last visit stand out. However the way NOT to introduce the change is to spring it on the entire community unannounced and without having alternatives lined up for those who don't want to avail themselves of this "benefit". If you had published, widely, a notice that said along the lines of

On date a change will be implemented that will bold changes in watchlists to bring en.wp in line with other wikis, the original discussion about this can be found at link to page. You can see a preview of this at link to page with picture. If this style isn't something you'd like then there are a number of options available by customising your custom.css, some of these can be found at Wikipedia:Customizing watchlists or if you want something else you can ask for help at whereever.

Something as simple as this and there wouldn't have been half the kerfuffle there has been. Then if there is widespread discontent at least it has a foundation to work from, not "who took a unilateral decision to do this?". NtheP (talk) 10:03, 19 May 2012 (UTC)[reply]

C[edit]

I also hate the latest change that was just forced on everyone without discussion. For the record. Equazcion (talk) 17:41, 18 May 2012 (UTC)[reply]

Edokter, this isn't your personal website. Will someone please reverse this latest change? Thanks. Equazcion (talk) 17:43, 18 May 2012 (UTC)[reply]
What is the "C" supposed to stand for anyway? Jared Preston (talk) 17:50, 18 May 2012 (UTC)[reply]
And so it begins again. I'm at a loss for words to describe how brainless a decision that was. Apparently "C" is Edokter's take on what should mean a page has Changed. Equazcion (talk) 17:52, 18 May 2012 (UTC)[reply]
Grateful thanks, User:Equazcion, for the opt-out script. Will I need to change it when the next implementation comes along? --Old Moonraker (talk) 18:09, 18 May 2012 (UTC)[reply]
You're very welcome. And yes, when someone makes another attempt at implementation, the script will probably need to be changed, depending on what the change is. Hopefully we can keep on top of the changes dreamed up by this whimsical administrator who seems to enjoy frolicking in our interface. Equazcion (talk) 18:15, 18 May 2012 (UTC)[reply]

Important and other[edit]

If you really want to do something new with the talk page, then here's a suggestion. When looking at my watchlist, I usually first scan it to see if any of the 10 odd articles I care about are showing up. Then, once I've dealt with them, I look at the rest of the list. It would be nice if I could divide the list into important and not-so-important sections (somewhat like what gmail does). --regentspark (comment) 18:00, 18 May 2012 (UTC)[reply]

User:UncleDouggie/smart watchlist.js does that. --lTopGunl (talk) 00:33, 20 May 2012 (UTC)[reply]

I have a suggestion:[edit]

The placement of the Mark all pages visited button really doesn't fit in where it goes. Could it be moved to the bottom of the page under the pages you're watching? Devin (talk) 21:05, 18 May 2012 (UTC)[reply]

I disagree. Moving the button to the bottom will force users to scroll all the way to the bottom of the page everything they want to click it. --Michaeldsuarez (talk) 21:18, 18 May 2012 (UTC)[reply]

Watching Sections[edit]

I find that Wikipedia's watchlist is nearly useless on pages such as Wikipedia:Dispute resolution noticeboard‎. I want to see if anyone has posted to the one particular dispute I am working on, not every dispute on the list. Same with the Village Pump -- I want to see if there are any posts responding to the question I asked without seeing everything posted in response to the other questions. --Guy Macon (talk) 02:37, 20 May 2012 (UTC)[reply]

Gets suggested often, there's one now at Wikipedia:Idea lab#Watching topic. PS I do agree this would be great. ANI alone is worth it. Equazcion (talk) 02:40, 20 May 2012 (UTC)[reply]
Yes, that's an issue for me too. Please? HiLo48 (talk) 02:42, 20 May 2012 (UTC)[reply]
This does get suggested often, to the point where it is listed at WP:PEREN#Allow watchlisting individual sections of a page. The problem is that it would require a major change to the software, and no one with the necessary skills has stepped forward to plan out and implement the necessary changes at the code level. Anomie⚔ 02:55, 20 May 2012 (UTC)[reply]
Has there been any effort to hire such a person on a short-term project basis? In software development, it often turns out that what was considered to be hard turns out to be easy once the right person looks at the problem.
I am wondering about that "it would require a major change to the software" bit. Right now the software feeds my watchlist the page that was changed, how many bytes, who changed it, when, and the edit summary. You could add the section title. Then the watchlist, when watching a section, could simply ignore anything with the wrong section title. Yes, this would fail if someone changes the section title, but that could be addressed by always sending me the pre-edit section title, so on my watchlist I would see the edit making the section title change. --Guy Macon (talk) 04:19, 20 May 2012 (UTC)[reply]
Having to determine the section title that was edited would add significant complexity over the current process that occurs when a page change occurs, since currently it just registers that some change occurred without determining anything. There would need to be a kind of diff routine added each time. What if multiple sections were changed etc? We could have it use the section header noted in edit summaries, but that's not reliable since people can change that manually or delete it entirely, and it doesn't even show up if you hit the edit tab instead of a section link.
Any "simple" solution involving only using the current system of wiki headers would likely require updating a new set of data that catalogs section changes as they occur. This is all just based on my evaluation though; someone could come up with an amazingly simple outside-the-box solution, who knows.
Then there's the more complex route, where we change the way discussion pages work fundamentally. Personally I think that's the way to go. The WP:LiquidThreads vaporware is/was an attempt, though I don't know how well it'll accomplish the goal, if it ever does get implemented. Equazcion (talk) 04:41, 20 May 2012 (UTC)[reply]

Copied to WP:VPT Equazcion (talk) 12:08, 21 May 2012 (UTC)[reply]

A couple of thoughts / suggestions[edit]

  1. I'd like to see the "expand" option on the watchlist page, instead of having to go to the preference page.
  2. A user name that doesn't have a user page is in red, but an unregistered IP is the same color as a registered user (blue). I'd like it in a different color. --Musdan77 (talk) 18:24, 22 May 2012 (UTC)[reply]

Should be determined by empirical testing, not a poll[edit]

Usability issues such as this should not be decided by polls but by empirical tests conducted by professionals. People don't always know what works best for them and opinions should only be one of the factors used to make decisions such as this. (Apologies if I'm being snippy; I'm more frustrated by the ham-handed amateur way this has been handled than anything. This is a live website used by millions of people and it shouldn't be treated as a private test project by handful of people making changes willy-nilly.) ElKevbo (talk) 21:34, 22 May 2012 (UTC)[reply]

Yeah, there's a gold standard for Usability testing but it costs money. Despite being in a sense a larger product than Windows or iPhone, Wikimedia's usability lab must have a much smaller budget than those, so we are left with an initial decision by a handful of internal experts, probably having a progressive bias, followed by a poll of hundreds of self-selected old-time users, whose bias is surely conservative. Despite being one of those hundreds, I am more inclined to trust the elite handful. Asking the silent majority is a major part of what empirical testing is about, but nobody's putting up the money for that. Jim.henderson (talk) 13:54, 25 May 2012 (UTC)[reply]

Why was MediaWiki changed?[edit]

Can anyone point us at discussion, announcements, etc. on why MediaWiki was changed so the proposed change to Watchlist format became the default on Commons and Wikitionary?

Comments that say that the MediaWiki change is a reason to do this change here on the English Wikipedia, just assumes that the process there was done well. Lentower (talk) 15:59, 25 May 2012 (UTC)[reply]

This is discussed on the main page at Option 2, under vote 88. Rd232 talk 20:28, 25 May 2012 (UTC)[reply]
Thanks, but:
This might be something that should be be backed out of MediaWiki, depending on how the initial decision was made.
Lentower (talk) 21:49, 25 May 2012 (UTC)[reply]
Yes, Option 3, not 2 - my mistake. The suggestion that a feature should be removed from MediaWiki that's been there since 2004 and is accepted on most (all?) other Wikimedia wikis and can be turned off in a number of ways (besides possibilities for customisation) is... interesting. Rd232 talk 22:05, 25 May 2012 (UTC)[reply]
Yes, it's... a good thing the feature is... switched on at several other Wikimedia sites, otherwise the side that wants it on here would have... little else to cling to in their defense. Not that this reason is... all that worth clinging to. There's no word for it yet, but the measure of average watchlist size combined with frequency of changes is higher for Wikipedia than for other projects (what the hell, let's call it "WatchLeFreq measure", has a nice French ring to it). Watchlists are used differently here. Bolding every single change makes sense when the fact that a change occurred is something that should stand out against a background of non-changes, but here the average active editor has a watchlist full of changes on a regular basis, very few of which they'll actually check. They don't care merely that a change occurred, and use different criteria to judge which to check (unlike emails, the comparison to which has also been used to justify this feature). More than often, the username, size of the change, and edit summary are enough of a check, all of which can be glimpsed without opening a link.
Given that, it's way more... interesting to me that any experienced editors think this feature is right for Wikipedia (but not so... interesting that they keep pointing out that "it's there already on the other sites", as so far that's their best argument; seriously). The underlying code that makes the bolding possible might be useful, were it implemented intelligently (it isn't) and if it were integrated with some preference options (it's not), dare I say even a comprehensive preference menu (alas, even one more preference would apparently make preferences "too confusing", down from the pillar of simplicity and intuitiveness it currently is). Equazcion (talk) 22:34, 25 May 2012 (UTC)[reply]
It's definitely reasonable to debate whether this feature is right for enwiki given its edit volume; it would be useful to compare other high-activity wikis like dewiki and frwiki, I suspect (although I don't know for certain) that their edits/article/second rates are not dissimilar to our own, which would counter your argument. Happy‑melon 23:13, 25 May 2012 (UTC)[reply]
"but here the average active editor has a watchlist full of changes on a regular basis, very few of which they'll actually check." [citation needed] Anomie⚔ 00:25, 26 May 2012 (UTC)[reply]
Here is one, and many others have expressed likewise. I'd be surprised if you check each and every of your watch list entries, unless you regularly spend your whole day on it. Nageh (talk) 10:13, 26 May 2012 (UTC)[reply]
There's also people who only pay attention to talk edits and not the associated page (and vice versa), people who use pop-ups to quickly check diffs directly from the watchlist (which doesn't change the bolding - I tried), edits which were only vandalism reverts or bot edits or minor formatting changes or something else you don't really need to look at...Nikkimaria (talk) 13:46, 26 May 2012 (UTC)[reply]
I check the changes for each page (804 at the moment) on My Watchlist using pop-ups. Goes quickly. Lentower (talk) 21:31, 26 May 2012 (UTC)[reply]
It would be easy to add support to the API for adjusting or clearing the wl_notificationtimestamp field, which popups could then use to change the bolding. The hard part IMO is getting the motivation to write the patch and convince the devs to apply it when I already have several other patches in the "wait for the devs to apply it" phase. Anomie⚔ 05:08, 27 May 2012 (UTC)[reply]
@Nageh: Actually, I do check almost all of the edits on my watchlist regularly (the exceptions are generally pages edited by my bot which I keep on my watchlist to see if anyone is reverting the bot without telling me). And the problem with "here is one" is that reasoning from individual anecdotes is often hasty generalization, and does not support a claim that "the average active editor" checks "very few" of their watchlist entries. Anomie⚔ 05:08, 27 May 2012 (UTC)[reply]
I don't want to dispute it, but you really check each vandalism and spam revert by another user, each warning message posted to an IP's talk page, each post on one of the village pump pages, each typo/MOS issue corrected, each message posted to another user's talk page that happens to be on your watch list? Such edits make up a good part of my watch list entries, and personally, I know to spend my time in better ways than checking them (unless someone pays me to). Absolutely no insult intended here. But right, I cannot making any conclusions about the "average user"'s watch list checking behavior. Nageh (talk) 17:02, 27 May 2012 (UTC)[reply]
I for one do (outside of edits to project pages and whatnot), but then again I don't have any IPs on my watch and few user pages, and the majority of article pages are pretty slowly edited. You can't assume just because one person has x-type of pages on their watch that everyone does. ♫ Melodia Chaconne ♫ (talk) 18:17, 27 May 2012 (UTC)[reply]
Well, whatever, the conclusion is that for some people watchlist bolding may be useful, and for some it isn't. Just make it optional – opt-in or opt-out, as long as it's configurable via the Preferences menu I don't care. ;) Nageh (talk) 18:50, 27 May 2012 (UTC)[reply]
I don't have many IP talk pages or other users' talk pages on my watchlist either; when I find I have one and I'm not wanting to look at the comments other people make, I just unwatch it. I do check all the Village pump posts by reading the diff between the last version I saw and the current version, although I will skim over sections about stuff I'm not actually interested in. I check all the edits to articles on my watchlist in the same way, both to make sure an earlier vandal edit isn't hidden by a good edit and to make sure an innocuous edit summary isn't trying to hide a vandal edit.
I don't think anyone has argued for enabling the bolding and opposed a gadget to disable it. Anomie⚔ 20:27, 27 May 2012 (UTC)[reply]
I do recall someone having stated that there will be no gadget. I'm not gonna point fingers, but it was in earlier discussions. Nageh (talk) 20:51, 27 May 2012 (UTC)[reply]
If you find the diff, let me know. The closest I can find is a statement on 12 May at 20:49 in Wikipedia:Village pump (proposals)/Archive 88#Next steps that asserts that there are "plenty of ways" to style it that most people would be satisfied without a gadget. Anomie⚔ 21:25, 27 May 2012 (UTC)[reply]
Hm, cannot find it either. I may have confused it with the same user's statement that "opt-in is not an option" ...which is obviously void now. Nageh (talk) 22:46, 27 May 2012 (UTC)[reply]
Suggesting that a feature be removed from MediaWiki core on the grounds that it is not right for enwiki fundamentally misunderstands the purpose of the MediaWiki software, as I've espoused elsewhere. Happy‑melon 23:13, 25 May 2012 (UTC)[reply]
No one actually suggested that. That's purely been a strawman stance, much easier to argue down than what people are actually against here. As long as people don't see the effects they'll be fine, I can assure all. Some who don't assume their comments will be scrutinized for technical accuracy (or simply don't realize there's any difference) refer simply to "the feature", but we know what they mean. Equazcion (talk) 23:31, 25 May 2012 (UTC)[reply]
No one actually suggested that. - Lentower suggested that. Rd232 talk 05:41, 26 May 2012 (UTC)[reply]
Indeed; I separated this sentence from my main reply to make it clear that I wasn't suggesting that Equazcion had said it; but Lentower made precisely this suggestion just a few lines above. Happy‑melon 09:44, 26 May 2012 (UTC)[reply]
You're right, my apologies. I missed the "backed out of MediaWiki" part. That happens to actually be here this time, but many complaints have also been mischaracterized this way. Equazcion (talk) 09:55, 26 May 2012 (UTC)[reply]
My concern is whether it's the right default for ALL of WP's wikis. Particularly since it, and much of the MediaWiki design, is NOT friendly to new editors. Lentower (talk) 21:31, 26 May 2012 (UTC)[reply]
Well the overwhelming majority of MediaWiki users, both within the WMF wikis and in the wider world, are getting on just fine with this behaviour and have been for half a decade now. However surprising the feature may be for editors who have never stuck their head outside enwiki, this functionality is old news for most of the digital world. Happy‑melon 15:42, 27 May 2012 (UTC)[reply]

Byte count of "(0)" should be bold, if the text has changed[edit]

I have the enhanced display on expanded watchlist options turned on. The summary line for a group of changes to a page for a single day, can have the byte count of "(0)". It would be helpful to me if this was bold "(0)", if the text between the first and last change of the day had changed, though the byte count had not. If I should request this feature elsewhere, please let me know where. Thanks. Lentower (talk) 16:11, 25 May 2012 (UTC)[reply]

The text has always changed for a byte count of zero. Null edits with no changes are not saved in the history. Nageh (talk) 16:15, 25 May 2012 (UTC)[reply]
Just to be clear, I'm not talking about a single edit. But a series of edits. The most common case is a revert of vandalism, where the byte count is "(0)" and the text has not changed, but there were, at least, two edits in between. A case I've seen, where bold "(0)" would be useful, is a series of edits on a number, e.g. 32,000 to 32,111 to 44,312. Lentower (talk) 16:33, 25 May 2012 (UTC)[reply]
Note: In order to better understand what Lentower is talking about, enable both the "Enhanced recent changes" and the "Expand watchlist to show all changes, not just the most recent" options in Special:Preferences (JavaScript is required). --Michaeldsuarez (talk) 17:58, 25 May 2012 (UTC)[reply]

Useful little userscript[edit]

Someone mentioned that they wished there would be a way on the watchlist page itself to choose from all these styles. I decided to take up the challenge. To try it, remove any overrides you may have to restore the indicators (e.g. if you added green stars, remove the css for that), and then add this to your common.js: 

importScript('User:Anomie/watchlist-change-style-selector.js'); // Linkback: [[User:Anomie/watchlist-change-style-selector.js]]
importStylesheet('User:Anomie/watchlist-change-style-selector.css'); // Linkback: [[User:Anomie/watchlist-change-style-selector.css]]

Then look near where the "Mark all pages visited" button was, and let me know what you think. Tested in Firefox and Chromium on Monobook and Vector, both with and without the "enhanced recent changes" option. Anomie⚔ 05:41, 27 May 2012 (UTC)[reply]

Is there currently any new functionality on the watchlist?[edit]

Is there currently any new functionality on the watchlist? Mine looks like it did before the new feature was brought in. Has it been disabled? Have I done something to mess it up?

Yaris678 (talk) 09:21, 29 May 2012 (UTC)[reply]

A bunch of people complained that they didn't like it, and instead of creating the gadget to disable it (that many would have been satisfied with, and the rest would quickly have gotten over it like they did with the recent diff color change), a few admins just disabled it for everyone in MediaWiki:Common.css. And now we have this RFC to decide which color to paint the bikeshed.
To get it back for your account, you can follow the instructions at Wikipedia:Customizing watchlists. Anomie⚔ 11:08, 29 May 2012 (UTC)[reply]
Cool. Thanks. Yaris678 (talk) 13:45, 29 May 2012 (UTC)[reply]

Next steps[edit]

So where do we go next. Clearly rolling it back would be a bad idea, because plenty of folks want the facility, and it's a really good facility, it's just the display - the bit that affects everyone - that's the cause of disagreement. But 90% of contributors seem to agree this feature should be available through preferences, either toggle on/off, or (for the more ambitious) a select your display option. I was in conversation about this with User:Jamesofur, who said (in one of those famous throwaway lines) "oh, it shouldn't be so difficult." I've never coded in MediaWiki, so if I have to do it, it'll take about a year. Can we pool resources and come up with something better and faster. --Elen of the Roads (talk) 21:12, 5 June 2012 (UTC)[reply]

it only needs to be written in javascript and then imported as one of the default tools in perferences, mediawiki coding isnt required, and if they really want to code in mediawiki it written in php so design code that works that way that can be installe din teh backendAndrewcrawford (talk - contrib) 16:39, 10 June 2012 (UTC)[reply]
If all we want is an on/off gadget, that's easy enough and should really have been done from day 1. A gadget that allows selecting the style on the preferences screen is not possible at this time, and development on such a thing in MediaWiki would probably have to wait until after Gadgets 2.0 is done. OTOH, a (on/off) gadget that enables selecting of the style on the watchlist page itself is quite possible.
Personally, I think this RFC should be closed such that MediaWiki:Common.css is changed to the "subtle underscore" styling (given the number of "option 3" comments that opposed just the bold styling or opposed the initial lack of a gadget), with a gadget created to remove the change indication completely. Should the decision actuall go that way, I'll volunteer to implement it all myself if necessary. And then any additional gadget can be discussed elsewhere. Anomie⚔ 18:13, 10 June 2012 (UTC)[reply]
considering the conseus was for opting in then turning it back on regardless what style is going against consesusAndrewcrawford (talk - contrib) 19:05, 10 June 2012 (UTC)[reply]
Ditto. I'll also note that the instructions for this survey originally told people to vote with a bare signature and no comments (I much later changed this to "add an optional comment"), so basing the decision on people's comments now doesn't seem right. Equazcion (talk) 19:49, 10 Jun 2012 (UTC)
WP:NOTVOTE, the quality of arguments should be considered. But now I see Equazcion has jumped in here, so I'll leave it at that. Anomie⚔ 19:53, 10 June 2012 (UTC)[reply]
Yeah the point of my comment was that this actually was/is presented as a vote. Perhaps it shouldn't have been, but it was. Equazcion (talk) 19:57, 10 Jun 2012 (UTC)
And yet very few people left just their name. It seems most were taking it as an actual RFC, no matter what the instructions were for the short time between when it was tagged as RFC and when the "add just your name" comment was removed. Anomie⚔ 20:15, 10 June 2012 (UTC)[reply]
i would be happy with subtle underscore if the conesus was to turn it on but it wasnt so another solution is required, there no point to a consesus if users will do what they want, no one own wikipedia it is made of a community and if the community deicded something until conesus changes then we cant go against that it goign agains thte prinicples of wikipediaAndrewcrawford (talk - contrib) 20:33, 10 June 2012 (UTC)[reply]
(edit conflict) It wasn't removed, just amended. The page is also named as a "survey" and all entries numbered. I'm not sure how responses might've changed had it been made clear that this was not a vote, as opposed to the current presentation that leans in the opposite direction, but nevertheless I don't think it's fair to judge based on those after the fact. Plus, there's the reality that if 101 out of 174 people put their name under one option and we end up implementing something else based on second-guessing them, there will be another backlash and another RFC. I see this happening even with the "subtle underscore" option. Equazcion (talk) 20:39, 10 Jun 2012 (UTC)
But many of the respondents gave arguments that do not apply to Anomie's suggestion. They complained about the bold-text implementation because it is obtrusive, and they objected to opt-out because opting out currently requires editing code. If instead we use subtle underline and implement an easy radio-button method for opting out, then those responses should no longer be considered as opposed to such an action. --BlueMoonlet (t/c) 14:52, 11 June 2012 (UTC)[reply]
Yeah but many more did not -- and many of the opt-out respondents offered similar arguments that could be addressed with something other than an actual opt-out solution as well. Equazcion (talk) 16:50, 11 Jun 2012 (UTC)
Well, I haven't counted the !votes, and it may be that the consensus would be unchanged, as you indicate. My point is only that it would be reasonable for !votes whose reasoning specifically relies on the bold format or the difficulty of coding to not be counted as opposition to a solution that includes neither of those problems. --BlueMoonlet (t/c) 00:16, 12 June 2012 (UTC)[reply]
Not necessarily, because a vote whose rationale makes reference to the bold doesn't necessarily indicate that they would be in favor of something else being the default. It goes back to the fact that this was presented as a vote. If people think they can just add to the tally they might not care to put effort into fleshing out their rationale, so a "what idiot decided this bold thing by default was good" would've seemed fine, even though bold specifically might not merely be their issue. If it had been made clear that this wasn't a vote, people might've been clearer regarding their rationale. This survey was skewed to begin with; opt-out requiring no rationale apparently, and opt-in requiring valid rationale. Not that this could've reasonably been predicted, so it shouldn't be seen as a commentary on Elen of the Roads' work (or mine, as I did reformat this early on). Equazcion (talk) 00:27, 12 Jun 2012 (UTC)

but that going against what this slightly bigger coments suggest that epopele wnat ti opt in, if you go against wha tthis ocnesus says, then wikpedia funedtanl princals will be useless, that it is free to edit and that the community diecideds how to do it, if you go opt out which isnt want the conesus suggest (i say conesus but still not a big enough respondents to say one way or another but far grater than the number who voted to have it turne don in teh first place) then wikipedia will basically be only run for select editors, its not for us to deicded yeah do it this way the conesus currently says overwhelming opt in so it now up to wikimedia to make ti possibleAndrewcrawford (talk - contrib) 15:06, 11 June 2012 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_comment/Watchlist_survey&oldid=1149004834"