@sapallie , 디자인 모형을 공개적으로 액세스할 수 있도록 만들 수 있습니까? 이 시점에서 공유하지 않는 한.

현재 XAML 개발을 하고 있는데 이런 모습을 보고 싶습니다. 또는 멋진 스크롤링 메시지 컨트롤과 같은 것입니다.

마이크로소프트 브랜딩의 관점에서, 표준화된 오류 배너는 끔찍하게 잘못될 수 있는 것처럼 보입니다. 최종 사용자가 모든 응용 프로그램 오류를 Microsoft 브랜드와 연관시키는 것이 두렵습니다. 방금 제안서를 읽었고 가장 먼저 떠오른 것은 화려한 죽음의 깃발에 대해 트윗하는 memelords였습니다.

@sapallie , 디자인 모형을 공개적으로 액세스할 수 있도록 만들 수 있습니까? 이 시점에서 공유하지 않는 한.

@adriantetar 죄송합니다. 아직 공유할 수 없습니다. 디자인은 현재 Microsoft에만 있습니다.

@sapallie , 이 놀라운 기능 아이디어에 감사드립니다! 저는 WinUI의 프로그램 관리자이며 팀에 이 사실을 알리게 되어 기쁩니다!

나는 당신이 여기에서 우리가 어떻게 진행될지 알 수 있도록 우리의 과정에 대해 조금 쓰고 싶었습니다. 지금부터 이 제안의 상위 수준 범위/요구 사항과 개발 근거를 구체화하기 위해 노력할 것입니다. 그런 다음 나머지 WinUI 팀에게 제안하고 로드맵(#717)과 일치하는지 여부와 상대적으로 빠른 시일 내에 조치를 취할 수 있는지 여부를 숙고할 것입니다. 그렇다면 개발자가 해당 기능을 사용할 수 있도록 세부 사항을 파악하고 사양 작성을 시작하도록 승인하겠습니다.

여기에 내가 이미 알고 있는 몇 가지 아이디어가 더 필요합니다.

• 시각적 행동

귀하의 제안은 전면적인 광고입니까? 또는 Windows 알림과 같은 알림 타일이 있지만 중앙, 하단 가장자리 또는 모서리와 같은 앱 창에 있습니까?

@adriantetar 죄송합니다. 아직 공유할 수 없습니다. 디자인은 현재 Microsoft에만 있습니다.

리포지토리가 오픈 소스이고 클로즈소싱이 대화의 시각적 측면이 우리 커뮤니티의 프로세스와 경험을 얽히게 할 것이기 때문에 요청에 대한 공개 시각 자료를 포함하지 않고는 이 제안을 승인할 수 없다고 생각합니다. . 위의 답변을 바탕으로 제안을 위한 목업 초안을 작성하게 된 것을 기쁘게 생각합니다. 이것을 선호합니까, 아니면 디자인을 공개할 수 있는 권한을 부여하기 위한 일정이 계획되어 있습니까? 나는 당신의 모형을 사랑하고 우리가 불필요하게 당신의 의도와 다른 방향으로 토론을 가져 가지 않도록 여기에서 브레인 스토밍에 포함시키기를 열망합니다. 알려주세요! :붉히다:

배너는 사용자가 앱/기능을 사용하지 못하게 하는 오류를 알려줍니다.

배너는 중요하지 않은 오류에 대해 닫을 수 있습니다.

심각한 오류 에 대해 닫을 수 없는 배너에 대한 옵션도 필요하다는 의미로 이 진술을 읽는 것이 맞습니까? 그렇다면 닫을 수 없는 배너가 있는 시점에서 하나를 받거나 진행하는 특정 앱 시나리오에 대해 자세히 알려주실 수 있습니까? 문제가 해결되지 않으면 사용자가 앱을 닫을 수 있습니까? 아니면 네트워크 및 인터넷 설정 페이지로 이동하는 버튼과 같은 위치에 있습니까?

다시 한 번 감사드리며 이 아이디어를 구체화할 수 있기를 기대합니다!

여러분, 여러분의 필요, 디자인, 관점을 이 대화에 기여할 수 있도록 격려해 주십시오! :붉히다:

나는 모두 비슷한 것을 요구하는 몇 가지 제안이 있다고 말하고 싶습니다. 이것을 특별히 오류 배너로 만드는 대신 커뮤니티 도구 키트에서 앱 내 알림을 가져오는 것이 좋습니다. 아이콘 속성이 추가되어 오류 아이콘이나 확인 아이콘 등이 표시될 수 있습니다.

@SavoySchuler – 좋은 소식을 듣게 되어 반갑습니다. 나는 당신의 모든 질문에 대답하려고 노력했지만 더 필요한 것이 있으면 알려주세요.

시각적 행동:
이상적으로 배너는 Windows 알림 타일과 유사하며 앱 창의 상단이나 하단에 고정됩니다. 고정 위치는 앱의 다른 시각적 요소와 포커스가 있는 위치에 따라 다릅니다. 이 결정은 디자이너가 해야 합니다.
게시된 GIF @mdtauk 가 좋은 출발점이 될 것이라고 생각합니다.

닫기:
중요한 오류와 중요하지 않은 오류가 의미하는 바를 더 깊이 파고드는 것이 합리적이라고 생각합니다.

• 치명적인 오류 = 시스템 전체의 문제(예: 인터넷 연결 끊김)로 인해 앱 기능이 손상되었습니다. 이러한 오류는 사용자가 문제를 해결할 수 있는 시스템 설정에 연결되어야 합니다.
• 중요하지 않은 오류 = 일부 기능이 손상되었거나 단일 기능이 작동하지 않지만 사용자는 여전히 앱에서 다른 작업을 수행할 수 있습니다.
• 또한 사용자에게 앱 업데이트 또는 새로운 기능을 사용할 수 있음을 알리는 데 사용할 수 있는 배너의 순전히 정보 제공 을 도입하는 것도 멋질 것입니다.

그리고 이 모든 것을 무시할 수 있어야 한다고 생각합니다(제안 설명에서도 업데이트했습니다)

예시 영상
비주얼에 몇 가지 변경 사항을 적용했으며 다음과 같이 공유할 수 있습니다.

이 예는 전체 배너가 기본적으로 큰 버튼인 반복입니다. 사용자는 이를 닫거나 클릭하여 시스템 설정(중요한 오류)으로 이동하거나, 기능 수정 사항에 대한 세부 정보가 포함된 웹 페이지를 열거나(경고 1), 앱 페이지를 다시 로드(경고 2)하거나, Microsoft Store로 이동하여 업데이트할 수 있습니다. 앱(정보용).
이 개념을 확장하여 배너 내에 여러 버튼을 추가할 수 있습니다.

나는 배너에 대한 저 비주얼을 정말 좋아한다. 텍스트와 아이콘을 4픽셀 위로 이동하여 흰색 및 컬러 막대가 아닌 흰색 영역 중앙에 배치됩니다.

동의. 게시 된 영상은 꽤 좋아 보입니다.

나는 배너에 대한 저 비주얼을 정말 좋아한다. 텍스트와 아이콘을 4픽셀 위로 이동하여 흰색 및 컬러 막대가 아닌 흰색 영역 중앙에 배치됩니다.

픽셀을 계산하지 않았지만 X 높이 위의 분음 부호 공간을 고려하면 픽셀이 중앙에 있는 것처럼 보입니다.

@sapallie 이러한 컨트롤을 자동으로 허용하거나 프로그래밍 방식으로 해제하는 것에 대해 생각해 본 적이 있습니까?

오프라인/오프라인 상태에 대한 메시지가 표시되면 다시 온라인 상태일 때 이러한 메시지를 프로그래밍 방식으로 제거하는 것이 좋습니다. (앱이 이 작업을 수행하지 않는 것을 보았고 혼란스러운 경험으로 이어질 수 있습니다.)

마찬가지로, 중요하지 않은 메시지가 무기한 표시되지 않도록 하면 불필요한 UI가 복잡해지는 것을 방지할 수 있으며 고급 사용자가 알림을 수동으로 해제하지 않도록 하여 메시지를 읽은 후 흐름을 벗어나지 않아도 됩니다.

이러한 컨트롤 및 이러한 동작에 대한 잠재적인 추가 액세스 가능성 고려 사항이 있음을 이해하지만 컨트롤을 해제하는 이러한 방법이 필수적이라고 생각합니다.

이러한 컨트롤은 앱 내 일반적인 메시징을 위한 것이 아니라는 점을 강조하는 것이 중요하다고 생각합니다. 그것이 정말로 원하는 사용 사례가 아닌 한.

앱에서 한 번에 여러 배너를 표시하도록 허용해야 합니까?
그렇다면 어떻게 배치됩니까? 그리고 이것이 앱이 제어할 수 있는 것입니까?

이것은 앱 알림 제어에서 Android Toast 스타일을 요청한 사람들을 만족시킬 것이며, 양식의 공간이 부족한 곳에 오류 텍스트를 표시하는 유효성 검사 시나리오에 유용할 수도 있습니다.

나는 또한 이것을 StatusTip 또는 StatusNotification 과 같은 것으로 부를 것이므로 부정적인 사용과만 연관되지 않을 것입니다.

단색 막대가 창 하단에 배치될 때 배치를 변경하여 디자인이 조정될 것이라고 가정합니까?

아마도 시간 초과 속성이 있어야 하며 오류 메시지 확인으로 전환하기 전에 진행 링 및 "지금 로그인"과 같은 일부 텍스트와 같은 보류 중인 메시지를 표시하는 기능이 있을 수도 있습니다.

나는 배너에 대한 저 비주얼을 정말 좋아한다. 텍스트와 아이콘을 4픽셀 위로 이동하여 흰색 및 컬러 막대가 아닌 흰색 영역 중앙에 배치됩니다.

픽셀을 계산하지 않았지만 X 높이 위의 분음 부호 공간을 고려하면 픽셀이 중앙에 있는 것처럼 보입니다.

색 막대를 고려하지 않고 텍스트가 상자의 세로 중앙에있을 가능성이 더 높았습니다.

컨트롤의 배치에 따라 컬러 바 배치가 어떻게 변경될 수 있는지는 다음과 같습니다.

@mrlacey 예, 배너가 더 이상 관련이 없을 때 프로그래밍 방식/자동 해제는 매우 중요합니다. 제안 설명에 추가했습니다.

상태 변경 및 오류: 배너를 사용해야 하는 이유입니다. 일반적인 메시지가 아닙니다. 동의합니다.

그리고 여러 배너가 작동해야 한다고 생각합니다. 그것들은 쌓이기만 하면 됩니다.

@mdtauk 이름을 "상태 배너"로 변경했습니다. 제안해 주셔서 감사합니다.

로딩 상태의 경우 – 배너에서 그런 일이 일어나야 한다고 생각하지 않습니다. 콘텐츠를 로드하는 것은 콘텐츠가 실제로 나타날 앱에 표시되어야 합니다.

그리고 색상 막대의 배치를 변경할 때 앱 창에서 오류 배너가 배치되는 위치에 따라 유연성이 있으면 좋을 것입니다. 👍

문제 #622 및 #792도 이 컨트롤이 빌드되는 경우 이 컨트롤로 처리될 수 있습니다.

@sapallie 심각한 오류 상황에 대한 귀하의 메모는 상태 배너가 사용자에게 솔루션을 알려주는 제안된 지침과 관련하여 흥미롭습니다. 내 직감에 따르면 비활성화하거나 적어도 일시적으로 해제할 수 있는 API가 필요할 수도 있습니다.

이러한 컨트롤 및 이러한 동작에 대한 잠재적인 추가 액세스 가능성 고려 사항이 있음을 이해하지만 컨트롤을 해제하는 이러한 방법이 필수적이라고 생각합니다.

@mrlacey , 훌륭한 설명입니다! 다행스럽게도 저는 TeachingTip에서 시간 지정 자동 닫기를 고려하는 동안 이 중 상당 부분을 해결했으며, 접근성 설정을 소유한 팀과 일부 협력이 필요할 수 있지만 접근성 문제로 인해 이 기능이 차단될 것이라고 생각하지 않습니다. 다른 모든 포인트에 +1!

솔루션 또는 네트워킹과 같은 설정 바로 가기에 연결되는 HyperlinkButton을 추가할 수 있습니까?

솔루션 또는 네트워킹과 같은 설정 바로 가기에 연결되는 HyperlinkButton을 추가할 수 있습니까?

인앱 또는 설정 앱(TeachingTip의 Xaml 컨트롤의 갤러리 코드 참조) 페이지에 대한 하이퍼링크가 포함된 하위 텍스트를 구상하고 있었습니다. 좀 더 표준화된 @mdtauk를 생각하고 계셨나요?

MessageText 대신 @SavoySchuler Content 속성?

심각한 오류 상황에 대한 귀하의 메모는 상태 배너가 사용자에게 솔루션을 알려주는 제안된 지침과 관련하여 흥미롭습니다. 내 직감에 따르면 비활성화하거나 적어도 일시적으로 해제할 수 있는 API가 필요할 수도 있습니다.

예, 아마도 제가 추측합니다... 확실히 추가하는 것은 나쁘지 않습니다. 결국 유연성을 추가하고 일부 사용 사례에 매우 유용할 것입니다.

@mdtauk - 예, 확실히 콘텐츠 속성을 의미합니다!

@sapallie

심각한 오류 상황에 대한 귀하의 메모는 상태 배너가 사용자에게 솔루션을 알려주는 제안된 지침과 관련하여 흥미롭습니다. 내 직감에 따르면 비활성화하거나 적어도 일시적으로 해제할 수 있는 API가 필요할 수도 있습니다.

예, 아마도 제가 추측합니다... 확실히 추가하는 것은 나쁘지 않습니다. 결국 유연성을 추가하고 일부 사용 사례에 매우 유용할 것입니다.

한편으로는 UI를 덮는 닫을 수 없는 팝업이 있고(그리고 그렇게 할 때 자체 시나리오 기반 오류가 발생할 수 있음) 다른 한편으로는 앱 경고/중요한 오류가 지속되지 않아 내 감각이 얼얼하다.

아마도 오버 UI + 팁 스타일 팝업보다 UI + 에지 투 에지 배너(이와 같은 것은 Office 제품군에서 업데이트에 대해 알리기 위해 사용됨 - 아래 참조)가 요구 사항을 충족하면서 동시에 UI에 영구적인 공간이 있습니까?

@SavoySchuler 컨트롤 너비가 충분히 넓은 경우 헤더와 콘텐츠를 한 줄에 넣는 컨트롤에 동작이 있을 수 있습니다.

다른 위치 지정 레이아웃에 대한 나의 이전 제안은 컨트롤이 창이나 패널 내에서뿐만 아니라 다른 컨트롤의 가장자리에서 미끄러지는 경우에도 작동합니다.

아마도 오버 UI + 팁 스타일 팝업보다 UI + 에지 투 에지 배너(이와 같은 것은 Office 제품군에서 업데이트에 대해 알리기 위해 사용됨 - 아래 참조)가 요구 사항을 충족하면서 동시에 UI에 영구적인 공간이 있습니까?

예, 그것도 작동합니다. 👍

Office Suite는 리본이 있는 모든 앱에 의존할 수 있으므로 인라인 및 오버레이 옵션을 모두 사용하는 것이 이상적입니다. @mdtauk 나는 우리가 외모/소실 행동에 대해 어떻게 생각하는지 암시하기 시작한 당신의 제안을 좋아합니다.

@all , 이 컨트롤이 사용되는 것을 상상하는 실제 앱의 특정 시나리오를 나와 공유할 수 있습니까? 특히, 시각적 입장 및 퇴장을 유도하는 데 필요한 사용자 상호 작용에 대한 생각에 관심이 있습니까? 여기의 요구 사항이 이 컨트롤에서 필요한 핵심 동작을 포함합니까?

@SavoySchuler 입구와 출구를 고려할 때 가장자리에서 미끄러질 수 있지만 개발자가 선택하면 부동 오버레이로 애니메이션이 적용됩니다. OS 수준에서 화면의 오른쪽 가장자리에서 밀어 넣습니다. 앱 창의 오른쪽 가장자리에서 또는 컨트롤 또는 UI 요소의 가장자리에서 바깥쪽으로 미끄러집니다.

닫는 버튼이 있지만 터치 디스플레이의 경우 버튼이 나타난 위치에서 반대 방향으로 슬라이드하는 기능도 작동할 수 있습니다. 일관성을 보장하려면 컨트롤에 이 기능을 구축해야 합니다.

컨트롤을 탭하면 메시지 텍스트가 지정할 작업이 트리거될 것입니다.
예외는 시간이 초과되어 오류가 발생하거나 성공적으로 완료될 때까지 해제할 수 없는 작업의 진행 상황을 표시하는 경우입니다.

애니메이션 예제

입력, 업데이트, 종료 - YouTube 링크

애니메이트 인 - YouTube 링크

TeachingTip은 존재하며 특정 컨트롤 또는 UI 요소를 대상으로 하는 좋은 방법이며 앱의 새 기능을 강조하는 데 좋습니다. 기술적으로 이 StatusBanner와 동일한 목적으로 사용될 수 있으므로 이들 각각의 의미론적 사용에 대해 생각하고 각각을 고유하게 만드는 요소를 식별해야 합니다.

다음은 스테이터스 배너와 티칭 팁의 차이점에 대한 개인적인 생각입니다.

• 상태 배너는 실제 실행 가능한 상태에 대해 권장되어야 하므로 탭할 때 단일 작업을 호출해야 합니다.

  • 티칭 팁은 일반적으로 쉽게 해제할 수 있는 정보에 사용되는 버튼 또는 하이퍼링크로 작업을 표시합니다.

• 앱 또는 OS 조건이 변경되면 앱에 필요한 상태 배너가 표시되도록 트리거해야 합니다.

  • 티칭 팁은 중요한 정보를 제공하지 않으며, 일단 해제되면 불러오기 위해 새로운 것이 추가되지 않는 한 다시 표시되지 않습니다.

• 상태 배너는 닫기 버튼으로 닫히지 않는 한 표시될 때 지속되어야 하거나 터치할 때 살짝 밀어야 합니다. 진행 중인 진행 시나리오가 완료되거나 OS 상태가 해결되는 경우를 제외하고(네트워크가 복원됨).

  • 교육 팁에는 시간 초과 기능이 포함될 수 있으며 앱이 실행되는 동안 무작위로 표시되지 않으며 대부분 앱 시작 또는 페이지/화면 탐색에 표시됩니다.

• 상태 배너는 일관된 방식으로 OS 셸에서 사용해야 합니다. 콘텐츠, 아이콘, 색상이 열거형으로 포함된 현지화된 표준 배너 세트가 있을 수 있습니다.

• 앱 창에 상태 배너를 추가하는 일부 OS 로직이 있을 수 있습니다.
  예를 들어 앱이 네트워크에 액세스하려고 할 때 네트워크를 사용할 수 없는 경우 OS는 화면 공간이 아닌 앱 창 내에 표준 상태 배너를 표시하거나 개발자가 구현하도록 남겨둘 수 있습니다.

  • 교육 팁은 앱에 따라 다르며 정의된 표준 콘텐츠가 없으며 개발자만 포함해야 합니다.

@mdtauk , 비디오에 대한 환상적인 작업! 🎉 이러한 아이디어에 생명을 불어넣는 데 도움이 되지 않습니다.

지속성에 대한 필요성은 훌륭한 포인트이며 중요한 경우 알림 창에서 상태 알림을 지속적으로 사용할 수 있도록 제안하거나 문제가 지속되는 경우 비침습적 간격으로 다시 표시하도록 제안하는 지침으로 해제 기능을 완화할 수도 있다고 생각합니다. 이는 확실한 주장이 아니며 이 솔루션이 시나리오 솔루션에서 적절하게 포괄적인지 확인하기 위해 고려해야 할 사항일 뿐입니다.

이 기능과 TeachingTip을 구별할 필요가 있는 것은 사실이며 귀하의 의견에 동의합니다. 이 컨트롤은 일부 공유 기능이나 코드에 대한 기회가 있을 수 있지만 TeachingTip이 해결하도록 설계되지 않은 뚜렷한 요구 사항을 충족합니다.

@mdtauk 이 위에서 공유한 것과 같은 것으로 요구 사항을 충족 하지 못하는 이해 관계자가 있습니까?

OP에서 조롱된 상태 배너와 Office(이전 주석의 위 이미지) 또는 Visual Studio(아래 참조)에서 볼 수 있는 전체 너비 알림 간에 차이가 있는 것 같습니다.

둘 사이의 차이점은 그들이 동일한 컨트롤이어야 하는지 아니면 별도의 컨트롤이어야 하는지 궁금하다는 것을 의미합니다.

다음은 각각에 필요한 속성의 빠른 목록입니다. (예를 들어, 고정되지 않았지만 의미를 유추하기 위한 이름)

상태 배너

• _상_
• 메시지 텍스트
• 추가 텍스트(두 번째 줄)
• 유형(중요, 경고 또는 정보)
• 색깔
• 위치
• 애니메이션 연출
• 이벤트/명령 탭
• 시간 초과

전각 알림

• _아이콘(아마도)_
• 메시지 텍스트
• 링크 스타일(버튼 또는 하이퍼링크)
• 링크(텍스트 및 탭 이벤트/명령 - 다중)
• 시간 초과

굵게 표시된 속성만 둘 다에 존재합니다. _Icon_은 각 유형에 대해 서로 다른 유형의 아이콘(원 또는 윤곽선)이 필요하기 때문에 잠재적으로 혼동을 일으킬 수 있습니다.
사용할 스타일을 나타내는 속성도 있어야 합니다.

나에게 이것은 단일 컨트롤에 대해 너무 많은 차이가 있는 것처럼 느껴지며 이 모든 기능을 함께 사용하면 혼란스럽고 복잡할 것입니다.
나는 이 두 가지 개념을 다음과 같이 생각한다.

• 0개 이상의 실행 가능한 하위 요소가 있는 해제 가능한 전체 너비 배너
• 상태 변경을 나타내기 위한 배너이며 단일 버튼으로 작동합니다.

별도의 컨트롤로 최고의 가치와 최소한의 혼란을 제공합니다.

애니메이션 상태 배너는 한 번에 여러 알림 표시를 어떻게 지원합니까?
아니면 지금은 범위를 벗어났습니까?

• 상태 배너는 일관된 방식으로 OS 셸에서 사용해야 합니다. 콘텐츠, 아이콘, 색상이 열거형으로 포함된 현지화된 표준 배너 세트가 있을 수 있습니다.
• 앱 창에 상태 배너를 추가하는 일부 OS 로직이 있을 수 있습니다.
  예를 들어 앱이 네트워크에 액세스하려고 할 때 네트워크를 사용할 수 없는 경우 OS는 화면 공간이 아닌 앱 창 내에 표준 상태 배너를 표시하거나 개발자가 구현하도록 남겨둘 수 있습니다.

이 수준의 OS 통합은 단일 제어 및 WinUI를 넘어서는 야심을 보여줍니다.

"표준 현지화된 배너"가 사용 가능한 전부입니까, 아니면 완전히 사용자 정의할 수 있는 것 외에 추가될 것입니까?
일부를 기본적으로 제공한다면 무엇입니까?
제한된 옵션 세트만 제공하는 것이 그러한 통제의 잠재력을 불필요하게 제한하는 것이 아닐까 우려됩니다.

네트워크 연결 끊김과 같은 시스템 전체 시나리오에 대해 개방형 앱에서 OS가 배너를 표시하도록 하면 여러 가지 우려 사항이 발생합니다.

• 관리 센터는 이미 시스템 전체에 알림을 제공하는 방법을 제공합니다.
• 여러 개의 창이 열려 있을 때 각각에 표시된 배너를 보는 것이 불필요하게 방해가 되는 것처럼 보입니다.
• 앱 내에서 시스템이 알림(배너)을 표시하는 것은 개발자가 제어하거나 비활성화하기를 원하는 것입니다.
• 앱에 네트워크 연결이 가끔 필요한 경우 현재 하고 있는 작업과 관련이 없는 경우 연결 끊김에 대한 메시지가 표시되면 사용자가 당황하거나 주의가 산만해질 수 있습니다.
• 이렇게 하면 앱을 특정 버전의 OS에 연결하여 업데이트나 원하는 동작을 얻을 수 있습니다. OS 기능의 향후 변경으로 인해 앱이 중단되거나 바람직하지 않은 방식으로 변경될 수 있습니다.
• 업데이트 및 버그 수정은 OS 수준 릴리스 일정에서만 사용할 수 있습니다. WinUI가 존재하는 이유 중 일부는 OS 및 앱 기능과의 결합을 깨기 위함입니다.

• 여기에 설명된 이러한 컨트롤의 목표 중 하나는 개발자가 쉽게 구현할 수 있도록 하는 것입니다. 제어 기능을 제거하면 특정 시나리오를 사용자 지정 방식으로 처리해야 하는 앱에 문제가 발생할 수 있습니다.

애니메이션 목업에 대한 Twitter 게시물에서 방금 이 문제를 찾았습니다. 툴킷에서 InAppNotification 컨트롤을 사용하여 수행한 많은 작업과 겹치는 것 같습니다. 여러 메시지를 처리하는 방법 등을 포함합니다.

우리는 이것이 단순한 컨트롤처럼 보이지만 꽤 복잡하다는 것을 배웠습니다. 이러한 모든 경우를 포괄할 수 있지만 WinUI에 기본 제공될 수 있는 전체론적 솔루션이 있으면 좋을 것입니다. 그런 다음 툴킷 컨트롤을 더 이상 사용하지 않을 수 있습니다.

@ryandemopoulos 와 상의하고 솔루션(오류 UI의 특정 부분/부분) 전에 문제(오류 UI의 필요성)에 초점을 맞추기 위해 이 초기 대화를 약간 리팩토링하고 싶습니다.

이를 위해 내 첫 번째 목표는 오류 UI에 대한 시나리오와 요구 사항을 잠그는 것입니다( @sapallie , "Critical: wifi 연결 끊김" 시나리오는 완벽한 시작입니다). 거기에서 우리는 솔루션에 하나의 오류 알림 UI 또는 오류 UI 구성 요소 집합이 포함되어 있는지 여부를 함께 결정할 수 있습니다. 여기에서 @mrlacey 의 API 유사성 분석(시작해주셔서 감사합니다)을 확장하여 이 대화의 출력이 여러 개 있는 경우 파생 접근 방식과 별개의 컨트롤에 대한 충분한 공통점이 있는지 결정합니다. 나 자신보다 앞서나가고 싶지는 않지만 @mrlacey 의 고유한 솔루션에 대한 주장은 이미 선명해 보이고 괜찮습니다. 저는 여기 있는 모든 사람에게 적합한 솔루션 세트를 만드는 데 중점을 둡니다.

따라서 이 컨트롤이 특히 관련이 있는 모든 사람( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk 및 @mrlacey )에 대해 다음을 제공하거나 dm @ [email protected] 으로 알려주십시오 .

• 앱 제목
• 시나리오 설명(오류, 중요/비중요, 제시 방법에 대한 설명)
• 오류가 표시되는 앱 화면의 스크린샷(사용 가능한 경우)

이 문제 중심 접근 방식을 반영하도록 문제를 업데이트했으며 지금까지 설명한 요구 사항, 시나리오 및 솔루션 가능성을 분류했습니다.

@sapallie 당신의 초기 작업을 보존하기 위해 최대한 정중하게 노력했습니다. 버전 기록은 문제 상단의 "편집자..." 드롭다운에서 볼 수 있습니다. 제가 제대로 캡쳐하지 못한 부분이 있다면 알려주세요.

저는 이것을 WinUI 팀에 제안했으며 여기에 정의된 기능이 오류 메시지뿐만 아니라 전체적으로 오래 지속되는 앱 전체 상태 메시지를 제공할 수 있다고 믿습니다. 여기에는 오류별 시나리오 외에도 "업데이트 사용 가능" 및 "백업 완료" 종류의 상태 메시지가 포함됩니다.

이 보다 전체적인 접근 방식을 반영하도록 문제를 업데이트했습니다. 앞으로 몇 주 안에 요구 사항과 시나리오를 마무리하여 이러한 메시지를 표시하는 데 필요한 UI 출력 부분을 조사할 수 있기를 바랍니다.

위의 요청을 다시 설명하겠습니다. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk 및 @mrlacey , 응용 프로그램에 표시하려는 상태/오류 메시지의 경우 여기 또는 [email protected] 으로 다음을 제공할 수 있습니다.

• 앱 제목
• 시나리오 설명(상태 메시지, 중요/비중요, 제시 방법에 대한 설명)
• 오류가 표시되는 앱 화면의 스크린샷(사용 가능한 경우)

가능하면 팝업 대화 상자를 피해야 합니다. 웹은 모든 곳에서 팝업 프롬프트로 가득 차 있으며 시선을 사로잡기 위해 흐름을 방해합니다. 예를 들어 컨트롤에 로드할 수 없는 항목이 있는 경우 빈 상태( example )가 선호되어야 한다고 생각합니다.

게시된 비주얼 @mdtauk 과 관련하여 화면/앱의 네 가장자리 모두에서 표시되는 팝업이 정말로 필요합니까? WinUI의 요점은 이러한 항목의 위치와 모양을 표준화하여 모든 앱이 동일하게 사용하도록 하는 것이어야 하며, 그런 면에서 Android Snackbar 는 명백한 참조입니다. Snackbar에서 주의해야 할 또 다른 사항은 밝은 빨간색이나 그 밖의 다른 오류를 표시하지 않는다는 것입니다. 그것은 냉정한 외관을 가지고 있어 사용자가 하고 있는 일에서 너무 많은 주의를 산만하게 하지 않는 데 유용하다고 생각합니다.

예를 들어 대화 상자 대신 이 팝업을 사용해야 하는 경우에 대한 지침도 필요합니다. 그렇지 않으면 단편화만 생성됩니다(다른 방식으로 메시징 컨트롤을 사용하는 다른 앱).

플라이아웃에는 배치 개념이 있으며 이 컨트롤은 동일한 작업을 수행할 수 있습니다. 페이지 또는 탭 콘텐츠 등 컨테이너 컨트롤의 내부 가장자리에서 나타납니다.

@adrientetar 모든 앱이 동일한 것은 아니므로 이 컨트롤에 대한 기본값이 있지만 개발자가 컨트롤을 다시 템플릿하거나 다시 엔지니어링할 필요 없이 이 위치를 변경할 수 있는 방법이 필요합니다.

Office는 리본 아래 공간을 사용합니다. Edge는 화면 하단을 사용합니다. Windows 자체에서만 이를 셸 또는 화면 가장자리에 연결할 수 있으며 앱이 시스템 수준 경고를 모방하지 못하도록 하는 충분한 이유가 있을 수 있습니다.

또한 모든 개발자는 자신의 경고 컨트롤 스타일을 변경할 수 있으므로 이 단계에서 가능한 한 유연해야 합니다. 그러면 Shell 팀이 컨트롤 사용에 적용되는 제한 사항에 대해 말할 것입니다.

Your Phone 팀에는 이러한 종류의 컨트롤 중 하나가 있으므로 어떤 문제가 발생했는지 물어보고 WinUI 컨트롤이 완료되고 포함되면 사용하도록 설득할 수 있습니다.

Dropbox는 또한 디자인 시스템에서 Snackbar를 사용 합니다(아래로 스크롤하여 이미지의 마지막 행에서 두 번째 행).

최근에 수명이 긴 앱 전체 상태 메시지의 몇 가지 예를 더 발견했습니다.

(팀의 "녹화 시작됨" 메시지)

(Dota 2의 "게임 코디네이터에 연결하려고 시도 중")

크기가 작아서 죄송합니다. 첫 번째 사진은 울트라와이드 모니터가 있는 데스크탑에서 찍은 것입니다. :)

