"Not specified" is confusing (in postbox collection times resurvey quest)

[mnalis]

User reports confusion, that the SC (at the same time!):

• claims collection times are (not specified), but also
• shows the collection times (10:00)

e.g. postbox collection resurvey quest here: https://www.openstreetmap.org/node/4404500844

It seems that the intention is (in that specific case) to say that "weekdays are not specified", but without saying "weekdays" (or having "days of the week" / "hours:minutes" as table headings or similar) it is unclear what is "not specified".

---

It should IMHO be clarified somehow, but it seems that quest_openingHours_unspecified_range string is reused for two different things in the code; so it probably should firstly be split to two different strings which can then be translated separately.

[westnordost]

Or just make it blank when not specified?

[mnalis]

Or just make it blank when not specified?

Perhaps that might be good enough¹, if it is too much trouble to add multiple strings...

Although I would still think it is preferable that SC indicates that the data is ambiguous/lacking, as on-the-ground user is in ideal position to add missing days range in such cases (because, with blank string most users would probably not be aware of that lack of days, so would not even attempt to improve it).

Footnotes

1. provided if only applied to this particular form, and not possible other uses where string is needed (I'm not quite sure where it all gets used). ↩

[westnordost]

Anyway. You wrote "user reports confusion". Which user? In what way is it a real issue that one user is confused? Wrong data entered? Useless notes created?

When a single user or few users are confused, it is not necessarily necessary to change anything, in particular when it does no damage.

[mnalis]

TL;DR: see 3 choices below the line.

You wrote "user reports confusion". Which user?

This one. They're quite a prolific SC/SCEE mapper, so they stumble upon more issues than a mere top-100'er like myself do (also, I'm tainted as being too familiar with how SC works and being able to look in the code).

In what way is it a real issue that one user is confused?

I was under impression that SC generally tries to be clear, non-confusing and understandable (especially to non-technical users).

It is because of that belief that I reported¹ this confusing UI (as I myself also agreed it was confusing, and others in our osm-hr telegram group also could not tell what was meant there. So it is more than one user, but still anecdotal sample size... The discussion starts here if someone cares).

Wrong data entered? Useless notes created?

In this particular case, the user invoked small discussion asked in our telegram group. I should not try to speculate what would they do if they did not do that - hide the quest, leave notes, disable quest, give up on SC as too confusing, etc. If I were forced to guess, I'd probably say one of the first three. 🤷‍♂️

When a single user or few users are confused, it is not necessarily necessary to change anything, in particular when it does no damage.

---

Sure. I have no horse in this race, I just reported the confusing UI as it made sense to me that it would be confusing to others too. I personally am totally fine with any of:

• just close this issue as such relatively minor UI confusions are not important (enough) for SC (least work)²
• just remove the text as you suggested (e.g. showing just 10:00 in resurvey text) which fixes the confusion, but misses on the opportunity to improve the data (very little work)
• split and clarify the texts so SC users are aware of the ambiguity in the OSM data and can improve it. (some more work, but most valuable result IMHO).

In order to make a decision, some stats: there are some 6.2k of such ambiguous/incomplete collection_hours worldwide (cca. 3% of all of them).

Footnotes

1. the user in question does not use github and does not speak English (even original report was in Croatian, but translation is pretty much the same, so it looks equally confusing in English to me); so I report some issues for them as a courtesy.
   It's the same user that spotted that statistic error with missing statistics in Gibraltar/Portugal. Only one user reported the issue there too, but there is probably more than one person who mapped with SC in those countries and who were affected (and in that case too, wrong stats would not lead to damaged OSM data...) ↩

2. which is fully understandable, as there are more important things to do (and probably deadlines to meet). Let us know if you'd prefer not to have UI confusions such as this not reported in the future (as going through them also uses up valuable time; I understand) ↩

[westnordost]

I mean, we have a channel for user confusion, and that should be leaving a note. Then, when many notes for something seem to pop up, we know that something should be changed. A confusion of a single user is IMO difficult to act upon, because whatever the change, the result of the change might also be confusing to then other users. That's why I argued that as long as the result of the confusion is harmless, it's really not urgent and if the number of users affected is (very) small, unimportant. And, I'd argue that any user that has seen any opening times quest before should know what's usually displayed left of the opening times.

The primary issue I see with your first suggestion that indeed would make it very clear is that the text might turn out too long (in some languages). E.g. German would probably look something like this:

(keine
Wochen-
tage
angegeben)

Looking at @deevroman's recent contributions, e.g. Russian might even be more verbose.

[matkoniecz]

Anyway. You wrote "user reports confusion". Which user?

I have not seen it ever live but it definitely confused me. Not showing any text (blank space) would avoid this confusion.

It is not clear what is "not specified" when you see it, at least for me.

[mnalis]

The primary issue I see with your first suggestion that indeed would make it very clear is that the text might turn out too long (in some languages).

The alternative is to leave "(not specified)" text (which would avoid that length issues); but instead add headers to that table values to make it clear what they are about; e.g. something like this (but less ugly then my quick mockup 😅 ):

But as I noted, I'm also fine with blank text you suggested; if forgoing opportunity to improve data is preferred due to its simplicity, and we want to concentrate on just removing confusion.

[HolgerJeromin]

Is this really an error in the data? Perhaps

All days

is shorter in all/many languages?

[deevroman]

Since you called me..., why is (Not specified) split into two lines? :) (Not 10:00 specified) ?

Looking at @deevroman's recent contributions, e.g. Russian might even be more verbose.

German is still more verbose 😜 But in Russian there is a more subtle translation Not specified — Не уточнено instead of a direct translation Не указано. Не уточнено seems closer to Not clarified. That is, it adds semantics that the cartographer can specify the day of the week value if it exists. This is a more lenient option that doesn't indicate missing data.

However, I would prefer to see @mnalis's version with a table. We all know in this thread that StreetComplete asks about weekdays and hours. But imagine a less-experienced user returning to StreetComplete a month later and seeing this.

[mnalis]

Is this really an error in the data? Perhaps

All days

It is not an error per se, but rather ambiguity. So e.g. collection_times=10:00 might mean different things depending on various unknown factors.

Details

So actual intended meaning of that tag might've been:

• collection_times=Mo-Su,PH 10:00 (i.e. "really ALL days"), or
• collection_times=Mo-Su 10:00; PH off (i.e. "all days, expect holidays of course when nothing works"), or
• collection_times=Mo-Sa 10:00; Su,PH off (i.e. "all work days, of course it doesn't get collected on non-working days"), or
• collection_times=Mo-Fr 10:00; Sa-Su,PH off (i.e. "all work days, of course it doesn't get collected on non working days, and postoffices don't regularly work on saturdays either here as they have 5day workweek"), or
• "it is collected some days at 10h, but it is unknown which days exactly", or
• something else

So imagine it like amenity=charging_station but not specifying whether it is car-only charging station, or bicycle-only charging station, (or station charging both cars and bicycles) -- but worse, since with charging stations there is prevalent opinion that it is by default for cars (since most of mappers live in car-centric world), and for collection_times there is no such prevalent opinion, but most options are equally possible.

[westnordost]

The table approach doesn't really work, because it is not always strictly one table. Select "Differs by month..." and observe that then one would have one table for each range of months.

[westnordost]

Alright, so the suggestions so far were (👎/🫤 is my opinion, of course, but in the end, it is I who has to make a decision):

1. leave everything as is
   👎 may be confusing to users who haven't seen yet how the opening hours/collection times table usually looks
   🫤 current text can be a bit long in some languages

2. arrange the opening hours in a table with a table header (days, hours)
   👎 doesn't work when opening hours differ by months: the months are already displayed as table headers
   🫤 more text / more verbose

3. clarify text, i.e. write "(weekdays not specified)"
   👎 that can get very long in some languages, in English it will already span three rows

4. change the text to "All days" or "Every day"
   👎 this is factually wrong. It doesn't mean every day, it just is not specified. (E.g. what about holidays, what about weekends?)

5. make it blank
   🫤 user is not made aware of that it can be somewhat ambiguous when no weekdays are specified
   👍 the UI should reflect closely what can be seen on the sign, a text like "(not specified)" is a little alien here
   🤔 users should just input what they read on the sign, regardless of whether it is ambiguous or not. So, when the weekdays are not specified on the sign, it somewhat makes sense to just display nothing. And when they are displayed on the sign, but not shown in the app, the user can add them all the same.

So, given that, I will opt for option 5.