Talk:List of winners of the Rotterdam Marathon

Table abbreviations

Inbound link referred to below:

Wikipedia:Teahouse#Creating policy to support an argument

which spawned:

Wikipedia talk:Manual of Style/Tables#Creating policy to support an argument

Guideline discussion at:

Wikipedia talk:Manual of Style/Tables#Requirement for key?

@Editør: Greetings! Regarding this revert...the tooltips don't work on mobile devices, which are more than half of Wikimedia traffic. When I look at these tables on my Android phone, they are already two lines of text per row and wider than the viewing window, so expanding from two-letter word width to a six-letter word width doesn't seem to impact layout that much. Certainly just seeing the meaning right away makes things easier to read for everyone, which is why I prefer just writing things out. If you feel strongly about having the compact version, though, the tables should get a legend at the top or the bottom explaining what "CR", "=CR", and "WR" mean. After a lot of hunting I found these terms defined in the prose, but many readers who just come here to look at the tables will simply miss that. -- Beland (talk) 20:46, 21 December 2023 (UTC)

Thank you for discussing this here. There appear to be more unsolved/unaddressed issues with the transition to the combination of both desktop and mobile. I think I understand the point you are making here, but if half of the Wikipedia users cannot access the "tooltips" as you are suggesting, I think this is an issue that should be solved for Template:Abbr, Template:AthAbbr, and similar templates collectively at a higher level. Maybe there is a technical fix that works on mobile, maybe the templates should be deleted, maybe they should come with specific instructions, etc. – Editør (talk) 22:23, 21 December 2023 (UTC)

@Editør: I'm a professional web developer, and I don't know of any technical fix that could be applied. Some devices simply aren't compatible with mouse-over triggers because they don't have mouse-like devices. This is why MOS:ACRO1STUSE specifically requires writing out the expansion of acronyms at least once. If you want to keep the abbreviations in these tables, a legend would be the way to go, I think. -- Beland (talk) 10:25, 25 December 2023 (UTC)

Yes, I agree with MOS:ACRO1STUSE, but the abbreviations CR and WR are both written out in the lead, and both are listed on Athletics abbreviations#Records suggesting they are standard abbreviations in athletics. However, making things accessible (for mobile users or others) often means adding some redundancy, so I will consider adding a legend or similar solution. – Editør (talk) 15:53, 25 December 2023 (UTC)

@Beland, would this CR, an extra link to the abbreviations page in combination with the 'tooltip' and the written out version in the lead, be a solution that would work for you? – Editør (talk) 21:59, 25 December 2023 (UTC)

And a technical solution for mobile devices could perhaps be something like displaying the 'tooltip' text in some sort of footnote. – Editør (talk) 22:31, 25 December 2023 (UTC)

If we're using footnotes for some devices, it would be better to use the same formatting for all devices, so readers only have to learn one set of conventions. -- Beland (talk) 04:34, 9 January 2024 (UTC)

I have added legends to the tables with confusing abbreviations. -- Beland (talk) 04:37, 9 January 2024 (UTC)

The abbreviations are explained in the lead and explained through their links. Your third explanation is overkill and makes no sense. – Editør (talk) 19:17, 9 January 2024 (UTC)

@Editør: In the English publishing world, it's simply the dominant typographical convention to explain unusual table symbols in a legend near the table. Looking at Wikipedia's featured lists, which are considered the most finely honed by the Wikipedia editing community, tables with unusual symbols or even relatively common abbreviations have a legend at the top, and if unusual symbols appear in more than one table, the legend is repeated so that readers don't have to go hunting around the page. (See List of National Football League annual passing touchdowns leaders, List of Washington & Jefferson Presidents head football coaches, List of English football championship-winning managers, List of Los Angeles Metro Rail stations.) In this article, the abbreviations CR and WR are not used in the prose, so there is no need to define them there. (And the notation "=CR" per se is not anywhere defined.) I propose we remove them from the prose to avoid "overkill" and add a legend at the top of the table, which is where readers should expect the definition to be. This change will have to be made eventually anyway, if this list is ever to become featured-quality. Links to explanatory articles are nice to have, but they do not work for all readers, especially those reading on paper or using a screen reader (as I often do). Even for readers using a conventional web browser, they are a bit of a puzzle to be unlocked, as it is not intuitively obvious to a lot of people that a definition can be obtained by clicking on the abbreviation. -- Beland (talk) 20:40, 9 January 2024 (UTC)

