When creating or editing multiple forms at once, the text boxes get so small that the text can't be read all at once unless the user clicks into the field and moves the cursor through the text.
Input types with their current behavior and proposed solution for each:
inputs that scroll when the end of the input is reached
types include text, integer, float, color, date, timestamp[tz], search
text and search have an issue based on the potential length of the content
change input type from text to textarea so the content will push to the next line and make the input taller
as the text flows to the next line, can the input be automatically resized?
do this up to 4 rows before adding the scroll bar
this should be applied to all search inputs in recordset views and facets
timestamp, data, color are fixed length values so this shouldn't apply
integer and float would have to be very large/long for this to be an issue
inputs where cursor is not allowed
types include foreign key picker, asset, boolean
we don't allow user to change the input using the cursor and keyboard
value is set after an action is taken (or on load in the case of disabled)
hover over input to show full value as a tooltip
something similar is being done for asset already
make sure content is truncated with ...
markdown, longtext, json[b]
no changes needed since the content is in a textarea that resize vertically as more content is typed into the input
array - can be ignored since the decision will depend on the type of each array element
Our disabled inputs are a special case since each disabled input is different from each other and sometimes different from the original input when not disabled:
text will have the same issue as above
integer, float, color, date, timestamp[tz] don't have an issue for the same reasons as above
foreign key picker, asset, and boolean have the same issue as above
could do a similar solution to text since the controls don't show
array displays as a single line input like text, foreign key picker, asset, and boolean
markdown, longtext, json[b] don't have an issue for the same reasons as above
these are already a resizeable textarea
Notes:
specifically for disabled inputs, the automatically generated text is filled in. We want to differentiate this value from a default value that is showing
should we make the text italic? have the tooltip show italic text?
When creating or editing multiple forms at once, the text boxes get so small that the text can't be read all at once unless the user clicks into the field and moves the cursor through the text.
Input types with their current behavior and proposed solution for each:
text
,integer
,float
,color
,date
,timestamp[tz]
,search
text
andsearch
have an issue based on the potential length of the contenttext
totextarea
so the content will push to the next line and make the input tallertimestamp
,data
,color
are fixed length values so this shouldn't applyinteger
andfloat
would have to be very large/long for this to be an issueforeign key picker
,asset
,boolean
asset
already...
markdown
,longtext
,json[b]
textarea
that resize vertically as more content is typed into the inputarray
- can be ignored since the decision will depend on the type of each array elementOur disabled inputs are a special case since each
disabled
input is different from each other and sometimes different from the original input when not disabled:text
will have the same issue as aboveinteger
,float
,color
,date
,timestamp[tz]
don't have an issue for the same reasons as aboveforeign key picker
,asset
, andboolean
have the same issue as abovearray
displays as a single line input liketext
,foreign key picker
,asset
, andboolean
markdown
,longtext
,json[b]
don't have an issue for the same reasons as abovetextarea
Notes:
disabled
inputs, theautomatically generated
text is filled in. We want to differentiate this value from a default value that is showingitalic
? have the tooltip showitalic
text?