Hello bettes@,

I was reviewing these mocks and discovered they show an error condition string:

https://folio.googleplex.com/chrome-ux/mocks/329-future-web-pay/latest/desktop#%2F15-card-add.png

The ccard field shows that the textfield may need to contain text and also display an error string, so my thought about displaying it like placeholder text won't work.

This mock shows the dialog content area growing in size to accommodate displaying the error string. I'm not sure how well that works in practice - it would be better if the layout already allowed for the appearance of the error string, although that's not ideal either. The error state needs to discuss accommodating this string (however it should be displayed).

These strings should really probably be more wordy - if you're not color blind you see the red and the error message, but if you can't see the red it's not as clear why the string is showing up. However they probably need to remain terse so that localized versions don't run the risk of wrapping.

From an engineering perspective, the decision we need to make is whether this error string should be considered "part of the control" or considered a separate label that is often placed near this control.

The design questions that answer this are, are there cases where these sorts of textfields have a requirement that we would display a message about in some other way (a different position, an icon instead of a label, etc.)?  Or are verification requirements for textfields always displayed in this way?  If the latter, we should probably consider these strings an optional element of the textfield itself.

shrike also raised the question: when this message appears, how should surrounding elements move?  Should they shift by the full height of the message line, or should there be some kind of "reserved space" ahead of time for these?  I'm not sure what his concerns with the former were -- I think either one of these can work, though implementing the latter is probably slightly easier.

Setting to P1 since it seems like this requires more design/engineering thought than the typical remaining Harmony Controls bug and thus we want to begin tackling it sooner.

Re: c#2, neither solution (reserved space nor moving controls) is appealing. If we go with reserved space the default layout looks clunky, but sliding controls to make room is inelegant (plus it causes a shift in the height of the dialog). Given the two I would opt for sliding controls, though, because it makes the default layout (no error) look better.

I think there's just one spot, maybe two, in Chrome desktop where this kind of textfield appears.

over to me to follow up with UX about this.

Decision here is to go ahead and display the error string and have that cause a relayout, which may affect dialog height.  I suggest that the error state only be toggled when the user tries to "submit"/"accept" the dialog, so it's not bouncing on and off as people type.

It seems like we use this very few places: the edit bookmarks dialog, and payments.  For now, we can one-off the implementations of these.

Leaving as P2 for now.  We could go to beta without this given how few places it touches, but we should probably fix for phase 1 for stable.

The NextAction date has arrived: 2017-08-04

I chatted with sky@ a little about how to implement this. There are basically three approaches we can take:

1) Have Textfield support this internally. This would involve some serious hackery, since the error label should be inside the bounds (in the Views sense) of the textfield, but outside its border and not have its background. There's also difficulties to do with the focus ring and the bounds for a11y and hit-testing purposes of the control. So, this seems like it would be pretty fragile and difficult to implement.

2) Add a sibling view to clients of Textfield that use ::SetInvalid(). For clients that use GridLayout, this is easy; they add another row to their GridLayout, and add the sibling view to the GridLayout cell immediately below the Textfield, and when there's no error that sibling view (and thus the row) collapse to zero height. Unfortunately, one of the clients, CardUnmaskPromptViews, uses a vertical BoxLayout of horizontal BoxLayouts. In that situation, the error label ends up in a separate horizontal BoxLayout from the textfield it's describing, so there's no good way to ensure that it ends up and stays underneath the textfield. We could change CardUnmaskPromptViews to use a GridLayout, but keeping the look specified in the mocks while using a GridLayout would involve quite a few padding cells & generally lead to an ugly GridLayout.

3) Create a new composite view, something like TextfieldWithErrorIndicator, and replace client uses of Textfield that need ::SetInvalid() with a TextfieldWithErrorIndicator. However, since all the existing clients lay the Textfield out as part of a row of controls, the rest of that row would also grow in height to match the TextfieldWithErrorIndicator, and since row elements are generally vertically centered, the rest of the row would end up vertically centered with respect to the composite control (ie: no longer vertically aligned with the Textfield). This isn't good either.

Probably the best tack is (2), but it would involve a considerable amount of delta in clients of Textfield :(. Given how difficult this looks to be, are there any other feasible options for accessibly indicating error state?

We definitely don't want to change complicated layouts like the middle dialog in https://folio.googleplex.com/chrome-ux/mocks/329-future-web-pay/latest/desktop#%2F19.png to GridLayout.

If we had proper baseline alignment, we could do (3) fairly easily by having everything in a row be baseline-aligned instead of vcenter-aligned, and having the composite view report the baseline of the top child as its baseline.  But we don't have that, and it's too late in phase 1 to add it.

Instead, I propose we go the composite view route.  To fix the vertical positioning, any time we transition from "no errors in this row" to "errors in this row", add padding or margin equivalent to the height of the error (i.e. the "additional height" of the composite view compared to its old state) to the other views in the row.  Remove this padding if we drop to the "no error" state.

One way to implement this, practically, would be to implement the composite view as some sort of generic wrapper that can accept any view as the "top child", and then wrap every view in a row that can show any errors.  Then tell the composite views on a row to size themselves as if they're showing the error label (whether or not they are) if any one of them is showing an error label.