Fabric에서 사용하는 버튼 등의 둥근 모서리보다 더 넓은 프로젝트여야 합니다.

• 버튼
• 스피너/프로그레스링
• 불확실한 진행률 표시줄
• 확인란 및 라디오 버튼
• 콤보 상자 및 텍스트 필드
  등등.

Xbox의 요구 사항은 계속 다를 것이지만 새로운 Xbox 콘솔 세트가 출시되면 Microsoft 디자인 팀이 함께 협력하여 WinUI 3.0 및 Xbox Next에 대한 모든 것을 제때에 맞출 수 있습니다.

Fabric은 현재 크로스 플랫폼 및 PWA 사용 사례에 대해 많은 관심을 받고 있는 것 같습니다. 따라서 Fabric은 최소한 Compact Density의 경우 청사진이 되고 최소 측정값으로 2px에서 4px로 이동한 다음 터치 어포던스를 추정하고 누락된 제어 상태를 채웁니다.

ThemeShadows 는 둥근 모서리를 설명해야 합니다. 그리고 아크릴 표면은 배경에서 높게 보이도록 내부 및 외부 경계를 포함해야 합니다.

@mdtauk 요구 사항 번호 4에서 알 수 있듯이 Xbox에서 이 변경 사항을 합리화할 계획이 있습니다. 즉, 이 특정 기능은 작업 범위를 명확하게 유지하기 위해 둥근 모서리로만 제한됩니다. 당신이 가지고 있는 다른 디자인 제안에 대한 별도의 요청을 자유롭게 여십시오.

BTW, 아크릴 표면의 내부 및 외부 경계에 대한 귀하의 피드백을 잘 이해하지 못합니까? 현재 귀하가 지정하는 두 개의 테두리를 사용하지 않기 때문에 귀하가 언급하는 Xbox 디자인입니까?

@chigy Xbox의 경우 물론

Fluent 팀이 동의했을 수도 있고 동의하지 않았을 수도 있는 내부 figma 디자인 사양을 알지 못하지만 Buttons 이상이어야 합니다.

Fluent Web은 둥근 모서리에 대해 2px 모서리 반경을 사용하지만 Fluent XAML은 기본 측정으로 4px를 사용하는 경향이 있습니다. 그렇다면 FluentWeb과 동일한 메트릭을 사용하는 CompactDensity 템플릿이 있습니까?

Xbox Fluent와 Fabric 공유 컨트롤의 비교 이미지를 만들고 어떻게 다른지 확인했습니다. 따라서 이러한 컨트롤 템플릿을 살펴보는 동안 수행해야 하는 둥근 모서리 이상의 것이 있습니다.

Xbox 항목 무시

@mdtauk , 이것이 버튼에 관한 것뿐이라는 인상을 받으려면 명확하게 지정하지 않았을 것입니다 ... 안심하십시오. 그렇지 않습니다. 요구 사항 번호 1 및 해당 하위 항목을 참조하십시오. 이것은 모든 컨트롤에 관한 것입니다.

디자인 파일을 게시할 기회가 없었지만 우리가 계획하고 있는 모서리 반경은 실제로 2px(오버레이 UI의 경우 4px)입니다. 저는 실제로 Fabric 팀(예: Fluent Web)과 매우 긴밀하게 협력하며 이러한 변경 사항을 함께 평가합니다. 그렇긴 하지만 정확하게 일치하게 만드는 것이 우리의 목표는 아니지만 사용자가 나란히 볼 때 일관성을 유지하고 가족의 일부로 느낄 필요가 있습니다. 요구 사항 번호 4를 참조하십시오.

따라서 이러한 컨트롤 템플릿을 살펴보는 동안 수행해야 하는 둥근 모서리 이상의 것이 있습니다.

작업 중이지만 하나씩/케이스 바이 케이스로 하고 있습니다. 우리는 변화를 위해 물건을 바꾸지 않도록 이치에 맞는 변화를 만들 때 주의를 기울입니다.

@chigy 감사합니다 감사합니다 감사합니다!

이러한 디자인을 커뮤니티와 공유할 수 있다면 좋겠습니다. 우리 모두는 컨트롤과 UI가 어디로 가는지 보고 싶을 뿐만 아니라 변경 사항이 구현될 때 불일치를 지적하고 미래를 보장할 수 있기 때문입니다. 제어 제안은 집에서 느낄 것입니다!

Fabric Web과 Fluent Web이 앞서 있는 것처럼 보이며 XAML과 WPF 및 WinForms/Visual Styles가 따라야 합니다!

@chigy @mdtauk 여기에서 내 응답을 참조 제안에 관해서도 사용자와 Fluent Design(FD) 팀 사이에 활발한 교류가 있기를 바랍니다.

@mdtauk FD와 일치하도록 WPF/WinForms 컨트롤을 업데이트하는 요점을 계속해서 제기하고 있습니다. Win10 네이티브 룩앤필이 포함된 비 UWP 앱을 제공하고 MS 팀에 UWP/WinUI를 결정하는 데 가장 잘 사용되는 유한한 리소스만 있는 경우 WinUI 를 사용 하게 되므로 저는 이에 반대합니다
그래서 @YuliKl @chigy @pag3 : 이것에 대해 논평할 수 있습니까? 기본 WinForms/WPF 컨트롤이 새로운 FD 모양으로 업데이트될 예정입니까, 아니면 WinUI 컨트롤이 제가 아는 한 가장 최신의 최고의 디자인 기능을 위한 방법이 될 것입니까?

이 이미지를 Numberbox 제안에 게시했지만 업데이트 중인 TextBox 컨트롤과 관련이 있을 수 있습니다.

장애인 국가의 경계선의, FocusReveal 집중 상태에 국경.

"스핀 버튼" 스타일은 검색 버튼, 비밀번호 공개 버튼, 일반 텍스트 버튼에 적용할 수 있습니다.

초점이 맞춰진 상태에서 테두리/제어 요소 주변의 그림자가 너무 강해 보입니다. 그림자가 필요한 이유는 무엇입니까? 현재 버전(테두리 색상만 변경됨)은 완전히 괜찮습니다. 그림자는 컨트롤(요소)이 전경으로 올라가고 있음을 암시할 수 있습니다. 이는 3D 환경에서는 의미가 있을 수 있지만 확실히 고전적인 데스크탑 환경에서는 필요하지 않으며 일부 사용자는 주의를 산만하게 만들 수 있습니다.

초점이 맞춰진 상태에서 테두리/제어 요소 주변의 그림자가 너무 강해 보입니다. 그림자가 필요한 이유는 무엇입니까? 현재 버전(테두리 색상만 변경됨)은 완전히 괜찮습니다. 그림자는 컨트롤(요소)이 전경으로 올라가고 있음을 암시할 수 있습니다. 이는 3D 환경에서는 의미가 있을 수 있지만 확실히 고전적인 데스크탑 환경에서는 필요하지 않으며 일부 사용자는 주의를 산만하게 만들 수 있습니다.

포커스가 있을 때 컨트롤 주변의 광선은 FocusVisualKind.Reveal이며 시스템에 의해 제어됩니다. 불투명도와 크기를 정확히 일치시키는 메트릭이 없기 때문에 대략적으로 표시해야 했습니다.

광선이 테두리 색상을 변경하는 것보다 초점을 훨씬 더 명확하게 만들 것이라고 생각한다는 표시로 사용하십시오.

@mdtauk , 각각 이 호의 대화를 둥근 모서리로 제한할 수 있습니까? 저는 특히 둥근 모서리에 대한 피드백을 받고 싶습니다. 그리고 이 대화가 그런 목적으로 여기에 왔을 수도 있는 사람들에게 너무 혼란스러워지는 것이 두렵습니다.

즉, 당신이 보여주는 것은 나에게 초점 표시 동작처럼 보입니다. 우리는 포커스 상태를 더 강하게 만드는 방법을 조사했고 일부 사용자 연구를 수행했으며 @Felix-Dev가 그의 응답에서 언급한 것처럼 너무 강력하다는 것을 확인했습니다.
https://docs.microsoft.com/en-us/windows/uwp/design/style/reveal-focus

@chigy 연구에서 텍스트 컨트롤 포커스에 대한 Reveal Focus가 너무

@mdtauk 및 @Felix-Dev , 이제 제안 중인 변경 사항의 시각적 구성 요소를 업로드했습니다.

@chigy 는 텍스트 컨트롤, 콤보 상자, 체크 및 라디오 컨트롤의 테두리 두께를 재고할 가능성이 있습니다.

Fabric Web은 1epx 두께를 선택했으며 특히 새로운 둥근 모서리로 컨트롤을 더욱 우아하게 만듭니다. 현재 그들은 약간 부피가 느껴집니다.

압축 모드의 텍스트 상자는 큰 이점이 있습니다. 하지만 초점을 맞추면 테두리가 더 두꺼워질 수 있습니다.

버튼은 기본적으로 20% 불투명도로 배경 채우기를 사용합니다. Fabric Web에서는 1 epx 테두리를 사용하고 채우기는 사용하지 않습니다. 나는 이것이 더 나은 해결책이 될 수 있고 텍스트 상자 컨트롤의 버튼이 잘 맞도록 할 수 있다고 생각합니다.

스핀 버튼이 있는 NumberBox 제안은 버튼과 텍스트 필드의 이 조합을 보여줍니다.

팀에서 이 스타일을 새 기본값으로 지정하지 않으려는 경우 스타일/템플릿을 포함할 수 있습니다.

@chigy가 만든 시각적 구성 요소를 보는 데 도움 이 되도록 이 항목을 만들었습니다.

둥근 모서리 주제에 대한 일화적이고 비전문적인 피드백.
Edge와 CrEdge를 모두 사용할 때 CrEdge의 가장 큰 문제는 전체 UI의 둥근 느낌입니다. 끔찍하고 적극적으로 사용하는 것을 싫어합니다. 사물에 둥근 모서리를 추가하는 경우, 안전 가위로 아이가 잘리는 것처럼 보이는 것을 원하지 않는 우리를 위해 날카로운 모서리를 전환하는 기능을 추가하십시오.

@chigy가 만든 시각적 구성 요소를 보는 데 도움이 되도록 이 항목을 만들었습니다.

@mrlacey , 정말 감사합니다!!

@chigy 는 텍스트 컨트롤, 콤보 상자, 체크 및 라디오 컨트롤의 테두리 두께를 재고할 가능성이 있습니다.

@mdtauk , 작업을 버킷화하는 방법에 대해 몇 가지 시각적 변경 사항을 더 정리하고 있습니다. (우리는 개별적으로 주소를 지정할 수 있지만 일관성이 있기를 원합니다), 그 중 하나는 귀하가 요청하는 것이므로 계속 지켜봐 주시기 바랍니다.

둥근 모서리 주제에 대한 일화적이고 비전문적인 피드백.
Edge와 CrEdge를 모두 사용할 때 CrEdge의 가장 큰 문제는 전체 UI의 둥근 느낌입니다. 끔찍하고 적극적으로 사용하는 것을 싫어합니다. 사물에 둥근 모서리를 추가하는 경우, 안전 가위로 아이가 잘리는 것처럼 보이는 것을 원하지 않는 우리를 위해 날카로운 모서리를 전환하는 기능을 추가하십시오.

@Zucce05 , 예 #684는 둥근 모서리가 아닌 모서리로 쉽게 다시 전환할 수 있어 귀하의 우려를 해결할 것입니다. 즉, 우리의 제안서에서 볼 수 있듯이 모서리가 전문적인 모습을 유지하기 위해 그렇게 둥글지 않습니다.

@chigy
나는 둥근 모서리 디자인 변경의 팬이 아니기 때문에 쉽게 다시 전환할 수 있는 옵션이 있다는 소식을 듣게 되어 기쁩니다. 하지만 시스템 전체의 모서리 반경 옵션이 있을 것이라고 생각하지 않습니다(시스템 전체의 강조 색상을 설정하는 것과 유사)?

테두리 두께에 대한 주제: 버튼의 현재 두께가 마음에 들고 테두리 두께도 현재 UI 환경에서 다소 독특하게 느껴집니다. UWP UI와 다른 UI에서 이 테두리 두께는 거의 또는 전혀 볼 수 없으므로 항상 "현재 보고 있는 UI는 UWP입니다."라는 훌륭한 구분자 역할을 합니다. 두께가 지금처럼 유지되었으면 합니다.

게시된 시각적 구성 요소를 보면 테두리 두께가 이상하게 보이는 유일한 영역은 확인란이 있는 TreeView의 경우입니다. 그런 경우에는 체크박스의 두께가 너무 두꺼워 보입니다. 오해의 소지가 있는 시각 효과일 수 있지만 독립 실행형 확인란의 테두리 두께가 더 얇아 보기에 좋은 것 같습니다. 따라서 TreeView에서 일반 체크박스 테두리 두께의 시각적 효과와 일치하도록 체크빅스의 테두리 두께를 줄였습니다.

@mdtauk , 작업을 버킷화하는 방법에 대해 몇 가지 시각적 변경 사항을 더 정리하고 있습니다. (우리는 개별적으로 주소를 지정할 수 있지만 일관성이 있기를 원합니다), 그 중 하나는 귀하가 요청하는 것이므로 계속 지켜봐 주시기 바랍니다.

@chigy 내가 언급한 변경 사항을 설명하기 위해 몇 가지 시각적 모형을 만들고 Fabric Web의 컨트롤에 더 가까운 컨트롤을 제공하지만 여전히 Fluent 컨트롤 메트릭을 사용합니다.

마우스 오버에 추가된 그림자는 Microsoft Store 웹 보기의 Fluent Web 컨트롤에서 사용되지만 기본적으로 생략할 수 있습니다. 또는 제거할 수 있는 테마 애니메이션으로 Z 변환을 수행할 수 있습니다.

위 @mdtauk 의 디자인 제안 중 일부를 보면 버튼의 현재 테두리 두께 등을 분명히 선호합니다.

또한 저는 Fabric Web이나 기타 웹 UI 구성 요소를 기반으로 Windows Fluent Design을 사용하는 것을 그다지 좋아하지 않는다는 점을 말씀드리고 싶습니다. 저는 Windows가 웹에서 진행되는 것과 구별되는 독특한 모양을 갖기를 원합니다. 인터넷 브라우저를 예로 들어 보겠습니다. Chrome은 오늘날 가장 널리 사용되는 브라우저이지만 Edge Chromium 기반 브라우저가 완전히 동일하거나 약간만 달라야 한다는 의미입니까? 내 생각에는 그렇지 않습니다. 위에서 말했듯이 현재 UWP 기본 컨트롤 스타일은 UWP(및 Windows)에 멋진 고유한 모양을 제공합니다. Windows Fluent 팀이 고려했으면 하는 것(즉, 변경을 위해 항목을 변경하지 마십시오).

@Felix-Dev Fabric Web은 Fluent를 기반으로 하는 Microsoft의 웹 컨트롤 디자인입니다. Chromium Edge는 기본적으로 이러한 컨트롤 스타일을 사용할 계획입니다. 그러나 물론 웹 디자이너는 CSS 컨트롤을 다시 디자인할 수 있으며 개발자는 XAML 컨트롤에 대한 자체 템플릿을 선택할 수도 있습니다.

왜 Microsoft의 컨트롤 디자인이 웹에서 Windows마다 그렇게 많이 달라야 하는지 잘 모르겠습니다. 서로 이야기하지 않고 다른 팀처럼 보입니다. 그리고 개발자는 여전히 재정의할 수 있는 옵션이 있습니다. 그리고 이러한 새로운 기본값은 앱이 WinUI 3.0으로 다시 컴파일되지 않는 한 적용되지 않습니다.

게시된 시각적 구성 요소를 보면 테두리 두께가 이상하게 보이는 유일한 영역은 확인란이 있는 TreeView의 경우입니다.

@Felix-Dev, 이 특정 문제에 대해 다소 이상한 스케일로 시각적 개체를 내보내는 Figma의 이상한 버그라고 생각합니다. PNG를 내보낸 실제 빌드와 실제 Figma 파일을 두 번 확인했는데 괜찮아 보입니다.

RE: 둥근 모서리의 인기
@mdtauk 및 @Felix-Dev,
내 동료는 개발자(대부분 LOB/WPF/WinForms 개발자)가 미리 보기 중에 둥근 모서리로 컨트롤을 업데이트하는 것에 대해 어떻게 생각하는지 비공식적으로 질문했고 청중으로부터 매우 좋은 반응으로 박수를 받았습니다. 또한 Windows용 Twitter에서 모서리를 둥글게 처리하지 않는 것에 대해 사람들이 불평합니다.

따라서 귀하의 피드백을 존중하지만(그리고 귀하가 피드백을 받기를 바랍니다), 여기에서 귀하로부터 들은 것과 반대되는 일화 데이터가 있습니다. 그렇기 때문에 원할 경우 다시 변경할 수 있는 방법을 고려하고 있습니다. 디자인은 다소 주관적이기 때문에 까다롭습니다. 빨간색이 마음에 들지 않으면 빨간색 셔츠를 입으라고 강요할 수는 없지만 그것이 "빨간 날을 입는다"면 눈에 띄지 않게 입는 것이 흥미로울 수 있다. 내 말을 이해한다면... :)

글쎄요, 결국 개인의 취향에 달려 있습니다. 현재 UWP 기본 컨트롤 스타일이 괜찮게 보이고 나에게 중요한 부분 중 하나는 웹이나 Chrome 브라우저와 같은 인기 있는 앱 또는 Android와 같은 모바일 OS에서 보는 것과 비교하여 독특하게 보인다는 것입니다. 상쾌한 공기가 좋습니다.

이제 MS가 디자인 언어에 대해 Windows와 웹 모두에 대해 서로 다른 "기본" 스타일을 사용하려는 이유를 알 수 있습니다. 그러나 현재 방향은 Windows를 모바일 앱/모바일 OS처럼 보이게 하는 것이며 저는 그 팬이 아닙니다("XAML 컨트롤이 웹 및 모바일 앱의 발전 방식과 일치하지 않음" 참조). 문제 제안에서).

개발자는 스타일을 쉽게 수정할 수 있지만 나에게 가장 중요한 것은 MS가 제공하는 모든 앱(예: 설정)에서 스타일링이 사용되므로 외부 개발자도 작업의 기반이 되는 스타일링이 되기 때문에 MS가 사용할 기본 스타일입니다. (일부 더, 더 적게).

@chigy

내 동료는 개발자(대부분 LOB/WPF/WinForms 개발자)가 미리 보기 중에 둥근 모서리로 컨트롤을 업데이트하는 것에 대해 어떻게 생각하는지 비공식적으로 질문했고 청중으로부터 매우 좋은 반응으로 박수를 받았습니다.