일부 보관용 계정 스낵바에는 하단에 진행률 표시줄이 있습니다. 여기에 포함되어야 합니까? 업로드, 다운로드, 업데이트, 동기화 진행과 같은 항목에 대해 의미가 있을 수 있습니다. 필수품은 아니지만 아마도 그럴 수도 있고 해야 할까요?

이것들은 반올림되어야 합니까? 아니면 아니요?

예, 여기서 티칭 팁과의 주요 차이점은 앱이 메시징 공간을 조정하고 동시에(또는 연속적으로) 표시할 여러 오류/상태 업데이트가 있을 수 있다는 것입니다.

이상적으로는 개발자가 앱 내에 구성하고 배치한 다음 메시지를 파이프하는 하나의 컨트롤이라고 생각합니다(오류, 상태, 경고 또는 기타 일반 메시지인지 나타내는 일종의 유형이 있다고 생각합니다).

배너와 팝업 모두에서 여러 메시지가 있을 수 있는 앱을 보았습니다. 때로는 UI 공간을 지배하는 배너를 쌓기 때문에 이 솔루션이 이를 방지하면 좋을 것입니다(개발자가 컨트롤의 여러 인스턴스를 사용하여 여전히 해당 동작을 다시 생성하는 것을 막을 수는 없지만).

