Page MenuHomePhabricator

Collapsed string of note marks (aka references)
Open, Needs TriagePublic

Description

In some cases there is a long string of note marks (aka references) and they make it slightly harder to read the text. In content text they are a sufficient seldom occurrence that they are not that much of a problem, but should be solved somehow. If we try to reuse references in the infoboks, then the number of note marks can be quite high.

I have been experimenting with collapsing the note marks into a single common one. Clicking (or hovering) on that opens a small toolbar with the other note marks. This does not work very well when a popup note is used for the citation, as it will stack two popups on top of each other. It would probably be better to list the notes for each citation in one and the same popup, probably as a scrollable list.

In my experiments a sequence like <sup>[1]</sup><sup>[2]</sup><sup>[3]</sup> would be rewritten as <sup>[&dagger;]</sup> and with an additional toolbar with <div>[1][2][3]</div>. In some of my experiments a single <sup>[1]</sup> was turned into <sup>[&dagger;]</sup> and multiple <sup>[1]</sup><sup>[2]</sup><sup>[3]</sup> was turned into <sup>[&ddagger;]</sup>. Both forms are shown in Figure 1, and in Figure 2 a reference toolbar is shown.

Figure 1: Text without open ref toolbar

Figure 2: Text with open ref toolbar

I have also experimented with removing the square brackets to make it even less disturbing. That made it a bit to small to hit with a pointing device, and I had to enlarge the clickable area.

To do this properly would require some small changes to both Reference Previews and Cite.

This is now part of a discussion at nowiki, but the community is made aware of the fact that the current Reference Preview does not support this style of encapsulating several note marks. Not sure if this is a real issue for anyone outside nowiki…

Event Timeline

jeblad created this task.May 31 2019, 4:26 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 31 2019, 4:26 PM

Personally, I think it is helpful for readers to immediately be able to see when text has multiple citations, because that implicitly has the information that editors have considered it worth giving multiple references, which might indicate that the information has been questioned, or is controversial in some way. E.g. the second sentence at https://en.wikipedia.org/wiki/Homeopathy !

Anything that partially-hides that kind of contextual information, would make it slightly harder to readers to notice and thus access citations.

Additionally, Readers are accustomed to the pattern of [1] leading to more info, and they would have to learn the new pattern of [†] and [‡]. Whilst not complicated, that is also a significant change which might not be clear to many less-well-educated readers.

Lastly, the glyph of [†] is somewhat problematic because it is already used to denote "date of death" in some projects, e.g. German Wikipedia, see example at https://de.wikipedia.org/wiki/Joseph_Haydn

In conclusion, I'd recommend against this change at Nowiki (though I do understand the desire to simplify the reading experience). Hope that helps!

Izno added a subscriber: Izno.May 31 2019, 9:00 PM

[...]

A lot of this comment seems focused on the implementation of the presentation. I could just as easily present these references as [1-3], [1, 3, 6-10], [a, c, 3, 2], rather than [1][2][3], [1][3][6][7][8][9][10], or [a][c][3][2], or the suggested daggers, with subsequent appropriate linking. A solution to the presentation of references here might allow us to get rid of the group citations that are responsible for T49544: <references/> list item must not wrap the text in <span>.

The real problem with a request like jeblad's is what the user-without-Javascript would do to access the "collapsed" references. If I want to access reference c in the group above without Javascript, how do I do that? It seems like a large accessibility degradation to force people to ctrl+f instead for the reference number in question.

I guess the "rewrite" of the reference links could be done with Javascript instead of PHP, but that would cause reflow and friends.

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

jeblad added a comment.Jun 1 2019, 1:52 PM

Personally, I think it is helpful for readers to immediately be able to see when text has multiple citations, because that implicitly has the information that editors have considered it worth giving multiple references, which might indicate that the information has been questioned, or is controversial in some way. E.g. the second sentence at https://en.wikipedia.org/wiki/Homeopathy !

This discussion started after it was observed that some infoboxes would be provided with way more references than just a few from Wikidata. Quite a few well-known people has more than 10 references, and the numbers are growing.

Anything that partially-hides that kind of contextual information, would make it slightly harder to readers to notice and thus access citations.
Additionally, Readers are accustomed to the pattern of [1] leading to more info, and they would have to learn the new pattern of [†] and [‡]. Whilst not complicated, that is also a significant change which might not be clear to many less-well-educated readers.

I can't really see this as a real problem.

Lastly, the glyph of [†] is somewhat problematic because it is already used to denote "date of death" in some projects, e.g. German Wikipedia, see example at https://de.wikipedia.org/wiki/Joseph_Haydn

The most well-known note marks are Dagger and Double Dagger. Perhaps make it localizable? :D

In conclusion, I'd recommend against this change at Nowiki (though I do understand the desire to simplify the reading experience). Hope that helps!

I guess this is an example (!) of the problem with giving examples. The examples are misinterpreted for the real thing. I guess I forgot to put in "the green button". (The green button is usually some failing part of a demo that has a sole function to divert the discussion from other minor design choices.)

jeblad added a comment.EditedJun 1 2019, 2:05 PM

[...]

A lot of this comment seems focused on the implementation of the presentation. I could just as easily present these references as [1-3], [1, 3, 6-10], [a, c, 3, 2], rather than [1][2][3], [1][3][6][7][8][9][10], or [a][c][3][2], or the suggested daggers, with subsequent appropriate linking. A solution to the presentation of references here might allow us to get rid of the group citations that are responsible for T49544: <references/> list item must not wrap the text in <span>.
The real problem with a request like jeblad's is what the user-without-Javascript would do to access the "collapsed" references. If I want to access reference c in the group above without Javascript, how do I do that? It seems like a large accessibility degradation to force people to ctrl+f instead for the reference number in question.
I guess the "rewrite" of the reference links could be done with Javascript instead of PHP, but that would cause reflow and friends.

I have already implemented this in Javascript, but by doing some preparation server side it is possible to avoid the reflow. You switch between two different classes, where one layout for the note marks is defined if Javascript isn't enabled and the other one if Javascript is enabled. Thus it will be no reflow.

(A string of note marks can be hidden and replaced by generated content, all as styling alone.)

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

I can't see how this relates… Can you clarify?

Izno added a comment.EditedJun 1 2019, 4:05 PM

As it happens, jeblad's problem can also be overcome by grouping references, as are presented in T49544. (Of course, that has its own issue... but that's an aside. 😃)

I can't see how this relates… Can you clarify?

When you have many references in a row, you can consider a construct like:

Fact.<ref>
First ref
* Second ref
* Third ref
</ref>

This is how en.wp deals with the problem. I just wasn't able to find where we document that solution else I would have linked it.

The solution in T224741#5228174 will fail badly when you have permutations of references. Permutations of references in such a list will spawn new entries in the references tag. This will be a real problem with references in infoboxes.

This discussion started after it was observed that some infoboxes would be provided with way more references than just a few from Wikidata. Quite a few well-known people has more than 10 references, and the numbers are growing.

Ah! That makes more sense as a significant problem. Thanks for clarifying. :-) I don't have any alternative suggestions, so, good luck!

Ah! That makes more sense as a significant problem. Thanks for clarifying. :-) I don't have any alternative suggestions, so, good luck!

[slightly off-topic]

What I did in a module for adding references to infobox rows was to use a fixed ordering and then create a hash for the name part of the ref-tag. It is the content that is hashed. You can repeat the content if it has the same name and it will not spawn new entries in the reference section. Sorting the entries can be done with the standard ordering function, and that is sufficient unless a property in the reference is repeated. The most common problem is several authors. Those are a bit difficult, as you should not change the ordering of authors. As the order of statements are a bit random, it will be a problem.

I did something slightly simpler, I reused the existing hash from the wb-reference, which exposed the problem with the statement order. Someone spotted the error and made a whole lot of fuzz about. It should only be a proof of concept, but in the end I had to kill the code to calm down two-three users that went completely ballistic.

You can't inspect results from processing other rows, unless you abuse an slight error in Scribunto, thus you must use the information available during processing of each row. If you could inspect the other rows, then you could reorder statements until a match is found with a previous reference.

Without a proper fix on statement order I doubt it is possible to reuse multiple references from Wd in the infobox.