So this is not the same as manually highlight certain text to start play from there, as it already works right now?

No, though they both allow the user more control over what to listen to. Solution 2 uses reuses functionality from the selection player, but with the difference that the playback won't stop when it reaches the end of the selection.

I've done some hacking just to see how this could work and have gotten some of the way there:

Looks like the most sensible thing probably is to extend the selection player with this functionality. Alternatively we could make a new module for this and break out the shared logic. Maybe even some abstract class, however that's done in JS.

I've also noticed a couple design things we need to figure out:

1. What happens to the play button when you start playing? We don't want it to cover the text as it does now.
2. How do you hide the play button if clicking anywhere in the text shows it? Maybe click one to show, twice to hide?

Not sure these need to be solved perfectly in the first implementation, but worth to think about.

Looks good! I would also suggest that the best approach is to extend the existing selection player with this functionality, if possible.
However, if it turns out to be too complex, then creating a separate module might be a better alternative.

That said, I’m starting to think that a better user experience could be achieved by having a player button appear when the user clicks anywhere in the text.
The button could say something like "Start playing from here", and when clicked, playback would begin from that point and the button would then disappear?

That said, I’m starting to think that a better user experience could be achieved by having a player button appear when the user clicks anywhere in the text.

Yes, that's what's happening in the video 🙂 It's not very clear since you don't see when I clicked. This wasn't an alternative in the description, but I added it now.

The button could say something like "Start playing from here", and when clicked, playback would begin from that point[...]

Do you think there needs to be text rather than just the play icon?

[...]and the button would then disappear?

That's one way of doing it. You'd lose the possibility to stop or pause, but maybe that's not a big deal in this case. If you keep listening and follow the text the button will eventually go off screen anyway.

Another possible way of doing it would be to put the button above the text instead of below. Then it should only cover text before where you start which should be less important. At least for any language I've seen, don't know if there are ones that go bottom up.

Do you think there needs to be text rather than just the play icon?

Maybe, but that means that more text will appear on the screen, and I am not so sure if that is user-friendy.. Either way, I think the "button" that appears should clearly be signaling that: "Do you want to start playing from here?"

[...]and the button would then disappear?

That's one way of doing it. You'd lose the possibility to stop or pause, but maybe that's not a big deal in this case. If you keep listening and follow the text the button will eventually go off screen anyway.

But won't the user be able to stop or pause in the regular playback?

Another possible way of doing it would be to put the button above the text instead of below. Then it should only cover text before where you start which should be less important. At least for any language I've seen, don't know if there are ones that go bottom up.

To put the button above the text is a quick and effective solution I think! Maybe this is something we should discuss with Begripsam's accessibility experts?

! In T182289#11394901, @Viktoria_Hillerud_WMSE wrote:
[...] Either way, I think the "button" that appears should clearly be signaling that: "Do you want to start playing from here?"

I wonder how you could do this. You could do something with highlighting, but that would off course only work if you have highlighting on.

I think this is one of those things that once you've done it you'll probably remember and maybe don't need extra information. Maybe making sure that the help page is good enough is fine.

But won't the user be able to stop or pause in the regular playback?

Yes and that might be enough.

To put the button above the text is a quick and effective solution I think! Maybe this is something we should discuss with Begripsam's accessibility experts?

Yes, I think that this is definitely something we want tested. For the first version we just want it to make some sense and don't go to far down into rabbit holes trying to figure out anything perfect.

The introduction of asynchronous logic (to make sure token information is loaded) caused some headache when I was writing tests. I ended up with something that I think is the third way of doing among our tests. May be worth having a look at using the same method for all of them.

Another thing I realised now is that this causes a delay between clicking and the button showing up if the utterances isn't loaded, especially if it needs to be synthesised first. There should be some indication for this. Maybe change the mouse cursor to "progress" and maybe showing the buffer animation. The latter may not be as relevant in this case since the focus is not on the player.

I don't think there's any way around this except for loading all utterances at the start, which isn't reasonable.

I think changing the mouse cursor to "progress" and the buffer animation sounds like a good idea.

And regarding loading utterances: is it not good to load all utterances at the start because of loading time and performance?

Yes, it would require making sure that all utterances are synthesised, which could take a while depending on if the page has been visited before and how long it is. It would also mean that you download the data for all the utterances and the audio could be quite a bit if it's a long page.

It would be possible to only download the token information initially (with some changes to the API). This would still require all utterances synthesised so I'm not sure how much it'd help. You can probably do a lot with this, like loading utterances for text currently shown, but I think we can save that for future improvements.

I realised that we don't need to load the utterance. The segments have the information about nodes which should be enough to see if where you click is something that can be played.

It's tricky to know when you actually click on a piece of text. Using getSelection() gives a selection even if you click outside a node.

For instance clicking between two paragraphs will give you the end of the first one or the start of the second one. This can be helped a bit by checking if the clicked element is a parent of the selected node. If not it means you actually clicked something higher up in the DOM.

Another similar issue is when you click the empty space after the text. This happens at the end of a paragraph when the last line doesn't go the width. I found that this can be avoided by checking if the anchor offset is the same the length of the node.

This is handled differently for different browsers. For instance the solution for the second issue works in Firefox, but not in Chromium. It's apparent that the browsers have some way of detecting when the mouse is over the text itself and not the element since it changes mouse cursor, but I haven't found anywhere to access this information.

I think we'll have to accept a bit of weird behaviour for the first implementation of this. If there are certain interactions that people find annoying we can look into those more.

I agree that it makes sense to accept a few small issues in the first version, especially since text interactions can work so differently in different browsers. And since we don’t really have a good way to test in Safari, I guess there will always be some edge cases we can’t catch right away.

The most important thing is that it works well for most users, and that we can get feedback if something doesn’t work. If we fix problems as they come up and listen to what users say, I think this is a good plan for now.