I am facing a design problem related to the design of the user notification messages to be used in a web application.
Just for the record, I am working in a JS environment and use a json structure to store user notification messages. However, I think the actual tech stack I use is of no importance here, since this is more of a high level software design problem.
I see two extremes between which I would like to take a middle way:
- Highly generic messages which do not offer great detail, but which make the design maintainable, clean, and uncluttered, as well as applicable for a wide variety of situations.
As an example, think of creating a new book / user / car / etc. in an app. With this approach, the user notifications could be:
- on success: "Entity created successfully"
- on error: "Could not create entity"
Highly informative and customised messages, but which make the design complex. Following the example above, we would need to have three messages for success and three for error:
- on success: "Book created successfully" / "User created successfully" / "Car created successfully" / etc.
- on error: "Could not create book" / "Could not create user" / "Could not create car" / etc.
Furthermore, if entities are added / changed, new messages need to be added; or, even worse, if the success message for instance is changed, it needs to be changed for every entity (book / user / car / etc.). Adding to this i18n aspects, maintainability becomes problematic.
I could cobble together some JS string interpolation to make the solution a bit more flexible, but I'm not sure that is the best approach.
Of course, the examples are a bit trivial and contrived, but I think they illustrate what I'm trying to express. How can one approach this design problem?