그것은 아마도 잘못된 청중이 묻는 것이 아닌가? 일상적인 사용자는 어떻습니까? 예를 들어 reddit 및 discord 채널에서 최근 둥근 모서리에 대해 불평하는 사용자를 꽤 많이 보았습니다.

Twitter의 예: 고유한 브랜드 스타일을 갖고 싶어하는 타사의 앱입니다. 나는 그것으로 괜찮을 것입니다. 하지만 Windows의 공식 디자인 언어를 점검하는 이유로 외부 앱을 사용하지는 않을 것입니다.

간단히 말해서 Windows 디자인 팀은 Windows를 모바일/웹 세계에 더 가깝게 스타일링하는 데 주력하고 있는 것 같습니다. 이제 이러한 변경 사항이 너무 급진적이지 않고 Windows가 여전히 독특한 모양으로 남아 다른 환경과 쉽게 구별되기를 바랍니다.

@Felix-Dev Fabric 웹 컨트롤은 다른 프레임워크 및 기본 웹 컨트롤과 다릅니다. Windows 10 MDL2 컨트롤 및 Windows 8/WinJS 컨트롤과 유사한 이전 모양과 비교하여 최근 Fluent Design을 사용하도록 업데이트되었습니다.

XAML 컨트롤은 현재 여전히 MDL2 컨트롤 디자인을 사용하며 플라이아웃 및 메뉴와 같은 일부 요소는 Fluent Design 요소 및 재료를 사용합니다.

Fluent 및 Fabric의 텍스트 스타일은 Bold 및 Semibold 가중치를 더 많이 사용하고 있습니다. 다양한 Windows 10 개념에서도 이를 사용했습니다. 그러나 Windows Shell과 받은 편지함 앱은 아직 모두 이 스타일로 이동하지 않았습니다.

Fabric Web 및 Fluent Web은 Fluent Design이 발표된 이후로 Microsoft에서 컨트롤에 대한 가장 최근 변경 사항이므로 이러한 UI가 어디로 갈지 찾는 데 도움이 되도록 이러한 디자인을 보는 것은 당연합니다. WinUI 3.0은 플랫폼에 대한 큰 변화이며 모든 컨트롤이 Microsoft의 Fluent Design과 더 좋고 신선하며 일관성을 유지하도록 새로운 모양으로 제공됩니다.

RE: 웹 일관성, Fluent 및 Windows 고유
@Felix-Dev와 @mdtauk ,
Windows 디자인 팀의 목표 중 하나는 "익숙함"입니다. 그들은 고객을 대상으로 많은 사용자 조사를 수행했으며(당신이 지적한 것처럼, 우리 개발자가 아니라 일상적인 사용자입니다) 정당한 이유 없이 다른 사람이 되는 것은 당신이 상상할 수 있는 것처럼 좋은 것이 아니라는 것을 알아냈습니다. 그래서 이것은 그들이 한 정확한 테스트가 아니므로 여기에서 나를 인용하지 마십시오). Windows는 모바일 또는 웹에서 시작하는 기술에 대한 경험이 있는 새로운 유형의 사용자를 유치해야 합니다. 이러한 사용자는 Windows를 처음 접하고 "다른" 모양과 느낌을 갖는 것이 도움이 되지 않을 때 엄청난 격차를 느낍니다. 둥근 모서리와 같은 작은 변화가 인식에 큰 차이를 만듭니다. Office 팀은 유사한 결과로 유사한 연구를 수행했으므로 우리는 둥근 모서리로 진행하고 있습니다. 우리는 이 결정을 가볍게 또는 공허하게 내리는 것이 아닙니다.

그렇다고 해서 우리가 그것들을 완전히 동일하게 만드는 것은 아닙니다. 우리가 개선할 수 있는 곳이 있다면 그것을 원합니다. 우리도 Felix가 언급한 것처럼 독특하고 싶지만 의견의 차이가 아니라 의미가 있어야 합니다. Fluent 고유의 치료법을 활용하는 곳입니다.

이 토론의 앞부분에서 언급했듯이 저는 Office, Windows 및 Edge 팀과 매우 긴밀하게 협력하고 있습니다. 우리 디자인 팀은 Microsoft/Fluent에서 나온 하나의 디자인을 갖고 싶어하므로 차이점을 매우 주의 깊게 살펴보고 차이점이 이해되지 않는 부분을 제거하여 함께 발전할 수 있는 출발점을 갖습니다.

그러나 이러한 변경 사항 중 많은 부분이 이러한 팀에서 별도로 배양되었지만 매우 유사한 지점에 도달하는 경우가 많습니다. 경계를 얇게 하는 것은 Office가 먼저 구현한 것이지만 Windows는 잠시 동안 이에 대해 논의해 왔습니다. 그리고 이것들은 모두 Martin이 제안한 대로 Fluent Design 방향의 일부입니다.

_RE: 둥근 모서리의 인기_
@mdtauk 및 @Felix-Dev,
내 동료는 개발자(대부분 LOB/WPF/WinForms 개발자)가 미리 보기 중에 둥근 모서리로 컨트롤을 업데이트하는 것에 대해 어떻게 생각하는지 비공식적으로 질문했고 청중으로부터 매우 좋은 반응으로 박수를 받았습니다. 또한 Windows용 Twitter에서 모서리를 둥글게 처리하지 않는 것에 대해 사람들이 불평합니다.

따라서 귀하의 피드백을 존중하지만(그리고 귀하가 피드백을 받기를 바랍니다), 여기에서 귀하로부터 들은 것과 반대되는 일화 데이터가 있습니다. 그렇기 때문에 원할 경우 다시 변경할 수 있는 방법을 고려하고 있습니다. 디자인은 다소 주관적이기 때문에 까다롭습니다. 빨간색이 마음에 들지 않으면 빨간색 셔츠를 입으라고 강요할 수는 없지만 그것이 "빨간 날을 입는다"면 눈에 띄지 않게 입는 것이 흥미로울 수 있다. 내 말을 이해한다면... :)

_RE: 웹 일관성, Fluent 및 Windows 고유 기능_
@Felix-Dev와 @mdtauk ,
Windows 디자인 팀의 목표 중 하나는 "익숙함"입니다. 그들은 고객을 대상으로 많은 사용자 조사를 수행했으며(당신이 지적한 것처럼, 우리 개발자가 아니라 일상적인 사용자입니다) 정당한 이유 없이 다른 사람이 되는 것은 당신이 상상할 수 있는 것처럼 좋은 것이 아니라는 것을 알아냈습니다. 그래서 이것은 그들이 한 정확한 테스트가 아니므로 여기에서 나를 인용하지 마십시오). Windows는 모바일 또는 웹에서 시작하는 기술에 대한 경험이 있는 새로운 유형의 사용자를 유치해야 합니다. 이러한 사용자는 Windows를 처음 접하고 "다른" 모양과 느낌을 갖는 것이 도움이 되지 않을 때 엄청난 격차를 느낍니다. 둥근 모서리와 같은 작은 변화가 인식에 큰 차이를 만듭니다. Office 팀은 유사한 결과로 유사한 연구를 수행했으므로 우리는 둥근 모서리로 진행하고 있습니다. 우리는 이 결정을 가볍게 또는 공허하게 내리는 것이 아닙니다.

그렇다고 해서 우리가 그것들을 완전히 동일하게 만드는 것은 아닙니다. 우리가 개선할 수 있는 곳이 있다면 그것을 원합니다. 우리도 Felix가 언급한 것처럼 독특하고 싶지만 의견의 차이가 아니라 의미가 있어야 합니다. Fluent 고유의 치료법을 활용하는 곳입니다.

이 토론의 앞부분에서 언급했듯이 저는 Office, Windows 및 Edge 팀과 매우 긴밀하게 협력하고 있습니다. 우리 디자인 팀은 Microsoft/Fluent에서 나온 하나의 디자인을 갖고 싶어하므로 차이점을 매우 주의 깊게 살펴보고 차이점이 이해되지 않는 부분을 제거하여 함께 발전할 수 있는 출발점을 갖습니다.

그러나 이러한 변경 사항 중 많은 부분이 이러한 팀에서 별도로 배양되었지만 매우 유사한 지점에 도달하는 경우가 많습니다. 경계를 얇게 하는 것은 Office가 먼저 구현한 것이지만 Windows는 잠시 동안 이에 대해 논의해 왔습니다. 그리고 이것들은 모두 Martin이 제안한 대로 Fluent Design 방향의 일부입니다.

저는 기본 컨트롤을 변경하는 데 모두 찬성하며 Fabric 웹 컨트롤은 현재 XAML 컨트롤 디자인 IMO보다 더 우아하고 세련되게 느껴집니다.

그러나 이것은 단순히 템플릿을 변경하는 것 이상이며 개발자가 전체 컨트롤을 다시 템플릿할 필요 없이 이러한 변경 사항을 쉽게 재정의할 수 있도록 하는 더 많은 속성을 노출하는 것입니다.

새로운 기본 CornerRadius 값은 다음과 같은 ThemeResources가 될 수 있습니다.
<Thickness x:Name="ControlCornerRadius" Value="2,2,2,2"/>
<Thickness x:Name="FlyoutCornerRadius" Value="4,4,4,4"/>

그런 다음 개발자는 App.xaml에서 이를 재정의하거나 제곱된 상태로 유지하려는 컨트롤에 CornerRadius="0" 을 적용할 수 있습니다.

이에 따라 BorderThickness의 기본값을 2epx 대신 1epx로 설정하는 것이 좋습니다. 그러나 모든 컨트롤은 다음과 같은 ThemeResources를 사용합니다.
<Thickness x:Name="ControlBorderThickness" Value="1,1,1,1"
<Thickness x:Name="ControlFocusedBorderThickness" Value="2,2,2,2"
<Thickness x:Name="FlyoutInnerBorderThickness" Value="1,1,1,1"
<Thickness x:Name="FlyoutOuterBorderThickness" Value="1,1,1,1"

따라서 App.xaml에서 전역적으로 재정의하거나 몇 가지 컨트롤에 적용된 스타일에서 재정의할 수 있습니다.

새 기본값을 설정하지만 템플릿을 다시 만들 필요가 없는 재정의를 허용합니다.

그러나 이것은 단순히 템플릿을 변경하는 것 이상이며 개발자가 전체 컨트롤을 다시 템플릿할 필요 없이 이러한 변경 사항을 쉽게 재정의할 수 있도록 하는 더 많은 속성을 노출하는 것입니다.

@mdtauk , @kikisaints 를 추가하면 그녀가 당신이 준 좋은 피드백을 볼 수 있습니다.

@chigy 마지막 답변을 게시하면서 다른 내용이 추가되었으므로 따옴표를 포함해야 했습니다. :)

Windows UI 팀에서 어떤 종류의 토론이 있었는지 자세히 듣고 싶습니다. 나는 지난 몇 년 동안 내 자신의 목적과 트위터 대화를 위해 컨트롤 디자인 아이디어를 만들어 왔으며 현재 Fabric Web과 Office Xaml에 있는 일부 항목은 변경하고 싶었습니다. 테두리 두께, 라디오 버튼과의 특정 불일치, 확인란, 드롭다운 등

이러한 변경 사항이 발전하는 것을 보게 되어 기쁩니다. 여기에서 진행 중인 토론에 참여하게 되어 기쁩니다!

내가 의도한 건설적인 방식으로 내 열정을 받아들여 주셔서 감사합니다.

단일 변경을 위해 전체 컨트롤을 다시 템플릿화할 필요 없이 속성을 설정하는 것처럼 간단하게 컨트롤을 사용자 지정하기로 한 결정에 박수를 보냅니다.

그러나 결국 내가 가장 보고 싶은 것은 OS에서 개인화 지원이 증가하는 것입니다. 지금까지 알다시피 저는 제안된 변경 사항의 팬이 아닙니다. 현재 디자인이 마음에 듭니다. 반면에 제안된 변경 사항의 열렬한 팬인 @mdtauk 와 같은 사용자가 있습니다. Windows는 이러한 컨트롤의 새로운 유연성을 활용하고 시스템 전체의 모양을 사용자 지정할 수 있는 옵션을 제공해야 합니다.

특히 경계를 고려하면 제안된 시스템은 모서리 반경에 대한 시스템 전체 옵션을 제공하는 것을 매우 쉽게 만듭니다. 특히 제안된 모서리 반경 변경 사항이 다소 작다는 점을 감안할 때 이는 디자인 측면에서도 앱에 적합할 수 있습니다(개발자가 그렇게 느끼지 않으면 항상 옵트아웃할 수 있음).

Windows UI 팀에서 어떤 종류의 토론이 있었는지 자세히 듣고 싶습니다.

@mdtauk , GitHub를 통해 다가오는 모든 시각적 변경 사항을 가져오는 것이 우리의 의도이므로 더 많은 변경 사항이 있을 것으로 기대합니다. 나는 또한 이러한 배경 중 일부를 포함하도록 문서를 확장할 계획이지만, 그것은 내가 실험하는 것이므로 그것이 확실한 것인지 확신할 수 없습니다...

하지만 결국 내가 가장 보고 싶은 것은 OS에서 개인화 지원이 증가하는 것...
Windows는 이러한 컨트롤의 새로운 유연성을 활용하고 시스템 전체의 모양을 사용자 지정할 수 있는 옵션을 제공해야 합니다.

@Felix-Dev , 우리가 현재 Windows에서 찾고 있는 개인화 유형(사용자가 설정에서 변경할 수 있는 것이 있다고 가정합니까?)은 사용성에 영향을 미치는 것입니다. 둥근 모서리 또는 테두리 두께가 그 중 하나인지 확실하지 않습니다. 사용자가 전체 UI를 원하는 대로 디자인할 수 있도록 하는 것이 Windows의 목표가 아닙니다. 우리는 여전히 Windows 디자인을 제공하기를 원하며 둥근 모서리는 개인화를 위한 것이 아니라고 생각하는 핵심 디자인 요소 중 하나입니다... 적어도 지금은 개인화의 정의에 따라. 귀하의 피드백에 감사 드리며 추가 디자인 변경을 생각할 때 노출하는 것이 타당한 곳을 찾을 것입니다.

@Felix-Dev 개발자가 컨트롤에 대해 수행할 수 있는 사용자 지정의 양으로 인해 컨트롤 디자인 변경과 관련된 OS 설정과 일치하는 것은 불가능합니다.

@chigy 각각의 새로운 제어 디자인에 대한 디자인 구성 요소를 GitHub에 가져올 때 변경 사항이 개선될 이유에 대해 Microsoft가 모든 연구 연구에서 수집한 정보를 포함하는 것이 유용할 것입니다. 그래서 "삼각형에서 육각형으로 바꿨다"라기 보다는 "사용자의 편안함과 친숙함 실험을 할 때 이 버튼 디자인을 삼각형에서 육각형으로 바꾸면 더 많은 사람들이 쉽게 찾을 수 있다는 것을 알았습니다. 버튼으로 식별하고 다른 플랫폼 UI와 비교했을 때 이 디자인에 친근감을 느꼈습니다." 등

@mdtauk

개발자가 컨트롤에 대해 수행할 수 있는 사용자 지정의 양으로 인해 컨트롤 디자인 변경과 관련된 OS 설정과 일치하는 것은 불가능합니다.

나는 외부 개발자가 어떻게 그 사용자 설정을 존중할 것인지에 대해 말하는 것이 아닙니다. 그들은 이미 원하는 방식으로 오늘날 컨트롤의 스타일을 지정할 수 있습니다. 그러나 Windows 구성 요소의 모양에 대해 이야기하고 있습니다. 즉, 설정 앱, 클립보드, 캡처 및 스케치, 작업 표시줄 플라이아웃의 UI 요소(예: 네트워크 패널의 버튼) 등...

저는 MS 제공 앱 이외의 UWP 앱을 거의 사용하지 않기 때문에 외부 개발자의 사용자 지정 스타일에 문제가 없습니다. 그래도 Windows 시스템의 UWP 요소와 매일 상호 작용합니다.

@chigy 맞습니다. 사용자가 UI 모양을 변경할 수 있는 Win 10 설정 앱의 설정을 보고 있었습니다. 사용자가 UI 특성을 변경할 수 있도록 하는 추가 작업 측면에서 실제로 의미가 있고 실행 가능한 것이 무엇인지는 여전히 남아 있습니다. 제안된 변경 사항이 작아질수록(미세한 모서리 반경) 이전 스타일(사각형 컨트롤)로 돌아가는 옵션을 추가하는 것이 더 실행 가능하다고 생각합니다.

마지막으로 Win 10은 8억 명의 사용자를 보유하고 있습니다. 모든 사람이 Martin만큼 제안된 변경 사항에 대해 열광적인 것은 아니며 Windows에서도 이러한 사용자를 수용하려고 노력하면 좋을 것입니다. 말씀하신대로 UI는 매우 주관적이고 UI 시스템에 유연성을 추가할 가능성이 있다면 최소한 MS는 그것을 고려해야 합니다.
예를 들어 인터넷 브라우저의 경우 색상뿐 아니라 탭이나 검색 표시줄과 같은 UI 요소의 모양도 변경되는 전체 테마 산업이 있습니다. https://github.com/muckSponge/MaterialFox (Funny 충분히 , 그 특정 프로젝트는 Firefox에 둥근 모서리를 추가합니다 - 그리고 저는 둥근 모서리의 팬이 아닙니다.)
그러나 Windows 시스템의 경우 사용자가 자신의 테마를 만들 수 없으므로 MS에서 UI 사용자 지정 옵션을 제공할 수 있으면 좋을 것입니다.

@mdtauk @chigy
이 레딧 게시물 을 확인하여 둥근 모서리의 팬이 아닌 것은 저뿐만이 아님을 확인하십시오. 우리는 전체 움직임을 싫어하는 사람들이 있으며 사용자에게 현재 모양으로 되돌릴 수 있도록 Windows 모양에 대한 선택권 을 제공해야 한다고 주장합니다.

좋습니다. UI에서 제안된 변경 사항에 대한 문의가 있기 때문에 많은 사람들이 이 스레드에 피드백을 제공하도록 촉구받았습니다. 주로 말 그대로 모든 것에 둥근 모서리를 강요하는 아이디어와 그래픽 인터페이스 디자이너(대부분 개념 및 디자인) 개발 중일 때부터 Windows 10을 사용해 왔으며 전체 OS에 둥근 모서리를 추가하기 위해 제안된 변경 사항을 매우 싫어하는 모든 사람의 편에 섭니다. 이러한 변경 사항이 완료되지 않거나 사용자는 개인화 옵션을 통해 둥근 모서리 또는 날카로운 모서리를 원하는지 여부를 선호합니다.

애도의 말로 : 그냥 정사각형으로 유지하거나 사용자 수준에서 선택 사항으로 만드십시오.

