Extend POI model/view/template according to cities requirements

[ulliholtgrave]

Motivation

At the moment our POI implementation doesn't support all required fields defined by the cities team.

Proposed Solution

Therefore, the following changes to our models, views and templates should be applied:

• [x] #726:

  • Add phone number field (not required)
  • Add E-Mail field (not required)

• [x] #951:

  • Add category field (Advice centre, Authority/Office, Meeting place, Leisure, Shopping, Service, Mobility, Health, Culture, Gastronomy)

• [x] #1832:

  • Add opening hours field (not required)

• [x] #2037:

  • Add organization relation (not required)
  • Add barrier-free field (boolean, not required)

• [ ] Add spoken languages field (design TBD) // re-opened by service-team in 02/2023, see discussion below

Rejected ideas:

• Add target group field (max 50 characters, not required) //removed by service team on 18.02.23)
• Change further important information field (max 50 chars, not required) // removed after a discussion with @osmers in 02/23
• Add "Stops in the vicinity" field //removed by service team on 18.02.23)

Design Requirements

@hauf-toni

User-Story: I, as user of the Integreat App, would like to see if a POI is multilingual or not

[svenseeberg]

This requires coordination with the app team to support the data types and extension of the API definition. I suggest to first create a UX Desgin for the app before deriving data types.

App map/POI Designs: https://scene.zeplin.io/project/5f9040aed45a280985d019fb

[ulliholtgrave]

@timoludwig and @svenseeberg This could become relevant for the Coldaid-Project. @JoeyStk I also contacted the App-Team if this requirements are still up to date

[f1sh1918]

for integreat we currently use this design and only images in all resolutions and sizes are missing:

• title
• content
• thumbnail in different sizes and resolutions (16:9 and 1:1) (https://issues.tuerantuer.org/browse/IGAPP-920)
• location information (provided by GoogleMaps Plugin atm)

At the moment we don't need the additional fields, but as @ulliholtgrave mentioned, we have to discuss what we need for coldaid, but i dunno know if you implement different fields in the backend, since it could be a little bit overwhelming for the integreat purpose to have all the coldaid attributes

[ulliholtgrave]

I moved it to the next milestone as our current implementation will be productive within this month and we should evaluate how the feature is used.

[sarahsporck]

I know for IGAPP-920 we need thumbnail images. Besides, that which fields should still be added? And is it okay to persist the opening hours as strings?

[ulliholtgrave]

I guess the critical issues are the categories (done), the thumbnail and the opening hours.

We already create thumbnails (150x150) for each uploaded image that can be accessed via the thumbnail attribute of our media_files. I guess we can just use them for this purpose.

Regarding the opening hours I am not sure about the best way. I guess some machine-readable output would be ideal for a better integration, but saving the opening hours for each day in the model would bloat up the model by a lot... Maybe we can use a JSONField https://docs.djangoproject.com/en/4.1/ref/models/fields/#django.db.models.JSONField) for that? :thinking:

@timoludwig Any objections?

[sarahsporck]

Hmm. If I'm not completely mistaken the thumbnails sent via the locations endpoint are all of size 300x300. Check out yourself: curl -X "GET" "https://cms-test.integreat-app.de/testumgebung/de/wp-json/extensions/v3/locations?on_map=1" -iL. But maybe I'm missing something here.

In the app team we also already discussed how to handle the opening hours. As this can actually become quite complicated if a location is closed during lunch time and then reopens, which would result in two opening hours a day. Not sure whats the best way to handle this. Maybe really a Json format like this:

{
  openingHours: [
    { day: string, start: Date, end: Date }
  ]
}

And then wed need to implement checks for overlapping times during the same day.

[timobrembeck]

Hmm. If I'm not completely mistaken the thumbnails sent via the locations endpoint are all of size 300x300. Check out yourself: curl -X "GET" "https://cms-test.integreat-app.de/testumgebung/de/wp-json/extensions/v3/locations?on_map=1" -iL. But maybe I'm missing something here.

Yes, correct! In IGAPP-920 @f1sh1918 mentioned that higher resolutions are always welcome, so probably we can leave it as it is?

In the app team we also already discussed how to handle the opening hours. As this can actually become quite complicated if a location is closed during lunch time and then reopens, which would result in two opening hours a day. Not sure whats the best way to handle this. Maybe really a Json format like this

Sounds good! :+1: We could also think about adding optional fields like allDay: boolean or closed: boolean if we don't have start and end times on some days? (and maybe breakStart and breakEnd if the location is closed somewhere between start and end, but no idea if that's stupid and we should rather have multiple start/end slots instead)

[ulliholtgrave]

Hmm. If I'm not completely mistaken the thumbnails sent via the locations endpoint are all of size 300x300. Check out yourself: curl -X "GET" "https://cms-test.integreat-app.de/testumgebung/de/wp-json/extensions/v3/locations?on_map=1" -iL. But maybe I'm missing something here.

Yes, you are right. But as 300x300 is still a 1:1 format it's probably fine, right?

[timobrembeck]

Also, the UI for opening hours probably becomes very complex. Most locations will have the same opening hours on some or even all week days and entering the same hours multiple times is very cumbersome... I kind of like the way Google Maps is doing it to allow users to specify the opening hours for multiple days at once:

[sarahsporck]

Yes, you are right. But as 300x300 is still a 1:1 format it's probably fine, right?

300x300 should also be fine. I'll ask Andy again what else would fit nice.

Okay, so then I'll try to copy the google approach 😇 Not sure about the break times. But i think I can figure it out. Thank you for you input.

[timobrembeck]

@sarahsporck oh, and just one thought: Perhaps the "opening hours" widget is complex enough to justify implementing it as preact component, if you want to.

[sarahsporck]

That would definitely be much simpler :)

[MizukiTemma]

I guess organization and barrier-free can be easily added just like other fields, though for spoken language and target group should we prepare a set of choices like category or category icon/cloro?

[JoeyStk]

Target languages and spoken languages need some further discussion, maybe at T29K

[dkehne]

@JoeyStk Service team discussed:

• target groups should not be implemented
• Stops in the vicinity is not relevant because 2/3 of all regions are districts

The language field shall be implemented in this way:

• checkbox (checked/unchecked) with "Hier werden mehrere Sprachen gesprochen". This text should be shown next to the checkbox in the CMS and also shown in the app at the poi details (possible UI/UX can make the visualization). We do not want to give detailed overview of languages to avoid exclusion.

[timobrembeck]

• checkbox (checked/unchecked) with "Hier werden mehrere Sprachen gesprochen". This text should be shown next to the checkbox in the CMS and also shown in the app at the poi details (possible UI/UX can make the visualization). We do not want to give detailed overview of languages to avoid exclusion.

Does this really make sense? I can hardly imagine a location where not at least German and English are spoken. In my opinion, this field only adds overhead when managing locations, but does not provide useful information to the end user?

[osmers]

• checkbox (checked/unchecked) with "Hier werden mehrere Sprachen gesprochen". This text should be shown next to the checkbox in the CMS and also shown in the app at the poi details (possible UI/UX can make the visualization). We do not want to give detailed overview of languages to avoid exclusion.

Does this really make sense? I can hardly imagine a location where not at least German and English are spoken. In my opinion, this field only adds overhead when managing locations, but does not provide useful information to the end user?

How about adding English as an option but all other languages will be grouped under "mehrere Sprachen"? In the CMS Kommunen could then choose between English and multiple languages or both. In the App it will be displayed lik "Hier wird Deutsch und Englisch gesprochen" oder "Hier werden neben Deutsch und Englisch noch weitere Sprachen gesprochen".

Bcs I think you are right that Kommunen might think of English (and German) already as mehrere Sprachen and thus tick the option. By giving English this extra status we might avoid that and it might be clearer for the target group

[timobrembeck]

@osmers But does that really add value for the end user? I mean, all people who don't speak German or English have to consult other sources to be sure whether or not they are understood in that place. In most cases, these other sources don't exist, so they have to go there or call anyway, which they would also have to do if they didn't have information about spoken languages. In my opinion, this field only makes sense if we want to tell exactly what languages are spoken. In all other cases, I think the effort of maintaining this additional field is higher than the benefit for the users. Especially since the content creators themselves need to do some research to get that information (which they probably won't, so they will just input their best guess which can also be incorrect)...

[osmers]

The problem with listing all spoken languages is the maintenance and exclusion point. Kommunen already complain that it takes too much time to maintain everything. If we consider that spoken languages sometimes change quite frequently, having specific languages would only add to their workload. Also, most POIs would probably not think of informing the Integreat-Verwalter:in of changes in spoken languages. The effort of maintaining the field if it only tells the user that there are multiple languages spoken, is far lower.

Regarding the exclusion problem we figured that if a person knows that specific languages are spoken there and theirs is not one of them, they might not go or feel discouraged to go. If it only tells them that the place is multilingual, it might be less daunting.

How much effort would it be to add that possibility? If it is not a lot of effort, we can trial it and see if it is accepted by the Kommunen. If it is a lot of effort, then maybe we leave it aside and only talk about it again if Kommunen ask for it specifically

[timobrembeck]

Ok, I agree that listing all spoken languages is not optimal. However, for the same reasons I think the field in the suggested form also doesn't make sense:

• If region managers already complain about the effort, adding another field (even if it's a simple select field) won't improve the situation
• The spoken languages can change and if another language is added besides German and English, the locations won't inform the region managers
• If somebody does not speak German or English and the field says "only German and English", they might feel excluded and are discouraged to go, even if the region managers provided incorrect information there because they didn't know better (and I can't imagine a region manager calling each specific location just to get the information about spoken languages)

There are two possibilities: Either it's very easy to find out the spoken languages (e.g. on the location's website), then the region managers can put the correct information in the form, but in this case the field doesn't add much value, because the end users can also visit the website. Or it's hard to find out the spoken languages, in this case the region managers will only be guessing and will likely enter incorrect information, which is even worse than having no information at all.

It's trivial to implement, I just don't think it makes sense from a user's perspective.

[osmers]

Your points are all true - then I would suggest to simply not add the field, but I will take it with me for discussion next Monday and post our decision here :)

[osmers]

@timoludwig we discussed the issue and would still like to add the button "weitere Sprachen" - design to be determined. It should probably specify that official offers are available in multiple languages - to differentiate from the simple fact that employees speak another language. We do not want to differentiate between English and other languages.

[hauf-toni]

Design Requirements @hauf-toni

User-Story: I, as user of the Integreat App, would like to see if a POI is multilingual or not

you can find my suggestion for the specification of this information in the creation process of a location in this 🏛️ design file 👉🏻 for the display in the application a recommendation is also included, here a consultation with members of the tech team is useful, e.g. @steffenkleinle

[steffenkleinle]

or the display in the application a recommendation is also included, here a consultation with members of the tech team is useful, e.g. @steffenkleinle

What is this discussion about? Anything needed from me here?

[hauf-toni]

@steffenkleinle i would suggest that the cms team evaluates the design proposal first and pulls you or someone from the former app team in as soon as the design is final. then you can give an assessment of the implementation. afterwards we create a ticket for the react & react native channel.

[svenseeberg]

Lets move the additional feature into a new ticket: #2421 :)