Proposal: Form focus visual

[sravya03]

Proposal: Update form type control's focus visual to be border not fill

Summary

Some of the controls use fill to indicate the keyboard focus state which is jarring when jumping through forms experience.

Rationale

• When going through forms and switching between controls of different types, each has a different focus visual, causing inconsistency and confusion during the scenario. Introducing an updated focus visual across the various controls allows the end to end to feel cohesive.

Scope

Capability	Priority
Developers are able to use WinUI2.2* package and without any work, get the new Windows visual style.	Must
Developers and end users experience control update that feel coherent with the same controls used by Fabric, Edge, and Xbox.	Should

*Timing here is not a commitment, but to follow the release cycle. Just using the next version #.

Design details and visuals

This impacts following controls:

• ComboBox
• DatePicker
• CalendarDatePicker
• TimePicker

Visual comp Visual comp

Important Notes

Open Questions

• How important is this change for us to make now?
• What is WPF and other older platforms doing? Are we deviating from them unnecessarily?

[chigy]

Added open questions

[mdtauk]

I agree that these picker controls are more similar to buttons, than Text Fields, and so should follow the conventions of the Button's hover, focus, and pressed states.

This would make the control a single clickable control - unlike an editable text field.

It is for this reason I chose in my design suggestion to not make the date and time picker separators touch the top and bottom borders, so they would not be confused with a separate button within a text field. It makes it clearer that the entire width of the control is one tappable surface.

[Felix-Dev]

Perhaps my last comment on any UI proposal here in this repo but I just have to say:

This image you posted, @mdtauk, is the first one where I can say the updated controls do look quite nice.

A suggestion (perhaps not my last comment after all): Looking at the separator in the search box (calendar date picker) and then the time picker separators: How would the separator for the time picker look for those controls above? That small padding somehow adds a very nice elegance to the spearator and I'd like to see the search box (date picker) with such a separator as well.

(Firefox address bar example, please excuse the crude image cut.)

[mdtauk]

Perhaps my last comment on any UI proposal here in this repo but I just have to say:

This image you posted, @mdtauk, is the first one where I can say the updated controls do look quite nice.

A suggestion (perhaps not my last comment after all): Looking at the separator in the search box (calendar date picker) and then the time picker separators: How would the separator for the time picker look for those controls above? That small padding somehow adds a very nice elegance to the spearator and I'd like to see the search box (date picker) with such a separator as well.

(Firefox address bar example, please excuse the crude image cut.)

It wasn't for aesthetic reasons why I made sure the separator looked disconnected, but the search button touches the top and bottom.

The search/calendar/combo box uses a button that has it's own hover and pressed states, that can be used without activating the editable text field beside it.

The date and time pickers are a single tappable control - and the separators are there only to distinguish the three pieces of content.

[Felix-Dev]

(Again Firefox, picture taken with mouse hover over the "..." (centered dots)).

As you can see, you can still have a button having its own states and also "touch the top and botton" and still have a separator which has some top & bottom padding. It will also depend on how the hover/pressed stated will look like, perhaps the button foreground could be color-changed instead of the button background? The latter would perhaps make a padded separator more complicated. Which is a point anyway...For this thought, I'm treating the vertical line in the search box and date calculator picker as a separator for the actual displayed content and the action button included in the control. In your examples above, it seems to be the left border of the actual action button. Again something to think about, perhaps.

[mdtauk]

@Felix-Dev in that Firefox example, you have two separate controls which are separated, but both related to Zooming.

Edge(ium)

Chrome

Firefox

Each do it similar but different.

What you are seemingly suggesting is

Textfield, Separator, and Button - that is two separate controls

[Felix-Dev]

control = [control1 | control2] ([] = border of control)

As you correctly showed, the change could be making the control2 borderless (i.e. the date calculator button, or the search button) and replace its left border with a padded separator. Hover/Pressed states for such a button could then be indicated by changes of the button foreground, that is the icon changes in color. An example for that can be seen in Edge (Chromium) with the tab-audio button toggle (Mouse hovering changes the color of the icon, and not the background).

So depending on the hover/pressed visual indicator, visual impact could be small (you still have a clear indicator for the different parts a control like the Search box (AutoSuggest box) is made of).

[mdtauk]

@Felix-Dev That is not much different to what there is now. Except controls like the Password Box and the Auto Suggest Box - do not have any visual indication that the control contains a button, other than hover and focus tabbing.

Sure you could add a separator for those and only have the full border around the button on hover - but my approach was to make it immediately clear where controls are multiple controls combined, and those which look like separate controls but aren't. Whilst ensuring all the controls would look comfortable and consistent together in a form, as well as not too heavy or strong to become overpowering and thus, intimidating.

I think having this in the Rest or normal state, will add confidence to someone using a tablet or touch device, where to place their finger - whilst making the distinction between the ComboBox and Editable ComboBox clearer than it is at present.

[mdtauk]

[chigy]

I agree that these picker controls are more similar to buttons, than Text Fields, and so should follow the conventions of the Button's hover, focus, and pressed states.

This would make the control a single clickable control - unlike an editable text field.

Image removed

It is for this reason I chose in my design suggestion to not make the date and time picker separators touch the top and bottom borders, so they would not be confused with a separate button within a text field. It makes it clearer that the entire width of the control is one tappable surface.

@mdtauk , good suggestion. Though this is not the right place for that proposal... If you were to create a new proposal, I'd be happy to continue iterating with you on your design idea and if lands on where it seems like a good improvements to the control, I could help propose it back to design team. No promises anything would happen, though. So you could well be wasting time. I am being frank so there is no misunderstanding...

That said, your suggestion is not at the place where I could do that.. It may look nice when the control is closed but how about when it opens? The lines are touching top/bottom because it has continuation with the open UI.

Please move this to a new proposal so we can keep this item to focus rect proposal only before you continue responding.

[mdtauk]

@chigy That is fair enough, it was your design spec that led to me looking at how those Picker controls could be adapted. For what it's worth, the expanded state would not need to change much (except 1 epx borders) as it is three controls side by side with their own interactivity, and the two buttons below.)

[chigy]

Status update: Reviewed with WinUI team. This one will require more value proposition.

[chigy]

Status update

This proposal is moved to the future backlog for a later discussion. Until then, this item will not be acted on. Community members are welcome to continue adding comments, feedback, where this change is useful, or not so useful, etc. @mdtaulk , @Felix-Dev FYI

@mdtauk , if you want to push for the vertical line that is not touching the top/bottom of the container, please open a separate issue since it is not part of this proposal.

[mdtauk]

@chigy Done #899