Feature/image in alerts

[gcamp]

Service alerts sometime can benefit of having an image next to the alert description to enhance the comprehension of the alert.

MBTA is already sending alerts with images on their twitter. UTA also uses a webpage to detail their alerts and add an image to the content. IBI service alerts too already support attaching images that way.

This proposal adds a URL to an image for it to be displayed by apps.

cc @ibi-group-team @paulswartz

[skinkie]

If we are not even able to follow up #76 for static, I do not want to see this proposal for RT fast tracked.

[gcamp]

@skinkie feel free to continue the discussion of #76 in that PR. The proposal here is not fast-tracked, it just follows the normal process as any other proposal.

I welcome your comments on this PR if you have any!

[skinkie]

It might make sense to make it a ilst, consisting of the image url and an enum with a type. Photo, Map, ..., come to mind.

[brodyFlannigan]

It might make sense to make it a ilst, consisting of the image url and an enum with a type. Photo, Map, ..., come to mind.

I like where this is going, especially with maps.
Often times, disruptions are very complicated to explain in a GTFS-RT alert where there is no formatting (i.e. headers, bullet points, etc.), and since not all consuming display/link to the URL provided, it can be very difficult to get information to riders. Being able to link to a map or image would be really helpful.

[skinkie]

It might make sense to make it a ilst, consisting of the image url and an enum with a type. Photo, Map, ..., come to mind.

I like where this is going, especially with maps.
Often times, disruptions are very complicated to explain in a GTFS-RT alert where there is no formatting (i.e. headers, bullet points, etc.), and since not all consuming display/link to the URL provided, it can be very difficult to get information to riders. Being able to link to a map or image would be really helpful.

Lets not forget accessibility, complementary information :)

[gcamp]

Yes I almost want to explicitly discourage text in image, that's certainly not what I wanted.

[brodyFlannigan]

Absolutely, there should NOT be any text in images. I'm thinking more like having an image of a map somewhat like OC Transpo (Ottawa, Canada) does for their detours (Like this <https://web.archive.org/web/20210624003349/https://www.octranspo.com/images/files/maps/detours/2021/Piperville_2021_222.pdf> ).

…

On Mon, Sep 20, 2021 at 3:48 PM Guillaume Campagna ***@***.***> wrote: Yes I almost want to explicitly discourage text in image, that's certainly not what I wanted. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#283 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALDT5V7IR3NW5OPSR3RBG7LUC6FXLANCNFSM5DVP5F7A> .

[stevenmwhite]

Since we did refer to agencies who include images with Twitter posts, when it comes to the idea about making sure there's not text in the images, we should note that plenty of agencies use images like the below on Twitter simply as a more visually appealing/branded way to share the message.

https://twitter.com/metrolaalerts/status/1439968121230667776

https://twitter.com/SMBigBlueBus/status/1438941139449548808

https://twitter.com/lbtransit/status/1405615776271278080

I think we all agree the intent here is not looking for this kind of "branded visual" that just replicates the text of the tweet (often with even less information), but we should at least recognize that this type of content would be the natural use case for many agencies.

As suggested, specifically calling out what types of images are desired and including the enum of type to force a selection into those desired categories could certainly be helpful.

[gcamp]

@stevenmwhite Having an enum seems overkill to me. I understand the goal of forcing different types of images but in practice we'll need an OTHER which defeats the purpose.

[stevenmwhite]

@gcamp Yeah, I agree with that as well...

I do think it will be difficult to enforce any kind of image that we don't want agencies to publish and we should recognize that.

Perhaps some language around how it shouldn't be used for "marketing or branding" images, but I don't think any of those agencies consider what they're posting to Twitter to be marketing or branding necessarily.

[gcamp]

@stevenmwhite let me know what you think of the updated language

[stevenmwhite]

@gcamp I think that's helpful.

I should also note that I'm not opposed to any of this and would be in favor of the feature generally. We'd love to include these features in our alert publishing software for GTFS-RT. As a consumer, you will certainly be more picky about what types of images you do or do not want to have showing up in your app than I will about what types of images agencies desire to include.

I just wanted to make the point that it's likely agencies will naturally publish images for visual branding purposes if their alert usage on Twitter is any indication, so we should either be prepared to accept that or to actively discourage it somehow.

[gcamp]

@skinkie added list of images. The enum has been discussed earlier and I don't think it's required.

Let me know if you have other comments before I call a vote.

[paulswartz]

Possible additions, which would involve a new type besides TranslatedString:

• should we include the MIME type of the image, so clients could provide a WebP image and others could filter it out?
• should we provide alt text?

[stevenmwhite]

On the alt text... I would generally highly suggest YES.

However, I'm curious how this would work practically. As-is, the image itself is kind of like an alt image for the alert text. Would we expect producers to provide an image that gives substantially new information (as opposed to just the same information visually) than the alert text, and thus the image could be described in a manner that also gives additional information? Or do we expect that the alt text for the image would reasonably be equivalent to the text of the alert in its meaning.

I'm imaging the following scenario:

