In the runup to the May 19th EAS Showdow… um… Summit in Washington, DC, most of the discussion has focused on the nuts and bolts of moving the nation’s broadcast alerts across digital networks based on CAP.
But CAP only defines the information “payload” of a warning. It doesn’t specify how that information should be presented over HD radio, digital TV, computers, PDAs, digital signage or any of our various other windows into the infosphere.
This is going to become a crucial question in the very near future, I think. As digitization drives “broadcast” content onto ever more diverse platforms we’re going to need to give these presentation/user interface issues as much attention as we have to transport/relay-network design.
We may want to develop some common elements… consistent visual, aural, even tactile (e.g., portable device vibrator cadences) cues that one might almost call “branding elements”… to ensure that emergency alerts have a degree of consistency across all media. Otherwise we risk letting diversity deteriorate into confusion.
The Australians have made an interesting foray in that direction with their Standard Emergency Warning Signal (SEWS)… basically a standard “sounder” that can be used consistently over broadcast, wireless, wireline and even acoustical (siren and public address) delivery systems. However they haven’t tried yet to set a comparable standard in the visual or other domains.
Last year the FCC’s cellular alerting advisory committee (the CMSAAC) took a few first steps toward designing a consistent user experience for a basic text-messaging interface.
But as we start talking about digital television and HD radio and the things that lie beyond them, we’re going to need to bring some real world-class user-interface expertise to bear alongside our enormous pool of transmission engineering experience.
The Common Alerting Protocol (CAP) provides a rich standard data payload that can be presented… hopefully consistently… over all media, broadcast and otherwise. But the details of how best to present that richer message are still to be determined and require immediate skilled attention.
This is certainly relevant. I had assumed that on computers that the FSK tones and crawl would be adopted as in present EAS. However a good market research project should address this question. Also I have suggested that such a project should address the negative value of alert messages to those for whom it is not intended or relevant. This would bring out the value of the selectivity methods I have suggested for language, location with fine resolution if needed, category and some type of user preferance. Such selectivity will increase acceptability and the ability to use alerting more frequently for less severe incidents, which should be able to increase the value of the systems. However these extra capabilities should not hinder the response time of transmitting the highest priority messages. These should be automatic to have value for earthquakes for example.
My concern precisely, Frank. Why on earth would we choose to perpetuate all that 1970s FSK-and-crawl technology? Certainly not on grounds of effectiveness. But if we don’t step back and think about what we’re doing, I’m afraid that what we’ll do.
Like the man says, “If you keep doing what you’re doing you’ll keep getting what you’ve got.” Surely we can do better if we only try.
Here at NIST as part of our Exercise Control System, we did some work on trying to represent cap messages in a user friendly way. It’s basically an XSLT transformation that turns CAP xml message into html. You can see what it looks like here: http://picasaweb.google.com/guillaume.radde/Public/photo#5153240235716068258
(You can click on the Magnifying glass to see it bigger)
Yes, using XSLT on CAP XML can be very handy. USGS came up with the same idea awhile back, and we copied it for the California EDIS and some other feed-based systems. XSL stylesheets can also be applied to the RSS or Atom feed index files to make the whole system both human and machine usable with a single set of files.
But I think the issue here isn’t just the mechanics of converting XML into something more human friendly, it’s the whole range of usability, accessability and effectiveness issues that surround user-interface design. This is the expertise of designers, art directors and TV weather folk, among others, and we need to bring them into the conversation as well.