나는 충분한 이유가 있지만 가장 큰 이유는 Windows 8 이후로 Windows에 사각형 모서리가 있고 거의 모든 것이 수년 동안 이를 중심으로 설계되었다는 사실입니다. 이 제안은 iOS에서 매우 동일한 둥근 모서리를 채택하려는 시도입니다. 이유가 무엇이든 Android 플랫폼. 더 큰 문제는 이렇게 하면 시스템 전반에 걸쳐 불일치의 양이 증가할 뿐만 아니라 실제로 당신이 깨닫는 것보다 훨씬 더 큰 "작은" UI 변경을 강요하면 전체 앱 생태계에 불일치가 발생할 것이라는 점입니다. 그런 단순한 변경으로 인해 앱을 업데이트하고 싶지 않은 개발자.

제 생각에 이것은 위에서 언급한 이유뿐만 아니라 Windows는 항상 사용자 정의와 성능에 관한 것이었습니다. 예를 들어 Windows 98(일명 클래식) 테마를 사용하는 것이 개발자의 선택이 되어서는 안 됩니다. Windows XP가 등장했을 때 많은 사람들이 여전히 Classic을 사용했는데, Luna 테마보다 더 많은 사용자 지정 옵션이 있었기 때문입니다. XP는 Luna 테마를 모든 사람에게 강요하지 않았지만 여전히 Classic을 사용할 수 있는 옵션이 있었습니다. 이 제안된 변경 사항은 정사각형 모서리를 어디에나 유지할 수 있는 옵션을 제공하지 않으며, 모든 사람이 좋아하지 않을 수 있는 것을 처리하도록 강요하고 있습니다. 사용자가 원하는 대로 OS를 사용자 정의할 수 있게 하는 것과 관련하여 제 생각에는 매우 나쁜 일입니다.

"그런 작은 변화는 사용자가 관심을 가질 만한 것이 아니다" 또는 "사용자가 너무 많은 것을 사용자 정의하면 혼란스러울 수 있다"는 생각을 알고 있지만 모든 사용자가 이 사이에서 전환하는 것을 이해할 수 있을 것이라고 확신합니다. 둥글고 날카로운 모서리 또는 주제조차도 적절한 설명과 맥락이 주어질 것입니다. 나는 또한 많은 사람들이 자신의 의지에 반해 다른 것을 강요하는 대신 이에 대한 옵션을 갖는 데 확실히 관심이 있다고 덧붙일 것입니다. 사람들이 반올림이라는 아이디어를 좋아하지 않는다는 증거가 더 필요하면 @Felix-Dev가 게시한 Reddit 게시물을 참조하십시오. 구석구석.

많은 사람들은 둥근 모서리에 대한 제안조차 매우 싫어하고 많은 사람들이 그것을 한 걸음 뒤로 생각합니다. 곧 출시될 Hololens UI의 여러 비디오에서 댓글을 확인하더라도 대부분의 댓글은 다시 한 번 모든 둥근 모서리를 강력하게 싫어한다는 내용입니다. 마이크로소프트가 둥근 모서리를 사용한 것이 처음은 아니지만 이제는 사람들이 그것을 부정적인 것으로 보고 있음에도 불구하고 "마이크로소프트가 UI 부서에 수건을 던지고 애플이나 구글을 베끼는 것"의 변형을 말하는 코멘트.

다시 말하지만 이것은 Windows가 이전 버전에서 몇 년 동안 테마를 가지고 있었기 때문에 새로운 개념도 아닌 옵션 또는 테마여야 합니다. 무엇이든 다시 강제하는 대신 강력한 테마의 반환을 요청하는 메시지여야 합니다. 모든 사람에게 적용하고 옵션을 줄입니다.

더 많은 피드백을 수집할 수 있도록 이 제안에 링크되는 reddit 게시물을 만들었습니다. 지금까지의 댓글을 보면 둥근 모서리로 섬세한 접근을 좋아하는 사람이 많다고 말할 수 있습니다.

사람들은 또한 공식 Win 10 MS 앱에서도 설정 앱 및 보안 앱(NavigationView가 제목 표시줄로 확장됨)을 참조하고, 또한 win32 시스템 구성 요소와 최신 UWP 요소 간의 차이점에 대해 UI 불일치를 지적하고 있습니다. @SavoySchuler가 언급했듯이 이 문제는 WinUI 3.0에서 해결되기를 바랍니다. 이것은 이 제안에 관한 특정 요점이 아니라 많은 Windows 사용자 사이에서 "중요한" 열망입니다. 모서리가 둥글거나 그렇지 않은 것이 아니라 Windows 시스템의 일관성 에 관한 것입니다.

일관성은 여기에서 핵심이며 저의 주요 관심사였습니다.

WinUI 3.0은 받은 편지함 앱 및 Windows UI에 영향을 주는 XAML 컨트롤의 변경 사항에 관한 것입니다.

Fabric Web은 자체 팀이지만 모든 팀이 함께 커뮤니케이션하고 Fluent Design을 기반으로 결정을 내리므로 Fabric Web의 디자인은 Microsoft의 최신 아이디어이므로 일관성이 우선해야 한다고 가정합니다.

Xbox Next, Windows Lite 및 Windows Core OS는 새로운 셸과 함께 제공되므로 팀도 고려해야 합니다. 레거시 지원을 위한 Windows 10

@chigy가 말한 것은 정확히 나와 다른 많은 사람들이 방금 요청한 것입니다. 개발자 수준이 아닌 사용자 수준의 사람들이 단순히 날카로운 모서리 또는 둥근 모서리를 보고 싶은지 여부를 결정할 수 있도록 하는 보다 미묘한 변경입니다. 작동하는 데 사용되는 Windows 테마.

@Nepxune이 위에서

UI 사용자 정의가 Windows에 추가되더라도 사용자가 변경할 수 있는 요소의 수와 사용자가 선택할 수 있는 값 집합 모두에 제한이 있어야 한다는 것을 알고 있습니다. 그렇지 않으면 기존 UI에 부정적인 영향을 미치고 디자인 팀이 원하는 Windows 모양에서 너무 많이 벗어날 위험이 있습니다.

나는 이것에 대해 일종의 다른 관점을 가지고 있습니다.
스레드의 앞부분에서 Fabric UI(웹)와 Windows(UWP) 스타일을 더 가깝게 가져오는 것에 대한 논의를 보았고 이것이 약간 걱정됩니다.

다음은 몇 가지 맥락입니다. 저는 수년간 Microsoft Edge를 사용해 왔으며 가장 좋아하는 것 중 하나는 UWP에서 영감을 받은 모양과 느낌이었습니다. Edge Insider가 공개되었을 때 이전의 UWP 스타일 대신 수정된 Chrome 및 웹 UI 디자인을 사용하는 것을 보고 매우 실망했습니다. 표시된 둥근 모서리는 매우 작지만 문제가 없는 지점까지는 이 스레드가 동일한 실망감을 줍니다. Windows가 잘못 설계된 "웹 표준"과 일치하기 위해 고유한(그리고 뛰어난!) 모양과 느낌을 잃는 것을 보고 싶지 않습니다. 사실, Fluent UWP 디자인의 측면이 Fabric에 적용되는 것을 보고 싶습니다!

Edge의 계획은 결국 Acrylic을 다시 가져와 UI를 Windows/Fluent 디자인 스타일로 더 많이 이동하는 것입니다.

그러나 Windows는 희망적으로 격차를 해소하기 위해 약간 앞으로 나아가고 있습니다.

반올림과 비반올림 중 하나를 선택하기 위해 OS에서 설정을 가져오는 것이 불가능한 것은 아니며 모든 앱에 적용하는 것도 불가능하며 XP 시대의 비주얼 스타일과 완전히 다른 방식으로 작동합니다.

또한 WinUI 3.0은 앱 플랫폼 및 컨트롤을 OS에서 분리하는 것이므로 더 많이 함께 묶는 것은 좋은 결정이 아닐 수 있습니다.

물론 앱 개발자는 컨트롤의 CornerRadius 값을 0으로 설정하여 제곱된 컨트롤을 다시 가져올 수 있습니다.

나는 작은 둥근 모서리에 대해 이 푸시를 지원하지만 현재의 수직 핸들 슬라이더 컨트롤을 원 핸들 슬라이더 컨트롤보다 선호합니다. 세로 손잡이가 더 정확하고 한 눈에 파악하기 쉽습니다. 적어도 저는 그렇게 봅니다. 좋은 일을 계속하십시오!

MediaTransport Scrub Bar Thumb이 윤곽선이 있는 원형이고 제안된 새 Slider Thumb이 원으로 채워진 이유가 있습니까?

나는 다른 컨트롤에 맞지 않는 어색한 마름모꼴/알약 모양보다 원형 엄지손가락이 훨씬 더 만족스럽다고 생각합니다.

기억하실지 모르겠지만 둥근 모서리에 사람 타일을 만드는 것조차 당시 많은 Windows 팬에게 큰 문제였으며 이는 약간의 변경일 뿐입니다. 나에게 모든 곳에 둥근 모서리가 있다는 것은 Windows가 지하철 디자인 언어와 유창한 디자인이 도입된 이래로 독특한 모양을 느슨하게 한다는 것을 의미합니다. 디자인 언어는 항상 저에게 uw 개발을 매력적으로 만든 큰 열쇠였습니다. 그것이 사라지고 일반화되는 것을 보는 것은 정말 슬플 것입니다.

내가 한 TextBox 및 NumberBox 디자인 개념과 함께 - 여기에 ComboBox 및 EditableComboBox에 대한 몇 가지가 있습니다.

좋은 작업!
플라이아웃 메뉴에 대한 몇 가지 제안 사항이 있습니다. 메뉴를 구분하는 그림자와 함께 테두리가 정말로 필요합니까? 그리고 IMO 선택 강조 표시는 간격을 남기지 않고 플라이아웃 표면의 전체 너비를 덮을 수 있습니다.

나는 초점이 맞지 않는 더 얇은 테두리를 고맙게 생각하며, 초점 표시 광선은 키보드를 사용하여 UI를 탭핑하는 동안 초점이 맞춰진 요소를 더 쉽게 볼 수 있도록 해야 합니다(실제로 위보다 약간 더 강한 것을 선호합니다).

좋은 작업!
플라이아웃 메뉴에 대한 몇 가지 제안 사항이 있습니다. 메뉴를 구분하는 그림자와 함께 테두리가 정말로 필요합니까? 그리고 IMO 선택 강조 표시는 간격을 남기지 않고 플라이아웃 표면의 전체 너비를 덮을 수 있습니다.

선택 강조 표시는 전체 너비를 덮지만 플라이아웃에 더 밝은 내부 경계를 배치하여 아크릴 효과 및 그림자와 함께 표면에서 들어올리는 데 도움이 됩니다. 내부 경계가 너무 강하면 더 미묘하게 만들 수 있습니다. - 완전한 최종 디자인 제안보다 아이디어에 가깝습니다.

@mdtauk

반올림과 비반올림 중 하나를 선택하기 위해 OS에서 설정을 가져오는 것이 불가능한 것은 아니며 모든 앱에 적용하는 것도 불가능하며 XP 시대의 비주얼 스타일과 완전히 다른 방식으로 작동합니다.

그래서 개발자를 위해 선택 사항 으로 만들라고 말한 것입니다. 솔직히 달라지는 것은 없을 것입니다. 타사 앱은 이미 원하는 모양으로 제공될 수 있습니다. 회사가 둥근 UI(원 버튼,...)로 앱을 출시하려는 경우 자유롭게 할 수 있습니다.

또한 WinUI 3.0은 앱 플랫폼 및 컨트롤을 OS에서 분리하는 것이므로 더 많이 함께 묶는 것은 좋은 결정이 아닐 수 있습니다.

위에서 말했듯 오늘의 Accent Color(사용자가 설정에서 설정할 수 있음)를 처리하는 방식과 비슷하다고 생각합니다. 리소스 컨트롤이 모서리 반경을 바인딩할 수 있으므로 이를 노출하면 개발자를 위한 추가 작업 없이 모서리 반경 변경 사항이 앱에 반영됩니다.

사용자 관점에서 reddit의 피드백을 여기에 남겨주세요. “제안서의 깨끗하고 둥근 모서리 모양이 마음에 듭니다. (reddit에서) 다른 모든 사람들과 마찬가지로 전체 OS에 대한 일관성은 여전히 ​​많은 사랑을 필요로 합니다."

MediaTransport Scrub Bar Thumb이 윤곽선이 있는 원형이고 제안된 새 Slider Thumb이 원으로 채워진 이유가 있습니까?

@mdtauk , 사실, 그것은 우리

플라이아웃 메뉴에 대한 몇 가지 제안 사항이 있습니다. 메뉴를 구분하는 그림자와 함께 테두리가 정말로 필요합니까? 그리고 IMO 선택 강조 표시는 간격을 남기지 않고 플라이아웃 표면의 전체 너비를 덮을 수 있습니다.

@quantumfrost , 예, 실제로 그렇습니다. 그림자는 똑똑합니다. 따라서 시스템이 저전력 모드이거나 그림자를 끄는 다른 상황에 있을 때 테두리가 재생됩니다. 우리는 경계를 미묘하게 디자인했습니다. 우리는 몇 가지 다른 옵션을 평가했지만 이것이 가장 강력한 옵션이었습니다.

@nepxune , @mdtauk
의견을 보내 주셔서 감사합니다.
위에서 지적한 몇 가지 사항에 대해 답변을 드리겠습니다.

사용자가 선택할 수 있는 모서리를 라운딩하도록 사용자 설정을 제공하는 옵션 은 흥미로운 옵션입니다. 그러나 Windows 시스템 전체에서 비교해야 하는 다른 중요한 기능에 대한 이 피드백과 많은 관련이 있습니다.

응용 프로그램 개발자로서 여러분 모두가 우선 순위를 정하고 고객에게 옳은 일을 해야 할 필요성을 잘 알고 있기를 바랍니다. Windows의 경우 고객은 OS를 사용하는 사용자입니다. 물론 이 OS에서 앱을 만드는 개발자도 중요한 고객이며 모서리 반경을 쉽게 전환할 수 있게 함으로써 이 변경으로 인해 발생했을 주요 문제를 해결할 수 있다고 생각합니다.

OS를 사용하는 사용자의 경우 Windows가 너무 위협적이라는 고객의 의견을 들었습니다. Windows와 Office 팀은 모두 사용자 연구를 수행하여 둥근 모서리만큼 미묘하더라도 제품이 친숙하고 친근하게 느껴지도록 만드는 데 차이가 있다는 결론을 (독립적으로) 마쳤습니다.

따라서 GitHub 및 기타 포럼의 많은 사람들이 우리가 iOS 및 Android를 따르고 있다고 언급하지만 그렇지 않다는 것을 알고 있습니다. 우리는 사용자를 이해하여 이 결정에 도달했습니다. 예, 둥근 모서리를 사용한다는 사실이 친숙함을 더하지만 우리는 업계가 하는 일을 맹목적으로 따르지 않습니다.

나는 이것에 대해 일종의 다른 관점을 가지고 있습니다.
스레드의 앞부분에서 Fabric UI(웹)와 Windows(UWP) 스타일을 더 가깝게 가져오는 것에 대한 논의를 보았고 이것이 약간 걱정됩니다.

다음은 몇 가지 맥락입니다. 저는 수년간 Microsoft Edge를 사용해 왔으며 가장 좋아하는 것 중 하나는 UWP에서 영감을 받은 모양과 느낌이었습니다. Edge Insider가 공개되었을 때 이전의 UWP 스타일 대신 수정된 Chrome 및 웹 UI 디자인을 사용하는 것을 보고 매우 실망했습니다. 표시된 둥근 모서리는 매우 작지만 문제가 없는 지점까지는 이 스레드가 동일한 실망감을 줍니다. Windows가 잘못 설계된 "웹 표준"과 일치하기 위해 고유한(그리고 뛰어난!) 모양과 느낌을 잃는 것을 보고 싶지 않습니다. 사실, Fluent UWP 디자인의 측면이 Fabric에 적용되는 것을 보고 싶습니다!

@19lmyers
Windows가 고유한(그리고 심지어 더 뛰어난) 모양을 잃는 것에 대한 걱정에 대해 피드백을 보내주셔서 감사합니다. 위의 의견에서 언급했듯이 사용자는 Windows에 익숙하지 않기 때문에 Windows가 너무 다르다는 것을 반드시 인식하지는 않으므로 균형을 잡는 작업입니다.

Fluent Design System에서 회사 전체의 디자인 팀은 많은 차이점에 대해 논의하고 지금까지 도입된 불필요한 차이점을 제거하기 위해 노력하고 있습니다. 위에서 iOS와 Android에 대해 언급했듯이 우리가 제안하는 디자인은 Fabric을 복사해서가 아니라 Windows 디자이너가 자체 UI 시스템을 재평가하여 도달한 것입니다. 그것들은 종종 유사한 디자인을 만들어냅니다. 흥미롭게도... 그렇지만 Windows를 고유하게 유지하려는 많은 사람들의 열정에 정말 감사드립니다.

@zag2me 리포지토리에 오신 것을 환영합니다! 여기에서 토론에 참여하게 되어 기쁩니다. 귀하에게 중요한 문제에 대한 관심을 끌 수 있는 적절한 장소라는 데 동의합니다! 기능 요청 양식은 https://github.com/microsoft/microsoft-ui-xaml/issues/new/choose 에서 찾을 수 있습니다.

@chigy

사용자가 선택할 수 있는 모서리를 라운딩하도록 사용자 설정을 제공하는 옵션은 흥미로운 옵션입니다. 그러나 Windows 시스템 전체에서 비교해야 하는 다른 중요한 기능에 대한 이 피드백과 많은 관련이 있습니다.

OS를 사용하는 사용자의 경우 Windows가 너무 위협적이라는 고객의 의견을 들었습니다. Windows와 Office 팀은 모두 사용자 연구를 수행하여 둥근 모서리만큼 미묘하더라도 제품이 친숙하고 친근하게 느껴지도록 만드는 데 차이가 있다는 결론을 (독립적으로) 마쳤습니다.

우리는 사용자를 이해하여 이 결정에 도달했습니다. 예, 둥근 모서리를 사용한다는 사실이 친숙함을 더하지만 우리는 업계가 하는 일을 맹목적으로 따르지 않습니다.

Windows가 고유한(그리고 심지어 더 뛰어난) 모양을 잃는 것에 대한 걱정에 대해 피드백을 보내주셔서 감사합니다. 위의 의견에서 언급했듯이 사용자는 Windows에 익숙하지 않기 때문에 Windows가 너무 다르다는 것을 반드시 인식하지는 않으므로 균형을 잡는 작업입니다.

