Message data model discussion

[folletto]

We need to collaborate across design and dev to clarify what's the data model we want to use. Having the data model helps inform design, in return design will check if the data model works for all our use cases.

The current draft is in code here, translated in simpler terms, this is the i1 draft:

• get_id int
• timestamp timedate
• sender user_id
• recipients users? roles? mix?
• message text? html?

Let's review what we need to do, how much it matches the requirements document, and how well it fits the use cases explored in the designs.

---

Jump to Current Update

The discussion evolved, but no need to read through everything, just check the latest summary and proposal here:
#16 (comment)

[folletto]

Reporting here a note from the i1 design iteration: that design iteration has a lot going on in terms of data model, with optional fields an all. It might not be what we want, but here's the current needs to make that design possible:

• All messages have a message content
• Some message content is HTML
• Optional title
• Optional action (label + URL?)
• Optional image (direct SVG or URL)

Open for discussion.

[folletto]

Reporting here also @daniloercoli's comment

—

Just my 2 cents about the data model from a mobile native perspective.

• If we go with HTML content in the body, i hope it will be restricted to few tags, otherwise it could be hard to represent the body properly in a native web view.
• Action - What the button should do on mobile native? i guess the easiest approach will be to open a web view, both in app or on system browser, and take the user to the proper HTML page within wp-admin.

[raaaahman]

* All messages have a `message` content

* Some `message` content is HTML

* Optional `title`

* Optional `action` (label + URL?)

* Optional `image` (direct SVG or URL)

I like the idea to put image and action in the data model, rather than putting it in the HTML message. This could really ease the communication between frontend and backend IMO.

Although, I would say we should focus on simple messages without any options for v0.1, in order to get a proof of concept ready the sooner we can.

[raaaahman]

* If we go with HTML content in the body, i hope it will be restricted to few tags, otherwise it could be hard to represent the body properly in a native web view.

That's a good point. Do you know about any resource we may use to list the tags we can use, and those we shouldn't?

[folletto]

All good points.

It seems to me however that implementing HTML might end up being way more costly (a large set of elements to support and/or to filter) than a couple of extra optional fields in the payload, at least for the first version.
Would this be a correct assumption?

[raaaahman]

I'd say this is a legitimate concern.

Although, to have compatibility with the existing notices that have been set by plugins and themes, HTML support will be mandatory.

Whether we focus on this task early or late is to be discussed for sure.

[jonathanbossenger]

Some thoughts.

I don't think that WP Notify has to be compatible with existing notices set by plugins and themes. What we're building here will eventually become the defacto way to manage notifications, and so plugin and theme authors should be required to create notifications on whatever way we decide they should work, for the best user experience for the user. Therefore, what we should consider building this so that it's easier for a plugin or theme author to create a new notification with the same functionality that is currently possible with admin_notices, but using WP Notify's functionality.

So, in my opinion, the message field should NOT support HTML in the first iteration. What we can do is allow for an action_link field, so that a plugin or theme developer can add a URL to the field, which allows the user to trigger any internal or external action required. When a plugin or theme registers a new notification, the action_link field should only accept a valid URL, either generated using admin_url() for internal actions, or hard coded to some external action.

I agree with having a title field, but making it optional.

I've started a database-schema.md document, which you can view here, and we can update as we agree on the schema. https://github.com/WordPress/wp-notify/blob/feature/database-schema/docs/database-schema.md

[jonathanbossenger]

I'm not opposed to adding the image field, as an optional field, as well. wp-notify should be opinionated about where that image is displayed, not the plugin/theme author.

[jonathanbossenger]

Additional question, as it pertains to the sender and recipients fields

Should this be an email/list of emails, or a user id/list of user ids? Do we want/need to allow notifications to be sent to users not registered in the system?

[raaaahman]

I don't think that WP Notify has to be compatible with existing notices set by plugins and themes. What we're building here will eventually become the defacto way to manage notifications, and so plugin and theme authors should be required to create notifications on whatever way we decide they should work, for the best user experience for the user. Therefore, what we should consider building this so that it's easier for a plugin or theme author to create a new notification with the same functionality that is currently possible with admin_notices, but using WP Notify's functionality.

In my opinion, there is two possible way of bringing WP Notify into the Core:

1. Either Wp Notify is compatible with the old admin notices and then replaces them
2. Either both systems coexists and WP Notify will slowly become the standard way to go because we provide more features / ease of use.

You seem to suggest we go with option 2, am I right?

So, in my opinion, the message field should NOT support HTML in the first iteration.

In the first iteration, definitely not. In the end though, it will only be possible if we choose option 2 (see above).

I agree with having a title field, but making it optional.
I'm not opposed to adding the image field, as an optional field, as well. wp-notify should be opinionated about where that image is displayed, not the plugin/theme author.

I agree here, standard notification with optional fields sounds less pain to manage. Even if this would probably mean adding more features over the lifecycle of the component.

[raaaahman]

I've started a database-schema.md document, which you can view here, and we can update as we agree on the schema. https://github.com/WordPress/wp-notify/blob/feature/database-schema/docs/database-schema.md

I'll quote myself from October 12, 2020 Office Hours (pretentious I know :D ):

As far as I understand it, @folletto, which is part of the designers in the team, is probably only concerned by the data to display to the user
Mapping this data directly to a database table scheme seems to be going a step too far into implementation details as:

• Not all notifications have a need to be persistent
• We'll probably start off with non persistent notifcations, as these are the existing notifications we want to replace
  I believe that between the database and the view, the data should be filtered between a few abstraction layers, for two reasons:

1. Not all data are relevant to be displayed: the recipient will be well aware that she IS the recipient of this notification, for example
2. We would probably want to let website developers swap the database storage for something else in the future, like a Redis cache or something else, at their very own discretion.