What's the best terminology to use in our UI for the concept of NULL?

[seancolsen]

In #774 we agreed that it's important to distinguish between NULL and empty string. We should present them as different values and concepts to the user.

What do we want to call the NULL value within our UI? How should we display it? Should it always be consistent? Or are there certain contexts in which it should be displayed differently?

From @kgodey here:

I'm not sure about the UI text being "Allow NULL", we're trying to balance showing DB concepts with being friendly to people that aren't familiar with them I would prefer a less technical word that's routinely used, like perhaps "blank".

For another example of how we're simplifying database concepts for non-technical users, see the Mathesar data type mapping.

Also see: Word suggestion - "empty" vs "blank" on the UX Stack Exchange.

[seancolsen]

My opinion: I don't care too much if we call it "NULL", "null", "Null", "Empty", or "Blank". What care most about is that we maintain consistency across the entire UI with respect to this value.

That said, I have a slight preference for using NULL. Always in uppercase. Why? Because I think most users would equate "Empty" and "Blank" with an empty string, conceptually. The word NULL, communicates more clearly the conceptual difference. But I don't feel too strongly about this and am happy to move forward with other words.

I also think it would be nice to display it with a distinct style everywhere like italics or monospace, but I don't feel as strongly about that. It might even be nice to make an inline component solely for the purpose of displaying (and consistently styling) this value.

[seancolsen]

The more that I think about this, the more that I feel like our choice of wording might now matter too much as long as: (1) we're consistent, and (2) we format the word distinctively from the text we use to display values. The gray text that we currently use to display "null" within cells, goes a long way towards communicating the conceptual difference. If we decide on the word "Empty" or "Blank". I think it will help to format the word in the same distinctive manner even when that word appears in a form label or select option. I kind of like the idea of giving it a subtle gray background and some border radius too.

[seancolsen]

One more thought, which is an argument for "NULL"...

If we choose a word like "Empty" or "Blank" that is more easily conflated with an empty string, we're going to need to lean more heavily on the custom formatting I think. For example, if a user wants to filter to see all the null values, they'll add a filter condition by selecting their column and then selecting an choice for "Is NULL" or "Is Empty" or "Is Blank". If we go with "Empty" or "Blank", the user might expect to see empty strings after applying their filter. But if we stylize those words, then we reduce that expectation. The problem is that stylizing words within a select option is extra work for us. Our components are not set up to make that easy right now. It's possible, of course, but will take longer. If we go with the word "NULL", I think we can more safely get away with displaying the value unstylized in some contexts, like option values for select elements.

[kgodey]

I think we should go with "empty". I don't think the word we use matters that much either, but I think "empty" and "blank" are more understandable to non-engineers than "null".

I like the idea of formatting the word in the same manner wherever it appears. @seancolsen I think you should implement it when you're working with it and we can adjust styling if needed in a later iteration.

[ghislaineguerin]

I think, given our recent discussions, that we should go with NULL. The new designs I'm prototyping for setting up foreign keys will be based on maintaining the DB concepts and helping users understand them based on context, and I feel it would be more consistent if we stick with NULL.

[kgodey]

After further consideration (and @seancolsen and @ghislaineguerin's comments), I too think we should go with "null" since it's the most accurate. We may want to have a little help icon/tooltip next to it that explains what it is for non-technical users, but we can do that in a later milestone.

[mathemancer]

I'm a little slow to get to this, and while I do think we can use null, the closest more common English word (to me) would be "undefined". This works better than blank or empty with the mechanics of null in the DB:

'a' = undefined   -> undefined

makes more sense than

'a' = blank   -> blank

All that said, I agree with others that the term isn't as important as consistent use of it.

[pavish]

If we use undefined, there is a good chance that technical users assume that it's a bug on the frontend.

[kgodey]

I'm assuming we are going with "null" and marked this discussion as done.