그리고 여기에 제가 가지고 있는 문제가 있습니다. 당신은 "Windows 사용자"를 언급하지만, 이 스레드와 다른 연결된 reddit 스레드가 지금까지 보여준 것은 "Windows 사용자"의 동종 그룹이 없다는 것입니다. 결국 기업은 대부분의 고객이 원하는 방향을 항상 따를 수 있지만 그렇게 해도 문제가 남습니다. 비율이 다소 작은 경우(그리고 각 숫자 뒤에 엄청난 절대적인 사용자 수가 있을 경우) 어떻게 될까요? 여기 피드백에 따르면 reddit과 다른 곳에서는 UI가 압도적으로 많다는 느낌을 받지 못합니다.

이는 우리 중 일부가 떠돌아다니는 제안으로 이어집니다 . Windows에 더 많은 UI 사용자 지정 옵션을 추가하는 것입니다.

당신이 말했듯이 주어진 사용자 정의 옵션은 신중하게 측정해야하지만 사용자 정의 자체를 옵션으로 버려서는 안됩니다. 당신이 말했듯이, 그리고 이 시점에서 나는 반복하기 시작했습니다. 제안된 모서리 반경 변경은 작은 변경이므로 UI에 대한 사용자 선택의 영향은 무시할 수 있거나 아예 존재하지 않아야 합니다. 나와 다른 사람들은 사용자가 "Windows UI 당신의 팀이 만들고자 하는 아이덴티티".

간단히 말해서 이러한 디자인 변경 사항에 더해 신중하게 측정된 사용자 지정 옵션은 Windows 사용자 사이의 다양한 UI 기본 설정을 해결할 수 있는 좋은 방법처럼 들리며 열정적인 Windows 사용자인 우리 가족 전체를 위한 만족스러운 UI를 만드는 데 큰 도움이 될 것입니다. .

@chigy
대부분의 사람들은 2px가 좋은 반경이라는 데 동의할 것입니다. 나머지 옵션을 끄는 옵션을 제공하는 것이 좋습니다.

대부분의 사용자는 Windows가 UI의 최첨단에 있기를 원하지만 다른 레거시 사용자는 변경하기를 원하지 않습니다.

소수를 위해 변경 사항을 희생하지 말고 사용 중지할 수 있는 옵션을 제공하세요.

@shaheedmalik
여기에 "레거시" 사용자가 없으며 " 대부분의 사용자가 [둥근 모서리]를 원함"에 도달했는지 또는 현재 Windows 모양이 "최첨단"이 아닌지도 알 수 없습니다.

UI는 매우 주관적이지만 "기존", "변경할 의사가 없음" 등의 다양한 의견을 그냥 지나칠 수 있는 것은 아닙니다.

"과거에서 깨어나고 싶지 않은 사용자"의 의견으로 다른 사용자가 말하는 것을 그냥 버리고 지금까지와 같이 현재 토론을 열정적이지만 존중 하도록 합시다.

@Felix-Dev 레거시 사용자는 기회가 주어지면 Windows 7에 머물렀을 사용자, Windows 8의 변경 사항에 저항하는 사용자, 앞으로의 OS UI 변경에 저항하는 사용자입니다.

Apple과 Google은 Windows 8.1의 기능을 복사하여 구현했으며 사용자는 해당 플랫폼이 최첨단으로 여겨졌기 때문에 해당 플랫폼으로 넘어갔습니다. 한편, 마이크로소프트는 레거시 사용자의 목소리를 듣다가 소수의 목소리로 인해 축소되었습니다.

