osara
osara copied to clipboard
jcsteh
Ability to toggle complete speaking of position on/of
Thanks Jamie for reminding me to post this as a new issue. I thought I already had but was apparently wrong!
Currently Osara speaks only the part of the position / time info that is unchanged. I sometimes find that this incomplete feedback is misleading when moving to a new position and can lead to confusion. I understand this saves speech feedback for some but would like the ability to have the entire time spoken after using such navigation commands. Perhaps a toggle for this could be added to the Osara configuration settings.
--Pete
Note that this option (as specified) would also impact reporting of lengths when growing/shrinking items, etc. Is that your intent?
I did not realize that, but my gut feeling is that it could be useful to hear how the length of an item is changing as one is growing or shrinking the item. Since I rarely do that I would defer to the opinions of other’s.
As a side note, I don’t know if I am an unusual user or not, but even after using a screen reader for nearly 30 years I still keep my verbosity to “intermediate” rather than “advanced”. I just like having the additional feedback and tend to tune out what I don’t want to hear or when I think I’ve heard enough. That can sometimes be a problem when my wife is telling me something and I can’t fast forward! 😀
From: James Teh @.> Sent: Sunday, December 5, 2021 2:03 PM To: jcsteh/osara @.> Cc: ptorpey @.>; Author @.> Subject: Re: [jcsteh/osara] Ability to toggle complete speaking of position on/of (Issue #613)
Note that this option (as specified) would also impact reporting of lengths when growing/shrinking items, etc. Is that your intent?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/613#issuecomment-986299842 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJJM55R6XIQWMFGBZRLUPPHP7ANCNFSM5JNGDYZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
it could be useful to hear how the length of an item is changing as one is growing or shrinking the item.
That's already reported. What would change is the style of the report. Right now, it's our usual style where only the units that have changed are spoken. What Jamie's saying is that having this option enabled would result in the full time of the new position being reported whenever an item edge is moved. To me, it seems hideously unproductive to hear say minutes, seconds and milliseconds if I've only moved an item boundary by a few MS. Ditto hearing bars, beats and percentage of beat if I've made a slight change that only effects the smallest unit. Sorry to be a naysayer, but I'm not grasping why this is needed yet, because users can already query two formats of their choice in full with Control+Shift+J.
Yeah, that's the one unanswered question for me too. I can see why you'd want this option if you didn't have control+shift+j... but as I noted, with control+shift+j, you get the benefit of querying this info easily without the loss of efficiency for every command.
Yeah, that's the one unanswered question for me too. I can see why you'd want this option if you didn't have control+shift+j... but as I noted, with control+shift+j, you get the benefit of querying this info easily without the loss of efficiency for every command.
[PT] For me querying the actual position with control+shift+J is the added inefficiency! I guess it depends on your point of view.
I do take Scott’s point in his previous message though, about not wanting to hear the full position each time one grows or shrinks an item by a small amount. In fact in that latter case I would probably rather hear the delta change in length.
--Pete
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/613#issuecomment-986324365 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJJZWHJNOEJYIVQTRWDUPPZZVANCNFSM5JNGDYZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub .
Okay, so if you'd rather here the delta for changes in length (and I assume growing/shrinking start/end position), that raises the question: for which exact groups of actions do you want full reports and which not? I guess you want full reports for moving by bar and beat. What about scrubbing? Those are very small units.
Okay, so if you'd rather here the delta for changes in length (and I assume growing/shrinking start/end position), that raises the question: for which exact groups of actions do you want full reports and which not? I guess you want full reports for moving by bar and beat. What about scrubbing? Those are very small units.
[PT] I always do scrubbing with my ears and never found it useful to hear exactly where I am, so I’m not the best one to ask about that. If I had to take a guess I would guess that, especially when making many small movements at a time such as when scrubbing or growing/shrinking items, if people do want feedback the minimal feedback would be more useful. When moving by larger amounts such as by bar/beats, minutes/seconds, beginning/next selection point, etc. I personally like the more complete feedback that informs me of the exact location.
How about if there could be a setting to always speak full positions or always speak partial positions no matter what the actions? There is already an Osara setting to "report position while scrubbing" (or not), so that case does already have some aditional flexibility.
I still like the idea of a screen reader providing the complete info that a sighted user gets without having to hit additional hotkeys as a base option, but can see how some more advanced users or users with a quick work style would prefer more truncated feedback in some circumstances.
Sorry to bring this one up again, but it continues to really bug me and often makes me think twice and/or get confused after certain actions are taken because of the incorrect feedback spoken. I'm hoping we can give this another look.
I understand why some folks like the truncated feedback given when navigating, but when my speech synthesizer gives incorrect feedback as a default, it doesn't seem good. So I would still like to see a preference in Osara to toggle complete / truncated feedback of position when navigating.
I often work in hours/minutes/seconds format. I may also have markers, regions, and edit cursors set at differnt positions. If I hit the Home or Apostrophe key and hear "45 seconds" it makes it sound like I somehow went back to the beginning of a project. Makes me think twice and causes a hiccup in my work flow. Yes, perhaps I should keep track in my head which minute I have been editing in for the past bit of time, but after making a number of small edits one has often cached that out of their mind by then. Thus when I hear '45 seconds" instead of (10 minutes 45 seconds" I think "oh no, where am I now?".
Another place where the current feeback gives incorrect information is when moving, for example, from bar 30 beat 2 to a marker that might be at bar 4 beat 2. Making this motion seems to inicate that the user has moved to bar 4 instead of bar 4 beat 2 since only "bar 4" is spoken. Again, the advanced or very careful user might assimilate this feedback properly, but it is not correct and can often lead to confusion or errors.
There was some discussion in this thread about which navigation options should one include in this toggle. Rather than decide or make every navigation option a toggle (such as scrubbing, lenghtening items, etc.) I would suggest that the toggle apply to all navigation. If someone is routinely hering too much they can always hit the Escape key or toggle on the truncated feedback. Just a thought, don't know if that addresses the question satisfactorily.
Anyway, I understand the reluctance to putting in too many configurable preferences, but my thought is that the default behavior of a screen reader should give accurate information. If less complete information is desired that should be the option
Again, sorry for bringing this up again, but I thought it was worth some further consideration.
--Pete and not the default.
IMO scrub, item edges and time selection boundary adjustments should only report the smallest unit of change even if we introduce such an option. Full reports any time the user makes such slight adjustments would make that feedback spurious jabber that would be insanely slow to consume during those workflows. I wonder whether there'd be any mileage in some sort of threshold that triggers a full report? Hmm, dunno how we could make that elegant with the amount of ruler formats on offer though. Maybe if anything other than the smallest unit changes, we'd report in full? Does a quick tap of Control+Shift+J not do enough to allay your confusion?
Also, a small but I think important point. we're not talking about incorrect feedback here. The feedback isn't incorrect, it's contextual by design. I appreciate the design isn't working quite right for you yet, fair enough, but it's not incorrect feedback.
IMO scrub, item edges and time selection boundary adjustments should only report the smallest unit of change even if we introduce such an option. Full reports any time the user makes such slight adjustments would make that feedback spurious jabber that would be insanely slow to consume during those workflows.
[PT] I can certainly buy into that. However, navigating by bar/beats, markers, regions, etc. wouldn’t generally suffer from too much feedback in the same way. Actually I’m surprised that even scrubbing would suffer from that problem since hitting a key should cut off any previous speech like hitting control does and one would hear the last position landed on in full.
Does a quick tap of Control+Shift+J not do enough to allay your confusion?
[PT] I think what is getting me here is that I have a quick sequence of actions in my head that I want to take after navigating. After the navigation, however, I hear some incomplete and misleading information that gets me to think “now, wait a minute…Did I move properly?”. So yes, one could hit control+J or take my hands off the keyboard to read the position on the braille display, but it is sort of like stumbling on a crack in the pavement when you’re trying to jog. Definitely slows me down, but maybe that’s just me.
we're not talking about incorrect feedback here. The feedback isn't incorrect, it's contextual by design.
[PT] Not to be disagreeable here, but what exactly is the “context”…partial position? If I move from page 22 to page 23 in a text document I wouldn’t expect my screen reader to tell me that I moved to page 3!
Anyway, I don’t think it is worth belaboring the point any more. I’ve tried to outline the various reasons that I find this behavior uncomfortable, but if the consensus is that folks are okay with it then that is fine with me. I can appreciate both sides of the issue and we do have limited resources.
--Pete
it is sort of like stumbling on a crack in the pavement when you’re trying to jog. Definitely slows me down
Sure, I can see that. Maybe this doesn't come up for me as often because I'm almost always in bars/beats here.
If I move from page 22 to page 23 in a text document I wouldn’t expect my screen reader to tell me that I moved to page 3!
That's not what's happening. Let's say you're navigating a book. If you move between lines on the same page of your text document, would you rather here "line 27" and have a means of querying for wider context if needed, or be force fed "line 27, paragraph 3, page 83, chapter 5, book title"? Hopefully the above illustrates that the design isn't partial position, it's intended to provide contextual feedback as productively as possible.
Anyway, I don’t think it is worth belaboring the point any more
C'mon now, don't roll over so easy. Let's at least see whether the bigger brains think there's any mileage in my half-baked threshold thought and give @jcsteh a chance to remind me that he prefers thoughts to be properly baked on delivery. :)
Just for the avoidance of doubt, I'm not claiming the rub isn't real for you by pushing back on these points, it's about exploring the nitty gritty and identifying whether there's a solution we can introduce to improve the situation without creating additional edge cases going forward. Limited resources doesn't mean we can't do anything, but it does mean we have to make sure that whatever we do do is smart.
To put in my two cents I have found this issue has come up when working on movies. Sometimes because we’re dealing with hours you can get a bit confusing which hour you’re in as the information isn’t delivered all the time. Other than that though with bars and beats it hasn’t been a problem for me
Sent from my iPhone
On 22 Mar 2022, at 9:54 am, ScottChesworth @.***> wrote:
it is sort of like stumbling on a crack in the pavement when you’re trying to jog. Definitely slows me down
Sure, I can see that. Maybe this doesn't come up for me as often because I'm almost always in bars/beats here.
If I move from page 22 to page 23 in a text document I wouldn’t expect my screen reader to tell me that I moved to page 3!
That's not what's happening. Let's say you're navigating a book. If you move between lines on the same page of your text document, would you rather here "line 27" and have a means of querying for wider context if needed, or be force fed "line 27, paragraph 3, page 83, chapter 5, book title"? Hopefully the above illustrates that the design isn't partial position, it's intended to provide contextual feedback as productively as possible.
Anyway, I don’t think it is worth belaboring the point any more
C'mon now, don't roll over so easy. Let's at least see whether the bigger brains think there's any mileage in my half-baked threshold thought and give @jcsteh a chance to remind me that he prefers thoughts to be properly baked on delivery. :)
Just for the avoidance of doubt, I'm not claiming the rub isn't real for you by pushing back on these points, it's about exploring the nitty gritty and identifying whether there's a solution we can introduce to improve the situation without creating additional edge cases going forward. Limited resources doesn't mean we can't do anything, but it does mean we have to make sure that whatever we do do is smart.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
Maybe that is the reason I am more sensitive to these issues than most of the folks who commonly use bar/beats format, since I also more often work in hours/minutes/seconds format for the work I do. There can be different needs for different work flows.
--Pete
From: mattymc2 @.> Sent: Monday, March 21, 2022 8:05 PM To: jcsteh/osara @.> Cc: ptorpey @.>; State change @.> Subject: Re: [jcsteh/osara] Ability to toggle complete speaking of position on/of (Issue #613)
To put in my two cents I have found this issue has come up when working on movies. Sometimes because we’re dealing with hours you can get a bit confusing which hour you’re in as the information isn’t delivered all the time. Other than that though with bars and beats it hasn’t been a problem for me
Sent from my iPhone
On 22 Mar 2022, at 9:54 am, ScottChesworth @.***> wrote:
it is sort of like stumbling on a crack in the pavement when you’re trying to jog. Definitely slows me down
Sure, I can see that. Maybe this doesn't come up for me as often because I'm almost always in bars/beats here.
If I move from page 22 to page 23 in a text document I wouldn’t expect my screen reader to tell me that I moved to page 3!
That's not what's happening. Let's say you're navigating a book. If you move between lines on the same page of your text document, would you rather here "line 27" and have a means of querying for wider context if needed, or be force fed "line 27, paragraph 3, page 83, chapter 5, book title"? Hopefully the above illustrates that the design isn't partial position, it's intended to provide contextual feedback as productively as possible.
Anyway, I don’t think it is worth belaboring the point any more
C'mon now, don't roll over so easy. Let's at least see whether the bigger brains think there's any mileage in my half-baked threshold thought and give @jcsteh a chance to remind me that he prefers thoughts to be properly baked on delivery. :)
Just for the avoidance of doubt, I'm not claiming the rub isn't real for you by pushing back on these points, it's about exploring the nitty gritty and identifying whether there's a solution we can introduce to improve the situation without creating additional edge cases going forward. Limited resources doesn't mean we can't do anything, but it does mean we have to make sure that whatever we do do is smart.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.
— Reply to this email directly, view it on GitHub https://github.com/jcsteh/osara/issues/613#issuecomment-1074629981 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADEPTJPQZACIXO6KDCFLORLVBETEZANCNFSM5JNGDYZQ . You are receiving this because you modified the open/close state.Message ID: @.***>
Honestly, I don't have strong feelings about what we do specifically here. I'm happy to add an option since it does seem there are multiple users with valid reasons for wanting this. However, whatever we do has to be:
- Well scoped. We either do this for all time reporting actions or we need to clearly define which ones we do it for and why.
- Consistent. Anything that isn't consistent is likely to be unintuitive. The current behaviour might not be workable for some people and that's fine, but it is absolutely consistent: we don't report a unit unless it changes. Doing a full report for all other units except the smallest feels risky to me. If the option is "Report full time for all time movement" or similar, how does the user understand that it doesn't do that for the smallest unit?
- Well defined and described. Following on from the last point, we need to be able to explain the option to the user, both in the documentation and in the configuration dialog. We can't have an option name which only explains half the behaviour, leaving the remaining behaviour to surprise the user.
If you can tick off all those three points without ambiguity, I'll be happy to approve this. Implementing it is a separate question.
Okay, I’m certainly not as well versed in all of the functions this might affect and/or how they are used by most folks, but let me try and give a first crack at addressing the concerns you rightly raised:
- Well scoped. We either do this for all time reporting actions or we need to clearly define which ones we do it for and why.
[PT] One proposal is to give full feedback for action commands, i.e., moving by bars/beats, markers, regions, beginning/end of project, etc. Actions such as growing/shrinking item lengths aren’t really “navigation” or “movement” actions. Scrubbing is probably in a gray zone, but there is already an Osara action to not speak while scrubbing.
Another alternative might be to offer full feedback for all of these commands. This preserves the current functionality for users who prefer less feedback or like to work that way while offering an alternative to others who prefer the more complete feedback. Although this could get frustrating for folks scrubbing or changing the lengths of items which require many quick keystrokes in succession, hitting keys with a screen reader usually truncates the last speech output and people who chose this option would hear a lot of chatter, but the last thing spoken would be the final result. Maybe not perfect, but seems workable. Again, there is already an Osara option to silence speech when scrubbing. If people don’t like this they can still use the current mode as a preference.
- Consistent. Anything that isn't consistent is likely to be unintuitive. The current behaviour might not be workable for some people and that's fine, but it is absolutely consistent: we don't report a unit unless it changes. Doing a full report for all other units except the smallest feels risky to me. If the option is "Report full time for all time movement" or similar, how does the user understand that it doesn't do that for the smallest unit?
[PT] Agreed, setting a “smallest threshold” doesn’t seem like a good idea. People will always wonder “what is mall?” and there is no right answer depending on workflow and preference.
- Well defined and described. Following on from the last point, we need to be able to explain the option to the user, both in the documentation and in the configuration dialog. We can't have an option name which only explains half the behaviour, leaving the remaining behaviour to surprise the user.
[PT] Agreed, consistency is very important. I think that describing this preference as giving full feedback for navigation hotkeys might describe this preference sufficiently. Again, I might not be aware of all of the use cases and subtleties, so I’m interested to see if this is a good starting point and what others think.
Thanks for your answers, @ptorpey . They seem reasonable to me, and given that we're now seeing others requesting this, I've attempted to implement this in #752.
This nice feature is working very well.
I did find, however, that when moving and selecting to an item using control+left/right arrow the truncated time is still being announced. Can we also make this movement/selection report the full time when this option is enabled?
Thanks.
--Pete
Ah, that's interesting. I guess that makes sense, though this raises the concern that now we have multiple different definitions of "time movement commands". For "Move relative to the play cursor for time movement commands during playback", we don't currently consider commands like item and envelope point navigation because there is additional state involved (the item or envelope point selection). But for this new option, we do want to affect item and envelope point navigation commands. And then there's "Report time movement during playback/recording", which has yet another definition because it also impacts changing item lengths, but we don't want to impact that for this new option. What a mess.
Also, the need to fix item navigation here has made me realise I'm going to need to completely re-think the way I've coded this. Damn.