나는 또한 VS Code를 호출하지 않았다는 사실에 놀랐습니다. 오른쪽 하단에 쌓이는 팝업 알림 패널이 있고 추가 작업 버튼도 있습니다(예: 설정으로 이동).

VS 코드 예제 스크린샷:

왼쪽 상단에 표시되는 다양한 유형의 아이콘, 사용자 정의 가능한 버튼 동작, 확장 프로그램별 알림에 대한 설정을 구성하는 '톱니바퀴' 아이콘이 있는 기능이 있습니다.

방금 Cortana의 이 스크린샷을 보았습니다...

Office UI Fabric의 MessageBar 는 멋지게 보입니다. IMO:

Windows 10용 Samsung Notes는 알림 토스트를 사용하여 메모에 너무 성가신 내용이 없기 때문에 메모가 삭제되었음을 설명한다는 것을 알았습니다.

안녕하세요 여러분! 저는 WinUI의 프로그램 관리자이며 @SavoySchuler에서 이 제안을 다시 선택합니다. 이미 이 스레드에서 많은 훌륭한 토론과 아이디어 공유가 있었습니다. 모든 제안에 감사드립니다!

여기에 어떤 활동이 있었던 지 몇 개월이 지났기 때문에 모든 사람과 다시 확인하고 현재 위치를 다시 확인하고 싶었습니다.

제안서 상단에 있는 현재 범위를 요약하면 다음과 같습니다.

• 알림 은 전체 응용 프로그램과 관련된 필수 정보를 사용자에게 알리기 위한 것입니다.
• 맞춤형 콘텐츠 및 스타일 지원
• 자동 및 프로그래밍 방식으로 닫을 수 있습니다.
• 알림 은 사용자가 해제할 수 있어야 합니다.
• 앱이 지정한 방식에 따라 쌓일 수 있는 여러 알림을 지원해야 합니다.
• 앱 크기 조정 및 UI 변경에 반응해야 합니다.
• 알림 은 시스템 전체 알림을 표시하기 위한 것이 아닙니다 .

내 범위 요약에서 놓친 것이 있거나 동의하지 않는 경우 언제든지 의견을 말하여 알려주십시오. 앞으로 나아가기 전에 우리 모두가 같은 페이지에 있는지 확인하고 싶습니다 😊

범위를 정의했으므로 아직 정의해야 하는 몇 가지 특정 시나리오와 사용자 환경이 있습니다. 이러한 경험을 정의하는 것이 컨트롤에 대한 UI 어포던스를 안내하는 데 도움이 되기를 바랍니다. 당신의 시나리오에 대한 당신의 생각은 무엇입니까?
CC: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

경험은 다음과 같습니다.

• 알림이 보기를 떠나는 방법
  
  
  
  • 사용자가 수동으로 알림을 닫습니다.
  
  
  • 알림이 자동으로 시간 초과되고 자체적으로 사라집니다.
  
  
  • 알림은 사용자가 처음에 알림이 나타난 이유와 관련된 작업을 수행한 후에만 사라집니다.
    
    
    
    
    
    • 즉, 인터넷 연결이 끊겼다는 알림을 받은 후 인터넷 연결이 끊긴 경우에만 알림이 사라집니다.
    
    
    
  
  
  • 다른?
  
  
• 사용자가 알림에 반응하는 방식
  
  
  
  • 알림과 관련된 즉시 조치
  
  
  • 통지와 관련된 조치를 나중으로 연기
  
  
  • 알림을 완전히 무시 및/또는 해제합니다.
  
  
  • 다른?
  
  
• 알림이 표시될 때
  
  
  
  • 앱 실행 시
  
  
  • 앱 상태에서 프로그래밍 방식으로
  
  
  • 사용자가 작업을 수행한 후(예: 문서 백업 선택)
  
  
  • 다른?
  
  
• 한 번에 여러 알림을 표시할 수 있는 경우와 그 이유

귀하의 모든 생각에 다시 한 번 감사드리며 이 사실이 밝혀지기를 기대합니다!

@gabbybilka 이 제안이 잊혀지지 않아 기쁩니다. 수락해 주셔서 감사합니다!

가능하다면 이러한 종류의 알림 UI가 포함된 자사 앱 작업을 하는 사람들에게 연락하여 요구 사항 목록을 만들고 사용자 지정 솔루션에서 WinUI 기본 컨트롤로 이동하기 위한 요구 사항 목록을 만들 수 있습니다. 커뮤니티의 필요 및 필요와 결합된 그들의 필요는 이 제어의 V1에 대해 충분히 커버해야 합니다.

