Emergency Web Notification Product
We are in the process of developing a Plone product that displays an emergency message on a Plone web site.
The following describes who will use this product and how each user will use this product.
Overview
The product will be used by a number of groups in the following overall process:
Message Creation
The emergency message is created/typed up by a Plone web site user, but the message remains private (not visible to the public). The user in question belongs to a group that has the appropriate emergency message creation role. The Plone site this work occurs on (the "emergency master" site) could be an existing live/production site or it could be a separate instance of Plone that is used only for emergency message handling.
Message Approval
The message creator submits the message for approval by a supervisor or supervisors. All supervisors belong to a group that has the appropriate emergency message review role.
Message Publication
After the emergency message has gone through all approval/review workflow states, the message is published and becomes visible to the public on this particular Plone site. Should we include a default expiry time for every emergency message, e.g. one day (24 hours)?
Message Distribution
The emergency message appears in the RSS feed managed automatically by the "emergency master" Plone site, presumably in a News-ish folder. Only "in progress" emergency messages should be in the published state in this folder; stale or out-of-date messages should always be retracted or revoked or deleted.
(Deletion may not be a good choice and perhaps should not be allowed; instead, we could allow an archive transition that hides the message but retains it for the record).
Message Receipt
All participating Plone sites have the product installed and configured to use the web address of the emergency message RSS feed, e.g. http://www.uwosh.edu/emergency/alerts/RSS (by default the product will come with that web address pre-configured). Periodically, each participating Plone site will refresh its view of the emergency RSS feed. (The refresh schedule should be every XXX minutes by default). When the RSS feed shows one or more live/published emergency messages, the product causes each live/published emergency message to be displayed to every user of the web site.
Message Display
When a new emergency message is detected, it must be displayed to each and every user of the web site in an obvious and intrusive way. All web site users should see a new emergency message, whether they are logged in or not ("anonymous"). Currently we envision a pop-up window appearing and containing the title and body of the emergency message. The pop-up window mechanism should work regardless of the following:
- presence or configuration of common web browser pop-up blocking mechanisms
- the activation or deactivation of JavaScript and Java in the web browser
- web browsers that are "text only", such as links/lynx
- the activation or deactivation of screen readers
Users should be able to dismiss or close the emergency message window. On dismissal or closing of the emergency message window, an indicator should remain on the web site; this indicator could be graphical or textual or both, should be noticeable, should have visual cues that indicate to all users (experienced and inexperienced) that it is an indicator of an emergency situation. The indicator should allow, through clicking or similar user action, the re-opening and re-presentation of the emergency message window.
Should the state of the emergency message window (open or closed/hidden/dismissed) persist between user sessions at the same web site? i.e. if the logged in user logs out of the site and reloads the page or views other pages on the same site, should the live/published emergency messages appear in a pop-up window? If an anonymous/not logged-in user to the web site closes the emergency message window, should the memory of this action persist when the same user closes the web browser and later returns to the same web site? My inclination is that the state of the window should not persist between sessions.
How often should the same live/published emergency message be re-displayed to the same user (logged in or anonymous)? Should we assume that, once a user has dismissed the window, we should never reopen it again except to show a new emergency message? Would it be more prudent to have the window reappear, regardless of the user's earlier dismissal of the window, once every 15 minutes or once an hour until there are no live/published emergency messages in the feed?
How should the product handle the display of more than one live/published emergency message? The user should be able to view every such message, either in summary view or in full view by clicking on a next/previous button or link.
Deployment
Here we describe how the Plone product will be deployed to sites that are to receive and display emergency web messages.
The emergency web notification product will be installed on the production Plone servers, and so will be available for quick installation onto any Plone site running on those servers.
Once the primary emergency web notification Plone site has been configured, we will need to be able to configure recipient Plone sites so that they can receive configuration updates. Some configuration settings will be local to each recipient web site, but others will need to be 'pushed' by the primary site. Similarly, we may want to have the primary site query recipient sites for their specific configuration settings. For this to happen, the product will have to communicate back to the primary server to register the new recipient site.
This registration/configuration/push framework could be generalized to allow a single Plone site to control the configuration of all aspects of product configuration of a network of Plone sites.
Ideas from Slow Jog
- different types of messages: some that cannot be dismissed
- which sites should be exempt from seeing these emergency messages? e.g. SMP, Wisc. Family Business Forum, IMSSS sites
- real emergency messages maybe should appear at the top in red, while weather notices appear in a portlet on the side
- tie together this with text messaging, email announcements
Implementation Design Notes
results of brainstorming session
Need to track not just alert type but also the audience type. Use a different RSS feed for the different alert types and the different audiences?
Two products:
- uwosh.emergency.master: specifies the type/audience mapping matrix
- uwosh.emergency.client: can specify the web site's audience(s); registers with the master on installation
Audiences all COLS COEHL History Clow Students Reshall A
Types
weather x
psycho
cancellation
facility (gas leak)
hall intruder
alerts.uwosh.edu/alerts/weather/RSS
/psycho/RSS
/etc/RSS
/facility/Clow/RSS
/ClowFaculty/RSS
/Swart/RSS
Use keywords for types and audiences?
Use vocabulary for types?
Create an AlertFolder and an Alert type
How will client know the RSS feed URLs?
How will the master structure/generate the RSS feeds? Folders of alerts (nested as necessary), collections.
When the master adds a new feed (type / audience) it has to tell the clients so they can decide if they need to subscribe.
When a client site changes its audience set, it has to ask the master for all the feeds that now apply.











