anthonyalfimov
commented
3 years ago Counter-argument: if we want the UI to be touch-friendly, we can't rely on mouse-hover state. Current label operation should be fine for touch UI: you could tap the control to see the value.
Currently the plugin uses the same label to display both the parameter name and its value. The value is displayed when you are interacting with the parameter control (i.e. clicking or dragging the control).
Controls are set up so they don't jump to the click position. To move the control, you have to drag it with the mouse. This way, it is safe to click any control to inspect its value.
Recently I noticed that Logic's Drum Kit Designer uses a similar system for its control labels. The main difference is that the parameter value is displayed on mouse hover, rather than on interaction. At the same time, controls in Logic do jump to the click position.
I do prefer controls not jumping to the click position, this helps to avoid accidental changes.
However, I'm not sure which condition for the label to show the value is better: mouse interaction or mouse hover.
Currently, all parameters have continuous ranges, so it is easy to get an idea of the parameter state just from the knob/slider position. But one of the upcoming changes is tempo sync for the delay time and modulation rates #4. Tempo subdivision value is a type of information the user might need to know precisely. Knob/slider position will not provide a useful estimate in this case. Displaying the control value on mouse hover could streamline the retrieval of this information.
48 could be relevant to this discussion.
If hover state reveals new information (parameter value), then it should comply with the following Web Content Accessibility Guidelines:
1.4.13 Content on Hover or Focus [AA] 1.4.13 Reference