Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Redesign profile handling in NVDA so users can lock / unlock them #17409

Closed
Adriani90 opened this issue Nov 18, 2024 · 7 comments
Closed

Redesign profile handling in NVDA so users can lock / unlock them #17409

Adriani90 opened this issue Nov 18, 2024 · 7 comments
Milestone

Comments

@Adriani90
Copy link
Collaborator

Adriani90 commented Nov 18, 2024

Is your feature request related to a problem? Please describe.

Currently, changing settings in NVDA when more than one profile is created becomes complex, especially when more than 30 profiles are used. Settings have to be changed regularly on many profiles and this cannot happen at the same time so it's very inefficient.
In case of audio settings, e.g. the other apps volume adjuster does not work as expected, because the setting is profile dependent and so there is no way to change volume of all other apps except NVDA at once, because this has to be done on every profile for every application.
This problem is widely described in #17124 and the solution is currently not fully solving #16052, leading to wrong explanations in the user guide.
Other settings that are problematic with the current profile approach are e.g. the speech rate which often needs to be changed only temporarily, but sometimes also on a global scale and not on a profile scale.
Also ther are valid use cases when screen curtain should remian global and there are use cases when it should be profile based (see #10476 for more details).

Describe the solution you'd like

In #10156 the community came to the conclusion that introducing a lock/unlock feature to every profile is the best solution and easiest to implement. Locking a profile means the parameter written to the profileName.ini cannot be changed anymore and there is nothing else written to the profileName.ini, but to the global configuration instead.
User story:

  1. A user created 10 profiles
  2. A user wants to change the speech rate globally
  3. The user wants to change reporting of elements in document formating settings globally
  4. The user wants to change table related reportings in document formating settings for a profile only.
  5. The user want to use the applications volume adjuster and the sound split feature globally as this is the best user experience and coresponds to the descriptions in the user guide.
  6. The user wants to change punctuation level on a profile only
  7. The user want to change the synthesizer voice on 2 of the 10 profiles
  8. The user wants to enable screen curtain globally accross all profiles
  9. The user opens the profile manager after 10 profiles are created
  10. In addition to the current list of profiles status, an additional checkable list is displayed (e.g. lock / unlock profiles list) in which every profile item name is preceeded by the string "lock" and can be enabled via its checkbox. E.G. the profile items in this checkable list would look like:
  • Lock firefox profile checkbox checked
  • Lock WinWord profile checkbox checked
  • Lock Outlook profile checkbox checked
    By default all profiles are locked / all checkboxes in the checkable list are enabled, meaning that settings changes are always global) The parameter of the settings are not written to the profileName.ini file.
  1. The user unlocks some profiles by disabling the coresponding profile check boxes.
  2. From now on, every setting that the user changes is only applied for the unlocked profiles and the parameter is written to the profileName.ini files of the unlocked profiles.
  3. The user can lock the profiles again as soon as the changes have been done, and the coresponding profileName.ini files become protected.

Conclusion: on locked profiles, NVDA would use a combiation of settings parameters written to the profileName.ini file before, and the remaining global settings parameters which are not written to the profileName.ini file.

Problem: What happens when users focused e.g. Firefox and changed a setting (e.g. speech rate) on its profile which was unlocked before, and change that setting again after the profile was locked? In that case we would have two speech rate settings parameters, one on the global configuration and one in the Firefox profile.
Does NVDA prefer the global setting? Or does the parameter which was written to the profileName.ini prevail?

My suggestion to the problem above is:

  • In case the user changed the same setting (e.g. speech rate) both on the locked and the unlocked profile, let NVDA always prefer the global parameter when the profile is locked and the one in the profileName.ini when the profile is unlocked.
  • Provide a keystroke to unlock / lock the profile of the currently focused application (e.g. nvda+shift+p) in order to switch on the fly between use the speech rate parameter written in the profileName.ini file and use the speech rate parameter written to the global configuration.
  • Provide an additional keystroke to lock all profiles at once in order to efficiently change a setting globally in case many profiles were unlocked before (e.g. nvda+shift+ctrl+p).

Describe alternatives you've considered

None

Additional context

This feature would introduce the risk that users get confused because some of their settings are changed after an NVDA update since the profiles get locked (e.g. if they changed the speech rate both on a profile and in the global configuration).
However, this is not a big problem, users would just have to unlock their profiles in the profile manager dialog manually, or via keystroke, and the previous behavior is restored.

@Adriani90
Copy link
Collaborator Author

