MacOS15.2 Sequoia, Safari Version 18.2 (20620.1.16.11.8)
When clicking through from a search result and in ?some? instances where a link is shared (harder to reproduce) the SCID references remain toggled visible even when the reference box has none ticked or M is toggled. The message saying that the references have been disabled appears, but nothing happens.
I just realised that the first fault is also present in Chromium browsers on Mac - that is, the inability to toggle the main reference numbers off and on when linked from search.
This happens essentially whenever someone links to a specific segment, e.g. SN1.1:1.1 EDIT: Interestingly enough, the link above creates the anchor #sn1.1:1.1, which highlights the text itself, whereas #1.1 highlights the number. In both cases, the references cannot be disabled anymore.
Ven. @Snowbird and I were just discussing this in dev chat (private link). Here’s a reproduction from him:
Which I was able to reproduce. And his user story[1], which is pretty compelling:
I’m pretty sure I’ve done this same thing before too, and ended up manually deleting the segment numbers from my copied text.
Doing it in the reverse order (copy the text, then enable references and copy the segment number) is workaround for this. So is right-click “Copy link address” on the segment number pill.
We had some slightly different opinions regarding whether the anchor text/segment number/ref pill should be shown at all when linked. Ven. Snowbird believed it was not necessary, whereas I do think it is a good visual indicator of that someone linked you to a specific segment and not just anywhere on the page. Particularly since most web users don’t know how anchors work to even understand that that may be a feature of a page.
But there’s still a few ways to workaround that I think would satisfy both of us:
Only show the linked, highlighted segment number and don’t turn on references for the whole page
Make clicking the segment number a second time remove the anchor in the URL. I.e. make the segment number click a toggle
Don’t show the segment number if references aren’t on. Highlight the actual text instead
EDIT: Apparently the highlighting is already possible with a longer anchor like #sn1.1:1.1, but this still shows the segment number and still makes it so references cannot be disabled
Toggling references should turn them off and probably remove it from the URL too.
But I can see why that would be pretty nuanced to design as the URL anchor and the toggle are two opposing user intents, and the anchor already temporarily overrides your localStorage settings/user preferences. As in, you can make arguments for different options being “correct” in that situation.
The options I listed above can bypass that nuance and avoid the question in a way.
This other one I couldn’t reproduce. It might have been fixed already?
I also hijacked the title of this post a bit to be more specific to the first one
note that I made some tiny fixes/edits to the quotes ↩︎
One thing to think about is user intent, which in this case conflicts since there are two users: the sender and the receiver.
Now, normally the one actually using the website should have their intent respected, i.e. show what they ask for.
But in this case I think the intent of the sender should take priority. They should have confidence that what the receiver sees is the same as what they see. Given that they want the receiver to look at a specific passage, I think it’s reasonable to show the reference anchor for that passage. In addition, I think it’s reasonable to assume that, on the whole, senders will be experienced users (they have, after all, figured out how to use the refs), whereas receivers may or may not be experienced, and hence might benefit from learning about how the ref anchors work, or even their existence. Finally, the ability to have a reference-free experience is mainly intended for reflective reading, so for simply checking a passage it’s not so essential.
For these reasons I think “show the ref anchor by default when a linked passage is shared” is best.
The other question was about the UI. There, we obviously need some improvement.
How about this. We keep the systems distinct: user settings have no relation to what is shown when a link is sent (i.e. when a hashed ID appears at the end of a URL).
Instead, a new button is shown on the linked segment. This includes the options for what a user might want to do. As I understand it, the main option would simply be “disable share view and show text per user settings”. I’m sure there’s a better way to phrase that! Perhaps a toggle button with “share view” and “default view” as options.
In addition, we can tell the user that they can change their default settings in the toolbar. Perhaps when they click the toggle button, they get a feedback message:
Text is now shown according to your “Views” settings. You can change these settings at any time via the “Views” button on the toolbar.
This a secondary issue to the fact that once you are sent to segment, either by search or someone sending you the url, there is no way to turn off the segment ids. Even if you toggle them in the settings toolbar.
The expected outcome of toggling segment id visibility is that it actually toggles.
Let’s fix this bug and then if we want to implement extra features, do that afterwards.
When I send someone a link to a segment, my one and only intention is that clicking on that link takes them to that segment. I am not familiar with any other website where an anchor in a url changes the look of the page. As a receiver I 100% do not want clicking a link to override my settings, even if it is temporary.
If you want to highlight the segment anchored to, great. But don’t start suddenly showing refs.
None of the current behavior makes sense to me. Don’t make it more complicated, just be like a normal website.
This is a pretty solid norms observation that I find hard to disagree with.
One piece of prior art I could think of off the top of my head is the text fragment draft feature of browsers that often highlights text as well. A few others I had to search up to remember, they are relatively rare on the web:
They all change the focus and highlight or expand a piece of dynamic content maybe, but otherwise don’t change the look of other parts of the site.
That being said, most websites don’t have anchors to literally every segment on the page, usually only to some headings.
GitHub follows this too, since you can use “Code”, “Blame”, or “Preview” from the URL. The first two keep the highlight.
There’s also some tinier URL view settings for diffs, such as whether to “Hide whitespace” and be “Unified” or “Split”. These respect your user preferences unless the URL has a query parameter in it.
Example: 422 adding second patimokkha · suttacentral/sc-data@c6830ae · GitHub, click the gear icon above the diff
This is largely what I meant by “opposing users intents” in my previous comment as well.
And, Bhante Sujato, since this affects the UX and has some differing opinions, it would be good to get your agreement on whichever option(s).
There is some prior art/precedent I can think of for this, for example “View as” mode that some apps have to view as a different user for preview purposes. That does make for very explicit intent, which I like.
But I’m not sure if I can think of an in-line option like this, vs a sticky top bar or button. This is also a relatively rare feature.
In particular, on mobile, this would be very crowded with a clickable segment anchor on the left and a “share view” button the right.
There’s potentially a way to fit this into option 2 that I listed in my prior comment. The segment anchor could be a toggle between two modes, or can have a drop-down appear when clicked to explicitly choose a mode or just copy a link.
But my intent as the sender is that the receiver is taken to that segment, not that the segment numbers be activated.
I think highlighting the segment is not a bad thing, but as it stands now, it is only possible to link to a single segment. I may want someone to start reading a whole section with my link and in that case highlighting a segment makes no sense.
I don’t know why we have to reinvent how people use the web. Putting an anchor in a link is a normal thing. Clicking on a link with an anchor in it and being taken to that spot is a normal thing.
What is not normal is changing the page layout based on having an anchor in the url.
I think there was some good intentions behind being able to give people a link that would automatically show the Pali as well as the translation (which is why we have those in the url as well) but I feel, in the end this is also misguided.
If a site is so difficult to use that you have to manipulate links to make up for lack of user understanding, then fix the site so it is easier to use. Or educate. Don’t mess with things via links.
Don’t assume that the sender of the link is any more skilled than the receiver of the link.
I don’t think we should be using GitHub as a standard of UI/UX. It’s far too technical of a domain to compare to. But I appreciate your research.
GitHub also has an anchor syntax for sending people to a range of lines, in which case it highlights the full range.
But I agree: users of SuttaCentral are both less tech savvy on average than a GitHub user and are using SuttaCentral less often, thereby having less time to learn its idiosyncrasies.
And the intent of an anchor link is obviously to send to that part of the page. If some layout change is needed to make that entire part visible, that’s a different beast than making an unnecessary settings change.
No, it’s basic, because it speaks to the conceptual confusion of what we want to show. Changing what the receiver wants to see by default should not affect what the sender wants the user to see.
Obviously the user must have a way to turn off the refs if they don’t want them. This is clearly a bug. But they should not have to change their default settings because someone else sends them something in a particular form. What they should have is a control that lets them revert to default settings from whatever the user sends them.
? That’s not what happens. What happens is that the page layout is determined by the URL, so that the sender sees is the same as that seen by the receiver. And this is because it might be relevant. The sender says in an email, “see what this note says on this Pali” and sends a link, and if the receiver sees their default view—just translation with no notes and no Pali—then it’s a mess. The sender should be confident that the receiver sees the same thing. One URL, one view.
As for this behavior, for the life of me I can’t recall why this is so, or even if it’s designed or just an artefact. It seems to me that only the ref should be highlighted.
The distinction here is that the URL does not specify the display details:
https://suttacentral.net/mn2/en/sujato#mn2:2.1
In this case, since the sender does not specify, the settings of the receiver take precedent. Which is what happens currently.
Obviously we’ll need to assess the UI, but FWIW I don’t think adding functionality to the ref numbers is a good idea: too much in too small a thing. It should be a dedicated control. Honestly shouldn’t be that hard.
I feel this is obfuscating the idea of user intent. The point is that the sender and the receiver see the same thing, not that the computer magically guesses the intention behind the keyboard.
FWIW I appreciate the perspectives, but any plan where the receiver sees different content to that sent by the sender is a non-starter.
Again, this is obviously a bug. You should be able to:
turn on the refs to see the anchor
click on it to get the URL
turn off the refs
copy the text
In fact, there should probably be a more streamlined way of doing this whole procedure. Perhaps a “share” widget with various options.
No, this doesn’t happen currently, that’s the crux of the bug. An anchor in the URL turns on references and makes them untoggleable via the UI and keyboard.
Here’s a quick screenshot from my phone of that same link to MN2:2.1 :
My references are off, per the screenshot, yet they are still showing up due to the anchor. Toggling references has no effect anymore. The reference= query parameter has no effect either. As in, these three are currently identical with respect to displaying references:
All three behave as if they were reference=main currently.
In the specific instance of a segment anchor in the URL, the reference query parameter and setting is ignored. References are always turned on due to the anchor.
Partially, that seems to stem from the short ID variant (#1.1) only highlighting the ref number, which doesn’t exist when references are off (nothing to highlight), so it flips them on, without a way to turn them off.
So there’s two parts to it:
The anchor turns on references regardless of setting (query parameter and localStorage are both ignored)
The anchor cannot be removed without modifying the URL manually
Because of the two parts, there’s different behaviors that could fix it.
It sounds like you’re saying:
The reference= query parameter should control the display of references, with the anchor having no bearing on it.
If so, should there be no highlighting of #1.1 when references are disabled, either by query parameter or localStorage setting?
That doesn’t necessarily address the second part, as it resolves the bug enough that it doesn’t really matter anymore.
One could also address the second and not the first, e.g. by having toggling references remove the anchor from the URL
I think we can all agree on both, though I personally like the highlighting.
As in, I personally prefer the opposite, highlight the whole segment. That also makes it so the segment number doesn’t have to be displayed, as the text itself is highlighted, which solves the bug in a different way.
Oh okay. I guess in that case, since the URL does not specify a state, it’s reasonable to just show the user default.
Yes, that’s reasonable. Like I said, I can’t exactly remember why we introduced this, but maybe this is the reason.
There’s a couple of issues with this. One is that getting the styling working correctly in all instances may be tricky. But perhaps that’s already solved.
The other is, as hinted above, to do with the question of highlighting ranges. If you send a user to a specific reference number, it doesn’t visually have a lower bound, so it conveys “start here”. On the other hand, if you highlight the actual text passage, it sends the message, “this is where it starts and ends”. And often this is not what you want.
We actually implemented range highlighting in an earlier version of SC, but it ended up being brittle and complicated so we forgot about it. Technically, it’s also made redundant by the “text fragment” spec.
Perhaps this can be solved by using the method found in a few of the examples sourced above: show the highlight then fade it out.
The way I see it, we can’t assume intention on the part of the sender.
In the case of linking to a segment, the only way for me as a sender to create a link to the segment is to turn on the segment numbers. I probably don’t care if the receiver sees those numbers.
As well, the sender may always have the notes and/or segment numbers turned on and the intention behind sending the link may have nothing to do with the notes. But now suddenly as a receive I’m seeing notes and numbers everywhere.
I realize that I may be making the case for a “sending mode” interface, lol. But I’m not sure if that complication is worth it.
Why? Imagine a sender that has the Pali turned off. But the receiver always has the Pali turned on. As it stands now, I think that the sender’s English-only setting (which really isn’t a setting, it’s just the default) will (temporarily) override the receiver’s English-Pali setting. So they will have to turn the Pali back on for themselves. If the defaults weren’t put in the URL this wouldn’t happen.
I think we are all onboard with this being a bug. But I guess folks are keen to really figure out how the whole thing should work. If someone has to re-figure out how the code actually works, might as well fix everything while the patient is open on the operating table.