@chigy 는 Fluent Design 팀과 함께 일하면서 최종 디자인 사양에 대해 이야기할 수 있는 사람입니다.

다른 사람들이 일관된 WinUI 컨트롤을 사용하도록 권장하려면 Microsoft가 이를 통해 모범을 보여야 합니다.

• 코타나
• 그루브 음악
• 영화 및 TV
• 너의 폰

하면 떠오르는 앱들입니다.

@gabbybilka 또한 Windows Community Toolkit에 제어 기능이 있으므로 언제든지 이에 대해 이야기할 수 있습니다. 여기에 사용자를 위한 업그레이드 경로가 있고 Toolkit에서 WinUI로 마이그레이션하는 것이 정말 좋습니다.

대부분의 내용을 다룬 초기 요약에서 생각합니다. 그러나 선택적이고 실행 가능한 버튼도 있다는 점을 언급하는 것이 좋을 것 같습니다. 아니면 항상 맞춤 콘텐츠일 뿐인가요?

툴킷의 컨트롤에 대한 일부 기록이 있는 툴킷의 후속 조치(오래된 일임):

• 원호
• 첫 번째 PR 검토
• GitHub 기록 - 한 페이지에서 전체 목록을 가져오는 방법을 모르므로 아래로 스크롤하여 '이전'을 계속 클릭하십시오.

도구 키트의 스타일은 원래 Microsoft Edge 및 VS Code 알림 스타일(그 이후로 둘 다 업데이트됨)을 모델로 합니다. 그러나 그림과 같이 유연하고 템플릿을 다시 지정할 수 있으며 최상위 상태 표시줄 Office 스타일 경고 또는 일반 팝업 스타일 알림 모두에서 작동합니다.

다시 안녕! 이에 대한 업데이트로 저는 최근에 이 제안을 팀에 다시 제안했으며 이 기능을 추가로 정의하기 위한 제안을 받았습니다.

앞에서 설명한 시나리오의 경우 현재 수명이 긴 앱 전체의 필수 상태 메시지를 나타내는 정보 표시줄(줄여서 InfoBar)이라는 컨트롤을 만드는 작업을 진행하려고 합니다. 초기 시각적 디자인 사고는 FluentUI의 MessageBar 와 Teams가 "지금 녹음 중" 및 "인터넷 연결 끊김" 메시지를 표시하는 방법에서 영감을 받았습니다.
특히, 아이콘, 제목, 유연한 메시지 영역 및 닫기 버튼을 컨테이너의 기본, 최소, 시각적 구성 요소로 포함하여 컨테이너가 있는 콘텐츠 영역의 너비에 맞게 기본 설정됩니다. 이전 범위에서 InfoBar는 다음을 통해 닫을 수 있습니다. 사용자 또는 프로그래밍 방식으로 상태에 영향을 미치는 앱 기능이 해결되면 소개/종료 애니메이션 없이 인터넷 연결이 복원됩니다.

팀(현재 녹음 중)

오피스(호환 모드)

팀(인터넷 없음)

API가 결정화되기 시작하면 사양에 대한 논의를 시작하겠습니다. 그 동안 InfoBar를 사용할 시나리오와 필요한 기능을 계속 공유해 주세요 😊

토론 앞부분에서 @mrlacey 와 다른 사람들은 언급된 시나리오를 다룰 수 있는 두 개의 개별 컨트롤을 가질 가능성을 제기했습니다.

나는 이 두 가지 개념을 다음과 같이 생각한다.

• 0개 이상의 실행 가능한 하위 요소가 있는 해제 가능한 전체 너비 배너
• 상태 변경을 나타내기 위한 배너이며 단일 버튼으로 작동합니다.

별도의 컨트롤로 최고의 가치와 최소한의 혼란을 제공합니다.

InfoBar 비주얼 스타일과 구성 요소가 이전에 공유된 일부 사용 사례에 적합하지 않을 수 있음을 알고 있습니다. 특정 앱 시나리오 및 기능에 다른 시각적 스타일이 필요한 경우 이 스레드에서 이러한 상황을 계속 공유할 수 있습니다.

다시 한 번 감사드립니다!

컨트롤은 템플릿 및 스타일과 잘 작동하도록 설계되어야 합니다. 따라서 모든 동작이 컨트롤의 속성인 동안 필요에 맞게 성형할 수 있습니다.
애니메이션 또는 애니메이션하지 마십시오.
닫기 버튼을 표시하거나 숨깁니다.
위치.
아이콘 표시 여부.

등

InfoBar 비주얼 스타일과 구성 요소가 이전에 공유된 일부 사용 사례에 적합하지 않을 수 있음을 알고 있습니다. 특정 앱 시나리오 및 기능에 다른 시각적 스타일이 필요한 경우 이 스레드에서 이러한 상황을 계속 공유할 수 있습니다.

다시 한 번 감사드립니다!

대단하네요 앞으로. 그 비주얼 스타일은 앱을 사용하고 싶지 않을 정도로 많이 남겨두었습니다.

@mdtauk 이 게시한 디자인이나 위의 Cortana 스크린샷이 훨씬 더 바람직할 것입니다. 앱 디자인은 프로그램에 의해 지연되지 않고 앞으로 나아가야 합니다.

프레젠테이션/데스크톱 공유 중에 사용되는 것과 같이 닫을 수 있는 CommandBar로도 작동할 수 있습니까/있습니까? 예

모든 것 위에 오버레이를 지원하지 않는다는 것을 알고 있지만 너비를 고정하고 앱의 오버레이 레이어에 넣는 측면에서 이 방향에서 비슷한 디자인/기능의 겹침을 볼 수 있습니다.

@mdtauk

컨트롤은 템플릿 및 스타일과 잘 작동하도록 설계되어야 합니다. 따라서 모든 동작이 컨트롤의 속성인 동안 필요에 맞게 성형할 수 있습니다.
애니메이션 또는 애니메이션하지 마십시오.
닫기 버튼을 표시하거나 숨깁니다.
위치.
아이콘 표시 여부.

@shaheedmalik

대단하네요 앞으로. 그 비주얼 스타일은 앱을 사용하고 싶지 않을 정도로 많이 남겨두었습니다.

@mdtauk 이 게시한 디자인이나 위의 Cortana 스크린샷이 훨씬 더 바람직할 것입니다. 앱 디자인은 프로그램에 의해 지연되지 않고 앞으로 나아가야 합니다.

피드백 주셔서 감사합니다! 컨트롤이 Fluent Design 시스템의 이러한 기본 동작과 사용자 지정 가능성에 대해 충분히 유연해야 한다는 데 동의합니다. 내가 공유한 영상은 주로 이전에 구현된 예제의 참조였습니다.
우리는 계속해서 너무 많은 기능으로 단일 컨트롤을 오버로드하는 동시에 다양한 장기 앱 전체 상태 메시지 시나리오에 대해 충분히 사용자 지정 가능하고 유용하도록 하는 것 사이에서 균형을 유지하려고 노력할 것입니다.

프레젠테이션/데스크톱 공유 중에 사용되는 것과 같이 닫을 수 있는 CommandBar로도 작동할 수 있습니까/있습니까? 예

@마이클 호커

나는 이것이 아직 스레드에서 제기되지 않은 흥미로운 시나리오이며 잠재적으로 이 컨트롤에 의해 지원될 수 있다고 생각합니다. 알려주셔서 감사합니다! 범위 지정과 관련하여 이것은 우선 순위가 낮은 시나리오인 것처럼 보이지만 오버레이 우선 순위를 제외하고 디자인/기능이 유사하다는 데 동의합니다.

이 문제에 대한 업데이트가 있습니까? 우리는 현재 Files UWP에서 파일 작업의 상태를 표시하는 UI를 계획하고 있으며, 우리가 지향하는 디자인은 여기에서 제안된 이러한 기능의 이점을 누릴 수 있습니다.

안녕하세요 @yaichenbaum , 체크인해주셔서 감사합니다! 이 제안에 대한 업데이트로 우리가 초안을 작성하기 시작한 사양 문서 를 공유하게 되어 기쁩니다.

지금까지 정의된 내용을 요약하면 "막대"와 "토스트" 또는 "카드"의 두 가지 시각적 모드가 있는 단일 컨트롤을 만들기로 선택했습니다. 우리의 현재 노력은 "바" 모드를 정의하고 프로토타이핑하는 것입니다. 이 두 모드의 구성 요소는 동일하며 시각적 레이아웃만 다를 계획입니다. 여러 시각적 모드가 있으므로 현재 단일 "막대" 스타일로 제한하지 않기 위해 InformationBar 대신 StatusBanner 컨트롤을 사용하고 있습니다. 그러나 이름 지정에 대한 아이디어를 자유롭게 공유하십시오 😊

레이아웃에서 왼쪽에서 오른쪽으로 StatusBanner의 주요 구성 요소는 다음과 같습니다.

• 상태 색상
• 상
• 제목
• 메세지
• 작업 버튼
• 닫기 버튼

이러한 속성은 선택 사항이며 "Content" 속성을 통한 사용자 지정 콘텐츠는 여전히 옵션입니다.

또한 상태에 따라 미리 설정된 아이콘과 색상 조합을 갖도록 개발자가 설정할 수 있는 다양한 배너 유형을 정의할 예정입니다. 이렇게 하면 알림의 중요도에 따라 올바른 Icon 또는 BannerColor를 선택하는 작업을 단순화하고 애플리케이션 간에 일관성을 제공할 수 있습니다. Icon 또는 BannerColor 사용자 정의도 지원됩니다.

작업 버튼 또는 사용자 정의 닫기 버튼이 없는 "바" 모드의 StatusBanner의 종이 프로토타입.

StatusBanner 바 레이아웃의 현재 디자인은 @mdtauk 의 상태 카드 디자인에서 크게 영감을 받았습니다. 감사합니다!

사양의 현재 상태와 관련하여 피드백을 공유하려면 이 문제에 자유롭게 의견을 말하십시오. 우리의 다음 단계는 디자인과 코드 조각을 강화하고 더 많은 사용 사례를 포함하도록 확장하고 스태킹 및 메시지 래핑과 같은 기능을 정의하는 것입니다. 모두 감사합니다!

@yaichenbaum 그 동안 Toolkit의 InAppNotification 컨트롤이 있습니다.

@gabbybilka 업데이트에 감사드립니다. 제 사용 사례에 필요한 중요한 기능은 이 스레드의 앞부분에서 공유한 @hawkerm 처럼 한 번에 여러 상태 메시지를 표시하는 기능입니다. 컨트롤이 여러 상태 메시지의 배치를 처리하도록 하면 장점이 될 것입니다.

@yaichenbaum 그 동안 Toolkit의 InAppNotification 컨트롤이 있습니다.

@hawkerm 나는 InAppNotification 를 많이 보지 않았지만 준비가 되었을 때 새 컨트롤로 전환하는 대신 WinUI 버전을 기다리고 싶습니다.

여러분, 안녕하세요!
마지막 업데이트와 지금 사이에 시간이 없어 죄송합니다. 이 컨트롤을 정의하는 데 열심히 노력했습니다 😊
몇 주 전에 리포지토리에서 @chenss3 의 프로토타입 이 병합되는 것을 보았을 것입니다. 이것이 실제로 구현되는 것을 보게 되어 매우 기쁩니다! 이 단계에서 우리는 프로토타입을 만들고 응용 프로그램에서 이를 사용하는 데 관심이 있는 이 컨트롤의 모든 소비자와 연결하는 데 관심이 있습니다. 개발 중인 애플리케이션, 이 컨트롤을 사용할 때의 시나리오, 시작하는 데 도움이 필요한 경우, 프로토타입을 사용한 피드백을 공유해 주세요.

여러 알림의 위치 지정 및 스태킹을 지원하는 이 컨트롤의 팝업 버전에 대한 구현 세부 정보를 파악하기 시작 하면서 가까운 장래에 인라인 버전 작업을 계속하기로 결정했습니다. 일부 시나리오에 팝업 기능이 필요하다는 피드백을 듣고 계속 그 방향으로 나아갈 것입니다! 그 동안 우리는 아래의 모형과 더 유사한 프로토타입의 다음 버전을 개발 중입니다.

몇 가지 예를 더 보려면 사양 을 확인하세요.

모두 감사합니다. 여러분의 의견을 기다리겠습니다!

이것은 WinUI 3에서만 사용할 수 있습니까, 아니면 WinUI 2 시험판으로 들어갈 예정입니까?

