Originally posted by @sherson in #4 (comment)

...

However, now that I think about it, we ought to sort by Priority too. How about:

• Group routes together (sort by route within each detour)
• Sort detours by Priority, then ascending by route (where general messages [ones that aren't associated with any routes] are after route-specific messages at the same priority level, and we use the lowest route number when there are multiple routes associated with a single detour), then descending by the date portion of FromDate, then descending by the time portion of FromTime (so newest detour shows first if route and priority are the same)

Priority values appear to be:

0. Emergency
1. High
2. Medium
3. Low

No matter what we do, the nature of grouping by route means we may occasionally end up with detours for a specific route not being next to each other in the list (and sorting by priority will affect that as well).

I have a vague recollection of FromTime maybe not being used (or not being used in a way that make sense), and what there's now is weird (explained in this comment):

<Message>
Due to staffing levels, "S" Trips will not operate between 05/27/2023 and 09/03/2023.
</Message>
...
<FromDate>2023-05-28T00:00:00</FromDate>
<FromTime>2023-05-30T00:00:00</FromTime>

But I can't think of harm being caused by sorting by FromDate and then FromTime.

Am open to suggestions.

As @frothedoatmilk noted on #1, duplicate message can occur.

I was on the fence but after talking to @sherson about the user stories for this app yeah it'll probably make sense to group them together.

Hey Adam and Ben,

In doing a task for Rob Hendry, I noticed that the iframe on the transportation website home page has a link to an external page on the PVTA website. In the iframe I see the “click here” link. On click, it opens in the same iframe but does not resize – so look slike the last screenshot.

Would you consider making these improvements?

Make the link open in a new window. The iframe is not resizing on click. (last screenshot)
Change “Click here for more info” to good linked text like: See all PVTA bus information.
Clarify the difference between the external page: PVTA bus info page and the transportation page: PVTA Routes. (The header above the iframe is to the PVTA routes page but the click here link is to the PVTA bus info page. Confusing?)

Thank you,
Joanne

It would be nice to offer/support some sort of way to make the height of a parent iframe dynamic (i.e. grow/shrink with the content of the widget).

I haven't found any css tricks, but there is a way to communicate between the parent and the widget with the postMessage API.

Since we're on react, there is a decent testing library available to us, and it works pretty well with vitest.

Haven't yet decided if this is worth it yet, moreso documenting that we could, so hold off for now.

In #4 I wrote:

I don't think we need to remove filtered-out-routes if they share a detour with routes that we included in our URL parameter

I've changed my mind and now think we should remove filtered-out-routes from shared detours.

There is currently a detour for P20, P21, and P21E along with R29 (that basically doesn't affect UMass). Because it lists 4 routes, it's tall enough that it pushes the detour we care about mostly off the screen (in the iframe on both desktop and mobile).

And even if it didn't push it off the screen, very few (if any) passengers at UMass even know those other routes exist... it's possible that some R29 passenger do, but even so it's probably still better to only show the UMass-area routes (to clean up the public messages list and reduce confusion for the other 99.9+% of our passengers).

I'm open to suggestions if anyone thinks otherwise.

Bustracker:

This app:

Since Avail supports it, I guess we don't really have a choice either. Shouldn't be that bad, the two possible pain points I foresee are:

• picking a good sanitized rendering method
• getting that rendering method to play nice with react

TypeError: null is not an object (evaluating 'publicMessage.routes.some')

Is fixed in #23, but an extra guard for the meantime is probably appropriate.

It appears that #23 broke route filtering by abbreviation

While this isn't a big deal for "normal" public messages, the "informational" entries still get a yellow border (i.e. "no messages found", "failed to load messages")

Originally posted by @frothedoatmilk in #6 (comment)

I spoke to @benmelz about this briefly but we wanted to get your opinion @sherson, for each priority level we could add some symbol/color to each message to indicate it's priority level (red for emergency, orange for high, etc). Especially since this would show the order of which the messages are appearing in, rather than it being seemingly random (especially since the sort order doesn't make apparent sense from the front end)