Usability problems with the telemetry request dialog

• Feb 7, 2020 - 18:23
Reported version
3.4
Priority
P1 - High
Type
Ergonomical (UX)
Frequency
Few
Severity
S3 - Major
Reproducibility
Always
Status
active
Regression
No
Workaround
No
Project
MuseScore

The dialog that requests permission to collect telemetry data from the user has the following problems:

  1. The dialog has no caption (title bar); instead it has a very thin colored bar at the top where the caption should be.
    Expected: Dialog has a caption like every other top-level window.
  2. The dialog is resizable.
    Expected: The dialog is not resizable.
  3. The dialog has no keyboard navigation. There is no visible input focus, and it's not possible to use the Tab key to navigate among the controls.
    Expected: Input focus is visible, and the Tab key cycles among the two pushbuttons and the “Privacy Policy” link.
  4. Clicking the “Privacy Policy” link does nothing.
    Expected: Clicking the link launches the link in a Web browser.

Version information: OS: Windows 10 (10.0), Arch.: x86_64, MuseScore version (64-bit): 3.4.2.9788, revision: 148e43f

Comments

• Feb 7, 2020 - 18:34

It would be great if the somebody from the internal team could explain why a custom dialog was needed rather than a standard Qt dialog that is a child of MuseScore's main window.

Reply

• Feb 7, 2020 - 18:42

I agree these are concerns. However, it's not actually true that the dialog has no keyboard navigation. It does, it just is very unusual and non-obvious navigation. The individual paragraphs of text are actually tabbable objects in this dialog (which is something I won't claim is without precendent, but it's new to me). So first press of Tab puts focus on "Help Us Improve MuseScore", and successive presses move focus paragraph by paragraph. The fifth press puts focus on the "Yes" button, which you can verify by pressing Enter. But, although the button has focus, this fact is not properly exposed in the UI. So you'd have no way of knowing any of this is happening - unless you turn on a screen reader. Then you can hear the results clearly.

The lack of title bar and tabbability of the static text combine to make the dialog more confusing than necessary to blind users. It means that at best, you are told a window has opened, associated with the program "MuseScore 3" or "MuseScore 3 Startup", but you have no idea what this window is until you press Tab. Then you start hearing it read, but it's not an expected interaction model. So we will have to be telling blind users to hit tab in order to know what is going on, or just presses Esc (which is always available, and always activates "Don't send", as I would expect).

Reply

• Feb 7, 2020 - 18:45
Severity S4 - Minor ⇒ S3 - Major
Priority ⇒ P1 - High

To me, while we've gotten past the "showstopper" stage with this dialog, it's still a major accessibility and general usability concern.

I agree with @shoogle in wondering why we are going to so much trouble to produce a custom window like when none of these problems would occur using a standard dialog. I can guess there are technical reasons for it, but it would be nice to hear them spelled out.

Reply