@kmgallahan WinUI 2 시험판, 정확한 배송 버전은 아직 확실하지 않으므로 프로토타입 및 미리 보기 버전에 대해 커뮤니티와 고객으로부터 좀 더 많은 피드백을 받고 싶습니다.

초기 피드백을 극대화하려면 이와 같은 프로토타입을 가능한 한 쉽게 시도할 것을 권장합니다. 면책 조항이 있는 시험판 빌드로 푸시하거나 개발/베타 릴리스를 제공할 수 있습니다.

프로토타입을 시도하기 위해 WinUI의 dev 분기를 빌드해야 하는 것은 상당한 마찰을 제공합니다. 특히 (어쨌든 코드베이스에 대한) 기여자보다는 주로 WinUI 소비자인 경우에 그렇습니다.

동의합니다. 프로토타입이 솔리드 상태(표시된 모형과 유사하고 다양한 입력 옵션을 지원함)가 되면 2.5 미리보기에 넣고 싶습니다. 그 때 시도해 볼 수 있습니까/관심이 있습니까?

지금 시도하는 데 관심이 있습니다. 내 빌드에 WinUI와 같은 대규모 프로젝트를 추가하는 것보다 NuGet에서 사용하는 것을 선호합니다.

지금은 무엇이든지 미리보기로 만들 때까지 기다릴 것입니다.

다시 안녕! 몇 가지 업데이트:

• 사양은 계속해서 검토되고 반복되었습니다. 부담없이 이 PR 에서 확인하시고 댓글을 남겨주세요. 주목할만한 변경 사항은 ButtonBase에서 상속되는 자체 콘텐츠를 가져오는 일반 ActionButton 속성이 추가되었다는 것입니다.

  • 내가 지적하고 싶은 현재 모형의 불일치는 이 ActionButton의 위치입니다. 사양에서 작업 버튼은 현재 닫기 버튼 바로 왼쪽에 오른쪽 정렬된 것으로 표시되지만 실제 위치는 메시지 바로 오른쪽에 있습니다. 내 이전 댓글과 아래에 표시된 이미지가 올바른 위치입니다. 개선된 모형은 계속 업데이트되고 개발이 계속됨에 따라 사양에 추가됩니다 😊

• @teaP 는 WinUI 2.5 시험판으로 이동하면서 이 컨트롤의 기본 버전을 구현하기 시작했습니다. 감사합니다!

이전과 마찬가지로 자신이 이 컨트롤의 잠재적인 사용자라고 생각되면 개발 중인 응용 프로그램과 InfoBar를 사용할 시나리오에 대해 자유롭게 의견을 말하십시오. 모두 감사합니다!

다시 안녕! 강조하기 위해 @teaP는 최근 InfoBar에 대한 pull request #3325를 열었습니다. 확인하고 싶다면 😊

이것을 InfoBar라고 하는 이유는 무엇입니까? 정보는 포함할 수 있는 정보의 작은 클래스 중 하나일 뿐입니다. 또한 오류 및 경고와 그에 따른 조치를 지원합니다. Bar는 또한 컨트롤의 '모양'을 인위적으로 제한합니다. 바 외에도 몇 가지 다른 사용 사례가 있습니다.

내 의견으로는 NotificationView 또는 MessageView 등이 더 나은 이름일 것입니다.

이것을 InfoBar라고 하는 이유는 무엇입니까? 정보는 포함할 수 있는 정보의 작은 클래스 중 하나일 뿐입니다. 또한 오류 및 경고와 그에 따른 조치를 지원합니다. Bar는 또한 컨트롤의 '모양'을 인위적으로 제한합니다. 바 외에도 몇 가지 다른 사용 사례가 있습니다.

내 의견으로는 NotificationView 또는 MessageView 등이 더 나은 이름일 것입니다.

원래 StatusBanner 로 제안되었습니다.
그런 다음 InformationBar / InfoBar 로 변경되었습니다.

이 컨트롤의 FluentUI 버전은 MessageBar 라고 합니다.

요약 감사합니다. 이름은 여전히 ​​나에게 큰 의미가 없습니다. 현재 컨트롤이 설계된 방식은 알림입니다. 보다 일반화하면 도움말/교육 시나리오도 지원할 수 있도록 '메시지'여야 합니다. 다양한 개념을 일반화하면 다음은 컨트롤에 대한 더 나은 디자인입니다.

1. ~ MessageView ~ 또는 팁 : 선택적 작업, 제목, 글리프, 이미지 및 버튼을 사용하여 사용자에게 상태, 힌트 또는 교육 정보를 표시하는 컨트롤입니다. 이것은 아무 곳에나 배치할 수 있으며 팝업이 아닙니다. 또한 다양한 레이아웃을 지원합니다.

2. TeachingTip : MessageView를 호스팅하는 플라이아웃/팝업입니다.

   • 호스팅 팁

3. NotificationBar 또는 StatusTip : 애플리케이션 또는 보기 상단에 '막대' 형식의 앱 전체 알림입니다.

   • 호스팅 팁

4. 도구 설명 : 이제 작업 및 이미지 등에 대한 지원을 제공하는 팁도 호스트할 수 있습니다.

   • 호스팅 팁

우리는 일반적으로 생각하고 높은 수준의 개념을 동일한 컨트롤에 결합해야 합니다. 그렇지 않으면 비슷하지만 다른 속성을 가진 매우 전문화된 컨트롤을 많이 만들 것입니다.

일반적인 'MessageView' 컨트롤에 대한 완벽한 이름을 생각하면 '팁'이라고 합니다. ToolTip도 이를 호스팅할 수 있습니다. 그에 따라 업데이트되었습니다.

다음은 일부 입력 필드 상단에 있는 알림 표시줄의 또 다른 '실제' 예입니다. 현재 컨트롤은 해당 시나리오에 유용합니다.

다음은 일부 입력 필드 상단에 있는 알림 표시줄의 또 다른 '실제' 예입니다. 현재 컨트롤은 해당 시나리오에 유용합니다.

TextBox는 이 중 일부를 다룰 수 있는 유효성 검사 상태를 얻게 되지만 다양한 컨트롤을 보는 방법은 다음과 같습니다.

• 사용자가 적극적으로 식별하려는 단일 요소에 대한 도구 설명입니다.
• 단일 요소에 대한 TeachingTip 개발자는 사용자가 알아차리기를 원합니다(요소에 연결 해제할 수도 있음).
• 개발자가 일부 정보를 전달하려는 전체 앱/콘텐츠 영역에 대한 InfoBar .
• 개발자가 닫기 전에 사용자가 무언가를 읽었는지 확인하기를 원하는 경우를 위한 플라이아웃/대화 상자 입니다.
• 개발자가 사용자에게 무엇보다 선택을 하거나 조치를 취하도록 요구할 때 사용하는 콘텐츠 대화 상자 .

나는 또한 OS 수준 알림과 알림 센터가 있기 때문에 알림 이라는 단어를 사용하지 않을 것입니다.

나는 또한 OS 수준 알림과 알림 센터가 있기 때문에 알림이라는 단어를 사용하지 않을 것입니다.

글쎄, 나는 개발자들이 그 차이를 알 것이라고 생각하지만 그것은 확실히 공정한 지적이다.

우리가 많은 별도의 컨트롤을 만들 수 있는 것도 사실입니다. 그러나 알림/상태/메시지/힌트/티칭과 관련하여 함께 결합될 수 있는 몇 가지 높은 수준의 개념이 분명히 있습니다. 우리는 적어도 이 모든 것에서 인터페이스를 만들어야 합니다.

플라이아웃/콘텐츠 대화 상자는 대부분의 경우 일반 콘텐츠 컨트롤이므로 별도의 개념입니다.

다양한 시나리오에서 호스팅할 일반화된 '메시지 보기' 유형 컨트롤의 완벽한 이름을 생각했습니다. 이를 '팁'이라고 합니다. 이에 따라 위의 내 의견을 업데이트했습니다. https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

다양한 시나리오에서 호스팅할 일반화된 '메시지 보기' 유형 컨트롤의 완벽한 이름을 생각했습니다. 이를 '팁'이라고 합니다. 그에 따라 위의 댓글을 업데이트했습니다. #913(댓글)

팁 에 중요한 경고나 오류 메시지를 넣는 것이 불편합니다...

우리가 많은 별도의 컨트롤을 만들 수 있는 것도 사실입니다. 그러나 알림/상태/메시지/힌트/티칭과 관련하여 함께 결합될 수 있는 몇 가지 높은 수준의 개념이 분명히 있습니다. 우리는 적어도 이 모든 것에서 인터페이스를 만들어야 합니다.

플라이아웃/콘텐츠 대화 상자는 대부분의 경우 일반 콘텐츠 컨트롤이므로 별도의 개념입니다.

이 아이디어가 정말 마음에 듭니다. 아이콘, 제목, 메시지, 작업 버튼 API에는 이러한 정보 컨트롤에서 일관될 수 있는 공통점이 있다고 생각합니다. InfoBar를 사용하면 이 현재 버전에서 구현할 수 있지만 잠재적으로 이 특성의 다음 제어를 위해 구현할 수 있는지 확실하지 않습니다.

다양한 시나리오에서 호스팅할 일반화된 '메시지 보기' 유형 컨트롤의 완벽한 이름을 생각했습니다. 이를 '팁'이라고 합니다. 그에 따라 위의 댓글을 업데이트했습니다. #913(댓글)

팁 에 중요한 경고나 오류 메시지를 넣는 것이 불편합니다...

저도 이것에 동의합니다... 더 많은 조사가 필요합니다.

다양한 시나리오에서 호스팅할 일반화된 '메시지 보기' 유형 컨트롤의 완벽한 이름을 생각했습니다. 이를 '팁'이라고 합니다. 그에 따라 위의 댓글을 업데이트했습니다. #913(댓글)

팁에 중요한 경고나 오류 메시지를 넣는 것이 불편합니다...

저도 이것에 동의합니다... 더 많은 조사가 필요합니다.

기존의 모든 컨트롤 및 아이디어와 얼마나 잘 맞는지 생각해 보세요. 그런 면에서 완벽합니다. 그러나 예, 오류/경고의 맥락에서 적절하지 않은 것 같습니다. 사람들이 빨리 이해할 것이라고 생각하지만 나는 그 논리에 대해 논쟁 할 수 없습니다.

이것을 InfoBar라고 하는 이유는 무엇입니까? 정보는 포함할 수 있는 정보의 작은 클래스 중 하나일 뿐입니다. 또한 오류 및 경고와 그에 따른 조치를 지원합니다. Bar는 또한 컨트롤의 '모양'을 인위적으로 제한합니다. 바 외에도 몇 가지 다른 사용 사례가 있습니다.

내 의견으로는 NotificationView 또는 MessageView 등이 더 나은 이름일 것입니다.

InfoBar가 항상 막대가 아닐 수 있다는 점에 동의하지만 이름에 "막대"를 포함하는 것은 시각적으로나 개념적으로 앱 전체의 시나리오를 위한 것임을 의미한다고 생각합니다. "정보 표시줄"의 이미지를 검색하면 IE에서 유사한 경험의 이미지를 찾을 수 있으며(꼭 IE와 일치시키려는 것은 아님) 예상되는 시각적 및 기능적 레이아웃을 내포하고 있다고 생각합니다. 나는 이것을 '보기'로 보지 않지만 메시지 또는 알림에 초점을 맞추는 것을 좋아합니다.

@gabbybilka 예, 이전 StatusBar 또는 최신 AppBar... CommandBar... 등과 매우 유사합니다. 문제는 컨트롤의 사용을 일반화하여 임의의 위치에 힌트와 메시지도 표시해야 한다는 것입니다. '보기'도 100% 맞지는 않지만 일반명에 가깝다. 실제로 내 관심사는 기본 개념을 통합하여 동일한 것을 변형하는 여러 컨트롤로 끝나지 않도록 하는 것입니다.

두 위치에 여러 댓글이 있어 혼동을 일으키기 위해 수정했습니다.

다른 문제 중 하나에 게시 한 생각을 반영합니다 ...

_컨트롤에 대한 부동 모드가 더 이상 V2에 대해 고려되지 않는다는 사실에 대한 응답_
나는 행동과 형태의 변화가 당신을 대안으로 TeachingTip으로 향하게 할 것이라는 점을 이해할 수 있지만, 심각성, 상태 색상 및 교육 팁 자체의 디자인의 부족을 제안합니다. 같은 종류의 것과 호환되지 않을 것입니다. InformationBar 컨트롤이 처리하는 메시지입니다.

