Ask if the opening hours here still not signed

[westnordost]

General

Affected tag(s) to be modified/added: opening_hours:signed
Question asked: Are the opening hours of Rhababerbarbarabar still not signed?

Checklist

Checklist for quest suggestions (see guidelines):

• 🚧 To be added tag is established and has a useful purpose
• 🤔 Any answer the user can give must have an equivalent tagging (Quest should not reappear to other users when solved by one)
• 🐿️ Easily answerable by everyone from the outside but a survey is necessary
• 💤 Not an overwhelming percentage of quests have the same answer (No spam)
• 🕓 Applies to a reasonable number of map data (Worth the effort)

I noticed that some shops may have opening hours signed at one time, but later they don't. Even later, they might have opening hours signed again. (Smaller shops, shops where opening hours are hand-written our printed out and taped to the door)

Since the opening hours quest also serves as a quest to check if a shop (etc) is still there, I think it would make sense to also ask recurringly about whether non-signed opening hours are signed now.

It should be a simple yes/no quest. However, if the user answers "yes", the UI to enter/display opening hours should be displayed (depending on if there are already opening hours recorded or not). After setting the opening hours, also opening_hours:signed=yes should be tagged.
For the check date, simply check_date:opening_hours could be used.

Maybe it could be re-asked less often. On the other hand, answering "no" is really fast.

[matkoniecz]

Maybe

Is there opening hours sign for Rhababerbarbarabar (greengrocer)?

would be simpler? For surveyor it is not important at all that it is asked because it was marked as signed...

Also "yes, it is signed" and "no, it is not signed" is significantly easier to parse than "no, it is now signed" and "yes, it is still not signed" (at least to me).

[westnordost]

Hmm, there is a UI problem:

If the question is "Is there an opening hours sign for ...?" and the user answers "yes", the quest title doesn't change, only the form. Because no quest form does that, to change the title. Only the form itself changes. So if in this case the current opening hours are displayed, it might lead to the user not knowing what to do.

On the other hand, starting to change the quest title may be equally confusing, i.e. the user might wonder if this is still the same quest?

Additionally, I believe this would then be the first quest that requires up to three answers to be given (in the same form, not in a dialog) until it is finished: "Is it signed?" ---yes---> "Is this still correct?" ---no--> define opening hours.

---

So, an alternative solution would be:

If the user answers "yes", additionally to setting opening_hours:signed=yes (or deleting it?) the check_date:opening_hours is set to the current last-edit-timestamp of the element being modified. This means that the opening hours quest will still consider this element as "old" and thus ask for opening hours.

This requires however the quest to know the element ('s timestamp) in the method applyAnswerTo, so that method and likely the StringMapChangesBuilder would need to be refactored. Maybe like this:

applyAnswerTo(answer: Boolean, element: ChangeElement) {
    element["lit"] = answer ? "yes" : "no"  // =changes.addOrModifiy
    element["lot"] = null // =changes.delete
}

or simplest at least

applyAnswerTo(answer: Boolean, changes: StringMapChangesBuilder, lastEditTimestamp: Long) {
    ...
}

Anyway, this would be too big now, so I am postponing this.

[peternewman]

Additionally, I believe this would then be the first quest that requires up to three answers to be given (in the same form, not in a dialog) until it is finished: "Is it signed?" ---yes---> "Is this still correct?" ---no--> define opening hours.

Also some of us, such as myself, may be willing to make the effort to answer yes/no for signed, but not to fill in the whole opening hours form.

If the user answers "yes", additionally to setting opening_hours:signed=yes (or deleting it?) the check_date:opening_hours is set to the current last-edit-timestamp of the element being modified. This means that the opening hours quest will still consider this element as "old" and thus ask for opening hours.

I think I suggested a similar workaround for something in the past (but I can't remember what off the top of my head), so perhaps that could be revisited if this is implemented in this way?

[westnordost]

I think I suggested a similar workaround for something in the past (but I can't remember what off the top of my head), so perhaps that could be revisited if this is implemented in this way?

Yes, of course