• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

SEE ALSO: LEP/FeatureNotifications

Overall summary

Currently an orange bar appears at the top of all Launchpad pages 15 minutes before a scheduled update, giving the time remaining until Launchpad goes offline.

We should build on this idea to communicate more service-affecting issues and new feature information to Launchpad's users.

Use cases

Planned downtime: Launchpad is due to go offline in the next 48 hours for a planned roll-out. A site-wide notification ensures all current Launchpad users have the opportunity to learn about the upcoming disruption.

Reduced service: Loggerhead is having difficulties. The rest of Launchpad is running fine. A notification show on code.launchpad.net pages tells the right people that we know about the problem (communicating that we're on top of it, thereby inspiring confidence, and saving them from having to tell us) and sets their expectations for when it might be fixed.

Upcoming major change to an existing feature: we're planning to change the format used for sending commands to the bug tracker's email interface. This will have a major impact on our existing users. We should use a site-wide notification to fore-warn of the change and also consider adding a line to email responses sent by the email interface.

New functionality, changes to existing functionality: depending on the scope of the change, post a notification on

Assumptions

• People will notice and read a notification at the top of the page.
• Many people start their Launchpad visit somewhere other than the front page.

Design

The notification must be:

• noticable but not annoying
• easily hidden/collapsed
• precise - e.g. give the start and predicted end times of planned downtime, in the user's time zone if logged in
• concise but not misleading - there should be a link to more information, either in project announcements or the news blog (TBD).

We have to make a decision about how many notifications can be active at any one time: should it be one or many?

Learning from Facebook, Google and RTM

Facebook handles notifications really well. It uses two methods:

• a small notification icon in the bottom-right of the screen (not page, it's static) that handles notifications relevant to your friends in Facebook
• a dismissable top-of-page notification window for service-related announcements.

Google Calendar and Gmail use small, red, "NEW" icons next to new features. They're easy to ignore and link to further information when clicked.

Remember The Milk uses a modal Javascript pop-up to announce new features, when you first visit following an update.

Facebook screenshots

Implementation

• We need both site-wide notifications and notifications limited to a particular section, perhaps decided by sub-domain.
• The author of a notification should always link to more information: usually on the blog or identi.ca status feed but the implementation should allow for any URL.

Do we allow only one notification at a time or many?

One

Pro: once someone has read and hidden the message, the interface returns to normal. This means that the notification bar remains something rare and so noticable.

Con: we may have more than one important message at any one time.

Pro: knowing that we can display only one notification at a time should mean that we use the facility sparingly and so make it less likely that people become blind to the notifications.

Many

Pro: it is entirely possible, once we get into the swing of using notifications, that we will concurrently have more than one message suitable for distribution that way.

Con: to retain their noticeability, notifications should be rare.

Site-wide, not section-wide?

At the August 2008 Releases team sprint we discussed whether we should allow for notifications that appear in one part of Launchpad only. We decided that notifications should be site-wide because:

• We want the notifications to be relatively rare. If messages could be limited to certain sections of Launchpad, it may encourage people to use them for less than urgent messages and so devalue their interrupting quality.
• Adding granularity to where the notifications are displayed will complicate their development and increase the risk that they won't be

implemented.

• If a message is sufficiently important as to warrant a top-of-the-page notification, it should be seen right across Launchpad as it's possible that the people who need to see the message will not visit the affected part of Launchpad in time.

However, all discussion since has emphasised the importance of granularity.

Automatic expiry

To prevent the risk of notifications becoming stale, they should have an automatic expiry. The author of a notification should be able to override this with a manual expiry time and date.

Read once

We should consider how to ensure notifications remain distracting enough to be noticed without becoming annoying. Should a notification disappear after a logged-in individual has seen it once? Should we require that people manually acknowledge warning messages, to ensure they've seen them?

• Seen it once, or explicitly marked it as "read"? -- JonathanLange [2009-12-02]

Comments

JoeyStanford: There has been some side discussion about the best way to do this. This is the summary although it's not something that has been official decided upon.

• Perhaps we can use site message
  • convert site message to use admin panel
  • for production set site message colour to dark red with white lettering
  • admin panel should let the admin specify
    • the msg text
    • hyperlink part of the message text (or a read more item). e.g. "Launchpad will be offline for an upgrade on 21 Feb from 02:00 UTC" with a link to the blog post by Matt Revell
  • enable a count-down timer if possible to be displayed
    • one way to do this is to set a standard date on the panel for the event occurrence and LP calculate the "t minus" value. e.g. 18 hours from now
• the notifications must be current (i.e. we can't continually broadcast LP going down in 10 hours on each page load) I don't fully agree with this but I was overruled. We have a DB model that enables this already.

MartinPool:

• I don't understand the point above "the notifications must be current." If it means that we should show them only immediately before they're going to happen then I disagree.
• Enough people should have access to set these that in any group responding to a Launchpad emergency at least one person will be able to do it. (So it might be enough to allow just OSAs or team leads to change it.)
• I think showing the UTC time plus a countdown will be enough.
• It might be good to allow different colors depending on severity.