Thinking about Error Messaging

Error messaging is critical to provide user feedback when a button does not perform actions. This can be done in Tulip easily using the “Show Message” trigger. However, there are many ways to organize your triggers to show these error messages. Creating consistency across your apps can have tremendous value for long term readability. This post will walk through my philosophy for building error messages into my apps, but I encourage you all to come up with your own and align on best practices with your fellow app builders!

Imagine you are building an app step such as below where you would like to require your users to enter certain fields to submit the form.

image

Below are pseudocode explanations of two very simple approaches. The first might be called “Negative Erroring” and the second would be “Positive Erroring”. Note that having descriptive trigger names can be extremely helpful to any future app editor eyes (even your own).

image

Currently, these two triggers do the exact same thing and have an equal number of trigger statements. However, I find the second approach much more scalable. This is because you are able to easily separate and add extra error messages for different missing fields. See here:

This is a simple example where perhaps separate error messaging was not required, but in complex scenarios the ability to divide your error messaging can be critical. This is why I strongly recommend using “Positive Erroring” instead of “Negative Erroring”.

What are your thoughts? Does anyone have other tips and tricks for writing error messages which are easy to read?

3 Likes