Microsoft-ui-xaml: Proposal: Update strokes that are currently using 2px to 1px

Created on 10 Jun 2019  ·  17Comments  ·  Source: microsoft/microsoft-ui-xaml

Proposal: Control border stroke consistency

Summary

Across Windows products, applications are moving against using thicker 2px borders in favor of lighter 1px borders. This is to update default control visuals to use lighter borders to align with the majority of the visuals being drawn and implemented (except for GridView).

Rationale

  • Web and app ecosystems are a mix of styles
  • Styles are emerging to enforce purpose and function
  • Apps and shell turn of fstrokes, others lighten and deemphasize
  • New design follow this trend, thus our updates should also follow

Scope

| Capability| Priority |
|:--|:-|
| Developers are able to use WinUI2.2* package and without any work, get the new Windows visual style. | Must |
| Developers have flexibility to style values of border thickness without retemplating. (This is to be tracked by #1031.) | Should |
| Developers and end users experience control update that feel coherent with the same controls used by Fabric, Edge, and Xbox. | Should |

*Just using the next version #.

Design details and visuals

All form type style controls to get 1px border update.
Button
DropDownButton
SplitButton
add link to comp

TimePicker entry point
ColorPicker controls on form
Visual comp

ComboBox entry point
Editable ComboBox entry point (NOTE: Focus state's accent color border remains 2px)
DatePicker entry point
CalendarPicker entry point
Visual comp

CheckBox
RadioButton
ToggleSwitch
Visual comp

TextBox (NOTE: Focus state's accent color border remains 2px)
RichEditBox (NOTE: Focus state's accent color border remains 2px)
Visual comp

TreeView's checkbox
Visual comp

GridView's checkbox
add link to comp

Open Questions

  • Will this impact layout?
area-Styling area-UIDesign feature proposal team-Controls

All 17 comments

Will this proposal address the problem that Xbox has right now where their system apps disable the automatic scaling because they need finer control over the thickness of lines?

I have proposed this myself, and I believe Microsoft did discuss it, but was conflicted. @chigy

buttons
Checks and Radios
combo boxes
Flyouts

Will this proposal address the problem that Xbox has right now where their system apps disable the automatic scaling because they need finer control over the thickness of lines?

@jevansaks , I do not believe so. I believe they use 1px. So we'd have to draw 0.5px to have them draw 1px at 200% scale factor.

Will this proposal address the problem that Xbox has right now where their system apps disable the automatic scaling because they need finer control over the thickness of lines?

@jevansaks , I do not believe so. I believe they use 1px. So we'd have to draw 0.5px to have them draw 1px at 200% scale factor.

Does Xbox still use those thin 1 epx borders for UI elements. I thought that had been superseded by the new Filled in panels with 2 epx spacing between elements.

080173

Of course there could be separate ThemeResources for when the DeviceFamily is Xbox.

Added an open issue.

I posted this in the NumberBox issue, but I think it is relevant here now this is an open issue and a proposal being considered.

If the borders for the Text Field controls, as well as the pickers and other controls which share a design pattern.

Comparing Similar Controls

I have also added the Date/Time/Calendar pickers

Will this proposal address the problem that Xbox has right now where their system apps disable the automatic scaling because they need finer control over the thickness of lines?

@jevansaks , I do not believe so. I believe they use 1px. So we'd have to draw 0.5px to have them draw 1px at 200% scale factor.

Does Xbox still use those thin 1 epx borders for UI elements. I thought that had been superseded by the new Filled in panels with 2 epx spacing between elements.

Removed image

Of course there could be separate ThemeResources for when the DeviceFamily is Xbox.

@mdtauk , you are right, the Xbox design no longer uses the 1px line. However the answer to @jevansaks 's question remains the same. What we are doing here does not address the scaling issue.

I posted this in the NumberBox issue, but I think it is relevant here now this is an open issue and a proposal being considered.

@mdtauk , not sure what you mean? Open issue is merely asking if we make the 2px line to 1px, does it make the control smaller and does it introduce layout issues. I did not mean to say we are redesigning all of the controls? Where did I make a mistake?

Status update: Reviewed with WinUI team and there was no immediate concern with the design's plan here to make the 2px lines to 1px other than the open issue around whether that impacts layout. Will be part of the consideration before a formal pitch is made to WinUI team.

I posted this in the NumberBox issue, but I think it is relevant here now this is an open issue and a proposal being considered.

@mdtauk , not sure what you mean? Open issue is merely asking if we make the 2px line to 1px, does it make the control smaller and does it introduce layout issues. I did not mean to say we are redesigning all of the controls? Where did I make a mistake?

@chigy I think I may have mis-interpreted the intention behind this issue. I thought the issue was asking if the borders should change, and so i contributed to the discussion. I am still relatively new to using GitHub.

The reason I posted the image was to illustrate a conceptual approach to handling borders on control to provide a consistent visual language to indicate how a control would function.

As for the open question :- Most controls with a border are still measured from their outer dimensions. Overlays will now have a shadow, but that shadow is not part of the bounding box for the controls. The buttons within the bordered controls will need some adjustments in padding around the Icon to maintain the touch target sizing.

We discussed as this change when scoping the Density work in 1809. One item that came up was the impact this may have on sight impaired users. I wish I had more concrete data on this, but we didn't pursue it during user research testing due to time and resources. Might be a good open question.

We discussed as this change when scoping the Density work in 1809. One item that came up was the impact this may have on sight impaired users. I wish I had more concrete data on this, but we didn't pursue it during user research testing due to time and resources. Might be a good open question.

Sounds like a good consideration. The focus state border would still be 2 epx thickness - but how High Contrast themes would adapt the controls needs to be considered too.

Will the Calendar Picker/View get a change in border thickness?
image

image

It will change the size of the control so will need some careful thought, considering the space between the 40 x 40 boxes would reduce.

image

image
_This sizing assumes a 2 epx outer border - which could be reduced to 1 epx (2 epx felt more solid)_

Update:
Reviewed the controls once again with the design team and decided to break out the GridView becoming 4px as they are not the same type of issue. I've opened issue #898.

Will the Calendar Picker/View get a change in border thickness?

@mdtauk ,
Thanks for asking. No, it will not.

The problem we are trying to solve with this border thickness update is to make the UI that is always visible lighter weight as we received it is a bit too accentuated unnecessarily. Calendar view's borders are designed so that it works with the hover state that gets user's attention (so we are not making it 1px as it could make it less visible). In other words, we do not have a problem with the CalendarView today so we are not going to go change it unless we identify an issue.

@chigy Thank you for the response

:tada:This issue was addressed in #1172, which has now been successfully released as Microsoft.UI.Xaml v2.2.190822001-prerelease.:tada:

Handy links:

Was this page helpful?
0 / 5 - 0 ratings