Paul Horrocks & Greg TylerStudent Systems Partnership

IS Alerts- v0.3

IS Alerts(SMI004)

SMI004

Table of Contents

Introduction

Pages

Service alerts page (ed.ac.uk)

IS Alerts

Home

Services

A service

An alert

Form

Parent / child structure (optional)

Reports

List pages

Management

Manage services

Manage IS Alerts

Communication

Email

Twitter

SMS

Database changes

Users

Introduction

Our proposed changes to the alerts system are motivated mainly by clarity of presenting information to an external user. We have proposed some structural changes to how alerts associate themselves to services / infrastructure and their impacts on each to better clarify at any given time the status of a service. We are also moving as much of the information as possible away from being hard-coded into the application and more easily customisable. As part of this we’re trying to maintain additional information about the services / infrastructure at the university to aid the process of adding alerts and provide more accurate information on service statuses.

The biggest changes we propose to the alerts system are in the structure of supported services. Rather than having free-text fields of services / infrastructure that can be updated later by Apps Management, we would propose keeping a much more up-to-date list of all the supported services and infrastructure, and when creating an alert have the user add the associations. We would also change the structure of some areas: rather than an event within an alert having a “type”, e.g. “at risk”, “degraded service” we would store the association to each service within the event.

Furthermore we would also like to be able to introduce parent / child relations on services: so if a piece of infrastructure goes down that a particular service depends on, the user will be prompted to add the impact on that service too. Similarly if a service relies on another service, and that goes down, the user will be prompted to add the impact on the child service.

This gives great flexibility and encourages more accurate reporting to our users. We know when EASE goes down that all the EASE-only services will have either degraded service or be unavailable, and we can quickly flag these all from one alert.

A lot of our front-end displays have restructured alert information to be much more focussed on the impact on services, rather than the alert itself, as we believe this to be the primary reason many users navigate to the alerts page.

Pages

Page / Description / Mock-up page
ed.ac.uk service alerts / The embedded service alerts page that will appear on / edacuk-service.html
Home / The home page of the IS alerts application / home.html
Services / The list of all public services / infrastructure in the IS alerts application / services.html
Service / An example of a service page in the IS alerts application / service.html
Alert / An example of an alert page in the IS alerts application / alert.html
History / An example of comparing the history of changes on an alert in the IS alerts application / history.html
Form / The “add an alert” form in the IS alerts application / form.html
Archive / A list view of alerts. Used for “my alerts”, “archive”, “upcoming alerts”, “unauthorised alerts”, “search results” in the IS alerts application / archive.html
Manage services / An example of the manage service page for a specific service/piece of infrastructure in the IS alerts application / manage-services.html
Manage IS alerts / Settings & user account control in the IS alerts application. / manage-is-alerts.html

Update from Design signoff 15/5/14:

  • Agreed to drop the alerts timelinefrom scope for ALL pages
  • Felt it needed a lot more discussion around display of timeline and could be taken forward if more funding was available
  • Concerns around the page being too busy if there was a major alert
  • The information is already on the page in tabular form
  • Issues with ipad for scrolling
  • Layouts of tables should be standardisedacross the system wherever possible

Service alerts page (ed.ac.uk)

Update from Design sign off 15/5/14 for Service Alerts page

  • Alerts timeline dropped
  • A ‘todays alerts’ table needs to be introduced due to losing the timeline
  • Neil had asked if the two pages “edacuk-service” and “home” were both required as they seemed to be showing pretty much the same information. It was agreed to make the ‘ed.ac.uk’ page a duplicate of the Home page - This will mean you get the same look and feel irrespective of which route you take to the system.
  • Agreed to use the old icons – Neil did not think that the new circles and squares are as clear as the ticks and exclamation marks.

Figure 1: New service alerts page on the ed.ac.uk main website

The service alerts page on the ed.ac.uk main website has been redesigned to give a much simpler display of alert information. It focusses much more on service statuses, using ties from alerts to services to display service traffic lights in addition to data about current availability from Site24x7, giving links to the relevant alerts affecting a service when there is an alert active. Green means “fine”, yellow means “at risk” or “degraded service” and red means “unavailable”. This scheme is used for information from both Site 24x7 and internal alerts: so if there is an alert present then we light the service based on that; if not we light either green or red based on Site 24x7 data.[1]

Figure 2: The traffic lights

Greg suggests that the red light should be square to create better distinction for those suffering from colour-blindness or other visual impairments. Paul suggests that that’s unnecessary as the lights should always be alongside explanatory text, and the differing shape makes it look like the icon is trying to convey more information than it is.

