Add a "Complete StreetComplete" Question

[ENT8R]

As you might know I already wrote a backend for this (see https://github.com/ENT8R/CompleteStreetComplete) and now I just wanted to implement the frontend for this special type of question!

This new kind of quest is pretty similar to the normal OsmQuest except that the answer will not be uploaded to the OSM server but to the backend that I wrote for this purpose. With this quest it will be totally easy to get country specific metadata for existing or future quests 🎉
I already implemented two quests (one for tactile pavings (see #750) and another for post box collection times (see #85))

The position of the quests is downloaded via overpass so the user can e.g. look whether a post box in his country has really collection times... Once a question is answered, all other quests of the same type automatically disappear so the user can't answer one question multiple times. The answer is currently uploaded to my testing instance at https://ent8r.lima-city.de/CompleteStreetComplete/
But if you have access to a server with PHP, you can of course simply create your own instance!

A question can for example look like this:

As you might see in the screenshot, the geometry of the element is not loaded... The geometry is not saved to the database too but I have absolutely no idea why... (see this code)

Another thing I am not sure about is, whether this code is necessary at all...

BTW: This PR would fix #633

[rugk]

I'd say:

• it should definitively only ask one complete quest once per user, so it must be hidden afterwards. Does it already do that?
• As for the UI: What about adding a + or some other indicator to the quest icon (maybe even outside of the circled area), so one can differentiate these complete quests from usual quests?
  Reason: Especially if the quest icon is used for both quest types (i.e. tactile paving here) this could lead users to adding wrong values. E.g. if I am in the process of adding tactile paving to many crossings, I do not always read the full question again, so I just click on the quest and click on "no", e.g.. And here, both the original quest and the complete quest are yes/no quests, so it is very easy to accidentally choose the wrong one.
• Can I also revert these complete quests? Would be useful (see previous point). (To prevent abuse of this feature on the server side, you could limit the revert to users who previously answered the quest and limit the time they can revert, e.g. only 1 hour)

[ENT8R]

• it should definitively only ask one complete quest once per user, so it must be hidden afterwards. Does it already do that?

Yes, if the user answered a question, all other quests for this type are hidden and no new quests of this type will be downloaded

• As for the UI: What about adding a + or some other indicator to the quest icon (maybe even outside of the circled area), so one can differentiate these complete quests from usual quests?

I agree, this is a good idea, but I think it is hard to implement, isn't it?

• Can I also revert these complete quests?

No, not yet... But is it worth the effort? I mean, is it wrong data, if only a small amount of users made a mistake? But nevertheless it would be doable...

[rugk]

But is it worth the effort?

Likely depends on the previous point… you might also just collect the "reverts" and save them separately, so you'll see how often it is used or so. (don't know whether that is useful, though)

I agree, this is a good idea, but I think it is hard to implement, isn't it?

The "outside of the quest icon" could be hard, but don't ask me. If it is too hard, you can always just modify the quest icon…

[rugk]

Just some notes…

[westnordost]

You are starting things too fast. I am honestly not sure if I want to have this kind of thing at all in the app. How about you bring the other projects you started to a close first?

[rugk]

Actually I think this feature is really awesome. I like how it is implemented (just as simply as every other StreetComplete quest), but I agree we do not need to rush here. Especially as this PR changes the concept of "serverless" StreetComplete app, but – on the other hand – with the Mapzen shutdown, we do also have this problem, so in the long-term you may need a server anyway.
Of course, however, this has to taken care of, both in how the load is (the mapzen thing can help to determinate that) and of the privacy consequences (who operates these servers?, what is logged?, what jurisdiction applies?/where are these located? -> so there need to be some changes in the privacy policy).

But just an important point for this PR: Do not ask "What is common in your country?", but rather "What is common in this country/here?" as StreetComplete users can also be visitors of other countries.
Although one may argue for these kinds of quests you might want to exclude them. (Depends on how easy it is to answer such a question question as a tourist…, i.e. whether it is obvious and you are likely to see it at the airport or not.)

[westnordost]

• I don't want to cast temporary surveys in code, inclusively maintaining translations in all languages for that
• The survey format - fetching certain elements via overpass - makes little sense for most questions and comes with issues, as @rugk pointed out.
• While the method how the tags2names dictionary should work (wikidata, or self-made, crowdsourced? etc), it is unclear if such a "survey" extension would be fit to source crowdsourced translation data

I think if there should be some kind of survey, it should be implemented from a completely different angle. There is no need to (mis-)use the whole quest system for that, because that really overcomplicates things. It is not necessary to

• download survey questions from overpass, have more than one per question
• display survey questions on the map
• keep the survey questions in a local database
• conflict resolution, changeset management etc -> no need to solve it atomically
• revert survey answers
• ... etc etc

Here is a better approach:

1. App requests the to-be-answered survey questions + answer options from the survey-server
2. If there are new questions, app shows an appropriate icon button (i.e. with a count of how many questions there are, for shows)
3. clicking on that button leads to a new screen, where the user can then answer or skip ("don't know") every question
4. The questions are then uploaded to the survey-server. No need for any fancy offline-functionality

The concept is very much like this https://github.com/AndreiD/surveylib but it can be simpler in some aspects I think but must be more complex in others.

Additional notes:

• So, to be clear: Any information, translations, answers, answer format, possibly icon and/or images should be served by the survey-server, i.e. as a JSON, and then only interpreted by the app. Example of how surveylib does it.
• The language of the questions that should be returned by the survey-server could be requested by the HTTP header Accept-Language. The questions could be translated also in POEditor or similar, in a project separate to StreetComplete
• The client (StreetComplete) needs some method how to only request survey questions that the user did not answer yet. Easy solution (a bit like an RSS feed):
  1. Every question has a publication date
  2. StreetComplete memorizes the date of the last time, the survey questions have been answered and sent
  3. StreetComplete will request the survey-server to only give him questions newer than that date

Perhaps even surveylib itself could be used for that, I did not have a deeper look into his code there, whether it is of good quality. But it has no tests.

[rugk]

Okay, so, I agree it is really a good idea:

• to not hardcode the survey quests, but load them dynamically from a server. This also makes starting, assessing surveys and so on easier

But:

• do not make a lame "list UI". I get your point, but I actually find it pretty clever to show these questions in the map. Because then users actually has to be at a place, where the question is asked about and as such you simply cannot answer what you guess could be correct.
  On the other hand, these questions may be answerable by any user in the country and you do not have to visit the place. However, e.g. for peak features I find it difficult even for Germany to say whether they are really that common…
  Yet again, if you have really many users, you could prevent the subjective aspect when displaying it on the map. I.e. instead of asking "What do you think is that in your country?" you directly ask "How is that for this element here?". Then, you can collect all this numbers and evaluate how many peaks (e.g.) have one feature compared to the number, who do not.

BTW: As for how common a thing is, you may also offer users a selection as it can commonly found in surveys. (Select on a range of 1 to 5 – with a slider).

TL;DR: I really like showing it on the map from a UX perspective. It is inside of the user's workflow, it is deeply integrated into the app, it is unobtrusive and does not need yet another button. However, I understand that for the results, it may be better, if anyone can answer these questions.

So why not do both? Allow users to answer them (on a website and/or in the app) and notice them when they are near of such an item, so that they can be "nudged" into answering the question.

[ENT8R]

I don't want to cast temporary surveys in code, inclusively maintaining translations in all languages for that

I agree! This can be all done by the backend.

download survey questions from overpass, have more than one per question

I did this just because I thought that the user could really go to a place where this feature exists and confirm how something is made in his country...

keep the survey questions in a local database

But if the user has to go to a specific feature where he maybe has no internet connection, this is essential...

If there are new questions, app shows an appropriate icon button

On the map or in the menu?

The concept is very much like this https://github.com/AndreiD/surveylib but it can be simpler in some aspects I think but must be more complex in others.

Mmhh yes, I think it could be done similar to this project (e.g. having a JSON file on a server and the app has to display it accordingly) but I would not use this library as it does not seem to offer the ability to upload pictures, which is also sometimes very helpful.

So why not do both? Allow users to answer them (on a website and/or in the app) and notice them when they are near of such an item, so that they can be "nudged" into answering the question.

We can also reduce the priority for this quests to the lowest... So it does not scare off new users who might expect to answer OSM-related questions and no StreetComplete-related questions...
I don't really have a opinion on whether the questions should be displayed on the map or in a seperate list (or even both)... I like both ideas...

[westnordost]

I did this just because I thought that the user could really go to a place where this feature exists and confirm how something is made in his country...

Yes, it is a nice gimmick, it's more immersed in the app this way. But, code is a liability. I want to keep the app as simple as possible and I do not think it is worth the added complexity.

I would not use this library as it does not seem to offer the ability to upload pictures, which is also sometimes very helpful.

Not sure when this would be useful for asking for the prevalence of features in a certain country.

But anyway, in my opinion first the tags2names project should be led to a conclusion to know if this kind of osm-element-referring method of surveying would be used also by that project or if that project would use a different data source (wikidata or normal crowdsourced translation).
(Also, I intended to ask you about the matureness of the tangram-stylesheet you made. I would like to finally employ it in the app in the coming release, if it is finished)

[ENT8R]

Also, I intended to ask you about the matureness of the tangram-stylesheet you made. I would like to finally employ it in the app in the coming release, if it is finished

From my point of view, this is already finished. The map style contains all necessary elements (buildings, roads, labels, housenumbers, etc...) and if something should be missing it can be added afterwards... And the issues which still exist are IMO only not that important ones which would block the implementation of this stylesheet... Except streetcomplete/streetcomplete-mapstyle#8 which might need some adjustment... Sorry for don't informing you about the state of this project...

[ENT8R]

If you want to, I can create a PR for implementing the mapstyles...

[westnordost]

I'd want to play around with the colors a bit, I think many users may be put off by the (too) playful and too Pokemon-alike colors. And I guess I would better make this in your repos then make adaptions to the stylesheet after import from your repos.

[ENT8R]

I'd want to play around with the colors a bit

Go ahead! You can open the mapstyle in Tangram Play here

I think if there should be some kind of survey, it should be implemented from a completely different angle.

OK. I agree. I will close this and implement this another time...

[ENT8R]

I've got one more question:
If I am going to implement this feature as a simple list, how can we determine in which country the user is? Using Overpass you could get the country of the user by the coordinates of the element...

[westnordost]

It's already possible. See CountryBoundaries. Am 25. Januar 2018 17:06:50 MEZ schrieb ENT8R <[email protected]>:

…

I've got one more question: If I am going to implement this feature as a simple list, how can we determine in which country the user is? Using Overpass you could get the country of the user by the coordinates of the element... -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #783 (comment)

-- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

[ENT8R]

But this would only work if the user has GPS enabled, right?

[rugk]

See also #798