Geary Notifications Design

There are a number of things people may want to be notified about when using Geary:

• Ongoing background processes (e.g. mailbox synchronisation, message sending)
• Ongoing foreground processes (e.g. account, folder and conversation loading)
• Transient status (e.g. new message received, conversation moved, message sent)
• Recoverable errors (e.g. message not sent, failed to connect, incorrect password, desktop service error)
• Ongoing status (e.g. offline)
• Ongoing errors (e.g. password entry cancelled, host not found, disk full, database errors)

Some of these support interaction (e.g. move mesage) or require it (e.g. incorrect password) to and may lead to a more permanent error (e.g. if the password dialog is cancelled). Error notification should provide people with a means to access technical details and to take corrective action if possible. Most are context-specific, in that they are specific to a particular account, mailbox or message.

Three design elements in the GNOME HIG support are suggested for notifications: system, in-app and info-bars.

System notifications

System notifications are used "to inform the user about events they will be interested in while they are not using your application". Per the HIG, system notifications most useful for notifying people of new messages. Since people may receive large numbers of messages, there should be at most one system notification per account, and that should show the number of messages received for that account since it was last viewed, and who sent them.

E.g. If the inbox for an account already has 10 unread messages, when a new unread message is received then a notification for that one message should be shown, if another is received shortly after then the notification is updated to show two unread messages. Once the inbox is shown, the notification should be dismissed and the count reset.

Titles and bodies

The title should specify how many new messages have arrived and the account (since the notification is account-specific), and the body should indicate the message's senders and in the case of a single sender, the subject. E.g. for a single new message:

• One new message for Home
  Received from Alice Person: My message subject

For two new messages:

• Two new messages for example@gmail.com
  Received from Alice Person and Bob Person

For multiple new messages:

• 12 new messages for Work
  Received from Alice, Bob, Charlie, Dan, Eve, Frank, and others.

In this last case, we want to limit the list of names to something short, maybe around 6, use first names only if possible, truncate if very long, and should be sorted from most recently received messages to least.

Actions

The default action for each notification should be "Show", which when triggered should do a number of things: Bring a MainWindow to the foreground (opening one if needed), select the account for the notification in the window, ensure the folder with the most recent unread message notified about is selected and the conversation is visible in the conversation list, select the conversation itself if autoselect pref is enabled, then clear the unread count and dismiss the notification.

Since each notification may display more than one message from more than one conversation and folder, it doesn't make sense to include other conversation-related actions such as "Mark as read" or "Archive".

One possible secondary action might be "Quiet", to mute notifications from that account for some period of time (1h?)

Command notifications

In-app notifications are used "to inform the user about an event that is relevant to their ongoing use of an application. They are best used to provide immediate feedback". Since in-app notifications are transient (they automatically hide after a timeout) these should be used for notifying the user of the completion of user-initiated operations such as sending a message or moving conversation, if the operation is successful (for important operations) or not (for all operations).

Since reporting errors via this mechanism may mean the user might miss the error message, and to provide a means of accessing technical details or a means of recovering from the error, an account or folder specific error status icon with popover should also be displayed for important errors — see below for details.

If operations can be undone, then the in-app notification should have an Undo button. If an error has more information, it should have a Details button. Notification text should be context specific:

• One conversation trashed [Undo]
  Two conversations moved to My Label [Undo]
  Sending message to Alice Person... [Undo]
  Message to Alice Person sent
  Error sending message to Alice Person [Details]
  Error marking as Junk [Details]
  

Minor operations that have already has an obvious completion state such as marking as read or flagging as important should only display an in-app notification if an error occurs carrying out the operation.

TODO: Work out what the Details button should do.

Application-wide status

InfoBars are used "to communicate a particular state about a particular content item or location". Since they are persistent, but are also very obvious, heavyweight controls, they should only be used to notify of important, persistent states or problems, that will probably require user intervention.

Examples of appropriate uses of info bars are:

• Indicate a missing password, in the event of the user cancelling a password prompt

• Indicate the app being offline or paused

• Indicate database or disk space problems

The title should describe the state or error, and the message provide more detail, rather than a description of any actions the user can take. Since these represent persistent states, they should not have a close button, rather an action button if possible to allow the state to be dealt with. E.g.:

• Geary is offline
  Messages will not be sent or received until reconnected.

  Geary is paused
  Messages will not be received until resumed. [Resume]

  Password required
  Messages cannot be sent for $ACCOUNT without a password. [Set Password]

  Server not found
  The server $SERVERNAME cannot be reached. [Details] [Change]

  Database Problem
  The email database for $ACCOUNT is corrupted and cannot be read. [Details] [Recover]

Ongoing processes

Foreground processes

Ongoing foreground tasks include loading the conversation list and loading a specific conversation. Since these are substantial UI elements that are always present in a MainWindow, we can use these to display their own indication of loading status.

To remain reactive when the user selects a folder to display, the conversation list and conversation view should be immediately cleared. As messages are loaded, a "loading row" is added that displays a loading spinner and "Loading $MAILBOX" message. As conversations are loaded, this is kept last and hence will float to the bottom and eventually go off-screen. After loading has completed it can then be hidden.

Ideally, the conversation viewer would not need a loading spinner. The next/prev conversation should be preloaded at idle and hence always be shown immediately. Currently, a loading spinner is shown in the centre of the widget if loading takes more than a second. Ideally, the viewer would use up/down wipes to transition from one conversation to the other, in which case a similar "loading row" approach could be used in cases where preloading is still catching up or skipping down the conversation list.

If an error occurs, it should be displayed as a placeholder in the relevant widget.

Background processes

Since mailboxes won't have icons in the redesign of the sidebar, we have an opportunity to use icons to draw attention to specific accounts and mailboxes with ongoing background processes and errors.

Background processes can be indicated by displaying a spinner for the specific account (if account-wide, e.g. opening the account) or for a specific folder (if mailbox-specific, e.g. for sending messages or background sync). The spinner should have a tooltip providing more information:

• Connecting to account
• Sending message
• Background sync 42% complete

Likewise, accounts and folders with ongoing problems can be flagged using an icon. Here, the icon's tooltip can report an error message. Additionally, if a flat-when-not-hovering menu button that on-click displays a popover, the popover can provide details and action buttons that provide additional information and a means of recovering or reporting the problem.

TODO: An alternative mechanism would be to provide a "Account problems" or similar line for an account in the sidebar when it has reported some errors. Again, clicking on this would display a popover with additional information and action buttons.

Design Feedback

Please add feedback here or send an email to the mailing list