Feature: Nuwe Notifications

As we’ve worked with more and more clients building health, wellness, nutrition, fitness and medical apps, we’ve seen repeatedly the use case for actionable data.

But, how do we action data?

The go-to tool kit for actionable data currently is in the form of notifications. Typically, these could be native mobile or browser push notifications, but equally, emails, SMS or just dynamic views and in-app messages.

The point is, that these notifications are responding to the data, taking action according to the rules developers and product designers have created.

Late last year, we conducted some prototypical tests based on my vision for how this feature could / should work for developers building apps and more importantly, experiences, for their users.

In simple form, what I have in mind is a cross between a rudimentary Push service, like that of the late Parse and something with richer capabilities of logic based rules engines, as you would find in a service like Intercom.

And Parse’s passing gives us a whole new opportunity, to serve the Parse customers with a new solution to their push notification needs.

The idea is, in addition to sending ad hoc targeted notifications, we can create background processes that listen out for triggers, logic based rules engines created by developers and product owners based on the different data their app has access to from the user.

Take the example above in the screenshot, I want to:

Send John a push notification when he hasn’t exercised for 20 minutes.

In other words

Send John a push notification when he hasn’t exercised for 20 minutes.




Recipient options

  • USER (specified by id or email)
  • SEGMENT (segment of users based on some filters)
  • ALL (send to all users)

Notification Options

  • Push Notification
  • Email
  • SMS
  • JSON (websockets / PubSub)

Events Options

  • Descriptive (exercised, eaten, tracked) with parameters, e.g. exercised(run, walk, swim), eaten(protein, carbs, fibre). No params apply globally to all sub-types
  • Data attributes e.g. user.steps, user.sys, user.bpm
  • Operators e.g. equals, greater than, less than, is exactly, contains etc.

Time Interval

  • Type e.g. seconds, minutes, hours, days, weeks, months, years
  • Amount e.g. 1 :smile:

Perhaps we can look at having multiple conditions in an engine, that would make sense.

I’m very keen for the engine to be natural language based, as much as possible. This will be a challenge, but worth fighting.

The interface for constructing messages with access to variables should be intuitive and not require too much learning of specific syntaxes or the data model naming, so context menus and pickers will be needed here.

Now, with the integration of Parse Server, I’m planning to delegate the core responsibility for the notification server to the library’s existing notifications API’s.

This will give us access to native push notifications via the Parse SDK’s out of the box, along with access to the notifications in our Cloud Code implementation.

That leaves us to tackle a few key things for my vision of this feature, before we can get into the richer UI and engine creation features.

  1. Enabling the upload of certificates etc. through the Nuwe developer platform to our Parse-Server docker container. This should give us access to notifications via the Parse-Server SDK and Cloud Code.
  2. Update Nuwe by ripping out our old Grocer gem implementation and instead, using the Parse REST API to send notifications.

Fortunately, we’ve now done 1.

Next is 2, one can deduce.

I’ve elaborated the wireframes / sketches on this a little, so felt like sharing…

The project itself hasn’t moved on much while we really stay focussed on the core Parse-Server services, but it’s certainly still in the pipeline - being able to action data like this is going to be super useful - I need it personally!

The basic flow is that, given an existing User database, we can start to segment our Users based on the data we store, like you would in a service like Intercom.

These User groups, or “Segments” can then be stored for easy access later. The Segments could be static or dynamically update, depending the on the data filters applied. We can easily create Engines, and allocate our Segments to them.

The Engines will listen out for conditions to be met and then trigger an action from the server, in our case typically, a notification (Native Push, websockets, email, SMS, webhook)

Not only can we set this Engine to run once, but it can run continuously, listening out for the parameters of the Engine’s rules to be met.

The idea is to see if we can leverage Parse Server and provide this capability not only for our Parse-Server instances but also for the core Health API’s on Nuwe too.