전체 화면 WinUI 앱, 좁은 너비 창, Hololens 및 Xbox와 같은 항목 간의 UI 레이아웃과 화면 너비 차이는 도킹된 Bar 폼 팩터에 적합하지 않습니다.

따라서 이를 염두에 두고 InformationCard 컨트롤과 함께 AppMessage API에 대한 정보 표시줄을 래핑해야 합니다. 따라서 심각도, 색상, 제목, 메시지, 작업 버튼 등의 동일한 속성을 XAML 또는 앱의 코드 및 화면에 표시되는 방식은 폼 팩터/장치 제품군에 맞게 변경됩니다.

첨부되지 않은 교육 팁이 있을 수 있지만 앱 상태 메시지에 적합한 사용자 지정을 지원하지 않습니다. 이는 이 컨트롤의 원래 의도입니다.

그래서 우리가 정말로 단지 메시지인 '팁'을 가지고 있다면 어떨까요? 글리프, 이미지, 메시지 텍스트, 제목이 있습니다.

그런 다음 Tip에서 파생된 심각도, 작업 및 사물을 추가하는 AppMessage가 있습니다. 그러면 Tip은 현재 존재하는 TeachingTip 및 ToolTip에서 계속 사용할 수 있습니다. 인라인, 문맥 힌트에 대한 내 시나리오에서도 유용합니다.

그래서 우리가 정말로 단지 메시지인 '팁'을 가지고 있다면 어떨까요? 글리프, 이미지, 메시지 텍스트, 제목이 있습니다.

그런 다음 Tip에서 파생된 심각도, 작업 및 사물을 추가하는 AppMessage가 있습니다. 그러면 Tip은 현재 존재하는 TeachingTip 및 ToolTip에서 계속 사용할 수 있습니다. 인라인, 문맥 힌트에 대한 내 시나리오에서도 유용합니다.

꼬리가 없는 티칭팁은 상황에 딱 맞는 것 같습니다...

꼬리가 없는 티칭팁은 상황에 딱 맞는 것 같습니다...

TeachingTip으로 그렇게 할 수 있는지 몰랐습니다. 또한 내 컨트롤은 TeachingTip보다 훨씬 더 오래 사용되어 지금까지 업그레이드에 대해 실제로 조사한 적이 없습니다. 어느 쪽이든, 당신이 그렇게 할 수 있다면 그것은 내 실수입니다.

편집: 신경 쓰지 마세요. 꼬리가 없더라도 여전히 어떤 식으로든 무시되는 오버레이입니다. 내가 설명하는 '힌트'는 모두 인라인이며 사용자가 기본적으로 첫 번째 요소를 생성할 때까지 지속됩니다. 팝업, 플라이아웃 또는 기타 비영구적 보기가 아닌 정보를 제공하는 단순한 컨트롤입니다.

나는 여전히 여러 곳에서 사용되는 인터페이스/컨트롤로 나눌 수 있는 많은 공통점이 있다고 확신합니다. 우리가 논의하는 이러한 모든 컨트롤에는 차이점보다 훨씬 더 많은 유사점이 있습니다. 기본 정보가 표시되는 위치/방법만 변경됩니다. 이것은 단순화를 위한 모든 것입니다.

꼬리가 없는 티칭팁은 상황에 딱 맞는 것 같습니다...

TeachingTip으로 그렇게 할 수 있는지 몰랐습니다. 또한 내 컨트롤은 TeachingTip보다 훨씬 더 오래 사용되어 지금까지 업그레이드에 대해 실제로 조사한 적이 없습니다. 어느 쪽이든, 당신이 그렇게 할 수 있다면 그것은 내 실수입니다.

나는 여전히 여러 곳에서 사용되는 인터페이스/컨트롤로 나눌 수 있는 많은 공통점이 있다고 확신합니다. 우리가 논의하는 이러한 모든 컨트롤에는 차이점보다 훨씬 더 많은 유사점이 있습니다. 기본 정보가 표시되는 위치/방법만 변경됩니다. 이것은 단순화를 위한 모든 것입니다.

분해하면 아이콘과 텍스트만 있고 연결된 "컨텍스트"가 없습니다. 그러나 AppMessage 로 래핑하는 제 제안에는 Non Attached TeachingTips가 UI의 다른 형태로 포함될 수 있습니다.

분해하면 아이콘과 텍스트만 있고 연결된 "컨텍스트"가 없습니다. 그러나 AppMessage로 래핑하는 제 제안에는 Non Attached TeachingTips가 UI의 다른 형태로 포함될 수 있습니다.

죄송합니다. 위의 편집 내용을 참조하세요. 티칭 팁은 여전히 ​​인라인이 아니며 닫힐 때까지 맨 아래에 떠 있습니다. 또한 고려해야 할 이미지와 제목도 있습니다.

분해하면 아이콘과 텍스트만 있고 연결된 "컨텍스트"가 없습니다. 그러나 AppMessage로 래핑하는 제 제안에는 Non Attached TeachingTips가 UI의 다른 형태로 포함될 수 있습니다.

죄송합니다. 위의 편집 내용을 참조하세요. 티칭 팁은 여전히 ​​인라인이 아니며 닫힐 때까지 맨 아래에 떠 있습니다.

맨 아래에 있을 필요는 없습니다.

인라인은 힌트에 대한 특이한 사용 사례일 수 있습니다. 이는 주변의 다른 콘텐츠를 대체할 수 있기 때문입니다.

V2가 인라인/비 부동 디스플레이 모드에 대한 지원을 추가하도록 제안할 수 있습니다.

@mdtauk 의 의견에 좀 더 자세한 정보를 제공하기 위해 사양의 "InfoBar V2에 대한 의도된 기능" 섹션에서 부동 모드 제거에 대한 그의 질문에 대한 나의 초기 답변이 여기에 있습니다.
나에게서:

디자인 토론을 위해 여기로 오세요. V2에서 의도한 기능이 변경되었음을 잘 확인하세요 😉 현재 몇 가지 이유로 V2 버전에서 InfoBar에 대한 부동 모드를 커밋하지 않습니다. 플로팅 모드가 InfoBar에 있어야 _해야_ 하는지 아니면 토스트와 같은 알림이 완전히 다른 컨트롤이어야 하는지 추가로 탐구하고 싶습니다. 조사하는 동안 우리는 부동 모드의 기본 구현이 Teaching Tip과 매우 유사할 것이라는 것과 스택, 위치 지정 및 오버레이 선택과 같은 알림 시나리오 기능을 완전히 탐색하려면( WCT InAppNotification의 StackMode 참조) 필요하다는 것을 깨달았습니다. 이렇게 하면 InfoBar의 범위와 의도가 초기 초점보다 훨씬 더 넓어집니다. 참고로 우리는 InfoBar에 플로팅 기능을 추가하는 것에 대한 문을 완전히 닫지 않았지만 아니오로 기울고 있습니다.

기본 AppMessage 클래스를 기반으로 하는 InformationBar 및 InformationCard 제안의 경우 이 아이디어가 좋습니다. "화면에 표시되는 방식이 폼 팩터/디바이스 제품군에 맞게 변경될 것"이라고 언급하셨는데, 이에 대해 더 자세히 살펴보고 싶습니다. 바 UX보다 카드 UX(특히 일시적인 메시지, 페이지별 오류 메시지, 도킹 가능한 표면이 없는 앱)에 더 적합한 시나리오가 있으며 그 반대의 경우도 마찬가지입니다.

나에게 InfoBar/InfoCard/Teaching Tip을 사용하는 "시기"(시각적 및 기능적 요구 사항과 관련됨)와 사용하는 "이유"(최종 사용자 인식 및 경험 일관성 기반)에는 둘 다 차이가 있습니다. 일시적인 메시지는 InfoCard에서 지원해야 하고 InfoBar에서는 지원하지 않아야 하는 것으로 저에게 분명한 하이라이트입니다. 영구 오버레이 콘텐츠가 접근성 관점에서 지원하기 까다롭기 때문에 사용자가 해제할 수 없는 메시지는 반대의 예입니다.

곁길로 빠져들지 마십시오. :) 이러한 다양한 컨트롤은 대부분 동일한 유형의 정보를 제공합니다. 단지 다른 영역/스타일일 뿐입니다. 이를 일반화하고 통합해야 합니다. 나는 당신이 그것을 부르고 싶다면 우리가 하나의 공통 'AppMessage' 컨트롤을 중심으로 통합할 수 있다고 생각합니다. 그런 다음 'AppMessage'를 다른 방식으로 표시하기 위한 다른 컨테이너를 사용하십시오. 이는 TeachingTip, ToolTip, NotificationBar, 카드 등으로 표시될 수 있습니다. 각 컨테이너는 사용 사례에 맞게 스타일을 수정할 수 있습니다. 기본 속성과 유형은 통합됩니다.

@gabbybilka님 의 답글로 문맥을 잘못 이해하려고 한 것이 아닙니다 😄

기본 AppMessage 클래스를 기반으로 하는 InformationBar 및 InformationCard 제안의 경우 이 아이디어가 좋습니다.

여기에서 이름 지정이 필요합니다. 저는 "AppMessage"를 좋아합니다("Tip"은 항상 계획된 것처럼 보이지만 "Tip"은 굉장할 것입니다). 그러나 우리가 함께 간다면 "MessageBar" 및 "MessageCard" 호스팅이어야 합니다. 그것.

나에게 InfoBar/InfoCard/Teaching Tip을 사용하는 "시기"(시각적 및 기능적 요구 사항과 관련됨)와 사용하는 "이유"(최종 사용자 인식 및 경험 일관성 기반)에는 둘 다 차이가 있습니다.

저는 이러한 다양한 사용 사례와 프레젠테이션에 전적으로 동의합니다. 그러나 그들은 여전히 ​​일반화되고 표준화될 수 있는 메시지를 제시하고 있습니다. 나는 우리 모두가 지금 개념에 동의한다고 생각합니다 :)

카드 메시지/팁의 예

내가 생각하는 목표 중 하나는 받은 편지함 및 자사 앱/Windows Shell이 ​​사용자 지정 솔루션에서 일관된 받은 편지함 제어/API를 사용하도록 권장하는 것입니다.

UWP 앱에서 내가 작업하는 이러한 개념 중 일부는 이미 통합되어 있다는 점을 추가해야 합니다. 이 토론과 관련된 단순화된 버전은 다음과 같습니다.

다음 속성을 가진 'Message' 클래스(컨트롤이 아니라 데이터 구조일 뿐입니다)가 있습니다.

        protected MessageDisplayMode _DisplayMode;
        protected List<Message>      _InnerMessages;
        protected MessagePriority    _Priority;
        protected string             _Text;
        protected DateTimeOffset?    _Timestamp;

우선 순위는 기본적으로 이미 결정한 것과 동일합니다(요즘에는 상당히 표준화되어 있습니다). DisplayMode는 알림, 없음 및 팝업을 지원합니다. 메시지가 백엔드 코드에 의해 생성되면 프론트엔드에 전달되어 그에 따라 앱 상단의 '바'에 빠른 알림으로 표시되거나 해제됩니다. 또는 더 심각한 메시지에 대한 차단 팝업으로.

또한 메시지 자체를 가져오지만 글리프와 제목을 추가하고 이전에 이야기한 인라인 컨텍스트 '힌트'로 표시하는 'MessageView' 컨트롤이 있습니다.

그것이 바로 제가 제안하는 것입니다. 앱 계층에서 추상화를 수행하십시오. 두 보기에 연결할 수 있는 간단한 ViewModel 클래스가 있습니다. 간단하고 유연합니다. 선호하는 로깅 프레임워크로 로깅을 하고 싶거나, 사용자 정의 우선순위를 갖고 싶거나, 고유한 데이터를 추가하고 싶을 수도 있습니다. ViewModel에서 모든 작업을 쉽게 수행할 수 있습니다.

언급한 컨트롤의 의도는 각 앱에 약간 다른 UI 및 동작을 제공하는 대신 여러 앱 및 OS 사용 사례에서 특정 시나리오를 수행하는 통합된 방법을 제공하는 것입니다. 도구 설명 및 InfoBar/MessageBar는 개발자와 최종 사용자 모두에게 잘 알려진 개념입니다. 둘 다 정보를 제공하지만 매우 다른 용도로 사용됩니다. 나는 이것들에 대한 공통 기본 클래스나 공통 개념을 갖는 것에서 많은 이점을 보지 못합니다. 글로벌 앱 InfoBar에 이미 표시되어 있는 도구 설명에 메시지를 넣는 이유는 무엇입니까(이 도구 설명을 어디에 첨부하시겠습니까?)? 이것은 재사용으로 이어질 것 같지 않습니다.