Alert Header: Detour on route 5 downtown
Alert Text: Buses detour onto Spring Street from 1st to 9th, missing normal stops at Main & 1st, Main & 5th, and Main & 8th. Stops will be available at Spring & 1st, Spring & 5th, and Spring & 8th. This detour will last for the remainder of the day.
Image: A map with stops crossed out on Main Street, showing the new path of travel on Spring Street with new stops highlighted.

Is the phrase in italics that I wrote above to describe the image something that would be useful as alt text? Or is it duplicative of/less useful than the actual alert text?

[paulswartz]

Here's a recent example from @mbta:

Alert ID: 404031
Header: Shuttle buses replace B Branch service between Kenmore and Washington St on weekends from Oct 16 through Oct 24, beginning Friday evenings at 8:45 PM.
Description:

Shuttle buses will begin at 8:45 PM on Friday and continue through the end of service Sunday.

This diversion will allow for work on the B Branch Station Consolidation Project. All shuttle buses are accessible to people with disabilities, If you need assistance, please see station personnel.

No shuttle service at Allston St, Warren St or Packards Corner due to accessibility concerns. Please use Washington St, Harvard Ave or Babcock St instead.
Affected stops:
Kenmore
Blandford Street
Boston University East
Boston University Central
Boston University West
Saint Paul Street
Babcock Street
Packards Corner
Harvard Avenue
Griggs Street
Allston Street
Warren Street
Washington Street

Tweet: https://twitter.com/MBTA/status/1444603130482593800
Tweet text: Green Line Reminder: Shuttle buses replace B Branch service between Kenmore and Washington St this weekend, from start to end of service. More: http://MBTA.com/alerts/subway
Alt text for tweet image: Green Line Reminder: Shuttle buses replace B Branch service between Kenmore and Washington St this weekend, from start to end of service. No shuttle service at Warren st, Allston St or Packards corner, use Washington st or Harvard ave instead. More: http://MBTA.com/alerts/subway

The alt text is somewhere between the full description and the header.

[flocsy]

Regarding multiple images: if we allow multiple images then since not all consumers will be able to support more than one image - and even for those that do - there should be a way to determine which one is the main image (or the "order of importance" of the images)

[flocsy]

I completely understand the intent of this sentence, but I think the wording is not correct. This sounds line a consumer's api documentation, while we mainly are talking about how to produce these files. So all the "is picked" should be changed IMHO. Maybe to something that makes it as a recommendation to the consumers. Or maybe a bit stricter than that... like "should be picked"

[gcamp]

This is text copied + adapted from TranslatedString. I'm for clarifying this but maybe that can be done in an other PR and fix both at the same time?

[sam-hickey-ibigroup]

It might not happen often but I see multiple images as a nice to have. I can see for example an images with a map of a detour and a second image with an detailed map of a new stop location in a dense area.

This is a good example.

If multiple images are allowed, there should be a way to define their ordering as noted by @flocsy and the image_alternative_text would need to move back into the TranslatedImage because each image could have different alternative_text.

[gcamp]

Right, my bad for not thinking of alternative_text relationship with the multiple stops. Even if I pushed for multiple images before, the effect is marginal. I would remove that capability to fix the alternative_text problem.

[gcamp]

I've gone ahead and changed the proposal to only allow one image.

[gcamp]

Let me know if there are more comments, if not I'll start an other vote by the end of this week.

[gcamp]

I think we're again ready for a vote. This vote is for adding an experimental field of images in alerts.

Voting ends on 2021-11-26 at 23:59:59 UTC.

[flocsy]

What about adding the required url-encoding to the url field? IMHO it should be in the standard and not a free choice.

[flocsy]

What about adding the required url-encoding to the url field? IMHO it should be in the standard and not a free choice.

[flocsy]

What about adding the required url-encoding to the url field? IMHO it should be in the standard and not a free choice.

[gcamp]

@flocsy I added the media_type in the TranslatedImage, is that what your question is about?

[flocsy]

@flocsy I added the media_type in the TranslatedImage, is that what your question is about?

No, I'm not talking about the media type of the file that the url points to, but the encoding in the value of the url field. i.e:
"http://example.com/file name" vs "http://example.com/file+name" vs "http://example.com/file%20name". Or more interesting example of non-ASCII character in the url: "http://example.com/Fővám tér" vs "http://example.com/F%C5%91v%C3%A1m%20t%C3%A9r" (url-encode) vs "http://example.com/RsWRdsOhbSB0w6ly" (base64), etc. IMHO the standard should explicitly define what to use to prevent confusion for both producers and consumers

[gcamp]

I updated the URL description for escaping, using the same description that GTFS static uses.

[sam-hickey-ibigroup]

+1 IBI Group

[flocsy]

+1

[paulswartz]

+1 (@mbta)

[skinkie]

+1 OpenGeo

[stevenmwhite]

+1 GMV

[lauramatson]

+1 Metro Transit (Minneapolis/St. Paul)

[doconnoronca]

+1 TransSee

[gcamp]

The voting period is finished and result are : 7 for, 0 against. The proposition passes! 🎉

For the maintainer merging, if possible squash and merge because the git history is not clean in this PR.