The “current alerts” section has been simplified into a timetable-like view of “Today’s alerts”, which for every service affected shows its either planned or unplanned statuses for the whole day.[2]

Figure 3: An alerts timetable. Statuses within a service can be clicked, opening the panel shown below the timetable.

Figure 4: Scrolling to regions where there are alerts not visible (e.g. earlier or later in the day) makes coloured arrows appear indicating the existence of earlier/later events.

Figure 5: When the end-time of events is unknown (in the case of unplanned alerts), they show until the end of the day with a diagonal striped pattern.

All links on this page go through into the actual IS Alerts application.

:

IS Alerts

Home

Update from Design sign off 15/5/14 for Home page

  • Alerts Timeline dropped
  • Agreed to use the old icons – Neil did not think that the new circles and squares are as clear as the ticks and exclamation marks.
  • Neil had asked if the two pages “edacuk-service” and “home” were both required as they seemed to be showing pretty much the same information. It was agreed to make the ‘ed.ac.uk’ page a duplicate of the Home page - This will mean you get the same look and feel irrespective of which route you take to the system.
  • Was it possible to hide the twitter if there hasn’t been a new tweet for 24 hours? This is not a deal-breaker but should ask the developer if there was an easy way to do this (implications over wording and number of times can use the same tweet)
  • Alerts list: Agreed that the font for “Unavailable”, “Degraded Service” act is quite small so the impact of an event should be made more prominent
  • Agreed the sort order of the tables should be by Start time – not when raised
  • Agreed that we should accordion down the alerts
  • Current alerts and alerts not being closed should be in own table at top of lists – this is a MUST

Figure 6: The home page of the IS Alerts application.

The IS Alerts application itself has been redesigned to fit in better with the new University branding, but still exist as an independent website separate to the main ed.ac.uk site. The homepage is very similar to the display on the service alerts page, however includes an additional table with further details about today’s alerts and upcoming alerts.

Services

Figure 7: The new "Services" page on IS Alerts

With the advent of closer service ties and easier availability to manage services within the application, it’s now possible to add more services to the site that don’t appear on the main home and service status page on the ed.ac.uk site, but do appear under “all services”.

A service

Update from Design sign off 15/5/14 for Services page

  • In the individual service page there are 2 options which were felt to be confusing. Should still include ‘No reported problems’ but no longer include ‘Able to connect to the Service’
  • Affected services table should have a column entitled ‘When’ added (lose this info as a result of losing the timeline)
  • Alerts timeline to be dropped
  • A ‘todays alerts’ table needs to be introduced due to losing the timeline

Figure 8: An individual service page.

We’re also introducing service specific pages, which give details on the alerts for the day on a particular service and also all upcoming alerts regarding that service. Here we have provided links to the reporting functionality and an RSS feed of alerts specific to this service, if desired to be implemented.

An alert

Update from Design sign off 15/5/14 for Alert page

  • Agreed Publishing and History sections should betaken out of the Technical information section
  • There should be a ‘published on’ date at bottom of webpage
  • Overview section – if no information in it, it should not show
  • Alerts timeline to be dropped
  • A ‘todays alerts’ table needs to be introduced due to losing the timeline

Update from Design meeting 1/5/14 for Alert page

  • Technical information: Events engineer should not be listed. The container page will give IS helpline contact. The events engineer should be the Event owner and he should only be shown to system admins who can contact that person if event needs closed etc
  • Technical information is minimised

Rather than separate out the alert pages into two separate technical / non-technical views, we have instead reorganised the content. Firstly, we expect front end users to be navigating to individual alerts less, as service pages and the overview now give much more instant breakdowns of the impact of alerts on services.

We have prioritised the service impact at the top of the alert, along with another alert timetabling giving an overview of this. Further down we give the technical information on the alert, publishing information, and a history of changes/updates to the alert, with links through to show these changes.

Figure 9: Alerts history comparison, showing changes made in a version and who by.

Form

Update from Design sign off 15/5/14 for Create an Alert page

  • The field, “Impacted Areas” should be called “Affected Services” as this is what it is called on the main page.

Update from Design meeting 1/5/14 for Create an Alert page

  • Contacts are populated with names - Bryan emphasised that groups should never be included here as there has to be responsibility.
  • All help text should be reviewed
  • Communications: Twitter should be moved down to the Publishers section.
  • Subject of Alerts emails should include: New, Remind, Update, Closed
  • Good if you could identify which fields in the alerts form appear in the alerts pages
  • Agreed that the person who closes the alert should be the Event Contact. The Event Contact is the person who is around when the alert happens and knows what is happening.

Figure 10: The “add an alert” form.

