Template talk:Xreadership

This page is about discussing the Talk page message box {{Xreadership}} containing summary page view info and a collapsed bar chart. Not to be confused with Template talk:Xviews, which is about discussing creation of the bar chart itself.

Promising template!

I think this template looks good and, if further developed, could become a nifty replacement for {{Annual readership}}.

In this TfD, the majority voted to keep the Annual readership template, but to 'noinclude' it, i.e. making it invisible on the talk pages that transclude it. However, the majority of people did seem to think that Annual readership was useful if the Graph extension is ever coming back.

{{Xreadership}} is currently used on 80 talk pages. For example:
Talk:SpongeBob SquarePants (character) and Talk:SpongeBob SquarePants (character)/pageviews.

One thing that would greatly increase this template's usability is to have a Day/Month switch, so that you can not only see the daily page views, but also the monthly page views.

The biggest challenge I think would be to have a bot that regularly updates the "/pageviews" subpages. The Annual readership graph was used on 53,510 pages before it was turned off. So if a bot would update the logs weekly, it would have to make tens of thousands of edits a week.

According to the {{NUMBEROFARTICLES}} magic word, the total number of articles currently stands on 6,883,482 (nine days ago, it was in fact 6,879,730 articles, so the number is still growing). If *all* those talk pages had {{Xreadership}}, then the bot would literally have to make millions of edits per week, i.e. multiple edits per second. In that case, it would be more feasible if the logs were updated monthly instead of weekly. Cheers, Manifestation (talk) 15:11, 16 September 2024 (UTC)

Manifestation, thanks for your comments. A few points:

• The toolforge pageviews tool can grab monthlies, so we ought to be able to do that, too. The change to the template to permit that is not difficult, but it would increase the burden on the bot by a small amount.
• Grabbing 53,510 datafiles and copying them to an equal number of Wikipedia subpages is not burdensome for a bot. Given 604,800 seconds in a week, that is only one page every 11 seconds. I should time myself doing it manually; I think I do two or three per minute when I have a bunch to do and I get in the zone. If I could keep up 3/min. for a week with no sleep, I could do 30,240 of them. So, I suspect a bot is not going to have any trouble with 53,000. One AI tool guessed that this could be done in Perl or Python at the rate of thousands of operations per minute, so all done in an hour.
• It's never going to be done for all 6.9M, because that would cause a huge backlash, and anyway, by then hopefully the original Graphing app will be fixed and back again. Plus, nobody would be looking at them. It really should be opt-in, the way it was before, with someone having to go to the trouble of adding {{annual readership}} to the page; at least that is proof that one person is interested in viewing the data. There is no reason to do it for every page, and we should not.

However, I haven't written a bot here before, and there could be all sorts of issues, like throttling toolforge pageview downlaods so as not to hog the tool or the servers, and other things I haven't thought of. I may ask for help on this question. Thanks, Mathglot (talk) 06:41, 28 September 2024 (UTC)

@Mathglot: I'm wondering how it would impact the servers if a User:Xreadership bot would make an edit every 11 seconds, 24/7. I doubt the BAG would approve of this, especially since they may consider this a 'luxury product'.

How many edits per day would they grant your bot? Like, perhaps 100 edits per day? That would be 3,000 edits in a 30-day cycle.

What you could do is use a dynamic list of pages the template is applied on. That list could have three types of entries:

• pages with long-term or permanent high traffic (e.g. Main Page, United States, Donald Trump);
• pages about planned high-profile events (e.g. Oppenheimer (film), Barbie (film), UEFA Euro 2024);
• pages about sudden high-profile events (e.g. Death of Michael Jackson, 2011 Tōhoku earthquake and tsunami, Uvalde school shooting)

Unfortunately, I cannot help you with creating a bot. - Manifestation (talk) 17:20, 29 September 2024 (UTC)

Really, do not worry about this. Remember that bots don't have to run on WM servers; it could easily run on my laptop. Here is a comment about one app that processed 80,000 files in 5 seconds, on a laptop that was already old in 2018. The worst possible performance would be doing 1 edit every N seconds, as almost all of the time spent would be overhead loading and initiating the program. If there were a throttling or load issue at all, you would probably want to do several thousand files each time you started the bot, regardless of the interval between runs. Mathglot (talk) 17:49, 29 September 2024 (UTC)

I'm sure a bot script wouldn't put a strain on any normal laptop. But would it put a strain on WM servers/databases? Cheers, Manifestation (talk) 18:05, 29 September 2024 (UTC)

Hairline font accessibility

The hairline fonts are hard to read on my screen. While I can't find any prohibition in MOS:SMALL, they go against MOS:FONTFAMILY or its spirit. I'm not sure if they have meaning or are just decorative, as its use for "(experimental)" seems arbitrary. The original pageviews.wmcloud doesn't use them, and neither does any other professional encyclopedia. I will remove them for these reasons. 174.89.12.36 (talk) 21:29, 18 September 2024 (UTC)

There is also the accessibility problem of the bar numbers being only 2.91 contrast. #737373 is the brightest that meets the WCAG. 174.89.12.36 (talk) 21:51, 18 September 2024 (UTC)

Visual bug

Hi!

I wish to report a small, yet pesky visual bug, which I think can quite easily be solved.

The scale of the screen of my Windows laptop is 175% (see screenshot). Pretty high, but I like that. The {{Xreadership}} template will render correctly when I have my screen on 125% (screenshot) or 150% (screenshot). But when I have it on 175%, something strange happens.

The view value of the the longest vbar, representing the day with the most page views, wraps to a new line. Here is a screenshot. Note the position of the number 8473.

An easy fix, I think, would be to remove width: 8ch; from .vbar-valh in Template:Xviews/vbar/styles.css. I'm not sure why the element has a width to begin with. It's not needed: the div will by default adapt its width to its content, which in this case is the nr of page views.

Perhaps I'm completely wrong here, and maybe a more sophisticated solution is needed in calculating the widths of the bars. But I tried removing width: 8ch; in Chrome DevTools and it worked. See here: before, after.

Cheers, Manifestation (talk) 09:57, 15 October 2024 (UTC)

@Mathglot: What is your opinion about this? Cheers, Manifestation (talk) 15:17, 17 October 2024 (UTC)

Manifestation, this is a known bug. See Template:Xreadership#Known issues, second bullet. {{Xviews}} is responsible for the actual chart generation; Xreadership is just the part that embeds it on the Talk page and adds some summary info and helpful warnings about expiration. So the fix would happen in an Xviews subtemplate, likely in {{Xviews/vbar}}, and very possibly a css-only fix in {{Xviews/vbar/styles.css}}.

Regarding the known issues in general: because I have no idea if this template will be accepted and used more than it is, I probably won't fix some of these bugs until it's clearer if the template will achieve enough acceptance to make it worthwhile. That said, if you have some CSS smarts, that will likely fix it with no actual template coding. If you do play with it, please use the sandbox first, and create a test case or two. If that works, feel free to change the template code or subtemplates as needed. Thanks, and I encourage your bug reports and comments, whenever you find an issue. Mathglot (talk) 16:15, 17 October 2024 (UTC)