IMO에서 공통 개념이 훨씬 더 유용한 다른 영역이 있습니다. Button, AppBarButton, MenuItem을 생각해 보십시오. 이 모두는 텍스트와 아이콘을 표시하며 모두 작업을 트리거하는 데 사용됩니다. 종종 MenuItem(ContextMenu)과 AppBar/CommandBar에서 동일한 명령을 제공합니다. 여기에 명령, 텍스트, 아이콘, 긴 메시지(도구 설명)를 넣을 수 있는 일반적인 개념이 매우 유용합니다. 그러나 ToolTip 및 MessageBar에 대한 공통 개념이 있습니까? 나는 이것이 정말로 필요하다고 생각하지 않습니다. 물론 UWP를 처음부터 다시 작성했다면 공통 기본 클래스를 생각해 냈을 수도 있습니다. 하지만 필요하거나 과도하게 도움이 된다고 생각하지 않습니다.

@lukasf 귀하의 요점은 의미가 있습니다. 앱 자체에서 수행할 수 있습니다. 그러나 매우 유사한 개념이 많이 있으며 여기에서 모두가 통일의 혜택을 누릴 수 있습니다.

도구 설명은 메시지와 함께 글리프와 제목이 있으면 도움이 될 수 있기 때문에 토론에 포함되었습니다. 개념적으로 이러한 컨트롤은 모두 어떤 형식의 메시지이기도 합니다. 표시되는 위치/방법만 다릅니다. 대규모 표준화를 수행하지 않더라도 MessageBar 및 MessageCard에는 여전히 많은 공유 속성/유형이 필요합니다. 우리는 MessageCardPriority 적과 함께 MessageBarPriority를 ​​갖고 싶지 않습니다. 기본 유형도 미래에 대비할 수 있는지 확인하려면 여전히 생각을 해야 합니다.

이 모든 것을 교육 팁의 기존 아이디어와 결합하는 것은 나에게 논리적으로 보입니다. 언급된 모든 컨트롤과 해당 속성을 나란히 비교하면 어떤 방향으로 가야 하는지 확신할 수 있습니다. 내가 시간이 아플 경우 직접 비교를 수행합니다.

Button/AppBarButton/etc에 대한 귀하의 의견. 우리가 확산하고 싶지 않은 생각의 완벽한 예입니다. Microsoft는 시간/노력을 들이지 않고 유사하지만 다른 여러 컨트롤을 만드는 습관을 들이고 있습니다. 이 장기간은 여러 가지 이유로 어떤 종류의 프레임워크에도 좋지 않습니다.

메시징 컨트롤을 비교했습니다. 너무 거추장스럽기 때문에 무료상담으로 풀어드립니다 :)

이것은 내가 Microsoft에서 내부적으로 만들 것으로 기대하는 일종의 상위 수준 비교 및 ​​전략 문서입니다. 내가 사양/설계 검토를 주도했다면 나는 이러한 유형의 분석을 요구할 것입니다. 그렇지 않으면 아무도 승인을 받고 떠날 것이라고 기대할 수 없습니다. 다음을 수행하는 것이 절대적으로 중요합니다.

1. 팀 구성원 간의 이해 격차 해소
2. 대규모 팀 및 조직에서 발생하는 '사일로' 극복
3. 미래 기능이 좋은 기반 위에 추가될 수 있도록 프레임워크의 일관된 미래 방향을 보장합니다(가장 중요).

Microsoft는 WPF 이후 어떻게든 이러한 큰 그림 원칙을 잃어버렸고 이 분야의 리더십에 의해 더 이상 '상위 수준' 비전이 없는 것 같습니다. 어쨌든 저는 내부 토론에 대해 잘 알지 못하므로 XAML 원칙에 대한 오랜 경험과 오랜 역사를 가진 일부 개인과 함께 내부적으로 더 많은 계획이 이루어지기를 바랍니다.

그 말과 함께 아래 문서를 자유롭게 찢으십시오. 가장 중요한 것은 토론 자체입니다.

MessageControl 비교 20200929.xlsx

비교 문서에 감사드립니다. 정보 제어에 대한 귀하의 생각을 전체적으로 볼 수 있어 매우 좋습니다! 내가 계속 논의하고 싶은 두 가지 주요 주제는 1입니다. 왜 티칭 팁과 InfoBar가 다른 API/속성/기능을 가져야 _안되나요_? 2. InfoCard가 비교 문서에 설명된 팝업이 아닌 경우 InfoBar와 InfoCard의 차이점은 무엇입니까?

첫 번째 질문의 경우 빨간색 텍스트 항목에 대한 디자인 결정을 강조하고 좀 더 명확하게 제공할 수 있습니다.

• TeachingTip Subtitle vs InfoBar 메시지: 기능적으로는 동일합니다! 이 컨트롤에서 굵게 표시되지 않은 텍스트가 있는 보조 메시지입니다. 교육 팁에서 이 메시지는 항상 제목 아래에 표시되며 부제목으로 명명되는 것이 합리적입니다. InfoBar의 경우 이 메시지는 대부분 인라인으로 표시되며 개념적으로는 부제목이라는 이름이 적절하지 않은 제목 오른쪽에 직접 표시됩니다.
• TeachingTip HeroContent 대 InfoBar 콘텐츠: Teaching Tip에는 HeroContent와 Content가 모두 있는 반면 InfoBar에는 Content만 있습니다. HeroContent 속성은 가르치는 데 도움이 되는 이러한 더 큰 이미지를 지원하기 때문에 Teaching Tip에 고유합니다. InfoBar는 가로 레이아웃에 초점을 맞추기 때문에 이미지를 명시적으로 지원하지 않습니다. 두 컨트롤의 Content 속성은 추가 사용자 지정 콘텐츠용이며 두 컨트롤의 나머지 UI 요소 아래에 있습니다.
• 교육 팁 버튼 전략 대 InfoBar 버튼 전략: 여기에서 주요 차이점은 InfoBar가 클래식 "버튼" 이외의 더 많은 유형의 버튼을 지원하고 텍스트를 포함하도록 닫기 버튼의 사용자 지정을 권장하지 않는다는 것입니다.
  
  
  
  • InfoBar의 일반적인 시나리오는 하이퍼링크 버튼을 포함하는 것입니다. 기본 하이퍼링크 버튼 전경색과의 색상 대비 및 다양한 색상의 배경색으로 인해 InfoBar에 포함된 하이퍼링크 버튼에 고유한 사용자 지정 스타일을 적용하여 액세스할 수 있도록 하고 싶었습니다.
  
  
  • 포함된 텍스트와 단일 작업에 초점을 유지하도록 디자인 검토 후 닫기 버튼 사용자 지정(텍스트에 대해 원하는 경우 약간의 가벼운 스타일을 수행하기 위한 CloseButtonStyle 속성이 있음)을 InfoBar에 포함하지 않기로 결정했습니다. 이와 관련하여 사양에서 언급했듯이 여기에서 둘 이상의 작업 버튼을 지원하기 위해 V2의 ActionContentArea에 대해 생각하고 있으며 여기에서 닫기 버튼 사용자 지정을 다시 활성화하는 것을 조사할 수 있습니다.
  
  
• InfoBar IsClosable & IsIconVisible: 교육 팁에는 IsClosable이 없습니다. 교육 팁은 팝업이고 비차단/긴급 정보를 표시하므로 항상 닫을 수 있어야 합니다. 또한 InfoBar가 다른 심각도 수준을 통해 수행하는 기본 스타일로 아이콘이 나타나지 않기 때문에 IsIconVisible이 없습니다. 개발자가 원하는 경우 제공된 아이콘을 제거할 수 있는 방법을 제공하고 싶었습니다. 우리는 많은 펑키 버그를 일으키고 IsIconVisible 속성을 통해 단순화한 IconSource를 null로 설정하려고 했습니다.

이게 말이 되나요? 두 컨트롤 모두 다른 목적이 있다고 생각하며 기능의 차이가 이를 반영합니다. 이 설명과 디자인 근거가 도움이 되었기를 바랍니다!

서식 문제 및 오타 수정😊 x2

이러한 컨트롤이 자체 컨텍스트 내에서 자체 작업을 수행하는 것에 대한 정당성이 있기 때문에 이러한 컨트롤 간의 조화를 직접 옹호하지는 않습니다.

그러나 통합 구조로 작동하지만 폼 팩터에 적응할 수 있는 인앱 메시징 API를 만드는 데 컨트롤을 변경할 필요가 없습니다.

이러한 종류의 API에 대해 토론하고 답변할 질문이 있습니다.

• 개발자는 메시지 호출이 화면에 표시할 컨트롤 유형을 어떻게 지정할 수 있습니까?
• 제어 유형을 지정하지 않으면 API가 주어진 속성을 취하고 가장 적합한 것을 "선택"합니까?
• 어떻게 행동 선택을 기본 컨트롤에 전달할 것인가?
• 플랫폼의 적합성에 따라 어떤 폼 팩터가 재정의됩니까?

그리고 아마 더 많은 내가 생각하지 못한 lol

Xbox를 플랫폼으로 사용하기
입력 방법은 화면 크기/배율과 마찬가지로 매우 다릅니다.

전체 너비 정보 표시줄은 화면 가장자리의 오버스캔을 고려해야 하므로 이러한 앱의 경우 정보 카드가 더 적합할 수 있습니다.

그러나 해고를 어떻게 처리하겠습니까?

닫기 버튼 위로 이동할 커서가 없지만 카드가 컨트롤러 입력을 대신하도록 하시겠습니까? 이렇게 하면 모달이 됩니다. 하지만 콘텐츠 위에 겹쳐진다면 어떻게 선택하고 집중할 수 있을까요?

그러면 인라인으로 표시되고 콘텐츠를 아래로 밀어내지만 전체 너비가 아닌 것은 무엇입니까?

또한 Xbox에는 알림 시스템과 같은 자체 토스트가 있으므로 이 API가 작동해야 합니까? 그것으로 작동할 수 있습니까, 아니면 시스템 전용입니까?

1. 왜 Teaching Tip과 InfoBar가 다른 API/속성/기능을 가지지 않아야 합니까?

목표는 항상 동일한 것에 대한 공통 API를 제공하는 것이어야 합니다. 이 전체 토론은 일반적으로 사용자에게 표시되는 메시지에 관한 것이며 이해하면 몇 가지 유사점이 나타납니다. TeachingTip과 MessageBar 유형의 컨트롤의 사용 사례가 다르다는 것은 논쟁의 여지가 없습니다. 기본적으로 하나는 메시지를 표시하고 다른 하나는 팁도 제공합니다. 나는 여기서 전반적인 디자인 선택에 의문을 제기하는 것이 아닙니다. 그러나 이러한 컨트롤에는 차이점보다 유사점이 훨씬 더 많습니다. 디자인만 보세요. 모두 아이콘, 제목, 부제목, 콘텐츠, 작업 버튼 및 닫기 버튼이 있습니다(하지만 이름을 다르게 지정했고 다른 API 노출 영역이 있음). 여기에서 최소한 명명 및 열거형을 표준화하는 것이 좋은 생각인 이유를 모르겠다면 더 이상 할 말이 없습니다. 이것은 좋은 아키텍처의 기본 요소일 뿐입니다.

버튼의 경우 두 컨트롤 모두 작업 버튼과 닫기 버튼을 지원합니다. 그러나 당신은 이것을 완전히 다른 방식으로 수행했습니다. 위에서 몇 가지 이유를 설명했지만 이제 이와 같은 상황에서 버튼을 사용하기 위한 '추한' API가 있습니다. 이것을 지금 일반화하여 미래에 좋은 것을 얻는 것이 어떻겠습니까? 이와 같은 버튼은 ContentDialog, TeachingTip, InfoBar 및 다음 항목을 아는 사람과 같은 여러 컨트롤에 적용됩니다. 우리는 현재 제어에 대해서만 생각하여 계속 디자인합니다. 나쁜 아키텍처입니다!

메시지 또는 팁 텍스트의 경우 하나는 Subtitle 이고 다른 하나는 Message 입니다. 기본적으로 이들은 동일할 수 있습니다. 다른 프로젝트 관리자가 이러한 컨트롤에 대해 작업하는 것 외에 다른 용어가 사용되는 이유는 무엇입니까?

