digitalcora / t-cal Goto Github PK

Readability of the web calendar suffers when there are alerts that last the whole duration of a month (and beyond). It would be nice to pull these into a separate "all month" section above the day grid and give them a less-obtrusive visual treatment.

There would be no direct equivalent for this in the iCal feed, but possibly we could turn these into single-day events on the 1st of each affected month, with the title modified to make it clear that the event applies to the whole month.

Currently we round off all alert time periods to whole days, which results in a more readable and less obtrusive presentation on calendars, but requires users to dig into the (sometimes verbose) description to notice when a disruption is actually not happening all day. We could do better with the presentation of these "non-all-day" disruptions.

• On the web calendar, their color blocks could have a striped or otherwise visually "partial" appearance.
• In the iCal feed, we could detect whether the time periods all have the same start/end time-of-day and try to give the title a corresponding prefix like "Evenings" or "From 8:45pm", with a generic fallback. (Really, almost all rapid transit disruptions that aren't all-day are specifically 8:45pm to end-of-service; maybe it's only worth recognizing this one pattern.)

Currently alert periods don't appear on the calendar at all if they don't have an end date, but alerts like this are sometimes published and it would be helpful to know about them.

Would need to develop a unique visual style on the web calendar and appropriate unobtrusive equivalent in the iCal feed. Overlaps with #2 since these alerts can be open for quite a long time (e.g. the current alert about Red Line speed restrictions, which has been active for over 3 months and counting).

In event descriptions, provide the actual time windows for the alert, with no adjustments (using a muted visual treatment on the web calendar, similar to the alert ID). This would help in case the description is unclear about the exact timing, or for alerts that last a long time (multiple months).

Very occasionally, the V3 API throws a 500 error. TCal currently has no protection against this and in turn throws a 500 of its own. Since the vast majority of the time we have a cached response, we could keep returning it for a while, to let the API recover from whatever it's doing.

Look into adding the Silver Line. Yes it's really just a bus, but unlikely to add much clutter on its own. Downside: requires hard-coding the specific line/route IDs. Edit: no longer applies since 6cdfdcb.

MBTA alerts are now using the image fields to provide disruption diagrams in some cases. It should be straightforward to pull these into the alert detail modal. TBD: iCal feed equivalent?

When alert text is long enough (or the viewport short enough) for the dialog content to scroll, the close button gets scrolled out of view along with the content and can no longer be accessed.