I thought your earlier point about mobile accessibility of the 'tooltips' for the explanations of the abbreviations was relevant. In December, I proposed a solution and asked you about your opinion, but you have ignored this. Eight days later and referring to our discussion, I made the changes which you have ignored, indicating to me that accessibility is no longer the issue. But the abbreviations still seem to bother you. You've made new edits to the explanations of the abbreviations without discussing them first, which I find disruptive behaviour. After I reverted your edits, you are now using different arguments for changes to the abbreviations. I don't think that your claim of "a dominant typographical convention" or the existence of featured lists with legends to explain colors, symbols, and terminology are convincing arguments to add a legend in this specific case. The lead in this list article is summarizing the list in order to introduce it with prose, which I believe is a reasonable place to explain an abbreviation used in the list. In combination with the 'tooltips' and the links under these commonly used athletics abbreviations, there is no need to also add a legend, in my opinion. – Editør (talk) 11:32, 10 January 2024 (UTC)

I want to add here that I noticed that you've created the section Wikipedia:Manual of Style/Tables#Explanatory notes and legends in support of your argument here, which in my opinion is the wrong way to approach a discussion like this. – Editør (talk) 12:11, 10 January 2024 (UTC)

@Editør: Sorry I didn't give a more detailed reply above; there are several problems with the idea of making a template that produces footnotes on mobile devices and tooltips on desktop devices. One, tooltips require discovery, so they are not all that great even for desktop users as a primary way to convey information. Two, they don't work for print readers. Three, such a template would be somewhat complicated, having to detect no-hover environments and probably requiring editors to add a second template to specify where generated footnotes should be displayed. Four, we don't have such a solution constructed; it would probably take a while, and we need to do something in the meantime. Five, so that readers learn a consistent set of typographical conventions, it would be better to have the same behavior on desktop and mobile. But doing that means we would have footnotes on all platforms...which is pretty much the same thing as a legend at the bottom of the table. Further research of how other Wikipedia editors solve these problems indicates to me that for accessibility reasons, legends are actually put above tables, not below as I proposed. It also seems like this practice is a de facto standard for tables on featured-quality pages, which is why I thought it made sense to solicit consensus for writing this down as a guideline. Presumably this question will come up on lots of articles, and it would save time if there were a documented best practice. And produce more accessible articles, given I was proposing putting the legend in the wrong place. I didn't mean to make anyone angry, and I'm sorry if I did so. I thought this sort of minor change would be relatively non-controversial and that the layout conventions used in print publishing were widely known and approved of. -- Beland (talk) 22:20, 11 January 2024 (UTC)

(arrived via Teahouse thread) As a mobile editor, I'm in agreement here that tooltips shouldn't be used, but I'm seeing a lot of ways these tables could cut down on the usage of horizontal space:

• The ref column could be removed, and citations appended directly to the time, as in e.g. Tiki Gelana's 2012 entry.
• The note column could be removed, and course records / world records denoted in another way, like changing the background colour of the row, boldfacing the time, or something (although MOS:ACCESS and MOS:NOBOLD might have things to say about this).
• The flag icons could be dispensed with, since in each case they are next to a wikilinked name of the country they're the flag of.

I'm pretty sure there's also a way to create an internally linked legend using {{efn}}, {{notelist}} and ref grouping that could allow for a tooltip replacement such that a time could have a superscript that would render as "Course record" on tap via mobile, with the notes placed at the bottom of each individual table, but it would take me awhile to figure out how to get the displayed note to stay as e.g. while knowing which table it was meant to link to. Folly Mox (talk) 13:18, 10 January 2024 (UTC)

