While the GUI is used for most of our user interaction, there are other methods to consider as well. The areas of focus in this episode will be messages and notifications. Much like other details of our solution, these need to be architected. Our goal is to provide a consistent experience and easy use of these tools for implementation.
MessagesOf the two items in this episode, these are easier to design. The architecture will often be a text file with message text values. Alternatively, they can reside in a database. While both options are viable, the database solution tends to be easier to maintain and extend. You will also have to determine whether the messaging approach is a one size fits all solution. This approach may not be correct if you have multi-lingual support for your application. For example, a Spanish speaking user should not see an English message and vice versa.
NotificationsThis means of communication has the same general challenges that we saw with messages. However, notifications tend to go outside of the system. Thus, they have obstacles related to that integration outside of areas we control. These are architectural decisions that should be made early on. It is harder to tack on such a feature down the road.
For example, notifications are often sent that require a response. For messages, it is simple to grab a response in a pop-up window. However, what happens when we want a response to an email or text? There are several ways to design your solution to support these responses (email reader, API functions, etc.). That provides flexibility.
On the other hand, most of these solutions require a certain set of features to be architected and adequately designed. You have to consider security and validation. What happens if your email goes to the wrong person, and then you get an incorrect response?
Timing IssuesAnother issue that you can run into with notifications is timing. Multi-factor authentication often hits this obstacle by expiring secondary auth codes (texted to you or sent via email). These may expire in a matter of minutes. The assumption (correctly) is that the longer those notification specific response links or values stay around, the higher the security risk. While many actions in a system will be serial (for typical systems), the messages and notifications features will rarely be so simple.