:tangerine: Design Bite: :bell: Notifications in the UI

887×256 14.6 KB

Every weekday I post a small Design Bite, covering a feature, question or topic for the Folio UX/UI. I encourage you to give constructive feedback on what I present, so we can adapt the system if necessary, to make sure it will work for you in practice

Today’s menu: Notifications in the UI

Please note: This post is not about the technical term of notifications, which might cover much more than what is described here. This is merely covering what is considered a notification from a user’s perspective—UI notifications like we know them from mobile apps, desktop apps and social networking platforms.

The current thought of notifications in Folio is to provide the user with a unified notifications view like we know it from mobile and desktop operating systems as well as social networking platforms. Through this unified view, the user will be able to view all notifications from the system, or to filter notifications based on which app provided them.

##3 Levels of notifications
The system would support a few different levels of UI notifications out of the box:

1. Basic notification—the type that appears in the unified popover for notifications (aka the notifications center)
2. Toast notifications—which will appear in addition to the basic notification, for urgent or very important notifications
3. External notifications—to begin with, email, but in the long run, potentially any kind of external messaging service (SMS, Slack, phone calls, etc.—this overlaps with the topics of integrations with external platforms as well as automation, both of which I will cover in other Design Bite posts at another time.

##1. Basic notifications

1280×799 41.6 KB

In the notification center, the amount of unseen notifications would be indicated with a small badge containing the amount of unseen notifications for all apps. Opening up the popover would also allow the user to see how many unseen notifications exist for each of the apps.

##2. Toast notifications

1277×803 37.1 KB

Toast notifications are useful for apps that provide a type of notifications that require immediate attention. They appear as a small box containing a message, on top of the page you have open at a given time, and provides a shortcut to the app in question to the user. The user can also close the notification if it gets in the way of something they are doing at that moment. If nothing is done from the user’s side, the notification disappears after a few seconds. All notifications that appear as toasts, must also appear in the general notification center for later access—if the user missed the toast or wishes to view the message again a little later.

##3. External notifications
External notifications might be set up to communicate with the user’s email address and would be controlled by the user on a per-app basis. (See more below)

##Notification Preferences

1280×800 53.8 KB

For each app, the user would be able to change the notification preferences—whether to receive notifications at all, and in which format. This setting would be reachable from the settings menu for the individual apps as well as a unified Notifications Settings view.

##Do not disturb schedule
In the future we might also think about creating a do-not-disturb schedule (like we know it from e.g. Slack) depending on the user’s working hours and time zone, but as we are thinking about notifications currently for the first version, this is not something we are prioritizing.

Are we missing something? Comment here and let us know!—Your feedback is essential to make sure we build a system that works in practice and not just in theory !

@filipjakobsen So, where in this scheme do operational warnings come up? I’m thinking of the things that tell an operator that a circulation they’re trying to perform is blocked or a cataloger that the record that they’re trying to save has an error.

. . . and just curious, why Toast?

Toast notifications: because they pop up like toast does from a toaster. Or a least they did when they appeared at the bottom of your screen / page. Now the term is used for any kind of non-modal notification element.

This topic has been rattling around in my head. I’ve been thinking about it in terms of Resource Sharing, because it is a domain I’m very familiar and it is a domain that involves long-running tasks (over days and months) and involved multiple people.

I’m thinking about if the style of notification is a preference. I’m wondering if it is determined by the current context, what the library staff is doing at the time of the notification, how important a particular instance of a notification might be to them.

If I am actively engaged in the subject of the notification, would I want to see a toast because the notification is likely to be about and is likely to affect my current task? Conversely if I am not actively engaged in the subject of the notification, would I want the notification to go into notification center so as not to interrupt my current task?

Is it more on a case-by-case basis? Scenario: I have initiated an automation workflow that is going to start some time to complete. Instead of twiddling my thumbs waiting for the workflow to complete, I engage in something else. But the automation workflow is my primary task right now. As soon as it completes, I want a toast notification because I do want the secondary task interrupted so I can re-engage in my primary task. But I might not want all automation workflow notifications to be toasts; just this one at this particular time.

In the same context I’ve been thinking about targets of notifications.

If I have been working on an interlibrary loan request, I want to be the target of the conditional response because I probably have the contextual knowledge to action the notification.

However if no one has been working on the interlibrary loan request, because to date the request has been unmediated and handled automatically, who is the target? The whole institution? The team? A random member of the team who happens to be logged in at the time of the notification?

In vSphere notifications are not just unread / read. You can acknowledge a notification to signal to your colleagues that the issue behind the notification is being worked on, but the issue hasn’t actually been resolved. This facilitates implicit team coordination. It works very well in our IT team, but I’m not sure if it would work in teams of library staff.

@jim.nicholls - lots of food for thought here . . . not only for resource sharing, but also circulation, course reserves and especially acquisitions.

I don’t think that there is a good universal way to set this up. Every institution’s workflows and staffing would need a different process. The next big trick would be how and at what level you’d set the customizations, individually or could some of it be done at a supervisory / departmental level.

Also, being aware that if only a single person is receiving a particular notification what happens if that person is out sick or on vacation. could you set back ups or a cascade if an acknowledgement process failed?

Very good thoughts, Is a notification valid if it disrupts my current task?

Not even modally, but psychologically. This is akin to email notification. The advice to turn off notifications in your email client is that they psychologically interrupt you, even encouraging you to multitask, which decreases productivity.