전반적으로 컨트롤이 같은 방식으로 작동하면 개발자에게 도움이 되지 않을까요? 물론 이죠! 이 모든 것의 밑에 동일한 통제가 있을 것이라는 것을 의미합니까? 반드시 그런 것은 아니지만 동일한 속성 이름, 동일한 작업 버튼 개념 및 동일한 유형을 사용해야 합니다. 나는 여전히 우리가 모든 것을 하나로 묶는 데 사용되는 메시지 구조나 인터페이스를 가질 수 있기를 바라고 있습니다. 이러한 모든 속성을 수동으로 설정하는 대신 MessageBar에 메시지를 설정하고 표시되도록 하는 것이 좋지 않을까요?

InfoCard가 비교 문서에 설명된 팝업이 아닌 경우 InfoBar와 InfoCard의 차이점은 무엇입니까?

비교의 최종 결론은 MessageBar/MessageCard가 동일한 컨트롤이어야 하며 스타일 사용자 지정을 통해 인라인 힌트 또는 팁 예제의 사용 사례도 지원해야 한다는 것입니다.

• MessageBar/MessageCard와 Tip을 하나의 컨트롤로 통합하는 것이 가능합니다. 유일한 관심사는 '메시지'와 '팁'의 개념적 차이입니다.
• 동일한 기본 컨트롤이어야 하지만 두 경우 모두를 지원하려면 스타일 지정을 고도로 사용자 지정할 수 있어야 합니다. 유일한 관심사는 '메시지'와 '팁'의 개념적 차이입니다. 디자인은 매우 유사합니다.

편집: 전반적으로 내 근본적인 관심사는 우리가 어떻게든 건축적 사고에서 거꾸로 갔다는 것입니다. 컨트롤 디자인은 이제 Windows Forms 시절처럼 수행됩니다. 새 UWP 컨트롤은 WPF 개념을 기반으로 해야 합니다. 컨트롤은 고도로 전문화되고 있으며 WPF를 처음 접한 개발자를 정말 '놀라운' 프레임워크에 걸쳐 있는 통합 스레드를 볼 수 없습니다. 내 의견으로는 '큰 그림' 사고방식으로 돌아가야 합니다.

비슷한 것들에 대한 속성 이름과 열거형 이름이 기존 컨트롤과 (가능한 한 멀리) 정렬되어야 한다는 @robloo 의 의견에 100% 동의합니다. 유사한 컨트롤은 유사한 API 표면을 가져야 합니다. MessageCard 클래스가 나중에 추가되어야 한다면(개인적으로 선호하는 MessageBar를 확장하는 대신) 최소한 MessageBar와 매우 유사한 API를 가져야 합니다.

IMO에서 공통 개념이 훨씬 더 유용한 다른 영역이 있습니다. Button, AppBarButton, MenuItem을 생각해 보십시오. 이 모두는 텍스트와 아이콘을 표시하며 모두 작업을 트리거하는 데 사용됩니다. 종종 MenuItem(ContextMenu)과 AppBar/CommandBar에서 동일한 명령을 제공합니다. 여기에 명령, 텍스트, 아이콘, 긴 메시지(도구 설명)를 넣을 수 있는 일반적인 개념이 매우 유용합니다.

@lukasf XamlUICommand 클래스를 알고 있습니까? 이를 통해 이러한 속성을 한 곳에서 묶은 다음 정의된 XamlUICommand를 이러한 컨트롤의 Command API에 전달하여 Button/MenuItem/....에 할당할 수 있습니다.

@Felix-Dev 네 맞습니다. 나는 그것에 대해 거의 잊어 버렸습니다. 지난 번 시도했을 때 WinUI에서 사용할 수 없었기 때문에 사용하지 않고 있지만 전체 솔루션이 아니기 때문에 사용하지 않습니다. AppBar 및 ContextMenu에는 명령 링크 이상의 기능이 있습니다. 완전한 솔루션을 위해서는 다음이 필요합니다.

• XamlUI명령
• XamlToggleUI명령
• XamlUICommandSubItem(하위 메뉴/플라이아웃)
• XamlUICommandSeparator

또한 "Visible" 속성 및/또는 "HideIfDisabled" 속성이 누락되었습니다.

그런 다음 MenuFlyout 및 AppBar/CommandBar 및 유사한 컨트롤에 대한 ItemsSource가 필요합니다. 그런 다음 최상위 컨트롤은 각 명령 항목에 해당하는 하위 컨트롤을 만듭니다.

이 모든 것이 준비되었을 때만 우리는 앱에 하나의 명령 모음을 가질 수 있었고 이를 MenuBar, ContextMenu, AppBar, NavigationView에 바인딩할 수 있었습니다. 그러나 지금과 같이 사용자 정의 클래스 목록을 유지하고 DataTemplateSelectors 및 기타 성가신 해결 방법과 같은 항목을 수동으로 구현 및 사용하여 다른 위치에서 동일한 명령 정의가 작동하도록 해야 합니다.

XamlUICommand는 좋은 시작이었지만 완전한 이야기는 아닙니다.

답변이 늦어진 점 사과드립니다. @roblo 귀하의 관점과 몇 주 전 비교표를 공유해 주셔서 감사합니다. WinUI를 개선하기 위한 모든 생각과 고려 사항에 진심으로 감사드립니다! 😊

InfoBar와 플랫폼 전체에서 제 생각에는 디자인하는 동안 정의된 UI 패턴으로 특정 시나리오를 위해 특별히 설계된 컨트롤에 대한 올바른 균형을 찾기 위해 노력하고 있다는 것입니다. 아직 확인되었습니다. 팀의 새로운 사람으로서 WinUI 컨트롤이 WPF 개념으로 돌아가야 하는 이유를 듣고 싶습니다. 유사한 개념적 컨트롤의 기본 구조가 동일하지 않을 때 귀하와 다른 UWP 개발자가 직면하는 일상적인 문제는 무엇입니까? 우리가 이 구조를 만드는 데 리소스를 투입해야 하는 이유를 더 잘 이해할 수 있도록 어떤 이점이 있습니까? 통합의 이점을 얻을 수 있는 WinUI의 다른 컨트롤이 있습니까(위의 @lukasf에서 버튼 대화 참조). 미래의 통제. @SavoySchuler 는 여기에 입력하십시오.

InfoBar의 경우 이 대화에서 미리 보기로 이동하므로 변경 사항을 아직 예측할 수 없습니다. 특히 Action Button 및 Close Button API의 경우 충족되지 않는 특정 요구 사항이 있는 경우 잠재적인 변경 사항을 평가할 수 있도록 알려주시기 바랍니다. InfoCard 컨트롤과 관련된 v2 또는 이전에 가져온 가변 레이아웃 '자동' 기능 @mdtauk 을 활성화하기 위한 별도의 DisplayMode로 공통 AppMessage 기본 클래스 또는 인터페이스가 구현될 것으로 예상할 수 있습니다. 또한 WinUI 팀은 현재로서는 교육 팁과 정보 표시줄을 추가로 정렬하는 것의 가치를 아직 알지 못하지만, 사용 요구 사항이 충족되지 않는 경우 이 문제를 해결하기 위해 여기에서 대화를 계속할 수 있습니다. InfoBar가 미리 보기로 전환되고 응용 프로그램에서 구현될 수 있으면 공식 릴리스 전에 특정 시나리오 또는 사용 피드백을 듣는 것이 좋습니다.

일반적으로 InfoBar의 의도와 일치하는 시나리오가 있고 해당 기능이나 시각적 디자인의 측면에서 요구 사항을 충족하지 못하는 경우 미리 보기에 들어갈 때 알려주십시오. 모든 의견과 대화에 다시 한 번 감사드립니다!

InfoBar와 플랫폼 전체에서 제 생각에는 디자인하는 동안 정의된 UI 패턴으로 특정 시나리오를 위해 특별히 설계된 컨트롤에 대한 올바른 균형을 찾기 위해 노력하고 있다는 것입니다. 아직 확인되었습니다. 팀의 새로운 사람으로서 WinUI 컨트롤이 WPF 개념으로 돌아가야 하는 이유를 듣고 싶습니다. 유사한 개념적 컨트롤의 기본 구조가 동일하지 않을 때 귀하와 다른 UWP 개발자가 직면하는 일상적인 문제는 무엇입니까? 우리가 이 구조를 만드는 데 리소스를 투입해야 하는 이유를 더 잘 이해할 수 있도록 어떤 이점이 있습니까? 통합의 이점을 얻을 수 있는 WinUI의 다른 컨트롤이 있습니까(위의 @lukasf에서 버튼 대화 참조). 미래의 통제. @SavoySchuler 는 여기에 입력하십시오.

구조를 갖는 요점은 프로그래머가 고품질 코드를 갖기 위해 더 적은 오류로 더 빠르게 코딩할 수 있도록 하는 것입니다.

Microsoft의 대부분은 고립된 팀이기 때문에 많은 경우에 여러 가지 방법으로 작업을 수행할 수 있지만 해당 절차를 통합하지 않아 중복이 발생하고 이미 수정된 문제를 수정하려고 합니다.

WPF가 만들어진 후 Microsoft는 "충분히 좋은 마음가짐"에 빠졌습니다. 이는 Microsoft 자체 팀에서도 앱 품질로 직접 표현됩니다. Microsoft의 자체 받은 편지함 앱이 코드 및 앱의 일관성에서 고품질의 균일한 일관성으로 동일한 페이지에 도달할 수 없는 경우 타사 파트너가 이러한 기능을 제공하기를 어떻게 기대합니까?

일반적이지만 사용자 정의 가능한 코드를 제공하면 일반적인 기준 앱이 생성됩니다. 대부분의 개발자는 앱이 기능적이고 세련되게 보이도록 추가 노력을 기울이지 않고 앱이 제대로 작동하도록 할 만큼만 할 것입니다. 이 수준의 "작동할 수 있도록 충분히 수행"은 최종 사용자가 "절반 평가"로 선택합니다.

제 생각에 컨트롤의 핵심은 바로 사용할 수 있는 고품질 코드를 갖고 원하는 경우 사용자 정의할 수 있다는 것입니다.

개발자에게 컨트롤을 사용하는 방법에 대한 옵션을 제공하는 것은 메시징 및 알림을 관리하는 단일 방법으로 제한하는 대신 긍정적인 효과도 있습니다.

그러나 어떤 옵션을 선택하든 친숙한 방식으로 모양과 동작을 하고 Fluent Design에 "속한다"는 것은 일관성이라는 이점이 있습니다.

따라서 WinUI의 컨트롤 자체가 통합 접근 방식을 제공하지 않는 경우 Windows Toolkit은 이를 관리하는 도우미 API를 만들 수 있습니다.

해당 리포지토리에서 제안하고 WinUI 컨트롤을 사용하여 앱에 표시할 수 있습니다.

안녕하세요 여러분, 업데이트로 InfoBar 컨트롤이 이제 미리보기로 제공됩니다 🎉 이 컨트롤의 이점을 얻을 수 있는 응용 프로그램이 있으면 사용해 보고 피드백을 공유해 주세요.
https://github.com/microsoft/microsoft-ui-xaml/releases/tag/v2.5.0-prerelease.201027002
지금까지 이 제어에 참여해 주셔서 감사합니다!

다음은 정보 표시줄/상자/카드의 또 다른 예입니다.

편집: https://github.com/microsoft/microsoft-ui-xaml/issues/3581에서 아래 문제가 이미 수정되었음을 깨달았습니다. 아래 문제는 무시하십시오. 제어해주셔서 감사합니다! 나이팅게일에서 멋지게 보입니다 :)

@gabbybilka 나이팅게일 REST 클라이언트 앱에서 정보 표시줄을 사용할 것입니다. 내 시나리오 중 하나에 완벽합니다. 내 빠른 테스트에서 정보 표시줄의 아이콘이 밝은 테마를 지원하지 않는 것처럼 보입니까? 또는 컨트롤의 XAML 사용에서 잘못된 작업을 수행하고 있을 수 있습니다. 다음은 몇 가지 스크린샷입니다.

컨트롤에 "열림" 이벤트를 추가하시겠습니까? 어떤 경우에는 몇 초 후에 InfoBar를 자동으로 닫는 것이 적절합니다. "열림" 이벤트 핸들러는 타이머를 시작하기에 적합한 위치입니다.

Dark Theme에서 Success 색상을 변경해야 한다고 생각합니다. @YuliKl @anawisnoff @chigy @teaP
현재 어두운 테마 색상은 #393D1B 입니다. 이는 황록색으로 보이며 거의 올리브색입니다. 밝은 테마는 녹색과 같은 민트에 가까운 선명한 녹색을 사용합니다.

_현재 색상 상단, 제안된 변경 사항 하단_

#1d3d1b

심미적 가치 때문이 아니라 올리브색이 가미된 막대가 경고색과 잘 구분되지 않기 때문입니다.

다음은 어떻게 보일지입니다.