@Folly Mox: Indeed, for accessibility reasons, MOS:COLOR says that color cannot be used as the sole means to convey information, and MOS:ACCESS points out that screen readers often do not indicate bold text. -- Beland (talk) 21:54, 11 January 2024 (UTC)

Actually I think {{efn}} and {{notetag}} etc auto-enumerate based on |group=, so the fourth idea I mention just above would have to be implemented way more jankily, but I don't like the current solution, with tooltips backed up by a wikilink to Athletics abbreviations § Records: it's not mobile friendly, and feels inelegant.

No strong opinion on the copypaste of MOS guidance from one MOS page to another, but seems like it should have been accomplished by {{excerpt}} or labeled section transclusion or {{see also}}, since duplicated guidance will be subject to desynchronisation. Folly Mox (talk) 13:36, 10 January 2024 (UTC)

Here's a few of my thoughts on the tables. The abbreviations cause a bit of an accessibility issue on mobile because there is no hover, but tapping gives you the meanings, just on a separate page that becomes a hassle (bad user experience). Since there are only two abbreviations, a legend could be added above the table or in its caption. Another option could be to rename the column label to "Record", a more fitting label, and spell out the values as "Course" and "World". On my Android phone, the tables aren't too wide in portrait orientation and the text wraps properly. In landscape, the tables fit without wrapping. To narrow the tables further, consider adding Help:Sortable tables#Sorting buttons in a separate row. Also, you could delete the ref column and relocate the refs inline with the athletes dates. The athletes might be a more fitting row header instead of dates since they are the main subject according to the caption. (Strike, doesn't work with cancelled marathons.) For me, the flags in the middle of the table server more as a distraction when reading and could be omitted since the country name is present. In general, I think flags are better in the first column, like in the third table, which help draw your eyes to the start of the row similar to bullet points in a list. Jroberson108 (talk) 17:04, 10 January 2024 (UTC)

I like the idea of renaming the column "Record"; then this article could actually avoid using the abbreviations "CR" and "WR" entirely, and readers would know the meanings of the notation on sight rather than having to remember back or hunt around. Any objections to doing that? -- Beland (talk) 22:20, 11 January 2024 (UTC)

@Beland, I asked experienced editors to weigh in on your conduct of adding new policy to support your argument in this discussion. Instead, people joined the discussion itself, which is fine and helpful, but I need some time consider all the suggestions made here. – Editør (talk) 23:57, 11 January 2024 (UTC)

I looked at the article's last revert. I initially thought "=CR" was a typo, but now know it means tied (or equal based on desktop's hover title), something not defined on the linked page. Also, the linked page defines CR as "championship record" or "course record (marathon)", where one is related to marathons and the other (possibly?) usable for marathons. On mobile, it isn't clear which one since there is no hover text. Keep in mind, I know nothing about this topic. Lastly, the "Time (h:m:s)" column header uses page links instead of {{Abbr}}, so it might need to change. Jroberson108 (talk) 06:04, 12 January 2024 (UTC)

Definitely support sorting buttons in a separate row. Another space-saving feature is date format: we could use yyyy-mm-dd, which is approved for use in tables per MOS:DATEFORMAT. (This has the additional benefit of making the column sortable without any additional data sort attributes.) Fold column headers that are wider than the widest data cell: in this case, the time column could be "Time<br/>(h:m:s)". (Drop the parens to save two more characters, or just drop the time legend entirely, because on what planet do you have to be on to require a legend to explain what "2:09:28" means in a sports table?) I'm persuadable about removing notes and refs columns, as long as the note or ref is still in the same row, although I'm opposed to dumbing down a table excessively for everyone if the primary reason is to cater to mobile devices just because mobile users are the majority of traffic. There's no question that some tables are simply going to tell a better story and be more comprehensible on a wider device, and editors that use wider devices should be able to have a rich experience. In cases where there are more than one acceptable way to display a data value, and the more acceptable way is longer, then consider use of the {{if mobile}} template, which may be used, for example, to display "CR" and "2023-01-12" on mobile and "course<br/>record" and "12 January 2023" otherwise. Mathglot (talk) 19:17, 12 January 2024 (UTC)

