List of speech modes which can be switched to with NVDA+S should be made configurable #15806
Comments
|
I like in general this idea, However, there is a risk with these checkboxes: imagine a new user disables by accident the speech mode speak and presses nvda+s afterwards, NVDA would change to one of the less verbose or no verbose modes. There is no way of enabling the speak mode again unless you know the menu structure by hard and you know how many times you have to tab around to include speech mode speak again into the nvda+s command. |
|
I agree that checkboxes for all speech modes are required including an ability to check and uncheck no speech mode since user might want to toggle between speech and speech on demand. By the way, are there any examples when beeps speech mode might be useful? I was always curious about the cases where it could be used. Thank you! |
|
yes they are very useful especially when you work in virtual enviroments where you have two sessions of NVDA running but are not allowed to use the NVDA remote addon. Or when you are in a meeting and you just want to be notified when something pops up without speech. |
The user can just restart NVDA in that case, as when NVDA starts it always defaults to the 'speech' mode.
What if I do not need the full speech mode as described in the original comment? In its current form synth settings ring is really slow to use, since there are way too many parameters in it to be practical, and therefore I would be very reluctant when considering adding into it. Another, much simpler alternative would be to enforce that either speech mode full, or speech on demand has to be enabled when configuring enabled modes.
When monitoring long console (that is not having a standard beeping progress bar) processes, the beep mode is quite useful to know if something is still happening, or if there is no new text in the console. |
|
I like the list of checkboxes idea. Maybe it could include all modes (on, beeps, on-demand, off), all initially checked, and with "on" not uncheckable; for me, it'd be a compact and clear solution. Sure, with just "on" checked the switching feature loses sense, but I'd not introduce a condition about that. |
This however results in loss of current focus position in many cases.
I agree to a certain extent, however I think your point can be easily solved. a checkable list which let me include or exclude categories in or from the settings ring would be much more useful than a checkable list of speech modes to be included into a command.
Could you explain this in more detail? How would that look like in practice? Let's say I enable speech on demand which in turn allows me to enable other speech modes but I don't enable speech mode speak, then I am still lost as a novice user unless I press everytime a command to report the currently focused element until I find the propper checkbox to enable speech mode speak again. |
|
I am still not 100% convinced that this feature needs to be in core and add more options in the default GUI. Anyway, if this choice is made, I think that the checkable list is a good solution. As for NVDA keys, a validation mechanism should be implemented. In the speech mode case, the mechanism should check that at least two boxes are checked since there is no point in checking only one; also, the full speech box should always be selected because I do not imagine any use case where a user would switch between speech modes without having one being the full (normal) speech mode. I have also thought to an alternative simpler solution:
|
Is this at all possible in WX Python 4.1? I didn't see any interfaces with such validation made with this wrapper. Anyway, this is I guess even more complex to implement than only two check boxes which alow to include or exclude on demand mode and beeps mode.
I agree. So in this case we don't need a checkbox for this at all.
This doesn't sound very intuitive to me. But I also don't have a better idea in mind.
I think there are lots of users who would prefer to have both on demand and off speech mode included. |
Are there any particular reasons against this feature, or is it just being careful with what is being added in to the GUI? In general terms do you agree that if something is as commonly used as NoBeepsSpeechMode it should be included into the core?
Wouldn't it be sufficient to verify that at least one of full speech and speech on demand is included? I still believe that for magnification users (which was the primary motivation for #481 and, closed as a duplicate, #5948) speech on demand can be the primary mode of working, and therefore they may want to switch between it and either no speech or beeps, yet full speech is unnecessary for them.
I do not think we can safely make that assumption. |
I am actually a bit worried to add more and more controls in the GUI. And especially to add 2 checkboxes or one checkable list only to configure a 3-value (or soon 4-value) toggle command. This seem to add complexity to a single toggle command. On the opposite, there is not (yet) the possibility to customize natively the synth ring setting selector (available parameters and available values for each parameter), where this would probably be more useful.
I do not know if the add-on is commonly used. But I imagine at least that the majority of people never use the "beep mode" and only switch between speech and no speech.
On the contrary to what I wrote before, it's true that some people may not need the full speech mode. But will these people using magnification ever use no speech mode?
I have no issue with using a checkable list control; it was just an alternative proposal. Note that even if my comments seem quite reluctant for this issue, I am not actually opposed to its resolution in NVDA core. I acknowledge that there is an expectation to improve the NVDA+S UX. |
In general screen readers other than NVDA are pretty configurable, and this lack of configurability is often brought up as NVDA's disadvantage. While adding controls to customize a single keyboard command may seem redundant, I'd say a starting point here should be:
Answer for 1 seems to be no, and no one proposed a change here which would improve the situation without GUI changes.
I certainly agree this is much needed.
I don't think this should be considering customizing all cycling commands - only these for which you need to perform a quick change, and this change cannot be done in other ways (if you for instance need to quickly switch between two particular punctuation levels you can have a profile with the lesser commonly level set, and add a keyboard shortcut assigned into it).
I am not a magnification user, so I'm not the best person to judge this. In general I dislike excluding options just because we cannot propose a clear use case for them right now, but may be just me :-)
To be clear that is how I understood your comments and questions from the beginning. In the retrospect the easiest option would be to assign a different command to the beeps mode, and leave NVDA+s to switch between speech and no speech, but there is way too late for this now. |
seanbudd
added
p5
|
So we have 3 proposals on the table in my view:
I am still in favor of approach 3 because it is a sustainable UX design which we can build different use cases upon. Users can get used to this approach if a good explanation in the user guide and other communication channels is in place (i.e. a list of settings that provide more toggling states in the ring than in their assigned key command). |
Why should this be a hard requirement for improvements? Changing the GUI in certain ways is not bad per se. |
|
@CyrilleB79 wrote:
However, my feeling is that it's not easy to find a good solution (both in the GUI and in the User Guide description), so that the majority of people
understand the GUI and actually use it for their needs. We should not end up with one or two more controls in the GUI but people still bothered by the beep
mode that they do not use.
While that is reasonable, it is also a case of the perfect being the enemy of
the good.
We won't find a perfectly pleasing solution for this, only one that meets the
need in some way. Not even trying to meet the need because we can't find a
solution that pleases the most number of people, isn't progress.
We simply can't know what arrangement of options will be the most useful to the
most people, the most user friendly to the most people, and the least intrusive
to the people who don't care.
We can only try something the best we can, and learn from how people react.
|
|
@Adriani90 wrote:
So we have 3 proposals on the table in my view:
You missed one:
4. Providing a checklist of four options, covering all of the possible speech
modes.
This is the one I favor--since if we are doing this I would like to turn off the
"off" option, and @lukaszgo1 thinks we need to include turning off the "speech"
option for magnification users who have to keep NVDA running in the background
apparently.
1. Enhancing the settings ring, allowing users to add settings from the GUI to the ring or remove them.
While I agree this would be most ideal--it is, after all, essentially the iOS
Voiceover rotor--there are two serious problems.
First, if the option doesn't exist in the GUI, it wouldn't be able to be added
in your proposal since it isn't a GUI option. If only GUI options are addible,
then we are back to implementing 1, 2, or 4 anyway, and we might as well do
that first.
* Disadvantages: higher effort to implement
Second, it is not just higher, but an order of magnitude higher. This would
require a redesign of the GUI backend on the order of complexity of the add-on
store, I suspect. So much so that, were we to do it, it would essentially
provide a basis for an easy solution to #872.
Just read through the comments on #872 if you want to get a glimpse of how
difficult this proposal would likely be, even though it would be highly
desirable.
|
|
i am voting for checked list with all of the modes except speech mode
to be unchecked if user doesn't need this particular mode.
…On 11/22/23, Luke Davis ***@***.***> wrote:
@Adriani90 wrote:
> So we have 3 proposals on the table in my view:
You missed one:
4. Providing a checklist of four options, covering all of the possible
speech
modes.
This is the one I favor--since if we are doing this I would like to turn off
the
"off" option, and @lukaszgo1 thinks we need to include turning off the
"speech"
option for magnification users who have to keep NVDA running in the
background
apparently.
> 1. Enhancing the settings ring, allowing users to add settings from the
> GUI to the ring or remove them.
While I agree this would be most ideal--it is, after all, essentially the
iOS
Voiceover rotor--there are two serious problems.
First, if the option doesn't exist in the GUI, it wouldn't be able to be
added
in your proposal since it isn't a GUI option. If only GUI options are
addible,
then we are back to implementing 1, 2, or 4 anyway, and we might as well do
that first.
> * Disadvantages: higher effort to implement
Second, it is not just higher, but an order of magnitude higher. This would
require a redesign of the GUI backend on the order of complexity of the
add-on
store, I suspect. So much so that, were we to do it, it would essentially
provide a basis for an easy solution to #872.
Just read through the comments on #872 if you want to get a glimpse of how
difficult this proposal would likely be, even though it would be highly
desirable.
--
Reply to this email directly or view it on GitHub:
#15806 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
--
with best regards Beqa Gozalishvili
Tell: +995593454005
Email: ***@***.***
Web: https://gozaltech.org
Skype: beqabeqa473
Telegram: https://t.me/gozaltech
facebook: https://facebook.com/gozaltech
twitter: https://twitter.com/beqabeqa473
Instagram: https://instagram.com/beqa.gozalishvili
|
As discussed above, this will introduce a risk of disabling full speech mode and causing especially novice users to get lost. Especially when a visual impaired person works together with a blind person on the same machine. But I adjusted my proposal 1 to include 3 instead of 2 checkboxes.
Thatt's not entirely true. Implementing 3 would mean we have to implement a combo box in which you can choose the speech mode in the GUI, but at the same time it allows you to add this combo box to the settings ring. We don't have to deal with checkboxes which include or exclude things from a key command. What I wanted to say is that the key command contains less options to switch through than the settings ring or the combo box in the gui.
I don't think this will give a good basis for that, because including settings to the ring or not does not imply the development of a basis for an algorythm for providing most relevant search results. However, this is a completely different issue. |
|
I, personally don't think adding this to the synth settings ring is a good idea. it will make it complicated even more. Checked list with validation that one of speech capable mode is selected is the only way to go i think. |
|
First of all, it won't break a backward compatibility for users. Frankly speaking, I don't understand points @Adriani90 is trying to rise and make things more difficult. |
|
@Adriani90 wrote:
As discussed above, this will introduce a risk of disabling full speech mode and causing especially novice users to get lost.
I agree with you and don't think Speech/Talk should be disablable, but
@lukaszgo1 appears to know of magnification use cases where that would be
required.
I don't think this will give a good basis for that, because including settings to the ring or not does not imply the development of a basis for an algorythm
for providing most relevant search results. However, this is a completely different issue.
I think you miss my meaning. I am not talking about the interface, or what is
done with it in the UI. I mean that in order to include every available
configuration option in the rotor, they will have to be exposed in some
codified, organized, unified way, and managed behind the scenes in a unified
way.
If we had all of that already, not only would your suggestion here be a lot more
easy, the most difficult part of #872 would be done as well--all you would need
to do is build a searching interface on top of it. Or, in this case, all you
would need is to expose the known options in a rotor.
Different interfaces, same basic problem, with likely the same solution in long
and drawn out back-end re-engineering.
|
|
If we try to do this in a list of checkboxes, we have at most three or four of them to represent the possible configurations. There are 14 possible configurations, if you eliminate duplicates (e.g. "beeps and talk" is the same as "talk and beeps"). Next if you further assume that no single option configuration is acceptable--require the user to have two modes enabled at all times--then there are 10 possible options:
Furthermore, I think we can safely eliminate the "Beeps and off" option as worth including. But still, that leaves us with nine possible states. |
|
Given most people seems to favor the approach I proposed initially i.e. the checkable list of all the modes, and that we can reasonably simply protect users from disabling modes which should not be disable-able, I propose, and will submit a patch for this when #15804 is merged. If this approach turns out to be unsuitable, or perhaps synth settings ring is significantly improved, we can always move the option there, I feel it is way more important to start somewhere than waiting, possibly indefinitely, for improvements for it. If there is a lot of complaints about users who have disabled speech mode accidentally, we can also reconsider the decision of placing it on the list. My main motivation here is that other screen readers / systems allow such config, so there is apparently value in having it. |
My point with the combo box is not meant to include or exclude things from a key command, but to choose the desired speech mode as alternative to the ring if someone prefers to do it from the GUI. We only include things into the ring that are also visible in the GUI. This should remain the same even when the ring is enhanced.
I agree this is a good start over all. |
I agree with this approach which is pragmatic, the most easy to understand from users point of view and allows future improvement if needed. |
|
I must admit that I find the additional item in the speech modes cycle pretty annoying. When I want to toggle speech from talk to off, i have to press twice instead of once. Therefore i wholeheartedly second this proposal. |
…15873) Closes #15806 Summary of the issue: NVDA allows to change the currently used speech mode by pressing NVDA+s. By default this gesture cycles between 'talk', 'beeps', 'on-demand' and 'no speech'. For many users having ability to switch to beeps or on demand is unnecessary, and they have no need for modes different than speech and no speech. For other beeps mode is certainly useful, but it is much more important to be able to quickly switch between speech and no speech, so beeps mode just makes the goal slower to achieve. With the introduction of fourth speech mode in #15804 it has been decided that users should be given ability to disable speech modes they do not need to use. Description of user facing changes The new checkable list containing all speech modes (all are initially checked)has been added into the Speech settings panel. When switching between modes with NVDA+s only modes which are checked in the list are included. When applying settings selected modes are validated, to make sure at least two modes are checked. When the 'talk' mode is disabled user is warned that they may be left without any speech. Description of development approach Configuration spec has been expanded to store list of disabled modes - this ensures that if any new mode is added to NVDA it is enabled by default in the cycling script. Speech settings panel now contains a list of all the speech modes, only enabled one are checked. When introducing validation for the speech settings panel it has been discovered that code responsible for checking panel's validity displays a warning about it being invalid, prevents saving invalid config, yet after dismissing the warning settings dialog gets closed. Since this is not optimal validation for settings dialog has been modified, so that after warning is dismissed settings remain open, and the invalid control is focused. The cycling script has been modified to only cycle between enabled modes. Unit tests verifying its behavior, both when no modes are disabled (the default) and some are disabled, were added. To make them work it has been necessary to perform a small modification to the method which lists configuration profiles in the config module, it assumed that profiles directory always exists, which is not true in unit tests. Now when the directory is missing appropriate warning is logged, and empty list is returned. User guide has been expanded to describe newly added control.
and others
Is your feature request related to a problem? Please describe.
NVDA allows to change the currently used speech mode by pressing NVDA+s. By default this gesture cycles between 'talk', 'beeps' and 'no speech'. For many users having ability to switch to beeps is unnecessary, and they have no need for modes different than speech and no speech. For other, myself included, while the beep mode is certainly useful, it is much more important to be able to quickly switch between speech and no speech, so beep mode just makes the goal slower to achieve. With the potential introduction of yet another speech mode in #15804, I believe time has come to make this configurable in core.
Describe the solution you'd like
I suggest to add a new checkable list into the speech panel, labeled something like switch between the following speech modes, where all supported speech modes are placed. When switching using NVDA+S the unchecked modes should not be taken into account, this ensures that when any new speech mode is introduced it can be switched to by default.
Describe alternatives you've considered
Additional context
From the users complaints when .1 releases break compatibility with all of the add-ons, one of the more common ones is the fact that NVDA is the only screen reader where switching between speech and silence is impossible with a single gesture unless add-on is used. I strongly believe integrating small stuff like this into the core improves user experience tremendously, and makes .1 releases less of a pain point. The request not to have beeps when switching speech modes was common enough that the NoBeepsSpeechMode add-on was mentioned in the basic training material for NVDA, which should speak for itself regarding user needs.
The text was updated successfully, but these errors were encountered: