Notifications

Notifications are a huge part of a typical user's interactions with baseline, and are an integral part of what makes baseline so powerful. For people who are just starting to journal and may not be as comfortable with it, it's easy to journal for a few days in a physical book and then put it off. Many people aren't around their journal for most of the day, and putting journaling off to the next day is easy -- and once the writer has put it off once, the habit gets weaker and weaker. Putting journaling off also creates a psychological block to starting it again. With every passing day, there's more to write about, and thus more time has to be set aside to "catch up" in the eyes of the journaler. This makes it less likely they'll go back soon, if at all.

Notifications help solve these problems. People almost always have their phones on them, and most young people see incoming notifications within seconds of them arriving on their phone. Notifications can also keep coming whether or not they're acted upon, serving as a constant reminder that the user needs to journal.

Now, the easy way to do this would be to send a random notification sometime in the day asking the user to journal. However, there are more considerations that just that.

Psychological Considerations

(1) One of the first issues I noticed when designing notifications was that they didn't come at the right times. A random notification might come at an inopportune time, and at least for me, I'm much more likely to ignore notifications until much later if I can't act on them right now. So, instead of having random notifications, baseline allows users to schedule their notifications, down to the weekday(s) and time. When I was in school, my class schedules were different for each day, so different schedules for different weekdays were added to ensure I always got notifications at opportune times. (2) By allowing for multiple notifications, users can also scale their use of baseline up or down depending on where they're at with their mental health.

(3) Another important psychological consideration with notifications are time effects. People often show patterns in how they feel depending on the time of day. By getting users to mood log at semi-consistent times, they get a more accurate picture of their mood over the long term, because some of those time effects are eliminated, and they can actually see how their mood itself is changing over time. Thus, baseline does not allow users to schedule random notifications.

(4) Finally, one of the biggest psychological considerations made when designing the notification system on baseline was something I like to call notification fatigue. On many mood logging apps, notifications come every day, and if users don't act on them, they stack up. As they stack up, just like with the physical journal I mentioned earlier, the user has a bigger and bigger barrier to getting back into journaling. It's less likely that they'll go back, and when they do, they'll likely spend so much time trying to catch up that they won't give an accurate point-in-time for how they're feeling (which is really what baseline mood logging is all about). I saw this empirically with a couple of my friends. To combat this, baseline only shows one notification, max. Whenever a new notification is delivered, older ones are automatically cleared.

Implementation Notes

(4) Solving the problem of notification fatigue was an interesting implementation problem, to say the least. Scheduled notifications aren't sent via push (they're Local Notifications), and they can't run code in the background when sent, so there's no way to clear older notifications, or to just not send the new notification depending on older notifications. There is a way to run code in the background, though -- Data-Only Push Notifications. These notifications are purely for delivering data to apps in the background, with no indication to the user that they're being delivered or processed. Thus, I decided to implement this by sending a data-only push notification to devices every few hours (see functions/index.ts, function sendCleanUpMessage). When devices get this message, they clear all but the latest notification from baseline. This is implemented in AppDelegate on iOS at application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any], fetchCompletionHandler completionHandler: @escaping (UIBackgroundFetchResult) -> Void), and on Android in the custom push-notifications Capacitor plugin we made in MessagingService, onMessageReceived(@NonNull RemoteMessage remoteMessage).