Thank you for mentioning {{if mobile}}, I think we can use it to create two solutions for the Note column, one that works best for desktop (keep as is with 'tooltips') and another for mobile (such as add a legend displaying the texts from the 'tooltips' before the table, or something else). – Editør (talk) 23:10, 12 January 2024 (UTC)

The Ref column was meant to give a reference for the whole row, not just the time, so I'm not sure if merging the references into the Time column will be clear. Also adding the reference superscript to the time will make it slightly harder to read. – Editør (talk) 23:15, 12 January 2024 (UTC)

I would prefer not using "=CR" altogether, but simply "CR" (or the chosen equivalent) and perhaps add a footnote explaining it equals the earlier course record, or something we didn't think of yet. And then we would just need a clarification for the course record and world record marks. – Editør (talk) 23:21, 12 January 2024 (UTC)

As far as refs being for the whole row, my preference is also for ref in its own column, all by itself; I'm just looking for other solutions for small devices. Remember what we're after, here: it's WP:Verifiability; there's nothing to say you can't come up with a creative solution, like a "Legend" just for refs, with verification in there; i.e., there's absolutely nothing wrong with this:

mockup of refs moved to divbox
Men's winners of the Rotterdam Marathon Date Athlete Country Time (h:m:s) Note 23 May 1981 John Graham Scotland 2:09:28 CR

(P.S., I tried doing that in a collapsible footer row that spans the whole table width, and it's doable, but requires lots of 'width' css, and is discouraged at Help:Tables#Notes.)

A further note on {{if mobile}}, since you mentioned it: while not deprecated, there is a move towards using WP:TemplateStyles as much as possible, and if it's possible to condition the column appearance purely with CSS using TemplateStyles, then that's what we should do. There's no reason not to start with {{if mobile}}, as it has a very low learning curve; if you do, maybe put something in the edit summary of it being a temporary solution, until you can get someone to figure out how to convert it to TemplateStyles. Mathglot (talk) 01:32, 13 January 2024 (UTC)

That's my first time seeing {{if mobile}}. I noticed it didn't have very much testing, so I took the initiative, which is discussed at Template talk:If mobile#Test skins, print, and screen readers. Per my findings, I don't recommend it for use with inline content such as in the cells. Although displaying a mobile-only legend (block of content) above the table is possible, it isn't going to print for the desktop version where it is also needed. Jroberson108 (talk) 09:09, 13 January 2024 (UTC)

Jroberson108 I didn't really follow what you were saying, but it certainly works. However, this is not the right place to discuss issues with whether a template works or not; if you'd like to raise a discussion at the template talk page and ping me, we can certainly discuss it there. Mathglot (talk) 09:56, 13 January 2024 (UTC)

@Mathglot: As mentioned, there is already a discussion about the template and its issues at Template talk:If mobile#Test skins, print, and screen readers. Jroberson108 (talk) 10:08, 13 January 2024 (UTC)

Proposed solution

Would the following using {{if mobile}} work as a solution for you? – Editør (talk) 20:59, 18 January 2024 (UTC)

I'm not sure this template works here... – Editør (talk) 21:09, 18 January 2024 (UTC)

@Editør: On my Android phone, I'm not seeing the legend, it's being hidden by {{if mobile}}. I also doubt that screen readers will be consistently given the mobile version of the page, especially if they are used while browsing the desktop site. I also don't think there's any need to try to use the template to hide the hover that doesn't work on mobile; that just makes the wiki markup overly complicated. -- Beland (talk) 19:46, 7 May 2024 (UTC)

---

Men's winners of the Rotterdam Marathon

Date	Athlete	Country	TimeTime	Note	Ref.Ref.
23 May 1981	John Graham	Scotland	2:09:28	CRCR
20 April 1985	Carlos Lopes	Portugal	2:07:12	WRWR
22 April 2001	Josephat Kiprono	Kenya	2:06:50

Notes

References