Notifications Centre

The Notifications Centre is a feature available to all users in LiteFarm. It is accessed on the status bar and houses all the relevant notifications for that user.

 

Notifications serve as the communication layer for ensuring that individuals on the farm learn about important farm events as quickly as possible. In most cases, notifications are system generated messages based on some change of state in the system, rather than a user specifically creating a notification. These messages are sent to users to bring something to a users' attention. In some cases a notification will go to an individual while in others it may go to a whole farm. The key attributes of a notification are:

  • Timeliness: Notifications will be generated for events where timeliness is the key attribute. For example, creating a notification when the details of a task have changed when someone will do that task later that day is incredibly valuable as long as it’s received prior to doing the work. If it’s received after the task has been completed, it’s basically worthless. As such, we strive for near real-time notifications and acknowledge that notifications quickly become stale. Another consequence of this attribute is that notifications are mostly immutable. The only attributes that will be modified after creation are around the status of the notification, rather than the content.

  • Audience: Notifications need to target the right audience. For example, modifications to an existing task (from the timeliness example) are only relevant to the person doing the work. Other individuals would quickly learn to tune out notifications if they are not consistently relevant for the notified audience.

  • Brevity: Notifications are a “sneak peek” into events on the farm. The Notifications Centre should give the user a “window” into the relevant happenings on the farm with the option to drill-down into the events that catch that user’s attention. As such, we need to be efficient with how we describe a notification. Brevity is more important than completeness.

 

Notification Attributes

This is an incomplete list of attributes that notifications should have. It does NOT describe the architecture of how these attributes should be stored or related.

 

Attribute

Data type

Entered / modified at…

Required?

Example data

Notes

Attribute

Data type

Entered / modified at…

Required?

Example data

Notes

Title

String

Entered at creation, immutable

Yes

“New task assignment”

See above. Also needs to support custom task types

Body

String

Entered at creation, immutable

Yes

“A planting task has been assigned to you.”

Assigned via actions rather than being editable via the UI

Icon

Asset

Determined by initiating process

Yes

 

Notification art for the Notification Centre will be defined based on the process that generates the notification. In many cases, this will be based on the reference to the notifying object, e.g.:

  • If a task, show the task type icon for that task

  • If a location, show a generic location icon

  • If a user, show a generic person icon

  • etc.

Reference to notifying object

Ref: Record_id

Entered at creation, immutable

No

 

  • See “Take me there” in detail view above for an example

  • This reference will also serve as the foundation for “related notifications” and threading on the notification detail page described below

Notification scope

Enum

Entered at creation, immutable

Yes

 

  • Defaults to “farm-wide” unless provided

  • To start with, notifications can either be for a specific user or for all users at a farm

  • Implementation should leave the door open for role based, access-based (e.g. extension worker), and all users at all farms

Alert

Bool

Entered at creation

Set to FALSE when a user views the notification centre

 

True or false

A notification is Alert = TRUE when it is created and become FALSE when the user views the notification centre (but not necessarily the notification detail). The alert, describes where the “bell” on the status bar should have a red dot or not.

Status

Enum

Entered at creation

Modified when viewing the notification detail or a user applies a new status

 

“Unread”

  • Defaults to “Unread”

  • Other valid values: {“Read”, “Archived”}

Base model attributes

 

 

 

 

Implements https://lite-farm.atlassian.net/browse/LF-294

  • CreateByUserId = null

  • OwnerUserId = null

  • AssigneeUserId = null

 

Notification threading

 

There are some cases where a notification has been posted, and before being viewed becomes irrelevant or less relevant. For example, a user may be assigned a task and then that task is deleted or re-assigned. To make sure the user is presented with the most relevant and timely notifications for a particular thing, we need to keep track of a thread for each referenced object. With acknowledgement of our key attributes of timeliness and brevity, this stack should be:

  • heavily geared towards the most recent, relevant notifications in the thread

  • very brief in how notifications in the thread are displayed

One visual example of how we could show this threading is shown below:

For an edge case where a task has been changed many times:

Note our focus on pushing the user towards the most timely notification if they are looking at an older notification for a particular notification thread.

Thoughts on pagination

 

We may or may not need to support pagination with notifications. One argument against implementing a pagination strategy would be that notifications are only valuable when recent and quickly become stale. In this case, we could likely get away with the idea of only returning the X most recent notifications. However, this would hamper future implementation of searching and filtering.

Answered questions

 

Q: What clickable actions can happen from the notifications tile?

A: https://lite-farm.atlassian.net/browse/LF-2150

 

Q: When is a notification marked read?

A: When it has been viewed by navigating to the https://lite-farm.atlassian.net/browse/LF-2150.

 

Q: What types of statuses can a notification have?

A: It can be unread, read, and archived. Additionally, notifications can also be marked as an alert.

 

 

Q: When should a notification be an alert? When is the alert removed?

A: A notification should be an alert for the time period between when it has been created and the next time a specific user clicks on the Notification Centre (as described in ). A notification does NOT need to be viewed to have alert set to FALSE.

 

Q: What types of notifications are there?

A: Here’s a(n incomplete) list:

 

Q: Should notifications be searchable / filterable / sortable?

A: Notifications will be searchable. Users can do a search against the title and body of a notification. Since older notifications are significantly less valuable. Notifications will not be filterable or sortable, since the majority of the value of a notification is based on it’s timeliness and not on it’s ability to be found at a later date.

 

Q: Will users be able to configure what types of notifications they would like to see?

A: Not in Q1 2022. This is a feature we would like to introduce in the future.

Open questions