No Audio languages are displayed in the chapter Evaluating Expressions

[KolliAnitha]

Describe the bug No Audio languages are displayed in the chapter Evaluating Expressions

To Reproduce Steps to reproduce the behavior:

1. Login as Admin
2. Scroll down to All Topics
3. Click on Expressions and Equations
4. Click on 1st Chapter- Evaluating Expressions
5. Click on Continue
6. In the Order of Operations page, click on the Audio symbol
7. Click on Language icon displayed

8. Expected behavior Audio Language with the list of languages should be displayed

Actual Result: No languages are displayed

Environment Device name: One plus Nord2 5G Android version : Android 11 App version : 0.7-alpha-d1b2827517

Note: This issue is related to #4290

[BenHenning]

Ah interesting. This definitely exposes an issue with cases when no audio languages are available. This is a good edge case to address since we do expect the app to handle cases when audio languages are missing (though perhaps in a more cohesive way once we have the notion of audio language packs).

@seanlip is it a known issue that these lessons don't have any available audio languages currently?

This is also going to be blocked on product to make a decision for how to handle such cases, or if we want to wait until audio language packs are added. If the latter, we ought to at least add some messaging or disable the button as the current experience is confusing.

Aside from the above, @KolliAnitha can you please make sure to add the 'Found in' label to these issues moving forward? They help make it easier to find release-specific issues. (If there's no such label for a release that you're testing, please go ahead and create one).

[seanlip]

@seanlip is it a known issue that these lessons don't have any available audio languages currently?

This can definitely happen for some lessons and we should definitely design to account for this use case.

This is also going to be blocked on product to make a decision for how to handle such cases, or if we want to wait until audio language packs are added. If the latter, we ought to at least add some messaging or disable the button as the current experience is confusing.

We should account for this use case in a reasonable way. Unfortunately the UX team doesn't have bandwidth to take this on. Can we just disable the audio button in the case where there are no languages, and if the user clicks on it, show a popup saying "sorry no voiceovers are available for this lesson"?

Aside from the above, @KolliAnitha can you please make sure to add the 'Found in' label to these issues moving forward? They help make it easier to find release-specific issues. (If there's no such label for a release that you're testing, please go ahead and create one).

Just a suggestion -- can we update the issue template to do this for all user-facing issues that anyone files?

[seanlip]

Also @BenHenning I note that "[Blocked on product]" is added to the issue title. Is the suggestion I gave above sufficient to unblock it?

[BenHenning]

@seanlip is it a known issue that these lessons don't have any available audio languages currently?

This can definitely happen for some lessons and we should definitely design to account for this use case.

This is also going to be blocked on product to make a decision for how to handle such cases, or if we want to wait until audio language packs are added. If the latter, we ought to at least add some messaging or disable the button as the current experience is confusing.

We should account for this use case in a reasonable way. Unfortunately the UX team doesn't have bandwidth to take this on. Can we just disable the audio button in the case where there are no languages, and if the user clicks on it, show a popup saying "sorry no voiceovers are available for this lesson"?

We can show a message or disable the button, but not both (it's an antipattern to react to pressing a disabled button as it can result in inconsistencies in screenreaders).

Aside from the above, @KolliAnitha can you please make sure to add the 'Found in' label to these issues moving forward? They help make it easier to find release-specific issues. (If there's no such label for a release that you're testing, please go ahead and create one).

Just a suggestion -- can we update the issue template to do this for all user-facing issues that anyone files?

I'm not sure how we would do this since the labels can change over time, and as I understand templates they can only assign a fixed label. We could add it as an instruction item, though (though we don't have any extra instructions in the template, today).

[seanlip]

We can show a message or disable the button, but not both (it's an antipattern to react to pressing a disabled button as it can result in inconsistencies in screenreaders).

Ack, thanks. Let's disable the button. If this causes confusion, we'll revisit.

I'm not sure how we would do this since the labels can change over time, and as I understand templates they can only assign a fixed label. We could add it as an instruction item, though (though we don't have any extra instructions in the template, today).

In my mind, the template wouldn't assign a label. It would just have instructions to say "please add this label (creating it if necessary)". Alternatively it could have a space to say what the version is and someone else who's looking at incoming issues could add it.

I would also suggest updating the labels to 0.6, 0.7, etc. so that they match with what the reporter sees in the app, which would make it easier for them to file things against the right label. (Though I suppose this depends on your aggregation strategy for how you want to slice/filter this data by label.)

[BenHenning]

For searching context, this issue was found in 0.7-alpha (MR4).