cc: @CyrilleB79, @XLTechie, @mltony, @Simon818, @rperez030, @pitermach, @TechHorseG, @Neurrone among people who would like this flexibility of deciding when global parameters and profileName.ini parameters are used.

@mltony
Copy link
Contributor

mltony commented Nov 18, 2024

@Adriani90, Regarding your example with Firefox and speech rate. One more feature I wish could be included is to clear Firefox-specific speech rate and make it follow global speech rate once again without deleting Firefox profile.
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox - but correct me if I'm wrong. Currently you would have to either drop the entire Firefox profile or manually edit ini files, which is way too tedious. I wish there was an easier way, but I am struggling to come up with a good UX concept for this feature that would be user-friendly.

@Adriani90
Copy link
Collaborator Author

Adriani90 commented Nov 18, 2024

One more feature I wish could be included is to clear Firefox-specific speech rate
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox.

There are two requests here:

  1. Reverting speech rate because you changed it accidentally
    Solution: if you didn't restart NVDA or you didn't save by pressing nvda+ctrl+c, then you can revert to the lastly saved setting by pressing ctrl+nvda+r, so the speech rate resumes to the value when you saved it for the last time. This should solve your issue actually. But yeah, if you want to make sure that only the speech rate is resumed, then have a look at Add temporary speech rate setting #16431, Jaws provides this already. The speech rate resumes as soon as you change the window and return back to it.

  2. Firefox profile speech rate follows global speech rate
    Solution: We have currently a list of profiles in the profile manager, this could be changed to a list similar to the addon store where every profile item would have a context menu. When opening the context menu of a profile item, following menu items could be available:

  • Follow global configuration (becombes "unfollow global configuration when following it). It is only available for unlocked profiles.
  • Mannualy activate
  • Rename
  • Delete

When following global configuration which would ofcourse work only on unlocked profiles, the settings changes on the global config would also be reflected in the Firefox profile ini file.

@Adriani90
Copy link
Collaborator Author

Note: if the decision is to have context menu on profile items, I would still vote for the checkable list of lock / unlock profiles for efficiency reasons. It would be a mess to open the context menu on every of the 30 profiles to unlock them.

@SaschaCowley
Copy link
Member

@Adriani90 would that not essentially be the same as deleting the profile and starting again? If we don't tell NVDA which settings you want to follow the normal configuration, then that option would essentially be telling it to reset the configuration to the normal configuration.

Personally, though more complex, I think the VO (and from memory Orca) solution of selecting categories to include in profiles makes the most sense. If a category is selected to be included, the any configuration from the profile in that category is used, otherwise the normal config values are used. If a category is excluded, the normal config is used.

@Adriani90
Copy link
Collaborator Author

would that not essentially be the same as deleting the profile and starting again? If we don't tell NVDA which settings you want to follow the normal configuration, then that option would essentially be telling it to reset the configuration to the normal configuration.

Not really, deleting a profile means you start really from scratch. Following the global configuration would practically happen only on a temporary basis, when you want to change just some settings but you don't want to focus three different applications.
In my suggestion you could open the context menu of 3 different profiles, choose to follow the global configuration, and you change the global configuration while this would reflect on three profiles at the same time. This is very efficient way of profile handling compared to what we have now or compared to VO or Orca. If you unfollow the global config, then the profiles are handled separately again.

Personally, though more complex, I think the VO (and from memory Orca) solution of selecting categories to include in profiles makes the most sense. If a category is selected to be included, the any configuration from the profile in that category is used, otherwise the normal config values are used. If a category is excluded, the normal config is used.

To me this sounds too general and doesn't really meet users expectations which we saw in different issues related to profiles. Adding a whole category to a profile is far too much. Users need more flexibility to adjust single settings on a profile basis or on a global basis, and this should ideally happen on the fly, not being tied to a whole included or excluded category.
The UX in VO and Orca is not satisfactory at least in my view, because you have to cope with lots of including and excluding activities.

Whereas the proposed UX would allow for a very quick lock / unlock feature and this allows more flexibility, especially when doing it via a key stroke.

@SaschaCowley
Copy link
Member

@Adriani90 how does your proposal address your point 2 "Firefox profile speech rate follows global speech rate"? I.e. how does the user tell NVDA that they want to delete speech rate from their firefox configuration permanently?

@nvaccess nvaccess locked and limited conversation to collaborators Nov 19, 2024
@seanbudd seanbudd converted this issue into discussion #17415 Nov 19, 2024
@github-actions github-actions bot added this to the 2025.1 milestone Nov 19, 2024

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants