feat: extend notifications to inform about transportation that mus be booket in advance

[jonasbrunvoll]

Closes https://github.com/AtB-AS/kundevendt/issues/4203

Background

It seems that the app is currently not handling notices on the EstimatedCall on which a trip ends:

mittatb-app/src/travel-details-screens/utils.ts

Lines 44 to 50 in 51ea34a

	export const getNoticesForLeg = (leg: Leg) =>
	filterNotices([
	...(leg.line?.notices || []),
	...(leg.serviceJourney?.notices || []),
	...(leg.serviceJourney?.journeyPattern?.notices || []),
	...(leg.fromEstimatedCall?.notices || []),
	]);

This results, among other things, in that users are not notified about trips that must be booked in advance (behovsanløp).

Illustrations

screenshots/video/figma

either fromEstimatedCall or toEstimatedCall	both fromEstimatedCall and toEstimatedCall

Proposed solution

To solve, we should probably extend the code above to also include notices from ToEstimatedCall.

Acceptance Criteria

• Notices from estimated call are displayed.

Test input

• Tromsø Prostneset hurtigbåtkai - Lauksundskaret ferjekai
• Terråk hurtigbåtkai - Skotnes hurtigbåtkai

[gorandalum]

I'm a little unsure about grouping the notices for toEstimatedCall together with the rest of them.

The text in Nordland just says "Behovsanløp. Anløpet må bestilles! se reisnordland.no/behovsanlop", and since it doesn't mention which harbor it is connected to it probably needs to be placed on the correct harbor/quay in the view. Grouping it with the rest will make it seem that it is connected to the fromEstimatedCall harbor.

[jonasbrunvoll]

I'm a little unsure about grouping the notices for toEstimatedCall together with the rest of them.

The text in Nordland just says "Behovsanløp. Anløpet må bestilles! se reisnordland.no/behovsanlop", and since it doesn't mention which harbor it is connected to it probably needs to be placed on the correct harbor/quay in the view. Grouping it with the rest will make it seem that it is connected to the fromEstimatedCall harbor.

I understand your concern about grouping the notices for toEstimatedCall together with the rest of them. However, In my opinion, it is more important that the users are being informed about that they need to contact the relevant authorities to carry out the trip. The specific details around the trip will be clarified when the users make contact.

Also, trips requiring a "Behovsanløp" will only appear when they are specified as either from or to locations in the search. Therefore, I dont belive that the the lack of harbour specifiaction in the view will appear misleading for the users.

[gorandalum]

I think it is great input, and really nice that you not automatically agree. Open discussions lead to better output 👍

I have given it some extra thought, and I agree with you with regards to the "Behovsanløp". It doesn't really matter where it is placed, it ends up the same for the user who need to make contact.

But when thinking broadly one can imagine situations where the notice doesn't really work when shown on the from-stop even if related to the end-stop. What if the notice is "Stop place moved 300m to the north" or "Only disembarking on this stop place"? One example from AtB is that we have "Operates only on school days" as a notice. When seeing this the user will interpret that the from-stop is only operated on school days, while it really is the end-stop.

From the modelling the notice is definitively connected to a specific quay. And If a notice is in toEstimatedCall, but not in fromEstimatedCall, then it is really connected to only the end-stop. If we present the notice directly under the from-stop in the UI, there is no question that the user will interpret it as a message connected to that from-stop.

All in all I think the safer route is to show the message connected to the same quay in the UI as it is connected to in the data, to limit the possibility for misunderstandings for the user.

[gorandalum]

Code looks good. Some thoughts:

• The notice could possibly be shown under the to-place name instead of above it. @ckbilstad can give his input on where it is appropriate to show it. See the screenshots to see where it is placed now.
• Should it be considered to hide notice on to-place if same notice is shown on the from-place? I'm not sure about this one, but it would probably be strange that the same text is shown two times 🤔

[jonasbrunvoll]

Code looks good. Some thoughts:

• The notice could possibly be shown under the to-place name instead of above it. @ckbilstad can give his input on where it is appropriate to show it. See the screenshots to see where it is placed now.
• Should it be considered to hide notice on to-place if same notice is shown on the from-place? I'm not sure about this one, but it would probably be strange that the same text is shown two times 🤔

Good thoughts and agree. Here are some images to show how these suggestions will look:

Hide notice on to-place if same notice is shown on the from-place	Notice shown under the to-place name

[ckbilstad]

I think this is a good enough solution for now. After all, we have the opportunities and limitations we have, without needing to redesign the entire view.

[gorandalum]

Should we filter out from toEstimatedCallNotices the notices which already are in notices?