For the alpha release, how should we allow the user to enter newlines within cells?

[seancolsen]

The problem

For our "Text" type, all of the Postgres types permit newlines. Data entered from outside Mathesar may contain newlines. So we should be able to support editing text with newlines. That means all DB configurations for the "Text" Mathesar type should support the ability to enter newline characters. What is our desired UI for entering newline characters?

Comparisons

• AirTable has two separate types "Single line text" and "Long text" which behave differently.

  

  With "Single line text", it's not possible to enter newline characters. Pressing Enter saves the cell and moves the cell selection to the row below, and modifiers such as Ctrl will not affect the behavior.

  With "Long text", pressing Enter inserts a newline.

  When you add a new column, the default type is "Single line text".

  

• LibreOffice and Google Sheets both let you enter newlines in every cell by pressing Ctrl+Enter (at least on Windows/Linux -- not sure what the shortcut is on Mac OS).

  Pressing Enter saves the cell and moves the cell selection to the row below.

Possible solutions for entering newlines in Mathesar

There are lots of different ways we could handle this.

We may even want to allow users to configure the behavior on a per-column basis. Kriti says we'd likely want to offer this configuration as a display option (and not a separate type like AirTable), but that we don't want to aim to do that for the alpha release.

For the alpha release we need to pick a sensible default that is easy to implement and unlikely to present friction for new users.

Here are a few options...

(A) Ctrl+Enter

Mimic the behavior of LibreOffice Calc and Google Sheets and closely follow the behavior of the default column type in AirTable.

Downsides:

• The feature is not very discoverable.
• It's hard to use when you're composing long text.

(B) Enter

Pressing Enter inserts a newline.

Downsides:

• Save-on-Enter a common behavior on all spreadsheets and for the default AirTable column type, so users may be frustrated by our divergence.
• It raises the question of whether we'll want to add Save-on-Enter for other column types which do not permit newlines (e.g. number).

(C) Modal

AirTable has a modal editor that's pretty slick. We could do something similar. If you want to enter multi-line text, you're probably going to be unhappy with such a small text area anyway.

Downsides:

• We'd need to figure out how the user would activate the modal.
• It's more work.

(D) different behavior depending on column settings

We could choose between some of the above options depending on the allowable length of the text in the column. For example, a VARCHAR(255) column might get behavior (A) whereas a TEXT column would get behavior (B).

[seancolsen]

Personally, I would like to do (A) for now and explore (C) and (D) after the alpha release.

[ghislaineguerin]

Given our current roadmap priorities I also believe that A is the best option. I think in the future exploring the modal option is a good idea, we have planned editing of lists and we might need to fit more content than what is manageable using a dropdown only or expanded cell.

[pavish]

I would also like us to go with (A). It would be better if we could display a hint somewhere saying press Ctrl+Enter for new line while the user is editing.

We can explore (B) and (C) after the alpha based on user response.

I don't think we should ever go with (D), especially since VARCHAR and TEXT both support new lines in the backend.

As a general rule, I would like us to establish that for cells, the frontend should not restrict any value which is accepted by the database. The db accepts new line characters and we should allow it.

[kgodey]

I'm in agreement with (A), with the caveat that Cmd + Enter should also work for Macs (this is the case in Google Sheets).

I don't have any opinions about (B), (C), or (D) at the moment, we can reevaluate after the alpha release.

@pavish said:

As a general rule, I would like us to establish that for cells, the frontend should not restrict any value which is accepted by the database. The db accepts new line characters and we should allow it.

I can imagine having a display option of "Single line text" that the user can turn on, in which case we wouldn't accept newlines. This would violate that rule, but based on user request.

[pavish]

@kgodey

I can imagine having a display option of "Single line text" that the user can turn on, in which case we wouldn't accept newlines. This would violate that rule, but based on user request.

I don't think we should have it as a display option. It would make things more confusing since the DB can accept multi line characters and the cells will reflect that, but the display option would not, and the user won't know why. It will create an unreliable user experience.

I'd suggest creating a custom database type like 'SINGLE_LINE_TEXT' where we restrict new line chars at the db level. It will still be a part of 'Text' mathesar type and we can still keep the checkbox but within 'Database options' instead of 'Display options'.

[kgodey]

@pavish That makes sense.

[seancolsen]

a custom database type like 'SINGLE_LINE_TEXT' where we restrict new line chars at the db level

I like this idea a lot. To implement post-alpha, of course. But this seems like the way to go.