Text used for quest_generic_otherAnswers2 can be mistaken for an acronym and causes confusion

[bompstable]

Quests that use the quest_generic_otherAnswers2 display answers such as "UH…", "ER…" "OH…". To new users, it is not always obvious that these are actually words and furthermore can sometimes be mistaken for acronyms. It is therefore not clear that people are meant to select them when they are not sure what the answer is.

For example, a friend thought that the EN-GB value of "ER..." was actually short for "Error" and thought it meant that something had gone wrong within the app. This was caused by the use of uppercase text and the three dots being misinterpreted as representing a cut off message rather than a person hesitating to answer the question.

Whilst this issue can be partly improved through better translations, the issue of the text not looking like natural words is caused by the fact that the answer text on quests such as bench backrests, postbox collection times, bus stop shelters etc is upper-cased even though the original strings use mixed case. Presenting "Uh..." instead of "UH..." would make it easier for users to read the strings as they are intended. Furthermore, using "Yes" and "No" instead of "YES" and "NO" for the other answers would make them easier to read and recognise. In general, mixed case is easier and quicker to read than uppercase and is arguably more attractive.

I think the answer options should be presented in their original case rather than being converted to upper case before being displayed.

[westnordost]

The uppercase is used in Android Material design 2 on all buttons, so it is quite consistent. But on the other hand, Material 2 is pretty, uh... alone with this. No other UI design language uses that and I think they also removed this behavior for Material 3 ("Material You"). (StreetComplete uses Material 2, though). I'd be fine to not use All-uppercase for buttons anymore in StreetComplete, if this helps somewhat to avoid this confusion. But I am not sure if it is possible easily to turn off this behavior in the style. It is welcome if someone wants to search if it is possible easily, i.e. turn it off for all buttons at once.

The other option that could be done (additionally) is to also use "Uh..." also on en-GB, even though "uh..." is used less often in en-GB than "er..."

Also, I agree that there is a general problem with the "..." in this regard, and that is that usually in the UI, if a button ends with "...", it means there will be a follow-up, e.g. a confirmation dialog or another prompt etc. So to solve this, if this is really a (big) problem, one could also change the text to maybe something like "Uh... 🤔"

[bompstable]

"Erm…" would be better in en-GB.

[westnordost]

Not according to ngrams: https://books.google.com/ngrams/graph?content=uh+...%2Cer+...%2C+erm+...&year_start=1800&year_end=2019&corpus=en-GB-2019&smoothing=0

[bompstable]

Agreed, I was just looking at that myself.

[bompstable]

Also, I agree that there is a general problem with the "..." in this regard, and that is that usually in the UI, if a button ends with "...", it means there will be a follow-up, e.g. a confirmation dialog or another prompt etc.

But there is usually a follow up to "Uh...", isn't there? It triggers another list of options in the examples I gave.

I think the main fix is to use mixed-case if that is possible. This isn't a major issue, but it did cause confusion for my friend (who has a lot of experience in UI and graphic) - he'd used the app quite a bit but didn't realise that selecting "ER..." gave more options until he saw me do it.

[westnordost]

But there is usually a follow up to "Uh...", isn't there? It triggers another list of options in the examples I gave.

Oh, right!

[westnordost]

But I don't quite understand how mixed-case helps. After all, , you can also write... "Error" - "Er..."

[mnalis]

So to solve this, if this is really a (big) problem,

I think something should be done to improve it, since it was reported several times already (and so who knows how many unreported cases).

one could also change the text to maybe something like "Uh... 🤔"

That would be best IMHO, but care should be taken for that emoji to be replaced with image instead of just using UTF-8 character (as we discovered with fonts issues in smoothness=* quest).

Maybe but emoji first (i.e. "🤔 Uh... " ), to better retain the meaning of ... (indicating followup answers)?

[bompstable]

But I don't quite understand how mixed-case helps. After all, , you can also write... "Error" - "Er..."

I think the mixed case makes the word look more natural so possibly more likely to be interpreted correctly. You're right of course - Er... could just as easily be misinterpreted.

The ellipsis (...) in this button is definitely doing double duty. "Uh" (or "Er") on its own doesn't really make sense as an answer so the ellipsis is needed to show hesitation. It is also needed to show that this button will trigger actions rather than simply recording an answer of "Uh". Maybe there's a better way to do this? If space were not an issue, I'd say the "Other answers..." form would be best.

I agree an emoji would have to come first, but to me this looks ugly. It may be better with a different emoji. Would an icon on the button work as well?

---

Regarding making the text mixed case, this can be done with the following in themes.xml:

<?xml version="1.0" encoding="utf-8"?>
<resources>

    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.MaterialComponents.DayNight.NoActionBar">
        [...]
        <item name="android:textAllCaps">false</item>
    </style>

I've tested this on my device but I'm not an Android developer so don't know if this is the best approach.

[riQQ]

See also

• 5573

• 5630

• 5641

[bompstable]

I note that "Other..." was proposed in https://github.com/streetcomplete/StreetComplete/discussions/5573#discussioncomment-9029193. For me, this would work better.

[westnordost]

I find that "other..." is lacking. Other what? Doesn't this just as well leave room for confusion?

For now what would be fine to me is:

• rename "er..." to "uh..." even in en-GB. It is used less, but should still be understood just as fine and doesn't have the issue of being mistaken for a truncated "error"

• change the app style to make buttons not all-uppercase by default. By the way, your snippet looks odd. This is the main theme, not the button theme. So it looks like that line should just make it so that text in general is not all uppercase. Why it works (for you), I don't know, but it is suspect. Maybe a bug.

Regarding the 🤔 emoji, the issue with this is that it draws too much attention to that button. It would need to be at least monochrome.

[goldfndr]

Slightly related to topic: string tutorial_stay_safe appears to have been missed in the change.

[westnordost]

Slightly related to topic: string tutorial_stay_safe appears to have been missed in the change.

The string seems fine to me. The "Can't say" option still persists.

[bompstable]

By the way, your snippet looks odd. This is the main theme, not the button theme. So it looks like that line should just make it so that text in general is not all uppercase. Why it works (for you), I don't know, but it is suspect. Maybe a bug.

I presume it is applying to Buttons but also to anything else that would otherwise transform text to uppercase.

Having delved into the code a bit more and learned a bit more about Android, I believe I now know the correct way to do this. I've created a draft PR at https://github.com/streetcomplete/StreetComplete/pull/5677.

---

I've noticed that some quests display the buttons in this order: Uh... Yes No (or Uh... No Yes). I think it would make more sense for Uh... to go last. a) it's the least expected answer, b) putting it last should make it clearer what the intent of the button is. What do you think?

[westnordost]

I've noticed that some quests display the buttons in this order: Uh... Yes No (or Uh... No Yes). I think it would make more sense for Uh... to go last. a) it's the least expected answer, b) putting it last should make it clearer what the intent of the button is. What do you think?

"Uh..." should always be on the left (start) side, i.e. so that the "yes"/ok button is always on the right/end side. This is pretty consistent at other places, too. E.g. in the overlay forms, the big "OK" button is to the right while the ... menu (basically the same as "uh...") is to the left. Kind of the reason for the positive button to be on the right is both to follow the Android material guidelines but also because when used one-handed, it should be reachable with the thumb.

[bompstable]

Fair enough, but I feel sorry for left-handers. ;-)