Relative rate
Closed this issue · 7 comments
For Richard:
- Relative Rate isn't speaking sensible numbers.
- I think the label should be "Relative Rate %" so (when it speaks properly) "200" has some context.
For Neil:
- It seems that the change in the rate setting isn't getting picked up.
Relative Rate still isn't speaking sensible numbers.
Two thoughts:
- Add a text field that mirrors the slider value
- Replace the slider with a text field and do a sensible number check of the result (or maybe there is a way to say 'only values in this range are allowed')
A slider control reports a value between 0 and 100. If the user can choose a speed slower/faster by this value, then to me this would mean they could make it speak up to twice the speed, or twice as slow (i.e. half the speed).
Is that the intention? If so, I just need to know what these values would map to for the MathRate value.
My current feeling is that no one would want to slow it down below 20% of the current text reading speed or more than 200% of the current text reading speed.
That means 0 -> 20 (in prefs.yaml) and 100->200. If you can make it jump in steps of 10, that's 18 steps.
The unfortunate UIX about this is that 100% really should be in the middle, so maybe make it go from 0 to 200. So:
- 0 -> 0 (maybe check and make it 1 in prefs.yaml)
- 50 -> 100
- 100 -> 200
Alternatively, 20 - 180 would also center 100% and would avoid a need to check for 0. I can't imagine many people wanting to speed up the math, so even 180% is pretty fast.
[capturing an email reply]
I think asking the maths group makes some sense, but usually people are better at saying "I like this" or "I don't like this".
One thing I think we should do regardless of what we decide for sliders/buttons/text box is have a speed preview so people hear the speed change. What MathCAT generates is a string like
the square root of x squared plus y squared end root
This is then sent to a function in ___init___.py: _processMpSpeech(text, language) and the whole call for speech is
speech.speak(_processMpSpeech(text, self.provider._language))
_processMpSpeech() converts the string into what NVDA's speech engine needs. If we want to call that, I'll need to restructure ___init___.py and break out the non-init parts into a separate file so that it can be imported by MathCATPreferences.py. I should probably do that regardless of this change.
However, that function does a bunch of other things that aren't needed for this and so I think it makes more sense to just have a local function to MathCATPreferences.py which would be just a few lines and maybe clearer what is being done. One the other, maybe it is good to keep it all in one place...
The bottom line is that if someone makes a change, they should immediately hear what the change will sound like.
Does that immediate feedback make you rethink the design at all?
Maybe the numerical audio feedback from the slider can be replaced by the speech. Or maybe the "slower"/"reset to text speed"/"faster" buttons make sense (hopefully users would figure out they can click on slower/faster multiple times).