Jacob Brown, software development team lead at Milk Moovement, joined us to chat about Notifications!
You can watch the 8-minute video below, scroll to read the transcript or read our shorter case study here!
Content:
- [00:00] About Milk Moovement and the role of notifications
- [00:38] What were the notifications like before NotificationAPI?
- [01:10] How did this [custom coded notifications] impact your team?
- [01:47] How did you evaluate NotificationAPI?
- [02:49] How hard was adopting NotificationAPI?
- [03:30] How was the customer support?
- [4:30] What headaches have gone away with NotificationAPI?
- [5:52] Would you build your own notifications in the future?
- [6:35] How much time have you saved in the last few months?
- [7:15] What keeps you up at night? Is it notifications?
- [7:52] Describe NotificationAPI in one word
About Milk Moovement and the role of notifications
Jacob Brown: Milk movement is a supply chain logistics company. And we deal specifically with dairy and milk. And what that means is we gather data on the producer side, so farms, and data on the processor side, so plants that process milk, as well as transportation information as well. We combine all those things, to give information to producers around the quality of their milk, how long it will take to transport the milk, where it's going, things like that.
What were the notifications like before NotificationAPI?
Jacob Brown: Creating the notifications, extending them, modifying them. Also, allowing for reuse was a huge problem as well, because the templates themselves were not reusable. Because they're HTML templates, you'd have to go in and create a brand new HTML template, copy and paste from the other HTML template, things like style sheets, which can be 1000s of lines long would have to be copied in between different HTML templates. So it was very, very cumbersome to do a lot of those activities.
How did this [custom coded notifications] impact your team?
Jacob Brown: So there was a lot of... people didn't want to go in and be assigned a task that has to do with notifications because of how cumbersome and how many pieces they would have to touch, how much of that have to change. The regression testing was really bad because all of the templates would have to be looked at and make sure that none of them were, were... no, no mistakes were made on other templates that wouldn't be there copied over or modified. So that was that was the general atmosphere around notifications.
How did you evaluate NotificationAPI?
Jacob Brown: This is a great question. We have a senior developer on our team who is very good at being devil's advocate. So I came with a, I knew of NotificationAPI, because I came from somewhere that had leveraged it before. So I suggested NotificationAPI as the solution here. And he said, "Yeah, what else is out there?" So I said, "good question." So we did look at a few other solutions. One of them was OneSignal, I think I got you to do a comparison between OneSignal and NotificationAPI. There's another solution as well, very similar to OneSignal, but I can't remember the name off the top of my head. But looking at those solutions, they're very geared towards gathering information from users. So sending out surveys or update notifications to be like, hey, we need to send this to audience to be like, "Hey, this is a new feature, go check it out."
How hard was adopting NotificationAPI?
Jacob Brown: So it was it was fairly straightforward. We built a service that plugs into this more complex computation beast. And that just sends out our notifications, very straightforward. Almost no work on our side, the only thing that we do is different than maybe most in your system is forceChannels. Right now, we allow users to select what channels they want to receive in our system, rather than using your user preferences built-in system. So because of that, we had to implement forceChannels. But that was extremely easy, and super straightforward, too.
How was the customer support?
Jacob Brown: Yeah, you guys are great at support. Always super active. If I have a question you get back to me in minutes, if not, within a day's time, which is awesome. I mean sometimes I'll message you at 2am. I obviously don't expect that. But yeah, it's great. It's super awesome. You're also on top of things like letting us know when you may see bumps, such as due to infrastructure, cloud provider issues that are out of your control, which is super great. As well as working with us to understand roadmap, things that are up and coming, sitting down with us and trying to understand the root cause of a problem so that you can not only fix it now, but hopefully implement something that will help make it easier in the future. Yeah, it's great, support is great.
What headaches have gone away with NotificationAPI?
Jacob Brown: I'd say the biggest one is ensuring that our templates produce the correct look and feel of the notification that we want to send. So we used to have HTML templates with CSS style sheets, they were all embedded in the same HTML template, because that's how email has to work. And it's quite easy to accidentally change a value or change a class name, or forget to change the class name somewhere else, we had a problem with indentation at one point that completely broke a template. So definitely, the biggest thing that's gone away is dealing with the template, the headaches of all these templates. Some of the other things that have gone away is making sure users have received specific emails. So we don't have to anymore.. where we used to have to send them to a bunch of different internal users to make sure that they could check to see whether or not the notifications have been received or not. A lot of those headaches just disappeared, because you guys always send the notifications whenever we tell you to send the notifications. And when you don't, you let us know. I guess those are the two main headaches that have kind of gone away.
Would you build your own notifications in the future?
Jacob Brown: Like I said, I've done this three other times before now. And each and every time it's a huge pain. It's such a, in my opinion, a waste of time. I've done it three times before. So it feels like I'm treading water that I should, should already exist or should already, I should be able to leverage some other way. So for my opinion, it's not a good use of time to implement your own system when you could leverage something like NotificationAPI. Like I said, our notification system is still extremely complex and has a lot of complexity to it. We still leverage NotificationAPI for what it's good at. And I think that's, that's what I would do next time if I had to implement it again.
How much time have you saved in the last few months?
Jacob Brown: Think about the new notifications that we've implemented, the changes to the templates that we've made, as well as the abilities of NotificationAPI that didn't exist in our previous system... probably on the order of weeks of time that saved over the last, what is it now? Five, six months? Yeah, I'd say order of weeks. I'd say that'll continue. We save probably three days of development, each time we make a new notification that has to start from a new template inside notification system, probably save three days worth of work.
What keeps you up at night? Is it notifications?
Jacob Brown: Haha... What keeps me up at night? Yeah, notifications definitely was something I was concerned about before. Not really anymore. I think our new custom system along with NotificationAPI kind of puts most of those concerns to rest. The only thing that keeps me up at night notification-wise is debugging notifications. But that's that's coming, the logging of notifications, I think will resolve all issues that I would have for notifications. And beyond that, it's it's going to be, I guess, cherry on top kind of stuff.
Describe NotificationAPI in one word
Jacob Brown: I think if I had to describe NotificationAPI in one word, it'd be simple.
If you also want to time and avoid headaches with notifications, we invite you to check out NotificationAPI.
.svg){kind=small}