Define form input elements

[joseegm]

Goals:

1. Define all elements needed for the different inputs types on Form Input inventory #733
2. Define a conventional naming for the elements on 1.

Preliminary

[denisewildner]

Regarding the "Limited":
There should also be a validation if user enters too much text.

What about bigger text input fields aka text areas? Do you want to incorporate them here, too. Or just 1-line-fields? For bigger text input, we usually show 3 lines and, if there's additional text, there'll be a scrollbar. Sometimes the input fields "grows" with the amount of text a user enters. We would need a defined rule how it should be. I prefer the latter one, because text is better readable without scrolling.

[denisewildner]

There is also some input fields with button, like search and edit.

[joseegm]

Yes. Text areas have to be included.

Text area rule on #735 (comment) sound good. We'll incorporate that.

Case for #735 (comment) will be the Form Input with Action as per the cases enumerated on #733 (comment)

Validation stuff will be addressed on #736

[joseegm]

Form input main elements

Element	Description
Label	The label related to the immediate from input.
Input	The main element where the interaction happens.
Icon	Display icons inside the input element. Can be left or right aligned.
Icon + Action	The icon can perform an action; I can be differentiated from the icon without action by a different color, with more contrast. It will always be displayed to the right.
Unit	Will display information about the units (scalar) belonging to the input.
Action Button	Can perform an action
Counter	Displays the remaining characters left on the input

[jeannewalters]

@joseegm Did you have the chance to look at what we are putting together for form fields in Smart Edit/Personalization? It might be good to piggy back off of that since we've had many discussions and tests related to these? https://hybris.app.box.com/files/0/f/23235450874/1/f_163459049832
We are still testing the toggle, read only and enabled fields. Did Irla happen to walk you through this last week when you talked?

[jeannewalters]

@joseegm I would watch out for the read only fields. Because of the layout, it was hard to not have them in the same position as without the field. In Smart Edit/Personalization, we are looking at a gray box behind it to make it look better on the page. This is another area where it helps to see the combination of the states of these fields in a single form rather than seeing them as separate entities.

[joseegm]

@jeannewalters Didn't Talked with Irla about that yet. But we will.

Agree with the layout on Read Only input fields. We'll address that using the pertinent padding on the HTML/CSS. Also like the idea of having a visual element to keep them in place. Gonna try that.

The toggles will be treated on a separate issue.

States and validation are been treated on #736.

Back to this issue in particular.
You think that the elements defined on #735 (comment) are sufficient to cover all cases we are addressing?

[LeoT7508]

@joseegm @jeannewalters

Per Jose:
"@jeannewalters Didn't Talked with Irla about that yet. But we will."

If this is the case, should we wait to have a bigger conversation about leveraging what SmartEdit is already using before starting to recreate this?

[joseegm]

@LeoT7508
The only thing new as per designs on #735 (comment) concerning the input lines is the up/down buttons on the number input; that we'll add. The up/down is a new element not present on #735 (comment).

Still we need to finish #733, #736 and #738, before starting the visuals on #737.
First 3 should be ready by midweek.

[xak]

Every form element supports a readonly attribute that renders the form element uneditable. https://www.w3.org/TR/html5/forms.html#the-readonly-attribute

From a programatic standpoint, it should be easier to output the same forms for read vs. edit mode and toggle only attribute. And the form fields maintain a tab order that a readonly DIV would not. Is there a reason we are using non-form elements.

<div class="form-group">
	<label class="control-label">Service name</label>
	<p class="form-readonly-text {$modifiers}">
	Content
	</p>
</div>

In the case above, the label is used incorrectly and could be confusing for a11y. I'd like to see real life examples of readonly implementations to better understand the use cases.

[joseegm]

Form input main elements

Element	Description
Label	The label related to the immediate from input.
Input	The main element where the interaction happens.
Icon	Display icons inside the input element. Can be left or right aligned.
Icon + Action	The icon can perform an action; I can be differentiated from the icon without action by a different color, with more contrast. It will always be displayed to the right.
Unit	Will display information about the units (scalar) belonging to the input. displayed to the left or to the right.
Action Button	Can perform an action.
Counter	Displays the remaining characters left on the input.
Spin Box	Displays up/increase and down/decrease buttons that modify the numeric value accordingly.

[joseegm]

With the updated on #735 (comment) we cover all Elements for the Form Input field, with element names and the expected behaviour now.

Details and Visuals and alignments for the Read Only Form Field will be addressed on #733 and #737 respectively.

[joseegm]

This is done.