We have simplified the “add an alert” form where possible, whilst also reducing the amount of information held in freetext fields and recording stronger associations to services/infrastructure. Every field has guidance text appearing next to it indicating the type of content that the field should contain.

The planned / short notice / unplanned alerts are all added through the same form now, with javascript applying changes to the form depending on which is selected. An example of this is shown below, with the “work summary” and “reason” fields becoming non-mandatory, and the risk field disappearing.

Figure 11: The form hides certain rows if "unplanned" is selected and makes other fields not mandatory any more, e.g. "Work summary".

The main description content has been condensed into three freetext fields: the description, work summary, and reason. The description is designed to be the public facing easy-to-comprehend description, again focusing on the impact rather than technical reasons.

The impacted areas are now guided to use a multi-select search field to where possible tag services. If the area is not listed, it can be entered manually in the freetext box below (comma separated). These services then appear under each event associated to the alert with prompts to add the impact for each service.

Figure 12: Management information on the event.

In an attempt to close the loop of making sure people are actually marking event s as completed, there will be a new mandatory field here to add an “event contact”. This is the person that is responsible for actually managing the event, and will be sent email notifications at the start/end of each event within the alert.

Person / Involvement
Creator / Initially creates the planned or unplanned alert.
Event contact / Responsible for the alert and marking it as complete. May be the same as the creator, the event engineer or someone else.
Authoriser / In planned alerts, confirm that the alert should be submitted.
In unplanned alerts, notified that the alert has been created.
Publisher / In planned alerts, confirm the alert is suitable to publish.
In unplanned alerts, notified that the alert has been created.

Table 2: People involved in an alert

Figure 13: Adding an event to an alert.

It’s now possible to add events with an unknown end time (unplanned only), set future events to start as soon as the previous one is marked as completed, or automatically mark an event as completed at a set time (e.g. planned maintenance going into at risk). It’s also possible to add more than two events to the alert.

Parent / child structure (optional)THIS SECTION IS OUT OF SCOPE

Figure 14: A sample of the University network; colours are just for display

Optionally, each service / piece of infrastructure within the system can have child services/pieces of infrastructure listed with them, and associated impacts. This will help people fill out the form, as if they select a parent service e.g. EASE to become “Unavailable”, this will auto-populate the event form with the appropriate child services, e.g. MyEd would appear as “Unavailable” but Central Wiki Service would appear as “Degraded Service”. This should hopefully better clarify service statuses at any given time, as it means that for a user trying to access MyEd they would see that MyEd was red and had an alert active about it on the service page, despite the fact it’s an issue with EASE.Users would still have the option to change these impacts, or even set them as “no impact” to not show them at all. See the management section later for how this is managed within the system.

Reports

Figure 15: The reports page. The notes at the bottom are managed through the "Manage IS Alerts" page, shown in the management section of this document.

The reports page has not been altered dramatically from the previous application.

List pages

Update from Design sign off 15/5/14 for Lists page

  • Mailing lists should also be a list

Figure 16: Lists of alerts.

This style of page is used on “My alerts”, “Authorise alerts”, “Archived alerts”, “All upcoming alerts” and “Search results”. It lists the relevant alerts, with links to edit if appropriate.

Management

Manage services

Update from Design sign off 15/5/14 for Manage Services page

  • The parent/child section is out of scope and should be dropped

Figure 17: The "Manage services" page for a service.

Services can be labelled as “infrastructure” if desired, and given a Site24x7 ID (optional). There is an option to choose how the service will be displayed:

  • Show under “all”
  • Show under “key”
  • Do not list publicly

The final option allows alerts to be assigned to the service, which will appear in the timetables on the front page, but the service does not appear listed publicly unless there is an issue present about it. This can also be useful when creating alerts on parent services that effect child services primarily.

Beneath this is the optional section for managing parental / child impacts relating to this service.

Manage IS Alerts

Figure 18: The Manage IS Alerts page contains settings and key operations for the application.

Communication

Email

There are various emails that we believe should remain in place as they are currently:

  • Notification emails to mailing lists arranged when filling in the alert creation form. (This is currently called “publishing lists” on the form.)
  • Emails to authorisers and publishers to notify them when an alert is created and needs their action.

We would also suggest adding the following emails:

  • Optionally, alert creators could opt to “notify the service/infrastructure owners” which would send an email to any mailing lists attached to the services they have noted as being impacted.
  • When events have finished, the event contact should be emailed to ask them to either mark the work as complete or extend the alert. If they fail to do so, it should continue to email them periodically as a reminder.

Twitter

We suggest that a lot of the twitter posts made by the IS Alerts account could be automated, highlighting when key services are currently or will soon be affected and giving and all-clear message when all services are up-and-running.