Problem Statement
In a recent rountable about the upcoming Database Tables feature, it was mentioned that database tables would be limited to one canvas column per table. This limitation creates a significant regression in UI design for complex “app-like” docs. Currently, Canvas columns are used as a workaround to provide a spacious, and visually distinct input area in Detail Views. Text columns, by comparison, feel cramped and lack the visual cues (padding, custom height) necessary to guide users through long-form data entry.
Proposed Solution: “Text Field UI Settings”
Instead of adding more Canvas columns, we should empower the Text column with specific layout-level settings in the Detail View editor. This allows for a visual cute to enter content larger than a single line, but is lighter than a full Canvas.
Key Requested Settings:
- Minimum/Maximum Display Height: Allow builders to set a height (e.g., 200px or “Auto-expand”) so the field doesn’t look like a tiny sliver on a large page. Setting a max height would help reduce scrolling fatigue if a user is trying to skip over sections.
- Rich Text Styling Toggle: Ensure consistent access to the “slash command” menu within these expanded text fields. (Maintain what exists today, but make it clearer to a user that they can use rich text styling)
- Container Styling: Options to enable or disable a background fill color or a defined border to distinguish the input area from the rest of the canvas background.
- Placeholder Text: The ability to set custom prompt text (e.g., “Describe the project goals here…”) that disappears upon typing.
- Show/Hide Column Type Indicator: Since a text column is basically the default, the visual indicator that it is a text column seems unnecessary and visually distracting and should be used only when there is a restriction on data type.
This would immediately reduce the need for multiple canvas columns in a table, making tables (database and standard alike) lighter, and reduce friction in the adoption of the database tables feature.