특히, 대다수가 링크된 것처럼 둥근 모서리를 원하는 경우(https://www.reddit.com/r/Windows10/comments/bwnxne/windows_10_rounded_corners_and_more_ui_changes/)

문제는 저는 레거시 사용자가 아니며 현재의 둥근 모서리 푸시(및 가능한 테두리 두께 감소)를 좋아하지 않는 모든 사람을 해당 범주로 던진 것처럼 보였습니다. 나는 또한 내 게시물에 대한 당신의 반대 투표를받지 않습니다.

대부분의 경우: 이 주제에 대한 MS의 디자인 설문 조사에 대해 알지 못했고 한 달 전 이 푸시에 대한 세부 정보가 인터넷에 처음 등장했을 때 많은 사용자가 알지 못했던 많은 사용자의 반응을 기반으로 했습니다( 그래서 아마도 묻지 않았을 것입니다). 이 reddit 게시물 을 확인하면(btw에는 지금까지 위에서 링크한 reddit 스레드보다 3배 많은 댓글이 있음) 그림이 정확히 명확하지 않다는 것을 알 수 있습니다. 나는 "이 입장은 명백히 다수다"라고 주장할 수 있는 입장이 아니며, 앞으로도 그러지 않을 것입니다.

내가 당신의 게시물에 대해 잘못 알고 있다면 사과하지만 읽는 방식에서 "변경을 원하지 않는 기존 사용자의 목소리"라고 선언한 이 변경에 대해 주장하는 어떤 목소리도 분명히 무시했습니다. ". 그것은 나에게 무례한 일이며 다른 모든 사람들이 이 토론에 목소리를 더할 것입니다.

@Felix-Dev 이 위/아래 투표와 답글에 개인적인 의견을 읽으려고 하지 맙시다.

간단한 대답은 이러한 변경이 변덕스럽거나 다른 플랫폼 UI 스타일을 모방한 것이 아니라 사용자와 개발자의 협의, 피드백 및 표현된 의지의 결과라는 것입니다.

우리는 토론을 건설적으로 유지하려고 노력해야 합니다. 따라서 변경해야 하는지 여부가 아니라 어떤 방식으로 변경해야 하는지에 대한 것입니다.

사람들은 원래 게시물의 둥근 모서리가 너무 둥글기 때문에 싫어했습니다.
이 최신 게시물은 이 업데이트된 GitHub 제안에 대한 링크입니다. 새로운 피드백은 업데이트된 제안의 응답을 반영합니다. 또한, 한 달 전의 원본 게시물을 링크하여 원래 제안서에서 수정 제안서로의 변경 사항을 사용자에게 보여줍니다.

동의합니다. 제안으로 돌아가서 이 마지막 게시물을 잊어버려야 합니다.

이 시점에서 이러한 변경이 이루어질 것이 매우 분명하다고 생각합니다. 제가 하려고 하는 것은 @chigy 에게 신중하게 측정된 사용자 정의의 경우가 있다는 것을 확신 @shaheedmalik을 포함하여 이상일 수 있습니다.

현재 개발자가 모든 컨트롤( #684 )에서 자신의 CornerRadius를 쉽게 설정할 수 있도록 하는 제안이 있으며, 이를 통해 팀은 기본적으로 CornerRadii를 컨트롤에 추가할 수도 있습니다.

OS 수준에서 수행하는 것은 복잡한 작업이며 연구는 이를 구현하는 데 관련된 엔지니어링 시간과 노력을 보증하지 않습니다.

하지만 @Felix-Dev의 견해를 분명히 하셨고, 새로운 컨트롤이 대다수의 Windows 사용자에게 전달된 후 피드백을 받으면 향후 이 아이디어를 탐색할 수 있습니다.

1px 라인임을 확인한 후 반올림에서 "AppBarSeparator"를 제거하도록 사양을 업데이트했습니다.

1px 라인임을 확인한 후 반올림에서 "AppBarSeparator"를 제거하도록 사양을 업데이트했습니다.

@chigy 100% 스케일링에서는 1 epx이지만 200%, 300%, 400% 스케일링에서는 약간의 주의가 필요할 수 있습니다.

실제로 직사각형이 아닌 선인 경우 - 아마도 StrokeStartLineCap 및 StrokeEndLineCap 을 PenLineCap.Round로 설정

@mdtauk

OS 수준에서 수행하는 것은 복잡한 작업이며 연구는 이를 구현하는 데 관련된 엔지니어링 시간과 노력을 보증하지 않습니다.

이 제안은 컨트롤에 CornerRadius 속성을 추가하여 이미 대부분의 작업을 수행하는 것으로 보입니다. 그런 다음 남은 것은 이러한 컨트롤이 실제 모서리 반경에 대해 바인딩할 수 있는 SystemCornerRadius 리소스를 만드는 것입니다(오늘날 SystemAccentColor 리소스를 사용하여 설정 앱에서 사용자가 설정한 강조 색상으로 UI 요소의 색상을 지정하는 방법과 유사합니다.

그러한 리소스를 만들고 설정 앱을 통해 업데이트할 수 있도록 하는 데 얼마나 많은 작업이 필요한지에 관해서는 MS가 논평을 남겨야 합니다. 그러나 이 제안이 이미 수행하고 있는 작업과 AccentColor 리소스를 노출하는 형태의 이전 작업을 감안할 때 귀하가 말한 것처럼 얼마나 까다로운 작업인지 모르겠습니다. OS 레벨은 문자 그대로 읽고 쓸 수 있는 모서리 반경 값만 제공하고, 오늘날의 액센트 색상 리소스에 대해 이미 있는 동일한 시스템을 사용할 수 있습니다.

@mdtauk

OS 수준에서 수행하는 것은 복잡한 작업이며 연구는 이를 구현하는 데 관련된 엔지니어링 시간과 노력을 보증하지 않습니다.

이 제안은 컨트롤에 CornerRadius 속성을 추가하여 이미 대부분의 작업을 수행하는 것으로 보입니다. 그런 다음 남은 것은 이러한 컨트롤이 실제 모서리 반경에 대해 바인딩할 수 있는 SystemCornerRadius 리소스를 만드는 것입니다(오늘날 SystemAccentColor 리소스를 사용하여 설정 앱에서 사용자가 설정한 강조 색상으로 UI 요소의 색상을 지정하는 방법과 유사합니다.

그러한 리소스를 만들고 설정 앱을 통해 업데이트할 수 있도록 하는 데 얼마나 많은 작업이 필요한지에 관해서는 MS가 논평을 남겨야 합니다. 그러나 이 제안이 이미 수행하고 있는 작업과 AccentColor 리소스를 노출하는 형태의 이전 작업을 감안할 때 귀하가 말한 것처럼 얼마나 까다로운 작업인지 모르겠습니다. OS 레벨은 문자 그대로 읽고 쓸 수 있는 모서리 반경 값만 제공하고, 오늘날의 액센트 색상 리소스에 대해 이미 있는 동일한 시스템을 사용할 수 있습니다.

슬라이더나 토글이 될까요?

[X] 컨트롤의 둥근 모서리

btw를 설정할 단일 모서리 반경 값만 있는 것은 아닙니다. 일부 요소는 한쪽만 둥글거나 상단 모서리만 둥글게 됩니다. 플라이아웃 및 팝 오버 컨트롤의 반경은 4 epx이지만 다른 컨트롤의 반경은 2 epx입니다.

OS에서 이 설정이 변경됨에 따라 많은 변수를 설정하게 됩니다. 그렇다면 테스트는 어떨까요? 기대도 있었을 것이다. 사용자는 사용자의 선호도를 무시하기로 결정한 앱에 어떻게 반응할까요?
반올림되는 컨트롤과 그렇지 않은 컨트롤을 사용자와 어떻게 소통합니까? 일부 컨트롤에는 내부 테두리 또는 외부 테두리 요소가 있습니다. 이들은 모양의 가장자리를 적절하게 끌어안기 위해 CornerRadius 값을 조정해야 합니다.

결국 이는 큰 무리 없이 환영할 만한 변화일 수 있어 OS에 또 다른 옵션을 추가하는 것은 과민반응이라고 볼 수 있다.

@mdtauk @chigy
확실히 계획이 필요하지만 팀은 개발자가 제곱 컨트롤을 매우 쉽게 만들 수 있기를 분명히 원합니다. 따라서 모서리 반경 값 설정 대신 간단한 UserRoundedCorners 부울 스위치를 사용하는 것이 좋습니다. 사실, 값을 설정한다는 아이디어는 더 많은 옵션을 추가하기 위한 것이었지만, 이 움직임에 동의하지 않는 사용자는 항상 컨트롤 모양을 되돌릴 수 있는 옵션을 제공하는 것이었습니다. 따라서 그것은 전혀 문제가 되지 않을 것입니다.

"아직 다른 옵션" 부분에 관해서는: 사용자가 사용할 수 있는 옵션이 이미 너무 많은 것처럼 들리는데, 이는 완전히 다른 문제이며 이 간단한 스위치를 추가 하지 않는 정의 지점으로 사용되어서는 안 됩니다.

Windows와 디자인 팀은 매일(트위터에서) 사용자를 제외 하지 않고 포함 하는 방법에 대해 이야기합니다. MS가 사용자 의견의 다양성을 존중하기 위해 단일 옵션을 추가하는 것이 상대적으로 쉽다고 생각하는 기회입니다.

사용자는 사용자의 선호도를 무시하기로 결정한 앱에 어떻게 반응할까요?

필수 Windows 앱/UI 요소(예: 설정 앱, 보안 앱, 클립보드, 작업 표시줄 네트워크 플라이아웃 연결/연결 해제 버튼....)가 이를 존중하는 한 문제가 되지 않는다고 생각합니다. 타사 앱은 원하는 스타일을 자유롭게 사용할 수 있습니다. 타사 앱이 이 사용자 설정을 따르도록 보장되지 않는다는 설정 앱의 간단한 메모가 좋습니다.

@mdtauk @chigy
@Felix-Dev가 옳다고 생각합니다. 간단한 토글이 있는 부울 스위치가 사용자 수준에서 사용자 지정을 위한 방법이 될 수 있습니다. 3개의 고정된 사전 설정 위치가 있는 슬라이더인 경우 상황이 변경될 수 있습니다.

3개의 고정 옵션이 있는 슬라이더를 사용하면 원래 제안된 것과 같이 더 급격한 모서리 반경 변경을 가질 수 있는 추가 설정을 허용하므로 다음을 수행할 수 있습니다.

Sharp - 지금처럼 날카로운 모서리
중간 옵션 - 새로운 더 작은 반경
반올림 - 원래 제안된 반지름 변경 또는 더 둥근 것

이 옵션은 모든 그룹을 만족시킬 수 있는 잠재력을 가지고 있으며 기본적으로 이것이 개발자에게 새로운 것으로 브랜딩하여 더 많은 변경 사항이기는 하지만 Windows의 새로운 "테마 지정" 기능으로 실제로 이것을 전달할 수 있을 만큼 충분히 과감한 변경입니다. 토글 구현 또는 3가지 사전 설정 슬라이더가 있는 "테마 지정" 기능을 소비자를 위한 새로운 기능으로 전달할 수도 있습니다.

사용자의 선호도를 무시하기로 결정한 앱에 사용자는 어떻게 반응할까요?

나는 사용자가 현재 악센트 색상을 사용할 수 없을 때 하는 방식으로 간단하게 볼 수 있다고 생각합니다. 타사 앱은 원하는 모든 작업을 자유롭게 수행할 수 있어야 하지만 @Felix-Dev가 말한 것처럼 Windows 앱/UI 요소는 분명히 다음을 수행해야 합니다. 사용자의 변수를 존중합니다.

타사 앱이 설정을 존중하지 않는다는 메모를 설정에 넣을 필요가 없다고 생각합니다. 강조 색상 섹션에 면책 조항을 넣을 필요가 없으므로 이것과 동일하다고 생각하십시오. 잘.

OS 수준에서 수행하는 것은 복잡한 작업이며 연구는 이를 구현하는 데 관련된 엔지니어링 시간과 노력을 보증하지 않습니다.

하지만 @Felix-Dev의 견해를 분명히 하셨고, 새로운 컨트롤이 대다수의 Windows 사용자에게 전달된 후 피드백을 받으면 향후 이 아이디어를 탐색할 수 있습니다.

여기서 짚고 넘어가야 할 것이 있는 것 같습니다. 나는 어느 쪽이든 제안된 변경 사항에 대해 강하게 느끼지는 않지만(나는 더 이상 나를 괴롭히는 불일치나 변경 사항 때문에 매일 다른 생태계에서 너무 많은 UI 스타일로 작업해야 함), 이 사고 방식은 순서대로 좋지 않다고 느낍니다. 풍부한 사용자 친화적인 경험을 제공합니다.

80% 완료되었으며 다음 릴리스에서 100%로 제공되거나 되지 않을 수 있는 기능을 릴리스하지 마십시오.
아마도 어떤 개발자도 둥근 테두리 또는 둥근 테두리가 아닌 앱을 테스트하고 개발하는 데 시간을 할애하지 않을 것입니다. 왜 그럴까요? 시스템은 이제 반올림을 사용합니다. 왜 누군가 자신의 앱이 OS와 약간 다르게 보이길 원해야 합니까(그렇지 않으면 어쨌든 전체 테마로 갈 것입니다)
시스템 전반에 걸친 토글이 있다면 그것을 구현할 인센티브가 있을 것입니다.
그러나 이러한 방식으로 작업을 수행하는 경우 처음부터 구현해야 할 필요성을 인식하는 앱이 없기 때문에 토글이 필요하지 않습니다.

원래 주제:
콤보 상자를 제외하고 2px 테두리가 멋지게 보입니다.
마지막 요소의 하이라이트는 그 아래에 흰색 테두리를 남겨서는 안 되며(또는 최소한 왼쪽과 오른쪽보다 크지 않아야 합니다. 이는 물론 아래쪽 하이라이트 모서리도 둥글게 처리해야 함을 의미합니다.) 상자와 It's 플라이아웃 사이의 확장된 상태입니다. 나는 그것이 그들 사이에 이상한 분리 된 모습을주는 것 같습니다.
플라이아웃을 양쪽에서 2px 작게 만들고 상단에 둥근 모서리가 없도록 하는 것이 더 나을 수 있습니다. 이렇게하면 디스펜서에서 종이 조각을 뽑아내는 것처럼 보입니다. (나는 당신이 내가 의미하는 바를 이해할 수 있기를 바랍니다 :D 슬프게도 나는 지금 그것을 스케치 할 수있는 도구가 없습니다)

원래 주제:
콤보 상자를 제외하고 2px 테두리가 멋지게 보입니다.
마지막 요소의 하이라이트는 그 아래에 흰색 테두리를 남겨서는 안 되며(또는 최소한 왼쪽과 오른쪽보다 크지 않아야 합니다. 이는 물론 아래쪽 하이라이트 모서리도 둥글게 처리해야 함을 의미합니다.) 상자와 It's 플라이아웃 사이의 확장된 상태입니다. 나는 그것이 그들 사이에 이상한 분리 된 모습을주는 것 같습니다.
플라이아웃을 양쪽에서 2px 작게 만들고 상단에 둥근 모서리가 없도록 하는 것이 더 나을 수 있습니다. 이렇게하면 디스펜서에서 종이 조각을 뽑아내는 것처럼 보입니다. (나는 당신이 내가 의미하는 바를 이해할 수 있기를 바랍니다 :D 슬프게도 나는 지금 그것을 스케치 할 수있는 도구가 없습니다)

나는 당신이 무엇을 설명하는지 알고 있으며 내 디자인 목업을 위해 그것을 고려했습니다. 문제는 ComboBox가 자체 플라이아웃 템플릿을 가져 상황에 맞는 메뉴, 메뉴 플라이아웃, 접두사, 접미사, 자동 완성 플라이아웃 등과 다르게 만든다는 의미입니다.

그것이 내가 의미한 바입니다(박스 자체가 하단 모서리를 둥글게 유지할 수 있다는 점을 제외하고)
예, 다른 플라이아웃은 다를 수 있지만 기본적으로 두 가지 유형의 플라이아웃이 있습니다.
어떤 것에 붙어 있는 것, 그렇지 않은 것. 이제 그것들이 달라져야 한다는 것은 둥근 모서리를 만드는 비용일 뿐입니다 ;)
또한 모서리 반경을 스타일화할 수 있는 경우 Parent 컨트롤로 설정할 수 없습니다.

내 XAML은 약간 녹슬었지만 다음과 같은 콤보 상자 템플릿입니다.

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

또한 모서리 반경을 스타일화할 수 있는 경우 Parent 컨트롤로 설정할 수 없습니다.

내 XAML은 약간 녹슬었지만 다음과 같은 콤보 상자 템플릿입니다.

<Combobox FlyoutCorners="GlobalCornerValue,GlobalCornerValue,0,0">
   <GenericFlyout Corners="something something parent property Binding"/>
</Combobox>

이는 스타일을 재정의하는 방법과 유사하지만 템플릿에서 사용하려면 각 방향에 대해 별도의 스타일이 필요합니다.

<Thickness x:Name="FlyoutLooseCornerRadius" Value="4,4,4,4"/>

오리엔테이션:

• 맨 아래
• BottomEdgeAlignedLeft
• BottomEdgeAlignedRight
• 가득한
• 왼쪽
• LeftEdgeAlignedBottom
• LeftEdgeAlignedTop
• 오른쪽
• RightEdgeAlignedBottom
• RightEdgeAlignedTop
• 맨 위
• TopEdgeAlignedLeft
• TopEdgeAlignedRight

플라이아웃은 ComboBox 컨트롤 내부에 포함되어 있습니다. 따라서 컨트롤에는 플라이아웃이 포함되지 않고 ComboBox에만 영향을 미치는 CornerRadius 속성이 있으며 재정의되는 ThemeResource가 있습니다.

<ComboBox CornerRadius="2,2,2,2">  
      <x:String>Blue</x:String>
      <x:String>Green</x:String>
      <x:String>Red</x:String>
      <x:String>Yellow</x:String>
</ComboBox>  

플라이아웃이 ComboBoxes(및 기타 컨트롤)에 정렬되고 연결될 때 CornerRadius 속성을 조정한 후 원하는 결과를 얻으려면 FlyoutPlacementMode 열거형에 TopEdgeAligned 및 BottomEdgeAligned 를 추가해야 할 수 있습니다.

_(업데이트된 이미지)_

나는 또한 플라이아웃 스타일링에 대해 800% 더 자세히 살펴보았습니다. 두 개의 테두리는 그림자가 있거나 없는 밝은 테마와 어두운 테마 모두에서 플라이아웃이 높아 보이도록 합니다.

아주 좋아보입니다.
물론 첨부된 모양은 첨부하는 항목이 플라이아웃보다 작을 때 이상하게 보이지만 개별 앱이 결정할 문제입니다.
맨 아래 행에 있는 항목의 포커스 강조 표시는 맨 아래에서 반올림되어서는 안 되지만(맨 위 행은 맨 위가 아니므로) 이는 의도된 것이 아닐 수 있습니다.

그런데 이 "첨부된 모양"이 MacOs Top Menu Bar가 작동하는 방식이므로 이 모양이 이상하게 드문 것처럼 보이지는 않습니다. ;)

아주 좋아보입니다.
물론 첨부된 모양은 첨부하는 항목이 플라이아웃보다 작을 때 이상하게 보이지만 개별 앱이 결정할 문제입니다.
맨 아래 행에 있는 항목의 포커스 강조 표시는 맨 아래에서 반올림되어서는 안 되지만(맨 위 행은 맨 위가 아니므로) 이는 의도된 것이 아닐 수 있습니다.

그런데 이 "첨부된 모양"이 MacOs Top Menu Bar가 작동하는 방식이므로 이 모양이 이상하게 드문 것처럼 보이지는 않습니다. ;)

반올림을 잊어버렸기 때문에 이미지를 업데이트하여 수정하고 Zoomed 예제를 통해 좀 더 세부적인 내용을 추가했습니다.

둥근 강조 표시가 있는 중간 항목을 선호하는지 여부는 확실하지 않습니다. 한편으로는 더 일관되고 다른 한편으로는 약간 공격적인 모습을 남기기 때문입니다. 강조 표시된 요소와 테두리 사이의 공백.
하지만 그건 내가 결정하는 실제 디자이너에게 맡기는 것입니다. :D

둥근 강조 표시가 있는 중간 항목을 선호하는지 여부는 확실하지 않습니다. 한편으로는 더 일관되고 다른 한편으로는 약간 공격적인 모습을 남기기 때문입니다. 강조 표시된 요소와 테두리 사이의 공백.
하지만 그건 내가 결정하는 실제 디자이너에게 맡기는 것입니다. :D

동의합니다. 저도 그것에 대해 두 가지 생각을 가지고 있습니다. 나는 직선형이 좋다고 생각하지만 플라이아웃을 호출하는 컨트롤이 둥글고 컨트롤 내의 컨트롤이므로 _반올림해야 합니다_.

그리고 일부 상황에 맞는 메뉴에는 플라이아웃의 전체 너비에 걸쳐 있지 않은 컨트롤이 포함되므로 둥근 선택이 해당 메뉴에서 작동합니다.

둥근 강조 표시가 있는 중간 항목을 선호하는지 여부는 확실하지 않습니다. 한편으로는 더 일관되고 다른 한편으로는 약간 공격적인 모습을 남기기 때문입니다. 강조 표시된 요소와 테두리 사이의 공백.
하지만 그건 내가 결정하는 실제 디자이너에게 맡기는 것입니다. :D

나도 같은 느낌이다. 콤보 목록이 콤보 상자와 같은 크기이면 원점에 직선으로 있어야 하고, 그렇지 않으면 정렬되지 않은 쪽이 둥글어야 합니다.

@mdtauk @Qowy @shaheedmalik 콤보박스 전용 문제를 만들 수 있나요? 이 스레드는 일반적으로 모서리 반경에 관한 것이며 여기에서 볼 수 있는 것처럼 완전히 새로운 대화를 쉽게 생성할 수 있으므로 일반적인 접근 방식에 대한 요점을 흐리게 할 수 있는 특정 경우가 아닙니다.

이것을 오해하지 마십시오. 그러나 많은 컨트롤에 대해 그러한 특정 토론이 있는 경우 이 스레드는 일반적인 초점을 쉽게 잃을 것입니다.

매우 감사!

추신: 테두리가 없는 강조 표시 요소 정보: 요소 강조 표시는 확실히 직사각형이어야 합니다. 둥근 색상으로 만드는 것은 이상합니다.

나는 아마도 내 의견으로는 소수에 속하지만 공통 컨트롤의 모서리 반경을 변경하는 것은 솔직히 끔찍한 생각입니다. @mdtauk 에서 위의 메뉴 예제를 보고 현재 Edge 메뉴와 비교하면 약간 혐오스럽습니다. Fluent 디자인으로 모든 것이 마침내 해결되고 모든 것이 마침내 일관되고 정말 좋아 보입니다. 이제 웹처럼 보이도록 모두 변경해 볼까요? 아니요...웹을 웹으로 만들고 Windows(및 공용 컨트롤)를 그대로 두십시오. 개발자가 자체 앱에서 타사 컨트롤을 사용하여 둥근 모서리를 구현하려는 경우 그렇게 하십시오. 그러나 지금 기본 모양과 느낌을 변경하기 시작하는 것은 이단에 불과합니다. Apple을 Apple로, Google을 Google로, 웹을 웹으로 두십시오. 계속해서 Microsoft가 되어 자신의 일을 하십시오. 작동 중이니 작동시키십시오. 예를 들어 저는 Fluent 디자인의 Microsoft Windows 10 모양과 느낌을 실제로 좋아하고 내 앱이 Apple, Google 또는 웹이 아닌 Windows처럼 보이길 원합니다. 나는 Chrome이 보이는 방식을 참을 수 없습니다. Edge는 훨씬 더 멋지게 보이고 Windows는 macOS보다 형태와 기능 면에서 훨씬 뛰어납니다. 그리고 TBH는 Windows 10 Mobile을 휴대폰으로 다시 가져옵니다. 좋은 슬픔입니다. 너무 빨리 포기하고 Fluent 디자인을 그대로 두십시오.

@mdtauk

OS 수준에서 수행하는 것은 복잡한 작업이며 연구는 이를 구현하는 데 관련된 엔지니어링 시간과 노력을 보증하지 않습니다.

이 제안은 컨트롤에 CornerRadius 속성을 추가하여 이미 대부분의 작업을 수행하는 것으로 보입니다. 그런 다음 남은 것은 이러한 컨트롤이 실제 모서리 반경에 대해 바인딩할 수 있는 SystemCornerRadius 리소스를 만드는 것입니다(오늘날 SystemAccentColor 리소스를 사용하여 설정 앱에서 사용자가 설정한 강조 색상으로 UI 요소의 색상을 지정하는 방법과 유사합니다.
그러한 리소스를 만들고 설정 앱을 통해 업데이트할 수 있도록 하는 데 얼마나 많은 작업이 필요한지에 관해서는 MS가 논평을 남겨야 합니다. 그러나 이 제안이 이미 수행하고 있는 작업과 AccentColor 리소스를 노출하는 형태의 이전 작업을 감안할 때 귀하가 말한 것처럼 얼마나 까다로운 작업인지 모르겠습니다. OS 레벨은 문자 그대로 읽고 쓸 수 있는 모서리 반경 값만 제공하고, 오늘날의 액센트 색상 리소스에 대해 이미 있는 동일한 시스템을 사용할 수 있습니다.

슬라이더나 토글이 될까요?
[X] 컨트롤의 둥근 모서리
btw를 설정할 단일 모서리 반경 값만 있는 것은 아닙니다. 일부 요소는 한쪽만 둥글거나 상단 모서리만 둥글게 됩니다. 플라이아웃 및 팝 오버 컨트롤의 반경은 4 epx이지만 다른 컨트롤의 반경은 2 epx입니다.
OS에서 이 설정이 변경됨에 따라 많은 변수를 설정하게 됩니다. 그렇다면 테스트는 어떨까요? 기대도 있었을 것이다. 사용자는 사용자의 선호도를 무시하기로 결정한 앱에 어떻게 반응할까요?
반올림되는 컨트롤과 그렇지 않은 컨트롤을 사용자와 어떻게 소통합니까? 일부 컨트롤에는 내부 테두리 또는 외부 테두리 요소가 있습니다. 이들은 모양의 가장자리를 적절하게 끌어안기 위해 CornerRadius 값을 조정해야 합니다.
결국 이는 큰 무리 없이 환영할 만한 변화일 수 있어 OS에 또 다른 옵션을 추가하는 것은 과민반응이라고 볼 수 있다.

여기에 2epx 모서리 반경이 있고 거기에 4epx 모서리 반경이 있고 2 또는 4가 제대로 보이지 않기 때문에 다른 곳에서 다른 것은 끔찍한 UX입니다. 공통 컨트롤을 그대로 두십시오 - 작업 완료... 다른 멋진 것을 만들기 위해 이동하십시오.

@chigy
그래서 나는 며칠 전에 시작한 레딧 스레드 의 응답에서 계산을 했고 여기에 있습니다(불행히도 참여한 총 사용자 수를 쉽게 볼 수 있는 분명한 방법이 없는 것 같습니다)

의견 표현 친코너 반경(대조 UI): 18
12 (+1 내가 레딧 포스터 나를 포함하면, 또한 친 코너 반경 카운트 @shaheedmalik 포함) 의견 친 현재 UI (콘트라 코너 반경)를 표명

나머지:

• MS에 UI 선택 제공 요청
• 둘 다 좋아
• 제안에 대한 의견을 밝히지 않음
• Windows 시스템의 불일치(예: Win32 프로그램 대 UWP 앱)에 대한 일반적인 좌절감을 표현했습니다.

특히 마지막 그룹(당황)은 스레드에 참여하는 사람들의 좋은 덩어리였습니다.

결과를 요약하면 둥근 모서리(제안)와 네모 모서리(현재 UI) 모두에 대해 상당한 파벌이 있음을 알 수 있습니다. 거기에 시스템에서 이 두 스타일 사이를 전환할 수 있기를 바라는 사람들의 그룹을 추가하십시오.
그러나 둥근 모서리 여부를 제외하고 가장 많이 주어진 응답은 마침내 Windows 시스템 전체에 일관성을 가져오는 것입니다. WinUI 3.0과 MS 팀은 모든 다른 Windows 시스템 구성 요소와 UWP 앱을 단일 UI 디자인 언어로 가져오기 위해 작업을 중단합니다.

@chigy
사용자를 "제외"하는 대신 "포함"하라는 Microsoft 디자인 팀의 모든 이야기와 함께 이 스레드와 위의 레딧 스레드는 제안된 둥근 모서리 사이를 전환하기 위해 UI에서 간단한 옵션을 제공해야 하는 충분한 이유가 있음을 보여줍니다. UI 및 현재 UI(날카로운 모서리).

@Felix-Dev 기술적으로 내가 작성한 게시물은 플라이아웃 컨트롤에 관한 것이었으며 ComboBox는 플라이아웃 구성 요소가 있는 컨트롤 중 하나일 뿐입니다.

모든 상황에서 모든 모서리를 반올림하는 것이 합리적이라고 생각합니다. 그리고 팀은 플라이아웃과 대화 상자가 4 epx 모서리를 사용하고 다른 컨트롤은 2 epx를 사용하기로 결정했습니다.

@mdtauk ,
내가 말했듯이, 이것을 오해하지 마십시오. 이 스레드에서 특정 컨트롤 UI를 지적하는 것이 절대적으로 괜찮다고 생각합니다(예: treeview 예제에서 체크박스 모서리 반경에 대한 이상한 모양의 모서리 두께에 대해 질문했습니다).
특정 UI 요소(예: 플라이아웃/콤보박스/...)와 관련하여 여러 게시물에 걸쳐 대화가 발생하는 경우 이 특정에 대해 별도의 문제를 만드는 것이 가장 좋습니다. 그리고 보셨듯이 플라이아웃에 대한 귀하의 게시물은 곧 콤보박스에 대한 토론으로 이어졌습니다. 이제 누군가 초점 그림자가 어떻게 생겼는지에 대한 대화를 시작하고 스레드를 일반 상태로 되돌리기 어려운 곳에서 시작하는 전체 "혼란"(근접에서 논의되는 여러 특정 UI 요소에서와 같이)이 있다고 상상해 보십시오. 제안 및 처리 방법.

@mdtauk ,
내가 말했듯이, 이것을 오해하지 마십시오. 이 스레드에서 특정 컨트롤 UI를 지적하는 것이 절대적으로 괜찮다고 생각합니다(예: treeview 예제에서 체크박스 모서리 반경에 대한 이상한 모양의 모서리 두께에 대해 질문했습니다).
특정 UI 요소(예: 플라이아웃/콤보박스/...)와 관련하여 여러 게시물에 걸쳐 대화가 발생하는 경우 이 특정에 대해 별도의 문제를 만드는 것이 가장 좋습니다. 누군가가 초점 그림자가 어떻게 생겼는지에 대한 대화를 시작하고 스레드를 일반 제안으로 되돌리기가 어렵고 그것을 처리하는 방법에 대해 시작하는 전체 혼란을 상상해보십시오.

플라이아웃에 대해서만 별도의 문제를 만들 생각은 없지만 해당 컨트롤의 모서리 반경에 대해 구체적으로 논의했습니다.

@chigy 가 업데이트된 모든 컨트롤 디자인이 포함된 업데이트된 Design Toolkit을 볼 수 있을 때 일종의 추정치를 제공할 수 있는지 궁금합니다. 와 함께.

게시물 수를 계산하려면 추천 수도 계산해야 합니다.

@shaheedmalik
찬성 투표자들이 이러한 UI 유형에 대해 어떻게 느끼는지 정확히 모르기 때문에 상향 수를 명시적으로 계산하지 않습니다(예를 들어, 둘 중 하나를 선택해도 괜찮을 수 있지만 여전히 현재 UI처럼 둥근 코더 제안을 좋아합니다). 더 중요한 것은 UI 불일치를 지적하는 것과 같이 해당 게시물의 특정 부분 때문에 게시물에 찬성 투표를 했을 수 있다는 것입니다. 따라서 저자의 진술에서 어느 UI에 대한 승인을 명확하게 볼 수 있는 실제 게시물만 계산했습니다.

FWIW, "2px가 스위트 스폿인 것 같습니다." 54점으로 가장 많은 표를 얻었다.

"최종 사용자 테마 지원"을 요구하는 높은 평가를 받은 게시물(+21 - 4위)도 있습니다. 하지만 이러한 모든 찬성이 사용자 지정 요청 부분에 대한 것인지 아니면 작성자가 누락된 부분을 비판하는 부분에 대한 것인지 결정할 수는 없습니다. 시스템의 일관성.

@chigy 가 업데이트된 모든 컨트롤 디자인이 포함된 업데이트된 Design Toolkit을 볼 수 있을 때 일종의 추정치를 제공할 수 있는지 궁금합니다. 와 함께.

물어주셔서 감사합니다. 해당 이슈의 '중요사항' 부분에 디자인 구성요소를 링크하였으니 확인 부탁드립니다.

일반적으로 WinUI에서 둥근 모서리가 작동하도록 하는 방법에 중점을 두고 대화를 유지하고 싶습니다. 나는 사람들이 이 아이디어에 대해 또는 둥근 모서리가 일반적으로 좋은 아이디어라고 해도 의견이 다르다는 것을 알고 있습니다. 따라서 이것이 Microsoft의 다른 팀에서 추방되는 전체 Windows 디자인 방향의 일부라는 점을 언급할 가치가 있다고 생각했습니다. 우리는 WinUI가 이 새로운 디자인 방향과 함께 작동하도록 하여 개발자를 더 쉽게 만드는 방법을 알아 내려고 노력하고 있습니다. 우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다. 즉, 둥근 모서리는 이미 계획이므로 WinUI 커뮤니티와 협의하여 이 기능을 책임감 있게 구현할 수 있도록 하고 싶었습니다. 그것이 의미가 있기를 바랍니다.

우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다. 즉, 둥근 모서리는 이미 계획이므로 WinUI 커뮤니티와 협의하여 이 기능을 책임감 있게 구현할 수 있도록 하고 싶었습니다.

여기에 있는 많은 사람들이 권한을 가진 사람들과 이야기하고 싶어할 것 같습니다. 왜냐하면 이것이 우리 중 많은 사람들에게 중요한 문제이기 때문입니다.

물어주셔서 감사합니다. 해당 이슈의 '중요사항' 부분에 디자인 구성요소를 링크하였으니 확인 부탁드립니다.

일반적으로 WinUI에서 둥근 모서리가 작동하도록 하는 방법에 중점을 두고 대화를 유지하고 싶습니다. 나는 사람들이 이 아이디어에 대해 또는 둥근 모서리가 일반적으로 좋은 아이디어라고 해도 의견이 다르다는 것을 알고 있습니다. 따라서 이것이 Microsoft의 다른 팀에서 추방되는 전체 Windows 디자인 방향의 일부라는 점을 언급할 가치가 있다고 생각했습니다. 우리는 WinUI가 이 새로운 디자인 방향과 함께 작동하도록 하여 개발자를 더 쉽게 만드는 방법을 알아 내려고 노력하고 있습니다. 우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다. 즉, 둥근 모서리는 이미 계획이므로 WinUI 커뮤니티와 협의하여 이 기능을 책임감 있게 구현할 수 있도록 하고 싶었습니다. 그것이 의미가 있기를 바랍니다.

TextBox 테두리 두께 등과 같은 몇 가지 사항에 대한 대화가 아직 진행 중이라고 말씀하셨습니다. 그래서 저는 그 디자인이 최종 최종본이 아니라 _초기 아이디어_라고 가정했습니다. (나는 여전히 TextBox, Buttons, CheckBoxes 등과 같은 것들에 영향을 미칠 수 있기를 바랐던 것 같다)

나는 이것에 대한 답을 알고 있다고 생각하지만 어쨌든 물어볼 것입니다. 팀이 결정한 이러한 Windows UI 디자인을 공유할 계획이 있습니까?

Windows에서 계획 중인 이러한 변경 사항은 Win32 Visual Styles 및 Shell 창 TitleBars 등에 대해서도 적용됩니까? 그렇다면 WPF는 이 새 스타일이 적용되는 해당 Windows 버전에서 실행할 때 기본 컨트롤도 업데이트해야 합니다. (나는 이미 #699가 일어나야 한다고 제안했다)

우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다. 즉, 둥근 모서리는 이미 계획이므로 WinUI 커뮤니티와 협의하여 이 기능을 책임감 있게 구현할 수 있도록 하고 싶었습니다.

여기에 있는 많은 사람들이 권한을 가진 사람들과 이야기하고 싶어할 것 같습니다. 왜냐하면 이것이 우리 중 많은 사람들에게 중요한 문제이기 때문입니다.

디자인 변경 사항이 적용되면 피드백 허브에 표시될 것입니다. Windows 팀에 전달될 가능성이 큽니다.

TextBox 테두리 두께 등과 같은 몇 가지 사항에 대한 대화가 아직 진행 중이라고 말씀하셨습니다. 그래서 저는 그 디자인이 최종 최종본이 아니라 _초기 아이디어_라고 가정했습니다. (나는 여전히 TextBox, Buttons, CheckBoxes 등과 같은 것들에 영향을 미칠 수 있기를 바랐던 것 같다)

나는 이것에 대한 답을 알고 있다고 생각하지만 어쨌든 물어볼 것입니다. 팀이 결정한 이러한 Windows UI 디자인을 공유할 계획이 있습니까?

@mdtauk
예, 여기에서 매우 투명하게 설명하자면... 현실은 이 특정 문제의 대화가 더 빨리 느려질수록 더 빨리 작업에 착수할 수 있다는 것입니다... :)

@chigy 대화의 탈선과 진행 속도 저하에 기여했다면 사과드립니다. 저는 단지 도움을 주고 싶었고, WinUI 3.0이 가능한 한 좋게 보이도록 하고 싶었습니다!

@chigy
나는 지금 혼란스럽다. 당신은 Windows Fluent 디자인 팀에서 일하는 사람입니다. WinUI는 "[...] Windows 자체를 만드는 데 사용되는 고도로 최적화된 기본 UI 플랫폼"이라고 합니다( 여기 에서 "WinUI 3의 이점" 섹션에서 인용). 이것이 Windows 10 디자인 언어에 영향을 주는 곳이 아니라면 무엇입니까?

나는 당신의 대답에 대해 어떻게 생각하는지 모르겠습니다. 기본적으로 우리에게 피드백을 요청하지만 어쨌든 제안에 영향을 줄 기회가 많지 않은 것으로 나타났습니까? 이 게시물에 실제 권한을 가진 사람이 없다면 여기서 우리가 하는 일은 기본적으로 뜨거운 공기입니다. Martin이 디자인 컨셉을 게시하는 것과 같은 경우에도 desgin 팀에서 구현되기를 바랍니다. WinUI 팀 자체가 "WinUI 3.0+는 Windows UI가 될 것"이라고 말했기 때문에 WinUI는 "Windows 디자인 권한"이 원하는 위치와 다르게 컨트롤의 스타일을 지정할 수 없습니다.

@chigy
나와 다른 사람들은 "Windows 사용자"가 일부 의견에서 제안한 것처럼 동질적인 그룹이 아니라는 점을 강조하기 위해 많은 시간, 에너지 및 열정을 투자했습니다. 우리는 Martin의 외부와 새로운 UI 업데이트를 좋아하지 않아 신중하게 측정된 UI 사용자 정의의 사례를 만들고 싶어하는 다른 사람들이 있음을 보여주었습니다.

당신이 바로 이 요구를 무시하고 있다는 느낌도 듭니다. "우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다."라고 말합니다. 저와 다른 사람들은 최근에 이 UI 푸시를 폐기할 것을 요구한 것이 아니라 트위터에서 "사용자 포함"에 대한 자신의 디자인 토크를 따르고 그들을 제외하지 말라고 요구했습니다. 우리는 움직임을 되돌리는 것이 아니라 옵션을 요구했습니다.
그러나 지금까지 "사용자가 선택할 수 있는 모서리 라운딩을 제공하는 옵션을 제공하는 옵션은 흥미로운 옵션입니다. 그러나 이는 다른 피드백보다 이 피드백과 많은 관련이 있습니다. Windows 시스템 전체에서 비교해야 하는 중요한 기능입니다." 이제 시작이라고 생각하지만 우리는 지금 어디에 있습니까?

당신은 당신이 Windows 디자인에 대한 권한을 가진 실제 팀에 속해 있지 않다고 말합니다. 그것은 우리 모두가 지금까지 잘못된 사람에게 말을 걸어왔다는 것을 의미합니다! 우리가 실제로 총을 쏘는 팀의 멤버와 이야기한 적이 없다면 왜 그렇게 빨리 말하지 못했는지 궁금합니다.

나는 지금은 시작 할 수있는 권한을 가진 사람과 이야기 결코 배우고, 투자 모든 에너지 후, 실망하고있다. 기본적으로 모든 피드백과 나와 다른 사람들이 수집한 UI 사용자 지정 사례는 기본적으로 아무 소용이 없습니다.

죄송합니다. 머리를 감쌀 수가 없습니다. Windoiws UI를 구동하는 것으로 추정되는 리포지토리의 Windows Fluent 디자인 팀 구성원은 며칠 후에 우리가 정말로 중요한 사람과 이야기한 적이 없다고 말합니다.

이것이 욕설로 들리면 죄송하지만 여기서 약간 충격을 받았습니다. 내가 이 특정 토론(및 열정적인 답변을 작성한 다른 사람들)에 얼마나 투자했는지 모를 수도 있지만 설명을 요청하고 싶습니다.

UI 사용자 정의에 대한 우리의 요구는 실제로 어디에 있습니까? 이 리포지토리가 Windows UI 토론에 더 이상 중요합니까?

나는 그것을 남길 것이다:

" [WinUI 3.0] Windows의 기본 UI 플랫폼WinUI는 Windows 자체를 만드는 데 사용되는 고도로 최적화된 기본 UI 플랫폼으로, 이제 모든 개발자가 Windows에 도달하는 데 사용할 수 있도록 더 광범위하게 제공됩니다.

@Felix-Dev 내 디자인이 실제 디자인이 되어야 한다고 주장하는 것이 아니라 영향을 미치고 싶었습니다. 저는 Windows Vista/7/Zune/Windows Phone 시절부터 Windows 애호가였던 디자이너입니다.

@mdtauk
사실, MS가 당신의 아이디어를 채택하는 것에 대해 당신은 분명히 반대할 것이 없겠지만, 맞습니까? 😉 결국, 당신은 그들을 확신합니다!

당신이 성급하게 다가왔다면 죄송합니다. (그리고 당신은 또한 당신의 제안이 그렇게 나올 수 있도록 말했습니다) 그러나 @chigy 의 대답은 충격적 이었습니다. 당신이 이해할 수 있기를 바랍니다!

WinUI 팀 != Windows 개발 팀.

Windows 10이 현재 OS이지만 Windows Lite 및 Windows Core OS는 향후 방향입니다.

@chigy 는 Windows 팀이 OS Shell에 대해 무엇을 할 계획인지 분명히 보고 있으며 WinUI 3.0이 그곳에서 홈을 볼 수 있도록 하기를 원합니다. 계산기, 설정, 작업 표시줄 플라이아웃 및 셸 등과 같은 Windows 앱은 아마도 모두 WinUI 3.0을 사용하므로 디자인 면에서 같은 페이지에 있어야 합니다.

Microsoft의 Fluent 디자인 팀은 UI 디자인 작업을 통해 WinUI, Windows, Xbox, Office, Bing, Teams, Fabric, Fluent Web과 같은 다른 Microsoft 팀이 따르는 규칙(색상, 글꼴 스타일 및 크기, 재료 등)을 만듭니다.

여기서 구조를 잘못 이해했다면 수정하겠습니다.

내가 이 리포지토리에 기여한 내 아이디어는 Fabric Web과 WinUI 3.0 사이의 격차를 좁히기 위해 노력했습니다.

내가 이해한 방법은 다음과 같습니다.

@chigy 는 Windows Fluent 디자인 팀의 구성원이며 FD(Fluent Design)가 Windows 10의 디자인 언어이므로 Windows 디자인 팀의 구성원이 됩니다.

그런 다음 공식적으로 Windows를 구동하고 Windows 자체를 만드는 데 사용되는 플랫폼으로 설명된 WinUI 3.0이 있습니다. 따라서 Windows UI 디자인 토론은 여기에서 집처럼 느껴집니다.
또한 위의 설명을 기반으로 Windows 개발 팀이 WinUI를 사용하여 앱과 시스템 UI를 모두 구현한다는 의미입니다. 그렇지 않으면 실제로 중요한 사람과 이야기하지 않을 UI 제안 스레드에서 명시적으로 지적해야 하며 제안은 실제로 UI 디자인이 아니라 실제 구현에 대한 피드백에 관한 것 입니다.

그리고 윈도우 유창함 디자인 팀과 WinUI 팀은 기본 Windows UI 설계 및 실현되는 팀이없는 경우에도, 우리가 실제로 중요한 사람에게 이야기를 결코 @chigy이 우리를 통보하지 않았다는 사실을 chanage하지 않습니다. 우리는 시간과 에너지를 투자했습니다(컨트롤 개념을 가진 당신, 피드백을 수집하려고 노력하는 나, 활발한 토론을 하고 열정적으로 참여한 다른 모든 사람들을 잊지 않기 위해). 결국 우리는 실제 Windows UI 팀원과 이야기를 나누지 않았습니다. 우리가 실제로 우리의 아이디어와 신념을 확신시키려고 노력할 수 있는 사람.

우리는 Windows에서 둥근 모서리가 "사물"이 아니라는 결론을 내릴 권한이 없습니다. 즉, 둥근 모서리는 이미 계획이므로 WinUI 커뮤니티와 협의하여 이 기능을 책임감 있게 구현할 수 있도록 하고 싶었습니다. 그것이 의미가 있기를 바랍니다.

글쎄, 이것은 다른 사람들이 우리 중 많은 사람들에게 큰 문제라고 말했듯이 나에게 엄청난 실망입니다. 따라서 이에 대한 영향력이 없다면 정중하게 @chigy 에게 물어볼 수 있습니다. 우리가 이야기해야 할 사람은 누구입니까? 그렇지 않다면 많은 사람들이 싫어하는 이 논란의 여지가 있는 UI 변경에 대해 어떻게 우리의 목소리를 낼 수 있습니까?

이는 몇 년 전 윈도우 10 개발 당시 스퀘어 프로필 사진을 원형 사진으로 만들자는 제안이 있었는데 다시 많은 사람들이 이를 싫어하며 피드백 허브로 갔던 담론과 매우 흡사하다. 피드백 허브에는 1000000개 이상의 찬성 투표가 있는 여러 게시물이 있어 이 작업을 수행하지 말 것을 요청했습니다.

응답은 본질적으로 사람들에게 그들의 의견에 관계없이 변경이 완료될 것이라고 다시 말했을 뿐입니다...

나는 그 게시물을 @Felix-Dev보다 덜 모욕적이고 모욕적으로 바꾸겠습니다.

@mdtauk
내 게시물이 어디에 모욕적입니까?

나는 아무에게도 이름을 부르지 않고, WinUI를 나쁜 말로 부르고, 이 문제를 모욕적인 말로 설명하지 않습니다. 나는 누군가를 개인적으로 공격하지 않습니다. 사실 저는 아무 것도 공격하지 않습니다.

@mdtauk
내 게시물이 어디에 모욕적입니까?

나는 아무에게도 이름을 부르지 않고, WinUI를 나쁜 말로 부르고, 이 문제를 모욕적인 말로 설명하지 않습니다. 나는 누군가를 개인적으로 공격하지 않습니다. 사실 저는 아무 것도 공격하지 않습니다.

@chigy 는 WinUI 컨트롤의 디자인 작업을 담당하는 사람입니다. 그의 역할을 Windows 또는 Fluent 팀의 역할로 착각했다면 그의 역할이 중요하지 않다고 말해서는 안 되며 개인적인 것으로 만들어서도 안 됩니다.

@mdtauk
"Chigusa Sansen은 XAML UI 플랫폼 팀의 수석 프로그램 관리자 이자 Fluent Design System의 핵심 구성원입니다. "(출처: https://mybuild.techcommunity.microsoft.com/speaker/545575?source=sessions)

그녀는 또한 그 세션에서 Windows와 관련된 FD 파트를 보유했습니다.

그리고 "정말 중요한 사람"이라는 부분에 대해. 나는 그것이 모욕이라고 생각하지 않습니다. 왜냐하면 우리의 경우 그녀는 실제로 Windows용으로 선택된 UI 방향에 대한 샷을 실제로 호출하는 팀에 없다고 말했기 때문입니다. 치구사 산센 양을 공격하지도, 조롱하지도, 이름을 부르지도 않았다. 나는 단순히 그녀가 우리에게 개인적으로 말한 것을 말했습니다.

그리고 "정말 중요한 사람"이라는 부분에 대해. 나는 그것이 모욕이라고 생각하지 않습니다. 왜냐하면 우리의 경우 그녀는 실제로 선택한 UI 방향에 대한 샷을 요청하는 팀에 없다고 말했기 때문입니다.
윈도우.

글쎄, 나는 그것을 모욕이라고 생각한다. 특히 "오도"되는 것과는 달리 토론의 목적을 잘못 이해 한 것 같습니다.

@mdtauk
우리는 여기에서 서로 다른 파장을 가지고 있으며 그것이 왜 그럴 수 있는지 추측하려고 노력하는 것은 의미가 없습니다...

일반적인 UI 이동에 대한 이 토론을 시작할 때 Miss Chigusa Sansen이나 WinUI 팀의 다른 구성원은 이 스레드가 이 토론에 적합하지 않다고 분명히 말한 곳이 없었습니다. 대신 사람들은 열정적으로 토론하기 시작했고 찬성/반대 의견을 내세우며 이 토론의 성격상 Microsoft/Windows에서 관련 UI 위치에 있을 누군가와 이야기하고 있다고 생각했습니다.

Chigusa도 참여했고 UI 방향에 영향을 미치기를 바라는 마음으로 컨트롤 이미지를 자유롭게 추가했으며 MS에서 더 이상 아무도 나서지 않아 일반적인 UI 디자인에 대해 논의하는 자리라는 느낌을 내 불만은 , 그리고 당신은 그것을 놓친 것 같습니다. @chigy 가 전화를 거는 팀에 있지도 않기 때문에 여기에서 그 토론을 하는 것은 별로 의미가 없다고 간단히 우리에게 말하는 데 너무 오랜 시간이 걸렸습니다. 일반샷.

그것은 당신이 말한 것처럼 "오도"또는 "오해"에 관한 것이 아니라 그러한 필수 정보가 며칠 동안 우리에게 숨겨져있었습니다. Chigusa Sansen 양이 더 일찍 언급했더라면 이 전체 토론은 이미 오랫동안 진행되었을 수 있습니다. btw, 당신과 그녀 모두가보고 싶어하는 것입니다.

@mdtauk
우리는 여기에서 서로 다른 파장을 가지고 있으며 그것이 왜 그럴 수 있는지 추측하려고 노력하는 것은 의미가 없습니다...

일반적인 UI 이동에 대한 이 토론을 시작할 때 Miss Chigusa Sansen이나 WinUI 팀의 다른 구성원은 이 스레드가 이 토론에 적합하지 않다고 분명히 말한 곳이 없었습니다. 대신 사람들은 Microsoft/Windows에서 중요한 UI 위치에 있을 누군가와 이야기하고 있다고 생각하면서 찬성/반대 움직임에 대해 열정적으로 토론하기 시작했습니다. 치구사도 참여했고 UI 방향에 영향을 주고자 컨트롤 이미지도 자유롭게 추가했습니다. 내 불만은 , 그리고 당신은 그것을 놓친 것 같습니다. @chigy 가 전화를 거는 팀에 있지도 않기 때문에 여기에서 그 토론을 하는 것은 별로 의미가 없다고 간단히 우리에게 말하는 데 너무 오랜 시간이 걸렸습니다. 일반샷.

그것은 당신이 말한 것처럼 "오도된" 또는 "오해"에 관한 것이 아니라 그러한 필수 정보가 며칠 동안 우리에게서 숨겨져 있었습니다. Chigusa Sansen 양이 당신과 그녀 모두가 보고 싶어하는 것을 더 일찍 언급했다면 이 전체 토론은 이미 오랫동안 진행되었을 수 있습니다.

@Felix-Dev @Nepxune
예의 바르고 긍정적인 태도를 유지합시다. 😃 게시된 이미지는 CornerRadius 값과 관련된 컨트롤의 변경 사항을 강조 표시합니다. 현재 값을 지원하지 않거나 존중하지 않는 컨트롤에 CornerRadius를 추가하는 특정 메커니즘이 이를 지원하도록 만들 수 있고 개발자가 값을 재정의하여 값을 무시하거나 사용자 지정할 수 있는 또 다른 문제가 있습니다. 브랜드와 니즈에 맞는 가치를 추구합니다. #684

이 문제는 웹 및 앱 스타일 방향과 일치하는 공통 컨트롤의 모서리 반경 업데이트와 관련이 있습니다.

내가 게시한 아이디어는 Fabric Web에서 사용하는 스타일을 가져와서 XAML 컨트롤로 가져오는 것이므로 이 논의의 범위에 있다고 생각합니다. XAML 컨트롤 ThemeResource를 제어하는 ​​OS 기능은 주제와 약간 다르지만 관련되어 있습니다.

대화는 이미 결정된 변경을 성공적으로 수행하는 방법보다 먼저 변경을 수행할 때의 장점 또는 부족에 대한 토론으로 전환하려고 할 정도로 흥미롭고 적절했습니다. 만들다.

반올림 금액을 사용자가 토글하거나 변경할 수 있는 OS 설정을 만드는 제안을 높이려면 새로운 제안으로 만들어야 합니다.

행동강령을 참고하여 존중해 주시기 바랍니다. @chigy 는 속이거나 오도하려고 하지 않았습니다.

Martin은 우리가 향후 Windows 버전의 요구 사항을 충족하도록 설계를 제품화하는 데 도움을 줄 책임이 있는 플랫폼 팀이라는 것을 알고 있습니다. 우리는 또한 우리 플랫폼이 자신의 브랜드와 스타일을 가져오고 Windows 스타일을 따르기를 원하지 않는 사람들을 포함하여 다른 모든 사람들이 잘 작동하는지 확인하고 싶습니다. 이 모든 피드백은 매우 중요하며 Windows 디자인 팀과도 공유하여 OS 수준에서 사람들이 노브를 사용자 지정하기를 원하는 특정 피드백을 들을 수 있도록 합니다.

@Felix-Dev , @Nepxune 및 @mdtauk , 내가 이 GitHub 항목을 인수할 때 명확하지 않았을 수 있는 것을 지적해 주셔서 감사합니다. 아시다시피, 이것은 공개 커뮤니티에서 논의 중인 첫 번째 디자인 관련 문제이므로 진행하면서 배우고 있습니다...

그리고 먼저 제가 의도하지 않은 변경을 할 수 있는 권한이 있는 디자인 담당자라고 이 그룹의 누군가에게 오도를 했다면 죄송하고, 시간낭비라고 느끼셨다면 죄송합니다.

@jevansaks , 디자인과 관련된 WinUI의 역할을 요약해 주셔서 감사합니다.

즉, 내가 이 커뮤니티에 빚을 지고 있기 때문에 나 자신에 대해 명확히 하겠습니다. 저는 WinUI 엔지니어링 팀의 프로그램 관리자입니다. 저는 WinUI가 Fluent의 디자인 방향뿐 아니라 Windows 디자인 방향의 디자인 진리를 나타내는지 확인하기 위해 회사 전체의 디자인 팀과 매우 긴밀하게 협력합니다. 예를 들어 어제 저는 Xbox 디자인 팀과 함께 여기에서 제안된 디자인 변경 사항에 대해 논의했습니다. Xbox 개발자에게 여전히 유용한지 확인합니다. WinUI 팀 내에서는 전반적으로 뿐만 아니라 수평적으로 보다 체계적인 방식으로 디자인을 감독하며 UI/UX 관점에서 일관성이 없는 개별 기능을 출시하지 않도록 합니다.

저는 Windows를 대표하는 Fluent 디자인 시스템 노력에 참여하고 있으며 개발자 커뮤니티를 위한 강력한 목소리를 내려고 노력하고 있습니다. 또한 명확히 하자면, Fluent 디자인 시스템은 Microsoft의 많은 팀(설계 및 엔지니어링 팀)이 함께 협력하여 회사로서 훌륭한 UX를 제공하고 귀하와 같은 개발자가 사용할 수 있도록 하는 일관된 시스템을 실현하는 공동 노력입니다. 그래서 제가 참여한다고 해서 전화를 걸 수 있는 것은 아닙니다... 제 생각에는 이 집단의 단 한 사람도 할 수 없습니다... 그것은 집단적인 노력입니다...

@Felix-Dev , Windows 디자인 조직의 누군가와 사용자 설정에 대해 제안한 개념에 대해 개인적으로 논의했음을 알리기 위해 내 응답을 확인하기 위해(예: 이에 대한 기능 계획이 없거나 해당 요청과 관련된 작업에 관심이 있음을 확인합니다. ). 귀하의 의견이 논의되었습니다. 만족스럽지 않을 수도 있다는 것을 알고 있지만 제가 여러분의 모든 의견에 관심을 갖고 있으며 여기에서 대표자/브릿지가 되기 위해 최선을 다하고 있다는 것을 여러분이 알고 싶었습니다.

여러분, 저는 이 문제를 닫을 생각이 없었습니다. 댓글 닫으려고 하다가 실수로 닫았어요!!

@mdtauk @jevansaks @chigy
이 토론이 전문적이어야 한다는 점에 전적으로 동의합니다. 우리 모두는 Windows에 대한 열정과 Windows가 가능한 한 최고가 되기를 바라는 마음으로 뭉쳤습니다.

확실히 하자면 저는 치구사 산센 양이 우리를 "기만"하거나 "오도"했다고 비난한 적도 없고, 그런 의도도 아닙니다. 나는 또한 개인적으로 누구를 공격한 적도 없고 공격하지도 않을 것임을 분명히 말할 수 있습니다.

그러나 이 최근 대화에서도 보여주는 것은 이 오픈 소스 프로젝트가 아직 학습 단계에 있다는 것입니다. Microsoft와 그 열성적인 사용자, 이 새로운 오픈 소스 접근 방식이 실제로 커뮤니티에 얼마나 많은 영향을 미칠지, 관련 Windows 팀이 커뮤니티 피드백을 실제로 처리하는 방법에 대한 명확한 이해라는 두 세계를 성공적으로 통합하기 위해 해야 할 일이 아직 있습니다. .

일반적으로 나는 현재 상태에 이미 꽤 감명을 받았습니다. 피드백은 실제 WinUI 제품과 관련된 피드백이 아니더라도 WinUI 팀에 의해 발행되고 심각하게 처리됩니다. 나는 이것을 고맙게 여기고 당신은 그것에 대해 존경심을 가지고 있습니다!

불행히도 이 특별한 경우는 모든 참여 당사자가 아직 서로에 대해 완전히 배우지 못한 아주 어린 오픈 소스 프로젝트라는 몇 가지 증상을 겪었을 것입니다. 저는 이 사례를 사용하여 우리 모두를 위한 이 새로운 접근 방식의 가능성 과 한계 를 더 잘 이해할 수 있을 것이라고 낙관합니다!

모두들 안녕!
솔직한 대화 너무 감사합니다. 저는 많은 것을 배웠고 여러분이 열린 커뮤니티로 함께 성장하기 위해 우리와 계속 일할 의향이 있기를 바랍니다!

몇몇 분들이 지적하셨듯이 저는 WinUI 팀과 제가 할 수 있는 일과 할 수 없는 일에 대해 명확하지 않았기 때문에 여러분이 제기한 좋은 점과 그 결론을 요약해 보겠습니다. 그리고 문제가 여전히 열려 있다고 생각되면 계속 진행하십시오!

논의하는 동안 일부 문제가 해결되었다고 생각했기 때문에 우리가 논의한 모든 문제를 나열하지는 않았습니다. 다르게 생각하시면 알려주세요!!

• Xbox가 고려 중인지 확인하십시오(@mdtauk).
  o Xbox 디자인은 Xbox 팀이 소유합니다.
  o 하지만 예, 우리는 그들과 긴밀하게 협력합니다. Xbox 디자인 팀과 이 제안 및 향후 디자인 제안을 검토한 회의가 열렸음을 확인합니다.
• 경계선을 더 가늘게 만드는 것과 같은 정렬에 대한 다른 제어 관련 변경을 고려하십시오(@mdtauk).
  o Windows 디자인 팀은 Microsoft 디자인 팀 전체를 조정하기 위해 Fluent Design System 컬렉티브와 조정하면서 Windows에 대한 최종 결정을 내립니다.
  o WinUI 팀은 개발자에게 더 나은 작업을 제공하고 전환(또는 다시 전환)할 수 있는 좋은 개발자 스토리를 제공합니다.
  o 이는 향후 GitHub 문제에서 추적될 것입니다.
• 커뮤니티는 Fluent 디자인 팀( @mdtauk , @Felix-Dev, @Nepxune)에게 직접 의견을
  o 참고로 Fluent 팀에는 LinkedIn 그룹이 있습니다.
  o 이것은 WinUI 팀이나 본인 소유가 아닙니다.
  o 이것은 그들의 주의를 환기시키는 것이지만, 무슨 일이 일어나면 우리가 스스로 할 수 없는 일입니다.
  o 뭔가 구체화되면 이 그룹에 다시 연락할 것입니다.
• WPF/WinForms용 Fluent 테마를 출시합니까? (@Felix-Dev, @mdtauk)
  o 이것은 우리가 아직 알아내지 못한 것입니다.
  o 이것은 약간 복잡합니다. 저는 Windows 전반에 걸쳐 개발자를 위한 디자인 지침 및 디자인 지원을 보고 있는 사람이므로 이것이 제 관심 영역에 맞습니다. 그러나 솔직히 이것은 WinUI 작업이 아니기 때문에 현재로서는 우선 순위가 아닙니다.
• 둥근 모서리를 켜거나 끌 수 있는 사용자 설정(@Felix-Dev) / 둥근 모서리를 좋아하지 않고 둥글게 유지하고 사용자에게 옵션을 제공( @Nepxune 및 people on 레딧)
  o 불행히도 이것은 WinUI 결정이 아닙니다.
  o 내가 지금 추천할 수 있는 최선은 이 변경 사항이 Windows OS에 전파된 후 피드백 허브 문제를 여는 것인데 여전히 디자인이 요구 사항을 충족하지 못한다고 느끼십니까?
  o 조금이라도 위로가 된다면 최선을 다해 Windows 팀에 알리고자 노력했지만, Windows 팀에서는 계획이 없습니다.

현재 계획을 요약하면 다음과 같습니다.

• WinUI 2.x를 사용하여 얻은 컨트롤은 둥근 모서리를 사용하도록 기본 비주얼을 업데이트합니다.
  o 즉, WinUI 2.x를 사용하지 않는 경우 이 변경 사항이 적용되지 않습니다.
• 둥근 모서리의 값은 대부분의 컨트롤에서 2픽셀이며 플라이아웃 유형 UI의 경우 4픽셀입니다. UI가 다른 UI 요소와 교차할 때 반올림 없음
  o 시각적 구성 요소: https://github.com/mrlacey/microsoft-ui-xaml-specs/blob/RoundedCornerVisualizations/active/RoundedCorner/ImageFiles/index.md
  o 이에 대해 대화를 나눈 @mdtauk , @Qowy , @shaheedmalik 에 대한 짧은 메모. 우리는 내부 라인을 반올림하지 않을 것입니다. 이것은 제자리에 있는 시각적 구성 요소에 반영됩니다. Windows 디자인 팀은 다양한 옵션과 장단점을 살펴보고 평가했습니다.
• 개발자는 이것을 쉽게 되돌릴 수 있는 방법이 있습니다(#684).
• 사용자가 이를 앞뒤로 토글하거나 세부적으로 변경할 수 있는 사용자 설정은 없습니다.

@chigy 게시한 요약에 감사드립니다.

다음에 일어날 일에 대해 몇 가지 질문이 있습니다 ...

• 이러한 디자인 구성 요소는 모든 컨트롤의 최종 디자인을 반영합니까, 아니면 나중에 업데이트되거나 게시될 추가 변경 사항에 대해 논의하고 있습니까?

• 커뮤니티로서 WinUI에 제공되는 이러한 디자인 선택 사항 중 일부에 대해 영향을 미치거나 제안을 하기 위해 어떻게 제안합니까?

• 언제 Windows 디자인 팀이 Windows UI에 대해 갖고 있는 비전을 볼 수 있으므로 작업 중인 컨트롤 디자인에 대한 컨텍스트를 가질 수 있습니까?

• XAML을 사용하여 받은 편지함 앱과 셸 요소 간에 일관성을 설득/유도/시행하려는 노력이 있습니까? 그래서 모든 것이 디자인에서 일치합니까?

• Xbox 수정 컨트롤 디자인이 WinUI에 포함됩니까, 아니면 다음 Xbox 장치에만 제공됩니까(Windows에서 개발하는 동안 이러한 컨트롤 템플릿을 테스트할 방법이 없습니까?

@mdtauk 앗 글을 너무 많이 썼는데 설명을 잘 했는지 확인하고 싶었습니다...

• 이러한 디자인 구성 요소는 모든 컨트롤의 최종 디자인을 반영합니까, 아니면 나중에 업데이트되거나 게시될 추가 변경 사항에 대해 논의하고 있습니까?

당신이 comps에서 보는 것은 우리가 현재 얻을 수 있는 한 최종적입니다. 즉, 실제 컨트롤에서 변경 사항을 구현함에 따라 디자인이 약간 바뀌는 약간의 변경이 발생할 수 있습니다. 보시다시피, comp는 모든 UI 발생을 다루지는 않습니다. 나는이 특별한 노력에서 그것을 기대하지 않지만 ...

• 커뮤니티로서 WinUI에 제공되는 이러한 디자인 선택 사항 중 일부에 대해 영향을 미치거나 제안을 하기 위해 어떻게 제안합니까?

커뮤니티에서 우리에게 알려주고 싶은 것은 이러한 디자인 선택이 응용 프로그램에 실패하는 부분입니다. 우리가 당신에게 제공하지 않는 사용자 정의를 위한 장소가 있습니까? 어떤 이유로 앱이 완전히 중단됩니까?

내가 언급했듯이 디자인 결정은 디자인 팀에서 이루어지지만 WinUI는 여전히 개발자를 위한 솔루션을 제공하고 그것이 건전한지 확인하는 책임이 있습니다. 결과적으로 설계 결과물에 영향을 미칠 수 있는 기회가 있을 수 있습니다. 나는 아무 일도 일어나지 않을 것이라고 약속하지 않겠지만 그것이 어떻게 작동하지 않고 어떻게 고쳐져야 하는지에 대한 실제 예는 이 경우에 가장 효과적입니다...

• 언제 Windows 디자인 팀이 Windows UI에 대해 갖고 있는 비전을 볼 수 있으므로 작업 중인 컨트롤 디자인에 대한 컨텍스트를 가질 수 있습니까?

비전이란 Windows에 전반적으로 도입되는 UI 변경 유형을 알려주는 전반적인 이야기를 의미합니까? 구체적으로 무엇을 염두에 두고 계십니까?

• XAML을 사용하여 받은 편지함 앱과 셸 요소 간에 일관성을 설득/유도/시행하려는 노력이 있습니까? 그래서 모든 것이 디자인에서 일치합니까?

아래는 제가 알고 있는 내용을 바탕으로 한 지극히 제 주관적인 생각입니다. 그냥 명확하게... :)
내 생각에 문제는 두 가지입니다.

첫 번째 문제는 현재 OS 릴리스에 의존하는 새로운 UI에 대한 전달 시스템이 있다는 것입니다. 그 때문에 많은 받은 편지함 앱은 여전히 ​​이전 OS 버전을 지원해야 했기 때문에 Shell이 ​​사용하던 새로운 스타일 등을 채택할 수 없었습니다. OS 버전에 관계없이 이러한 변경 사항을 적용할 수 있도록 WinUI에서 새 UI를 제공하여 이 문제를 해결하려고 합니다.

두 번째 문제는 문화적 변화가 필요하다는 것입니다. 저는 Windows Phone을 포함하여 다양한 UI 플랫폼에서 작업하여 제품의 일관성을 유지하기 위해 다양한 접근 방식을 시도했습니다. 이런식으로.. 제한속도가 있어도 모두가 따라가는건 아니잖아요. 하지만 집행하기 위해 얼마나 많은 경찰을 보내야 합니까? 제한속도를 지키는 문화를 만들어야 합니다. 여기에는 마법의 해결책이 없습니다. 그리고 이것이 Fluent Design System이 가져오는 데 도움이 되기를 바라는 것입니다. 개인적인 의견이 아닌 시스템에 대한 디자인 결정을 내림으로써.

• Xbox 수정 컨트롤 디자인이 WinUI에 포함됩니까, 아니면 다음 Xbox 장치에만 제공됩니까(Windows에서 개발하는 동안 이러한 컨트롤 템플릿을 테스트할 방법이 없습니까?

Xbox 전용 컨트롤을 수정할 계획은 없습니다. 우리는 과거에 그렇게 하지 않았으며( 문서를 발표함) Xbox 팀과 커뮤니티 모두로부터 강력한 요청을 받지 못했습니다(이것은 사전 오픈 소스입니다).

@chigy 너무 솔직하고 답변해주셔서 다시 한번 감사드립니다.

다음 Xbox도 앱을 지원하고 코어 OS에서 XAML을 셸로 사용할 것이라고 가정했습니다. 이는 Xbox에도 Windows만큼 WinUI 3.0 컨트롤이 필요하다는 의미이기도 합니다. 따라서 Xbox용으로 설계된 템플릿을 포함하면 프로세스가 단순화되고 Xbox 앱 개발자가 더 쉽게 접근할 수 있습니다. 하지만 이는 분명히 다른 팀의 결정입니다. 😄

비전에 관해서는 - "미래의 Windows Shell 및 Inbox 앱의 모습은 다음과 같습니다." "우리는 Windows 디자인을 업데이트할 기회를 잡고 있습니다. 여기에 우리가 만들고 있는 몇 가지 변경 사항이 있습니다..."

큐 이미지 또는 비디오 😃

또한 Xbox와 Windows는 서로 일치해야 한다고 생각합니다. Windows에서는 중단되었지만 Xbox(CBS, FOX Sports)에는 여전히 존재하거나 Windows 10(YouTube)에는 존재하지 않는 Xbox용 앱이 있습니다.

모든 유형의 UI 변경을 수행해야 하는 경우를 제거하면 이러한 앱이 플랫폼에 유지됩니다.

그냥 내 생각.

또한 Xbox와 Windows는 서로 일치해야 한다고 생각합니다. Windows에서는 중단되었지만 Xbox(CBS, FOX Sports)에는 여전히 존재하거나 Windows 10(YouTube)에는 존재하지 않는 Xbox용 앱이 있습니다.

모든 유형의 UI 변경을 수행해야 하는 경우를 제거하면 이러한 앱이 플랫폼에 유지됩니다.

그냥 내 생각.

Xbox 앱에는 다양한 제어 스타일과 동작이 필요합니다. 그러나 이러한 앱은 Windows 컨트롤 스타일을 사용하지 않고도 해당 앱을 실행할 수 있도록 하는 일부 속성을 포함하여 Windows에서 실행할 수 있어야 합니다. 따라서 Xbox First 접근 방식입니다.

@shaheedmalik 및 @mdtauk , Xbox와 Windows가 일치해야 하고 앱이 서로에서 실행되어야 한다는 논의에 대해 약간 혼란스럽습니다.

Xbox 셸과 Windows 셸의 디자인은 다릅니다. 그것은 그들이 독특한 제품이기 때문에 의도적입니다. 그러나 우리는 하나의 스타일을 사용하려는 앱이 사소한 작업으로 실행할 수 있도록 WinUI 컨트롤을 설계했습니다. 몇 년 전 Xbox 팀과 작업할 때 XAML 컨트롤(당시 WinUI 없음)이 TV에 올바르게 표시되는지 확인하고 앞서 언급한 지침도 발표했습니다.

제대로 만든 UWP 앱은 Windows와 Xbox 모두에서 실행됩니다. @shaheedmalik이 나열한 앱과 같은 앱의 경우 Xbox 및 Windows에서 동일한 브랜드를 자주 볼 수 있는 브랜드입니다. 따라서 하나의 앱 디자인이 해당 기기에서 실행되는 경우가 많습니다.

다시 말하지만, 이것은 모서리가 둥근 주제이므로 다시 가져옵니다.
다음은 둥근 모서리가 출시되면 개발자가 Xbox에서 수행해야 하는 작업입니다. 개발자가 둥근 모서리 기능이 있는 WinUI 2.x를 채택하는 경우 개발자는 쉘 스타일과 일치시키려면 둥근 모서리 스타일을 꺼야 합니다. Xbox의 많은 앱은 그렇지 않습니다... 그렇기 때문에 관심 있는 사용자를 위해 지침 문서를 대신 출시합니다. 출시할 때 10FT 지침 문서에 둥근 모서리에 대한 언급이 있는지 확인하겠습니다.

비전에 관해서는 - "미래의 Windows Shell 및 Inbox 앱의 모습은 다음과 같습니다." "우리는 Windows 디자인을 업데이트할 기회를 잡고 있습니다. 여기에 우리가 만들고 있는 몇 가지 변경 사항이 있습니다..."

큐 이미지 또는 비디오 😃

@mdtauk , 그것은 내가 과거에 디자인 팀에 요청한 것이므로 플랫폼 팀인 우리는 개발자 청중을 위한 디자인 비전을 전달하는 데 사용할 수 있습니다. 내가 아는 한 당장의 계획은 없지만 다시 확인할 수 있다.

비전에 관해서는 - "미래의 Windows Shell 및 Inbox 앱의 모습은 다음과 같습니다." "우리는 Windows 디자인을 업데이트할 기회를 잡고 있습니다. 여기에 우리가 만들고 있는 몇 가지 변경 사항이 있습니다..."
큐 이미지 또는 비디오 😃

@mdtauk , 그것은 내가 과거에 디자인 팀에 요청한 것이므로 플랫폼 팀인 우리는 개발자 청중을 위한 디자인 비전을 전달하는 데 사용할 수 있습니다. 내가 아는 한 당장의 계획은 없지만 다시 확인할 수 있다.

감사합니다. //Build/는 계획 중인 변경 사항을 공유할 수 있는 완벽한 기회였을 것입니다. 특히 WinUI 3.0의 초기 릴리스와 함께 여름 말에 이러한 컨트롤 템플릿을 업데이트할 계획이라면 더욱 그렇습니다.

Xbox 셸과 Windows 셸의 디자인은 다릅니다. 그것은 그들이 독특한 제품이기 때문에 의도적입니다. 그러나 우리는 하나의 스타일을 사용하려는 앱이 사소한 작업으로 실행할 수 있도록 WinUI 컨트롤을 설계했습니다. 몇 년 전 Xbox 팀과 작업할 때 XAML 컨트롤(당시 WinUI 없음)이 TV에 올바르게 표시되는지 확인하고 앞서 언급한 지침도 발표했습니다.

물론 쉘은 경험에 맞게 다를 것입니다. 내 유일한 의견은 다음 Xbox에서 앱 개발을 권장하려는 경우 기본 WinUI 컨트롤에 WinUI에 포함된 템플릿 및 ThemeResources가 있어야 하므로 Xbox에서 실행할 때 컨트롤 디자인 지침과 일치해야 한다는 것입니다. 그리고 개발 중에 이러한 컨트롤이 어떻게 보이는지 테스트할 수 있어야 합니다. Windows와 XAML 디자이너 모두에서.

Xbox 컨트롤에 대한 디자인 구성 요소 중 일부를 찾았지만 UWP 문서에는 없었습니다.

@mdtauk , Xbox에 대한 이 대화가 #698과 더 잘 어울리는 것 같습니다. 다른 대화에 댓글을 달 수 있는지 확인하기 위해 Xbox의 누군가에게 핑을 보냈습니다(약속 없음 :)). 다시 말하지만, 이것은 오픈 소스 커뮤니티입니다. 아마도 해당 리소스를 만들고 우리가 어떤 식으로든 소비하도록 제안할 수 있습니까? 말만...

@chigy 그것은 내가 제출한 문제였으며 커뮤니티가 WinUI에 추가하는 모든 컨트롤에 향후 Xbox 콘솔에서 실행하기 위한 템플릿이 포함되어야 한다는 것이었습니다. 개발자가 Xbox 앱에 WinUI 3.0 이상을 사용하려는 경우 모든 컨트롤이 TV에서 실행될 때 올바르게 보이도록 조정되어야 합니다.

그러나 디자인이 거의 마무리된 상태에서 이 문제는 모든 템플릿이 업데이트될 때 완료된 것으로 표시되는 것 외에는 더 많은 목적이 없습니다.

저는 NumberBox 컨트롤 제출에 아이디어를 제출했으며 컨트롤의 디자인이 나머지 컨트롤에 대해 계획된 것과 일치하도록 하고 싶었습니다.

개발자가 Xbox 앱에 WinUI 3.0 이상을 사용하려는 경우 모든 컨트롤이 TV에서 실행될 때 올바르게 보이도록 조정되어야 합니다.

@mdtauk , 전에 언급했듯이 이것은 좋은 제안이지만 Xbox 팀 자체 또는 귀하 이외의 커뮤니티에서 오는 요청이 없기 때문에 우리의 우선 순위가 아닙니다.

WebView의 ScrollIndicator가 XAML을 통해 업데이트되지 않지만 웹을 있는 그대로 사용한다는 사실을 업데이트했습니다.

MUXControlsTestApp의 현재 진행률 표시줄 보기 - 진행률 표시줄의 오른쪽 끝도 둥글게 처리됩니까, 아니면 평평한 가장자리를 유지합니까?

볼륨 플라이아웃 내의 슬라이더에도 스타일이 지정됩니까?

기본적으로 모든 컨트롤에 공개가 추가됩니까, 아니면 여전히 스타일에 의해 추가되어야 합니까?

ColorPicker에 사용된 슬라이더는 MediaPlayer와 유사한 윤곽선 스타일을 사용하면 이점을 얻을 수 있습니다. 따라서 Bar의 더 어두운 색상 사이에서 길을 잃지 않습니까?

MUXControlsTestApp의 현재 진행률 표시줄 보기 - 진행률 표시줄의 오른쪽 끝도 둥글게 처리됩니까, 아니면 평평한 가장자리를 유지합니까?

디자인 정의에 따르면 그래야 합니다. MUXControlsTestApp에 ​​대한 문제를 여십시오.

볼륨 플라이아웃 내의 슬라이더에도 스타일이 지정됩니까?

셸 UI는 공통 컨트롤을 사용하므로 컨트롤이 변경될 때 사용해야 합니다. 그러나 업데이트된 내용이 표시되지 않으면 FeedbackHub 문제를 여십시오. 이것은 쉘 팀의 작업이며 WinUI 팀이 우선 순위 및 리소스에 대한 최종 요청을 하는 것이 아닙니다.

기본적으로 모든 컨트롤에 공개가 추가됩니까, 아니면 여전히 스타일에 의해 추가되어야 합니까?

이것은 둥근 모서리 주제가 아닙니다.
기본적으로 모든 컨트롤에 공개를 추가하려면 새 문제를 여십시오.

ColorPicker에 사용된 슬라이더는 MediaPlayer와 유사한 윤곽선 스타일을 사용하면 이점을 얻을 수 있습니다. 따라서 Bar의 더 어두운 색상 사이에서 길을 잃지 않습니까?

MediaPlayer는 새 슬라이더(#841)의 디자인을 따를 계획입니다. 그래서 당신이 제안하는 것은 계획에 없습니다. 사용성 문제라고 생각되시면 별도의 이슈를 열어주세요.

와! 여기에 많은 의견이 있습니다.

지속적으로 날카로운 모서리가 Windows 10을 독특하게 보이게 한다고 생각합니다. 둥근 모서리를 도입하려면 Windows 로고, Microsoft 로고 및 타일에 대해 조치를 취해야 합니다. 타일과 같은 지하철 유물을 제거한 후에는 Office와 같이 기울어진 로고도 다시 해야 합니다. 둥근 모서리와 일관성을 도입하는 효과에 대해 계속해서 설명할 수 있지만 여기서는 생략하겠습니다.

@Pooporacoocoo 새 사무실 아이콘/로고는 새 터미널 아이콘 및 새 Visual Studio 아이콘/로고와 마찬가지로 둥근 모서리를 사용합니다.

그리고 FWIW, 나는 그들이 타일을 제거하는 것을 원하지 않습니다. Windows 10 태블릿 UI는 충분히 나쁘고 Windows 8.1에 비해 크게 다운그레이드되었습니다.

@Pooporacoocoo , @mdtauk ,
의견을 보내 주셔서 감사합니다. 변경 사항이 전반적으로 적용되어야 한다는 두 가지 의견이 모두 맞습니다. 따라서 이러한 노력은 Fabric 및 Edge와 같은 다른 가시적인 UI와의 정렬을 시작하는 것입니다. 우리는 일관성이 하룻밤 사이에 이루어지기를 원하지만 이것은 여정입니다. 그리고 여기에서 재생 중인 UI 플랫폼(예: WinUI)의 기본값에서 시작합니다.

상황 업데이트:

모서리 반경(일명 둥근 모서리) 방법 문서 PR 이 생성됩니다.

이것은 문서로 docs.microsoft.com에 추가됩니다.
https://docs.microsoft.com/en-us/windows/uwp/design/style/ 의 새 페이지가 됩니다

커뮤니티에 요청:
저는 고객이 일부 포커스 그룹에서 문서와 함께 제공한다고 표현한 "배경 설명(WHY)"을 조금 더 작성하려고 합니다. 이것은 일반적인 문서 패턴을 따르지 않기 때문에 피드백을 받고 싶습니다.

이러한 추가 정보가 유용/유용한가, 관련이 없는 것, 기타 정보가 누락된 것 등입니까?

@chigy 문서에 대한 유일한 제안은 컨트롤이 둥근 모서리를 받는 이유를 언급하지 않았다는 것입니다.

@mdtauk , 잘 잡았습니다. 나는 그것을 잡는 "할 일"섹션 (원칙)이 있었지만 편집하는 동안 어떻게 든 컨텍스트가 손실되었습니다. 그 부분을 채우기 위해 계속 노력하고 있습니다.

상황 업데이트

List 및 GridView 내에서 체크박스 모서리를 둥글게 만드는 작업을 추적하기 위해 별도의 문제를 만들었습니다(#1096).

둥근 모서리 변경 사항이 이제 체크인되어 이 문제를 종료합니다.

@mdtauk

그리고 FWIW, 나는 그들이 타일을 제거하는 것을 원하지 않습니다. Windows 10 태블릿 UI는 충분히 나쁘고 Windows 8.1에 비해 크게 다운그레이드되었습니다.

이제서야 답장을 드려 죄송합니다. 그들은 정말로 타일을 없애고 있습니다! :(

Windows가 자유 형식 아이콘으로 전환하는 동안 iOS와 유사한 방식으로 Android는 이제 적응형 아이콘만 허용하므로 흥미로운 결정입니다. "적응형" 아이콘은 단색 아이콘이 있기 때문에 시작 화면에서 더 보기 좋으므로 눈부신 흰색 시작 화면이 필요하지 않습니다. 반면에 자유 형식 아이콘은 개발자에게 아이콘에 대한 더 많은 제어 권한을 부여하고 데스크톱 플랫폼(제목 표시줄, 작업 표시줄과 같은 항목) 및 win32 앱에 적합하기 때문에 훨씬 보기 좋습니다.

Office 아이콘 자체는 ​​Word나 PowerPoint의 아이콘처럼 보이지 않습니다. 이러한 변경으로 인해 Microsoft는 정체성을 잃어 버리는 것 같습니다.

@Pooporacoocoo 아이콘이 새 셸의 새 기본값이더라도 아이콘 대신 타일을 사용하는 옵션이 있기를 여전히 희망하고 있습니다.

@Pooporacoocoo 및 @mdtauk , WinUI 팀은 타일에 관여하지 않으며 계획에 대한 지식이 없기 때문에 타일 토론을 위해 Feedback Hub에 피드백을 제출하십시오.

@Pooporacoocoo 및 @mdtauk , WinUI 팀은 타일에 관여하지 않으며 계획에 대한 지식이 없기 때문에 타일 토론을 위해 Feedback Hub에 피드백을 제출하십시오.

타일 ​​유지에 대한 피드백을 제출했습니다. 찬성 투표가 많은 컬렉션이 있습니다. 피드백 허브는 Windows 개발자 팀의 피드백이나 토론 기여가 거의 또는 전혀 없기 때문에 GitHub만큼 좋지 않습니다.

안녕하세요, 반올림을 비활성화하는 방법은 무엇입니까? 둥근 버튼에 둥근 툴팁이 있으면 보기 흉해 보입니다.

@kikisaints @chigy @mklemarczyk 같은 특정 요소를 요청하는 말의 둥근 모서리를 해제하는 방법이 있나요?

안녕하세요, 반올림을 비활성화하는 방법은 무엇입니까? 둥근 버튼에 둥근 툴팁이 있으면 보기 흉해 보입니다.

@mklemarczyk 컨트롤 스타일에서 CornerRadius 값을 0으로

@kikisaints @chigy @mklemarczyk 같은 특정 요소를 요청하는 말의 둥근 모서리를 해제하는 방법이 있나요?

@mklemarczyk , 우리의 지침 문서를
https://docs.microsoft.com/en-us/windows/uwp/design/style/rounded-corner#page -or-app-wide-cornerradius-changes

@mklemarczyk ToolTip.CornerRadius 속성 또는 OverlayControlResource를 두 가지 옵션으로 사용하여 툴팁 컨트롤의 모서리 반경을 변경할 수 있습니다.

Control.CornerRadius 속성은 Windows 1809부터 사용할 수 있으며 다음과 같이 사용할 수 있습니다.

<Application.Resources>
    <Style TargetType="ToolTip">
        <Setter Property="CornerRadius" Value="0" />
    </Style>
</Application.Resources>

이렇게 하면 앱의 모든 툴팁에 대해 모서리 반경이 0으로 설정됩니다.

또는 다음을 사용할 수 있습니다.

<Application.Resources>
    <CornerRadius x:Key="OverlayCornerRadius">0</CornerRadius>
</Application.Resources>

이것은 툴팁 컨트롤의 모서리 반경을 앱 전체에 설정하는 것뿐만 아니라 이 리소스를 사용하는 다른 모든 컨트롤(예: ContentDialog 및 ComboBox와 같은 팝업을 사용하는 컨트롤)도 설정한다는 점에 유의하십시오. 즉... 이론적으로는 리소스를 재정의해도 이러한 컨트롤에 영향을 미치지 않는 것처럼 보입니다(도구 설명이 작동함).

앞뒤가 너무 많이 바뀌어 다른 입력 및 모서리 반경과 관련하여 무엇이 결정되었는지 알기 어렵지만 매우 빠르게 WinUI 3만 사용하도록 UWP 프로젝트를 마이그레이션한 후 버튼에만 모서리 반경이 적용된 것을 확인했습니다. (개선된 공개 등과 같은 다른 변경 사항과 함께) 그러나 다른 입력 컨트롤(예: 콤보 상자)은 메트로 모양(더 어둡고/두꺼워진 테두리 및 90° 각도)으로 남았습니다. 이것은 의도적인 것입니까, WIP입니까, 아니면 버그입니까? 또한 콤보 상자가 버튼과 일치하도록 하려면 온라인에서 보고 있는 모든 항목에 새 기본 모서리 반경이 4epx 라고 나와 있지만 모서리 반경 3epx를 사용해야 합니다.

앞뒤가 너무 많이 바뀌어 다른 입력 및 모서리 반경과 관련하여 무엇이 결정되었는지 알기 어렵지만 매우 빠르게 WinUI 3만 사용하도록 UWP 프로젝트를 마이그레이션한 후 버튼에만 모서리 반경이 적용된 것을 확인했습니다. (개선된 공개 등과 같은 다른 변경 사항과 함께) 그러나 다른 입력 컨트롤(예: 콤보 상자)은 메트로 모양(더 어둡고/두꺼워진 테두리 및 90° 각도)으로 남았습니다. 이것은 의도적인 것입니까, WIP입니까, 아니면 버그입니까? 또한 콤보 상자가 버튼과 일치하도록 하려면 내가 온라인에서 보고 있는 모든 항목에서 새 기본 모서리 반경이 4epx라고 _말하지만 3epx의 모서리 반경을 사용해야 합니다.

스타일과 관련하여 WinUI2와 WinUI3의 차이점이 보이면 새 문제를 열어 주시겠습니까? WinUI2에서 WinUI3으로 스타일 병합과 관련된 버그일 수 있습니다.