Standardized message formatting

[6TELOIV]

In the alerts the api provides, we get a ton of useful information, in a standardized, machine-readable format. This is amazing, and extremely useful for creating software that can present many types of events in a consistent manner.

Unfortunately, the documentation of this standard only applies to the structure of the data, not the structure of the text in the fields of the data. Particularly, the headline, description, and instruction fields seem inconsistent in formatting from alert type to alert type, and from forecast office to forecast office. On it's own, this isn't a big issue. However, as these messages formats are designed for presentation on TV, they are pre-formatted with newlines in the middle of sentences (and sometimes words), and designed to be displayed in monospace font.

This creates usability issues:

1. The legibility of monospaces fonts are not as good as "regular" fonts.
2. On mobile screens in particular, you are presented with two unfortunate options.
   • Let text wrap, and end up with strange stub lines (example below)
   • Don't let text wrap, and force the user to scroll horizontally to see the message.

Example

Originial message:
-------------------
This is a message that is preformatted
to wrap at certain locations, meaning
that you could end up with wierd
situations on mobile.

Potential wrapping on mobile:
-------------------
This is a message that is
preformatted
to wrap at certain
locations, meaning
that you could end up with
wierd
situations on mobile.

By establishing a standard (or documenting an existing one), it would allow developers to parse and re-display the messages in nicer, easier to read formats than the raw mono-text format we have currently.

[scadergit]

It effects our own applications, too, like alerts.weather.gov. This formatting comes straight from the weather offices, and the office would have to send multiple versions of the same data for weather-ready services that need the formatting. Reconciling this is long overdue, but will take a coordinated effort across the organization. The API is getting a lot of resources for improvements, I'll check if this is on their list.

[6TELOIV]

@sullynole that's very helpful! For example, the fire WWAs should follow: https://www.weather.gov/media/directives/010_pdfs/401h/Exhibit_3-1.pdf

With these, it's (at least theoretically) possible to parse the messages and display them in a better format than monospace/preformatted.

However, it's probably too much for us to maintain for our application, due to the sheer quantity of products and formats. As @scadergit said, reconsiling the formats or providing a new "rich text" or other format at the system level would be more useful.

I appreciate the consideration on the issue, and absolutely understand and appreciate the level of complexity internally for a change like this.

[greg-does-weather]

The directives do indeed specify formatting rules, but the beta site team can confirm that not all alerts conform to the directives. We've taken the approach of capturing and documenting the outliers to try to get them fixed, rather than trying to specially handle them.

@6TELOIV Can you describe more about your specific use case? I'm on a team working with NWS to make recommendations for the future of the API, and we'd love to get your perspective! We have definitely run into this exact same issue before and I am personally invested in delivering these text products in a way that's more generally usable.

In case it's helpeful, the beta.weather.gov code is public and open source and here's where we parse the big text blob into content "nodes" that we can then render more usable on a web site:

https://github.com/weather-gov/weather.gov/blob/main/api-interop-layer/data/alerts/parse/description.js

[6TELOIV]

Sure! I work with Leon County Government, and we are revamping our mobile app and emergency information portal website. On the emergency management side of things, we present citizens with a mixed feed of NWS alerts and our own emergency communications.

I wasn't aware of beta.weather.gov, will definitely be looking to that for some inspirations. That description parser seems like exactly what I'm looking for.

I've attached some screenshots of what we're building:

Screenshots

[greg-does-weather]

That's very exciting! I'll pass this message along to our team. Thanks for replying! 🙂

[6TELOIV]

@greg-does-weather would NOAA be interested in/able to publish that description parser as an package on npm? It solves exactly the problem that we were trying to solve, and would be very cool if we could receive any upstream fixes/features in the future.