@sapallie , не могли бы вы сделать макеты дизайна общедоступными? Если они не должны быть разделены на данный момент.

В настоящее время занимаюсь разработкой XAML, и мне бы хотелось увидеть что-то подобное. Или что-то вроде красивого элемента управления прокруткой сообщений.

С точки зрения фирменного стиля Microsoft стандартизированный баннер с ошибкой может привести к ужасным ошибкам. Я бы боялся, что конечные пользователи будут ассоциировать каждую ошибку приложения с брендом Microsoft. Я только что прочитал предложение, и первое, что пришло мне в голову, это мемлорды, твитящие о кричащем знамени смерти.

@sapallie , не могли бы вы сделать макеты дизайна общедоступными? Если они не должны быть разделены на данный момент.

Извините, @adrientetar , я пока не могу ими поделиться. Проекты Microsoft только на данный момент.

@sapallie , спасибо за эту феноменальную идею! Я руководитель программы для WinUI, и я рад представить это команде!

Я хотел немного написать о нашем процессе, чтобы вы могли быть в курсе того, как мы будем двигаться дальше. Начиная с этого момента, я буду работать над уточнением общего объема/требований этого предложения и обоснованием разработки. Затем я представлю его остальной команде WinUI, и мы обсудим, согласуется ли он с нашей дорожной картой (#717) и сможем ли мы действовать в соответствии с ним относительно скоро. Если это так, я буду одобрен, чтобы выяснить детали и начать писать спецификацию, чтобы функция была готова для разработчика.

Вот несколько вещей, которые я уже знаю, мне нужно получить немного больше идей для...

• Визуальное поведение

Ваше предложение для от края до баннера? Или плитка уведомлений, аналогичная тому, что делают уведомления Windows, но в окне приложения, например, в центре, вдоль нижнего края или в углу?

Извините, @adrientetar , я пока не могу ими поделиться. Проекты Microsoft только на данный момент.

Я не думаю, что смогу получить одобрение этого предложения, не имея возможности включить общедоступное визуальное изображение запроса, поскольку репозиторий _is_ с открытым исходным кодом, а закрытый исходный код визуальной стороны разговора запутал бы процесс и опыт для нашего сообщества. . Основываясь на ответах на вышеизложенное, я с удовольствием попробую составить макет предложения. Вы бы предпочли это, или у вас есть предполагаемые сроки предоставления вашего разрешения на публикацию вашего дизайна? Мне нравится ваш макет, и я бы хотел, чтобы они были включены в наш мозговой штурм здесь, чтобы мы без необходимости не увели обсуждение в противоположном направлении от вашего намерения. Пожалуйста, дайте мне знать! :краснеть:

Баннер информирует пользователей об ошибках, которые мешают им использовать приложение/функцию.

Баннер будет закрыт для некритических ошибок

Правильно ли я понимаю, что эти утверждения означают, что вам также нужно иметь возможность неотклоняемого баннера для критических ошибок? Если да, не могли бы вы рассказать мне больше о вашем конкретном сценарии приложения для его получения/исходя из точки наличия неотключаемого баннера? Должны ли пользователи закрыть приложение, если проблема не будет решена? Или здесь будут кнопки, скажем, для перехода на страницу настроек сети и Интернета?

Еще раз спасибо, и я с нетерпением жду доработки этой идеи!

Все, пожалуйста, не стесняйтесь поделиться своими потребностями, проектами и точками зрения в этом разговоре! :краснеть:

Я хотел бы сказать, что есть несколько предложений, которые все просят об одном и том же. Вместо того, чтобы делать это конкретно баннером ошибки, почему бы просто не добавить уведомление в приложении из набора инструментов сообщества. Может быть добавлено свойство значка, которое будет отображать значок ошибки или значок подтверждения и т. д.

@SavoySchuler - рад тебя слышать. Я попытался ответить на все ваши вопросы, но, пожалуйста, дайте мне знать, если вам нужно что-то еще.

Визуальное поведение:
В идеале баннер должен быть похож на плитку уведомлений Windows и прикрепляться либо к верхней, либо к нижней части окна приложения. Место его закрепления зависит от других визуальных элементов в приложении и от того, где находится фокус. Это решение должен принимать проектировщик.
Я думаю, что GIF, опубликованный @mdtauk , был бы отличной отправной точкой.

Отклонение:
Я думаю, что имеет смысл углубиться в то, что я имею в виду под критическими и некритическими ошибками:

• Критические ошибки = функциональность приложения нарушена из-за общесистемной проблемы (например, потери подключения к Интернету) — они должны ссылаться на системные настройки, где пользователь может решить проблему.
• Некритические ошибки = некоторые функции нарушены или одна функция не работает, но пользователи могут выполнять другие действия в приложении.
• Также было бы здорово представить чисто информационную итерацию баннера, который можно использовать, чтобы информировать пользователей о доступных обновлениях приложения или новых функциях.

И я думаю, что все они должны быть отклонены (я также обновил это в описании предложения)

Примеры визуальных эффектов
Я внес несколько изменений в визуальные эффекты и могу поделиться ими следующим образом:

Эти примеры представляют собой итерацию, в которой весь баннер представляет собой большую кнопку. Пользователи могут отклонить его или щелкнуть по нему, чтобы перейти к системным настройкам (критическая ошибка), открыть веб-страницу с подробной информацией об исправлениях функций (предупреждение 1), перезагрузить страницу приложения (предупреждение 2) или перейти в магазин Microsoft, чтобы обновить приложение (информационное).
Можно было бы расширить эту концепцию, добавив несколько кнопок внутри баннера.

Мне очень нравятся эти визуальные эффекты для баннера. Я бы переместил текст и значок вверх на 4 пикселя, чтобы они располагались в центре белой области, а не на белой и цветной полосе.

Согласованный. Опубликованные визуальные эффекты выглядят довольно красиво.

Мне очень нравятся эти визуальные эффекты для баннера. Я бы переместил текст и значок вверх на 4 пикселя, чтобы они располагались в центре белой области, а не на белой и цветной полосе.

Я не считал пиксели, но похоже, что они расположены по центру, если учесть пространство для диакритических знаков над высотой X.

@sapallie Думали ли вы о том, чтобы позволить этим элементам управления автоматически или программно отключаться?

Если появляется запрос о том, что вы находитесь/выходите из сети, имеет смысл программно удалить такой запрос, когда он снова будет в сети. (Я видел, что приложения этого не делают, и это может привести к путанице.)

Точно так же отсутствие отображения несущественных сообщений на неопределенный срок может помочь избежать ненужного беспорядка в пользовательском интерфейсе и может помешать опытным пользователям выходить из потока после того, как они прочитают сообщение, не заставляя их вручную закрывать уведомление.

Я понимаю, что есть потенциальные дополнительные соображения доступности вокруг такого элемента управления и такого поведения, но я считаю, что эти способы отклонения элемента управления необходимы.

Я думаю, важно отметить, что такой элемент управления не предназначен для общего обмена сообщениями в приложении. Если это действительно не желаемый вариант использования.

Следует ли разрешить приложению отображать несколько баннеров одновременно?
Если да, то как они будут устроены? И это то, что приложение может контролировать?

Это удовлетворит тех, кто просил стиль Android Toast в управлении уведомлениями приложений, а также может быть полезен для сценариев проверки, чтобы отображать текст ошибки, когда пространство в форме ограничено.

Я бы также назвал это чем-то вроде StatusTip или StatusNotification , чтобы оно не ассоциировалось только с негативным использованием.

Я предполагаю, что дизайн будет адаптироваться, изменив положение сплошной цветной полосы, когда она находится в нижней части окна?

Вероятно, он должен иметь свойство тайм-аута и даже иметь возможность отображать ожидающее сообщение, например, кольцо прогресса и некоторый текст, например «Вход в систему сейчас», прежде чем переключиться на подтверждение сообщения об ошибке.

Мне очень нравятся эти визуальные эффекты для баннера. Я бы переместил текст и значок вверх на 4 пикселя, чтобы они располагались в центре белой области, а не на белой и цветной полосе.

Я не считал пиксели, но похоже, что они расположены по центру, если учесть пространство для диакритических знаков над высотой X.

Я думаю, что более вероятно, что текст был вертикально центрирован в поле без учета цветной полосы

Вот как расположение цветной полосы может меняться в зависимости от положения элемента управления.

@mrlacey да, программное/автоматическое удаление, когда баннер больше не актуален, очень важно — я добавил это в описание предложения.

Изменения статуса и ошибки: Вот для чего нужно использовать баннеры. Не общий обмен сообщениями — я согласен с этим.

И я думаю, что несколько баннеров должны работать. Они должны быть просто сложены.

@mdtauk Я переименовал его в «Баннер статуса» — спасибо за ваши предложения.

Что касается состояния загрузки — я не думаю, что это должно происходить в баннере. Загружаемый контент должен отображаться в приложении, где этот контент должен появиться на самом деле.

А когда дело доходит до изменения расположения цветной полосы — было бы здорово иметь гибкость в зависимости от того, где в окне приложения находится баннер с ошибкой. 👍

Выпуски № 622 и № 792 также могли бы быть охвачены этим контролем, если бы он был построен.

@sapallie Ваше замечание об обстоятельствах критических ошибок интересно в связи с предлагаемым руководством, согласно которому баннеры состояния указывают пользователю на решение. Моя интуиция подсказывает, что вам также может понадобиться API для отключения или, по крайней мере, временное увольнение?

Я понимаю, что есть потенциальные дополнительные соображения доступности вокруг такого элемента управления и такого поведения, но я считаю, что эти способы отклонения элемента управления необходимы.

@mrlacey , отличный отзыв! К счастью, я проработал значительную часть этого во время рассмотрения автоматического закрытия по времени в TeachingTip, и хотя некоторые партнерские отношения с командами, у которых были бы собственные настройки специальных возможностей, были бы необходимы, я не думаю, что эта функция будет заблокирована из-за проблем с доступностью. +1 по всем остальным пунктам!

Может ли быть возможность добавить ссылку HyperlinkButton на решение или на ярлык настроек, например «Сеть»?

Может ли быть возможность добавить ссылку HyperlinkButton на решение или на ярлык настроек, например «Сеть»?

Я предполагал подтекст, содержащий гиперссылку на страницу приложения или приложения настроек (см. код галереи TeachingTip Xaml Control). Вы думали о чем-то более стандартизированном @mdtauk?

Свойство содержимого @SavoySchuler вместо MessageText?

Ваше замечание об обстоятельствах критических ошибок интересно в связи с предлагаемым руководством, согласно которому баннеры состояния указывают пользователю на решение. Моя интуиция подсказывает, что вам также может понадобиться API для отключения или, по крайней мере, временное увольнение?

Да, возможно, я думаю… Определенно не помешает добавить. В конце концов, это добавляет гибкости и, вероятно, будет весьма полезно для некоторых случаев использования.

@mdtauk - Да, я определенно имею в виду свойство контента!

@sapallie

Ваше замечание об обстоятельствах критических ошибок интересно в связи с предлагаемым руководством, согласно которому баннеры состояния указывают пользователю на решение. Моя интуиция подсказывает, что вам также может понадобиться API для отключения или, по крайней мере, временное увольнение?

Да, возможно, я думаю… Определенно не помешает добавить. В конце концов, это добавляет гибкости и, вероятно, будет весьма полезно для некоторых случаев использования.

С одной стороны, у вас есть всплывающее окно, которое нельзя закрыть, закрывающее пользовательский интерфейс (и, возможно, вызывающее при этом собственную ошибку, основанную на сценарии), а с другой стороны, у вас есть предупреждение/критическая ошибка приложения, которая является непостоянной, что также делает мои паучьи чувства покалывают.

Возможно, вместо всплывающего окна в пользовательском интерфейсе + подсказка баннер в пользовательском интерфейсе + от края до края (аналогичный тому, который используется пакетом Office для уведомления об обновлениях — см. предоставлено постоянное пространство в вашем пользовательском интерфейсе?

@SavoySchuler Может быть поведение элемента управления, когда он помещает заголовок и содержимое в одну строку, если ширина элемента управления достаточно широка.

Мое предыдущее предложение с различными макетами позиционирования также будет работать, если элемент управления выдвигается за край другого элемента управления, а не только в пределах окна или панели.

Возможно, вместо всплывающего окна в пользовательском интерфейсе + подсказка баннер в пользовательском интерфейсе + от края до края (аналогичный тому, который используется пакетом Office для уведомления об обновлениях — см. предоставлено постоянное пространство в вашем пользовательском интерфейсе?

Да, это тоже работает. 👍

Кажется, что было бы идеально иметь как встроенные, так и наложенные параметры, поскольку, оглядываясь назад, Office Suite может полагаться на то, что все их приложения имеют ленту. @mdtauk Мне нравится ваше предложение, которое начинает намекать на то, как мы думаем о поведении появления / исчезновения.

@all , может ли кто-нибудь поделиться со мной конкретными сценариями в ваших реальных приложениях, где вы предполагаете использовать этот элемент управления? В частности, меня интересуют мысли о визуальном входе и взаимодействии с пользователем, необходимом для быстрого увольнения? Охватывают ли приведенные здесь требования основные функции, необходимые для этого элемента управления?

@SavoySchuler Что касается входа и выхода, он может скользить с края, но также может анимироваться как плавающее наложение, если разработчик выберет. Скольжение от правого края экрана на уровне ОС — от правого края окна приложения или от края элемента управления или элемента пользовательского интерфейса.

Есть кнопка закрытия для закрытия, но для сенсорных дисплеев также может сработать возможность сдвинуть ее в обратном направлении от того места, где она появилась. Для обеспечения согласованности это должно быть встроено в элемент управления.

Нажатие на элемент управления, вероятно, должно вызвать действие, указанное в тексте сообщения.
Исключением будет отображение хода выполнения действия, которое нельзя будет закрыть до тех пор, пока оно не истечет с ошибкой или не завершится успешно.

Анимированные примеры

Войти, обновить, выйти - ссылка на YouTube

Анимировать в — ссылка на YouTube

TeachingTip существует и является хорошим способом нацеливания на конкретный элемент управления или элемент пользовательского интерфейса, а также для выделения новой функции в приложении. Технически его можно использовать для тех же целей, что и этот StatusBanner, поэтому необходимо подумать о семантическом использовании каждого из них и определить, что делает каждый из них уникальным.

Ниже приведены мои личные мысли о разнице между баннером статуса и советом по обучению.

• Баннер статуса _я считаю_ следует поощрять за реальные статусы, требующие действия, и поэтому он должен вызывать одно действие при нажатии.

  • Совет по обучению будет представлять действия в виде кнопки или гиперссылки, обычно используемой для информации, которую можно легко отклонить.

• Когда состояние приложения или ОС изменяется, что необходимо для приложения, это должно вызывать отображение баннера состояния.

  • Совет по обучению не будет предоставлять важную информацию, и после закрытия он не будет отображаться снова, если не будет добавлено что-то новое для вызова.

• Баннер состояния должен либо сохраняться при отображении, если только он не закрывается кнопкой «Закрыть», либо, возможно, смахивать при касании. За исключением завершения сценария текущего прогресса или разрешения статуса ОС (сеть восстановлена).

  • Учебный совет, возможно, будет включать функцию тайм-аута, не будет отображаться случайным образом во время работы приложения, в основном отображается при запуске приложения или переходе на страницу/экран.

• Баннер состояния должен использоваться в оболочке ОС согласованным образом — может быть набор стандартных локализованных баннеров с содержимым, значками, цветами в виде перечисления.

• Может быть некоторая логика ОС для добавления баннеров состояния к окнам приложений.
  Например, когда приложение пытается получить доступ к сети, но оно недоступно, ОС может отображать стандартный баннер состояния в окне приложения, а не на экране, или оставляя это на усмотрение разработчиков.

  • Совет по обучению будет зависеть от приложения, без определенного стандартного контента, и его может включать только разработчик.

@mdtauk , фантастическая работа над видео! 🎉 Они очень помогают воплотить эти идеи в жизнь.

Необходимость постоянства — отличный момент, и я думаю, что функцию отклонения также можно смягчить с помощью рекомендаций, которые предлагают сделать уведомления о состоянии постоянно доступными в панели уведомлений, если они критичны, или _возможно_ повторно отображать их через неинвазивные интервалы, если проблемы сохраняются. Это не определенные утверждения, а просто соображения, которые следует учитывать, чтобы убедиться, что это решение является надлежащим образом всеобъемлющим в своем сценарном решении.

Необходимость отличать TeachingTip от этой функции очевидна, и я согласен с вашим мнением. Этот элемент управления будет служить определенной потребности, для решения которой TeachingTip не предназначен, хотя может быть возможность для некоторых общих функций или кода.

Есть ли какие-либо заинтересованные стороны, потребности которых не были бы удовлетворены чем-то вроде того, что @mdtauk поделился выше?

Кажется, существуют различия между баннерами состояния, смоделированными в OP, и полноразмерным уведомлением, которое видно в Office (изображения выше в предыдущих комментариях) или Visual Studio (как показано ниже).

Различия между ними означают, что мне интересно, должны ли они быть одним и тем же элементом управления или отдельными.

Вот краткий список свойств, которые понадобятся каждому. (например, имена не фиксированы, но предназначены для вывода значения)

Баннеры статуса

• _Значок_
• Текст сообщения
• Дополнительный текст (вторая строка)
• Тип (Критический, Предупреждение или Информация)
• Цвет
• Место нахождения
• Направление анимации
• Нажмите «Событие/команда».
• Тайм-аут

Полноэкранные уведомления

• _Иконка (возможно)_
• Текст сообщения
• Стиль ссылки (кнопка или гиперссылка)
• Ссылки (Текст и нажатие, событие/команда — несколько)
• Тайм-аут

В обоих случаях существуют только свойства, выделенные жирным шрифтом . _Icon_ потенциально сбивает с толку, поскольку для каждого типа необходимы разные типы значков (в круге или в контуре).
Также должно быть свойство, указывающее, какой стиль использовать.

Мне кажется, что для одного элемента управления слишком большая разница, и объединение всех этих функций было бы запутанным и сложным.
Я думаю, что эти два понятия:

• закрывающийся полноразмерный баннер с нулевым или более подэлементами действия
• баннер, предназначенный для индикации изменений статуса и работающий как одна кнопка

будет обеспечивать наибольшую ценность и наименьшую путаницу в качестве отдельных элементов управления.

Как анимированные баннеры статуса будут поддерживать отображение нескольких уведомлений одновременно?
Или это уже не в тему?

• Баннер состояния должен использоваться в оболочке ОС согласованным образом — может быть набор стандартных локализованных баннеров с содержимым, значками, цветами в виде перечисления.
• Может быть некоторая логика ОС для добавления баннеров состояния к окнам приложений.
  Например, когда приложение пытается получить доступ к сети, но оно недоступно, ОС может отображать стандартный баннер состояния в окне приложения, а не на экране, или оставляя это на усмотрение разработчиков.

Этот уровень интеграции с ОС демонстрирует амбициозность, выходящую за рамки единого элемента управления и WinUI.

Будут ли «стандартные локализованные баннеры» всем, что доступно, или они будут в дополнение к возможности иметь что-то полностью настраиваемое?
Если некоторые из них будут предоставлены по умолчанию, какими они будут?
Я был бы обеспокоен тем, что только предоставление ограниченного набора опций будет излишне ограничивать потенциал такого контроля.

То, что ОС показывает баннеры в открытом приложении для общесистемных сценариев, таких как потеря сетевого подключения, вызывает у меня ряд проблем.

• Центр уведомлений уже предоставляет способ отправки общесистемных уведомлений.
• Когда открыто несколько окон, отображение баннеров в каждом из них кажется излишне навязчивым.
• Я ожидаю, что разработчики захотят контролировать или отключать отображение системных уведомлений (баннеров) в приложении.
• Если приложению требуется сетевое подключение только изредка, сообщение о потере подключения может сбить с толку или отвлечь пользователя, если оно не имеет отношения к тому, что он делает в данный момент.
• Это привязывает приложения к определенным версиям ОС для получения обновлений или желаемого поведения. Будущие изменения в функциях ОС могут нарушить работу или изменить приложение нежелательным образом.
• Обновления и исправления ошибок будут доступны только по расписанию выпуска на уровне ОС. Одна из причин существования WinUI состоит в том, чтобы разорвать эту связь с функциональностью ОС и приложений.

• Одной из целей описанного здесь элемента управления является упрощение реализации разработчиками. Удаление их возможности контролировать это вызовет проблемы для приложений, в которых определенные сценарии должны обрабатываться нестандартными способами.

Только что нашел этот выпуск из поста в Твиттере об анимированных макетах. Кажется, что большая часть работы, которую мы проделали с элементом управления InAppNotification в наборе инструментов, перекрывается. Включая такие вещи, как обработка нескольких сообщений.

Мы узнали, что, хотя это выглядит как простой элемент управления, это довольно сложно. Было бы неплохо иметь целостное решение, которое можно было бы встроить в WinUI, чтобы покрыть все эти случаи. Затем мы можем отказаться от управления набором инструментов.

Совещаюсь с @ryandemopoulos , и я хочу немного реорганизовать этот первоначальный разговор, чтобы сосредоточиться на проблеме (необходимость пользовательского интерфейса с ошибками) до решения (какой-либо конкретной части/частей пользовательского интерфейса с ошибками).

С этой целью моя первая цель — заблокировать сценарии и требования для ошибок пользовательского интерфейса ( @sapallie , ваш сценарий «Критический: потеря подключения к Wi-Fi» — идеальное начало). Оттуда мы можем работать вместе, чтобы решить, включает ли решение один элемент пользовательского интерфейса для уведомлений об ошибках или набор компонентов пользовательского интерфейса для ошибок. Исходя из этого, мы расширим разбивку @mrlacey на сходство API (спасибо, что начали это), чтобы решить, достаточно ли общности для подхода деривации по сравнению с отдельными элементами управления, если есть несколько выходов этого разговора. Я не хочу забегать вперед, но аргумент @mrlacey в пользу различных решений _is_ уже выглядит четким, и это нормально. Я сосредоточен на создании правильного набора элементов решения для всех присутствующих здесь.

Итак, для всех ( @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk и @mrlacey), которым особенно важен этот элемент управления, не могли бы вы предоставить мне следующее здесь или в dm @ saschule @microsoft.com :

• Название приложения
• Описание сценария (ошибка, критическая/некритическая и описание того, как вы хотели бы ее представить)
• Снимок экрана приложения, на котором может появиться ошибка (если доступно)

Я обновил Issue, чтобы отразить этот ориентированный на проблему подход, и я каталогизировал требования, сценарии и возможности решения, описанные до сих пор.

@sapallie Я старался быть вежливым, насколько мог, сохраняя вашу первоначальную работу. Историю версий можно просмотреть в раскрывающемся списке «отредактировано…» в верхней части выпуска. Пожалуйста, дайте мне знать, если я что-то не правильно зафиксировал.

Я представил это команде WinUI, и мы считаем, что определенная здесь функциональность будет способна обслуживать не только сообщения об ошибках, но и долгоживущие сообщения о состоянии всего приложения в целом. Сюда входят сообщения о состоянии «доступно обновление» и «резервное копирование завершено» в дополнение к сценариям, связанным с ошибками.

Я обновил проблему, чтобы отразить этот более целостный подход. Я надеюсь завершить работу над требованиями и сценариями в ближайшие недели, чтобы мы могли изучить необходимые части вывода пользовательского интерфейса для отображения этих сообщений.

Я перефразирую свой запрос выше. @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk и @mrlacey для сообщений о состоянии/ошибках, которые вы хотите отображать в своих приложениях, не могли бы вы предоставить мне следующее здесь или по адресу [email protected] :

• Название приложения
• Описание сценария (сообщение о состоянии, критическое/некритическое и описание того, как вы хотели бы его представить)
• Снимок экрана приложения, на котором может появиться ошибка (если доступно)

Стоит отметить, что, по возможности, следует избегать всплывающих диалогов. В Интернете повсюду полно всплывающих подсказок, и они прерывают поток, пытаясь привлечь ваше внимание. Например, я думаю, что пустой статус ( пример ) должен быть предпочтительным, например, если что-то не может быть загружено в элемент управления.

Что касается визуальных эффектов, опубликованных @mdtauk , действительно ли нам нужны всплывающие окна, отображаемые со всех четырех краев экрана/приложения? Смысл WinUI должен заключаться в стандартизации положения и внешнего вида таких элементов, чтобы все приложения использовали одно и то же, и в этом отношении Android Snackbar является очевидным эталоном. Еще одна вещь, которую следует отметить в Snackbar, это то, что она не отображает ошибки ярко-красным цветом или что-то в этом роде, она имеет трезвый вид, который, я думаю, снова полезен, поскольку не слишком отвлекает пользователя от того, что он делает.

Нам также понадобится руководство о том, когда использовать это всплывающее окно, например, вместо диалогового окна, иначе оно просто создаст фрагментацию (разные приложения используют элементы управления обменом сообщениями по-разному).

Всплывающие окна имеют концепцию размещения, этот элемент управления может делать то же самое. Появляется от внутреннего края элемента управления контейнера, будь то содержимое страницы или вкладки и т. д.

@adrientetar Не все приложения одинаковы, поэтому, хотя для этого элемента управления будет значение по умолчанию, у разработчиков должен быть способ изменить это местоположение без необходимости повторного шаблона или повторной разработки элемента управления.

Office использует пространство под лентой. Edge использует нижнюю часть экрана. Только сама Windows сможет прикрепить его к краям оболочки или экрана, и, вероятно, есть веская причина не позволять приложениям имитировать предупреждения системного уровня.

Кроме того, любой разработчик может изменить стиль своих собственных элементов управления оповещениями, поэтому на данном этапе он должен быть максимально гибким, и тогда команда Shell будет иметь право голоса в отношении ограничений, влияющих на использование элемента управления.

У команды «Ваш телефон» есть один из таких элементов управления, так что, может быть, вы могли бы спросить их, с какими проблемами они столкнулись, и убедить их перейти к использованию элемента управления WinUI, когда он будет готов и включен?

Dropbox также использует Snackbar в своей системе дизайна (прокрутите вниз, от предпоследнего ряда изображений).

Недавно заметил еще пару примеров долгоживущих сообщений о статусе для всего приложения:

(сообщение "запись началась" в Teams)

("пытается подключиться к игровому координатору" в Dota 2)

Извините, они маленькие - первая фотография была сделана с моего рабочего стола с ультрашироким монитором. :)

Некоторые закусочные Dropbox содержат индикатор выполнения внизу. Это должно быть включено сюда? Это может иметь смысл, например, для таких вещей, как загрузка, загрузка, обновление, синхронизация. Это не обязательно, но, может быть, может или должно?

Должны ли они быть округлены? Или нет?

Да, я думаю, что ключевое отличие здесь от «Совета по обучению» заключается в том, что приложения хотят координировать свое пространство для обмена сообщениями и могут отображать несколько обновлений ошибок/статуса одновременно (или последовательно).

Я думаю, что в идеале это один элемент управления, который разработчик настраивает и размещает в своем приложении, а затем также передает сообщения (которые, как я полагаю, имеют какой-то тип для обозначения, если это ошибка, статус, предупреждение или какое-то другое общее сообщение).

Как в случае с баннером, так и во всплывающем окне я видел приложения, которые могут иметь несколько сообщений. Иногда они складывают баннеры, которые затем доминируют над пользовательским интерфейсом, поэтому было бы неплохо, если бы это решение избегало этого (хотя ничто не помешает разработчику использовать несколько экземпляров элемента управления для воссоздания этого поведения).

Я удивлен, что мы также не вызвали VS Code, так как у них есть свои всплывающие панели уведомлений в нижнем правом углу, которые также имеют дополнительные кнопки действий (например, для перехода к настройкам).

Скриншот примера кода VS:

У них есть различные типы значков, которые появляются в верхнем левом углу, настраиваемые действия кнопок и возможность иметь значок «шестеренка» для настройки параметров уведомлений для каждого расширения в их случае.

Только что видел этот снимок экрана Cortana...

MessageBar Office UI Fabric выглядит великолепно, IMO:

я заметил, что Samsung Notes для Windows 10 использует всплывающие уведомления, чтобы объяснить, что заметка была удалена, потому что в ней ничего не было, что так раздражает

Всем привет! Я руководитель программы для WinUI и получаю это предложение от @SavoySchuler. В этой теме уже было много отличных дискуссий и идей, спасибо за все ваши предложения!

Поскольку прошло несколько месяцев с тех пор, как здесь не было никакой активности, я хотел проверить всех и повторить, где мы находимся в настоящее время.

В качестве краткого изложения нашего текущего объема в верхней части предложения:

• Уведомление будет предназначено для оповещения пользователя о важной информации, связанной с приложением в целом.
• Будет поддерживать пользовательский контент и стили
• Смогут быть автоматически и программно отклонены
• Уведомление должно иметь возможность быть отклоненным пользователем
• Должен поддерживать несколько уведомлений, которые могут быть сложены в соответствии с тем, как указано приложением.
• Должен реагировать на изменение размера приложения и изменения пользовательского интерфейса.
• Уведомление не будет предназначено для отображения общесистемных уведомлений.

Пожалуйста, не стесняйтесь комментировать и дайте мне знать, если я что-то пропустил в своем резюме или если вы не согласны. Я хочу убедиться, что мы все на одной волне, прежде чем двигаться дальше 😊

Теперь, когда мы определили область действия, осталось определить несколько конкретных сценариев и взаимодействия с пользователем. Я надеюсь, что определение этих возможностей поможет определить возможности пользовательского интерфейса для управления. Что вы думаете о своих сценариях?
Копия: @sapallie , @adrientetar , @EverydayApps @Felix-Dev, @mdtauk , @mrlacey

Опыт:

• Как уведомление покидает представление
  
  
  
  • Пользователь вручную закрывает уведомление
  
  
  • Уведомление автоматически отключается и отключается
  
  
  • Уведомление исчезает только после того, как пользователь совершит действие, связанное с тем, почему уведомление появилось в первую очередь.
    
    
    
    
    
    • т.е. после получения уведомления об отключении интернета уведомление исчезает только при отключении интернета
    
    
    
  
  
  • Другой?
  
  
• Как пользователь отреагирует на уведомление
  
  
  
  • Немедленно принять меры, связанные с уведомлением
  
  
  • Отложить их действие, связанное с уведомлением, на более позднее время
  
  
  • Игнорировать и/или полностью отклонить уведомление
  
  
  • Другой?
  
  
• Когда появится уведомление
  
  
  
  • При запуске приложения
  
  
  • Программно из статуса приложения
  
  
  • После того, как пользователь совершит действие (например, решит сделать резервную копию своих документов)
  
  
  • Другой?
  
  
• Возможно ли одновременное отображение нескольких уведомлений и почему

Еще раз спасибо за все ваши мысли, и я с нетерпением жду возможности пролить свет на это!

Рад видеть, что это предложение не было забыто @gabbybilka, и спасибо, что приняли его!

Если это вообще возможно, вы можете связаться с теми, кто работает над сторонними приложениями, которые включают такие пользовательские интерфейсы уведомлений, чтобы составить список требований, чтобы они могли перейти от своего пользовательского решения к собственному элементу управления WinUI. Их потребности в сочетании с желаниями и потребностями сообщества должны покрывать достаточно для V1 этого контроля.

@chigy будет тем, с кем можно поговорить об окончательных спецификациях дизайна, поскольку она работает с командами Fluent Design.

Корпорация Майкрософт должна подавать пример с этим, если другие должны поощряться к использованию согласованного элемента управления WinUI.

• Кортана
• Грув Музыка
• Кино и ТВ
• Ваш телефон

Это приложения, которые приходят на ум.

@gabbybilka у нас также есть контроль в Windows Community Toolkit , так что мы рады поговорить об этом с вами в любое время. Было бы здорово иметь здесь путь обновления для наших пользователей и перенести его с Toolkit на WinUI.

Я думаю, что из вашего первоначального резюме, которое охватывает большинство вещей, но, может быть, было бы неплохо отметить что-то, связанное с наличием дополнительных кнопок с действиями? Или это всегда будет просто пользовательский контент?

Последующие действия из набора инструментов с некоторой историей управления из набора инструментов (прошло некоторое время):

• Оригинальный выпуск
• Первый PR-обзор
• История GitHub — не знаю, как получить полный список на одной странице, поэтому прокрутите вниз и продолжайте нажимать «Старые».

Стили в наборе инструментов созданы по образцу исходных стилей уведомлений Microsoft Edge и VS Code (которые с тех пор были обновлены). Но, как показано, он является гибким и поддерживает повторный шаблон и будет работать как для строки состояния верхнего уровня с предупреждением в стиле Office, так и для общего уведомления в стиле всплывающего окна.

И снова здравствуйте! В качестве обновления по этому поводу я недавно повторно представил это предложение команде и получил разрешение на дальнейшее определение этой функции.

Для сценариев, описанных ранее, мы собираемся продвинуться вперед и создать элемент управления, который в настоящее время называется InformationBar (для краткости InfoBar), чтобы представлять долгоживущие важные сообщения о состоянии для всего приложения. Первоначальный образ визуального дизайна вдохновлен панелью сообщений FluentUI и тем, как Teams отображает свои сообщения «Идет запись» и «Интернет отключен».
В частности, включая значок, заголовок, настраиваемую область сообщений и кнопку закрытия в качестве основных, минимальных, визуальных компонентов в контейнере, который по умолчанию соответствует ширине области содержимого, в которой он находится. Как и ранее, информационная панель будет закрываться с помощью пользователем или программно, когда функциональные возможности приложения, влияющие на статус, разрешаются, т. е. подключение к Интернету восстанавливается без анимации входа/выхода.

Команды (сейчас запись)

Офис (режим совместимости)

Команды (без интернета)

Когда API начнет кристаллизоваться, я перейду к обсуждению спецификации. А пока , пожалуйста, продолжайте делиться своими сценариями, где бы вы использовали InfoBar и какие функции вам нужны 😊

Ранее в ходе обсуждения @mrlacey и другие упомянули о возможности иметь два отдельных элемента управления, которые могли бы охватывать упомянутые сценарии.

Я думаю, что эти два понятия:

• закрывающийся полноразмерный баннер с нулевым или более подэлементами действия
• баннер, предназначенный для индикации изменений статуса и работающий как одна кнопка

будет обеспечивать наибольшую ценность и наименьшую путаницу в качестве отдельных элементов управления.

Я понимаю, что визуальный стиль и компоненты InfoBar могут не подходить для некоторых вариантов использования, о которых сообщалось ранее. Если для конкретных сценариев и функций вашего приложения требуется другой визуальный стиль, не стесняйтесь продолжать делиться этими ситуациями в этой теме.

Еще раз всем спасибо!

Элемент управления должен быть спроектирован так, чтобы хорошо работать с шаблонами и стилями, чтобы его можно было формировать в соответствии с потребностями, в то время как все варианты поведения являются свойствами элемента управления.
Анимировать или не анимировать.
Показать кнопку закрытия или скрыть ее.
Позиция.
Показать значок или нет.

так далее

Я понимаю, что визуальный стиль и компоненты InfoBar могут не подходить для некоторых вариантов использования, о которых сообщалось ранее. Если для конкретных сценариев и функций вашего приложения требуется другой визуальный стиль, не стесняйтесь продолжать делиться этими ситуациями в этой теме.

Еще раз всем спасибо!

Это здорово, это идет вперед. Этот визуальный стиль, как показано, оставляет желать лучшего, и я бы не хотел использовать приложение.

Дизайн, опубликованный @mdtauk , или скриншоты Cortana выше были бы намного предпочтительнее. Дизайн приложений должен идти вперед, а не сдерживаться программами.

Будет ли/может ли это действовать как закрываемая панель CommandBar, как те, которые используются во время презентации/общего доступа к рабочему столу? Например

Я знаю, что он не будет поддерживать наложение поверх всего, но с точки зрения фиксации его ширины и помещения его в слой наложения приложения я мог видеть сходство в дизайне/функциональности в этом направлении.

@mdtauk

Элемент управления должен быть спроектирован так, чтобы хорошо работать с шаблонами и стилями, чтобы его можно было формировать в соответствии с потребностями, в то время как все варианты поведения являются свойствами элемента управления.
Анимировать или не анимировать.
Показать кнопку закрытия или скрыть ее.
Позиция.
Показать значок или нет.

@shaheedmalik

Это здорово, это идет вперед. Этот визуальный стиль, как показано, оставляет желать лучшего, и я бы не хотел использовать приложение.

Дизайн, опубликованный @mdtauk , или скриншоты Cortana выше были бы намного предпочтительнее. Дизайн приложений должен идти вперед, а не сдерживаться программами.

Спасибо за ваш отзыв! Я согласен с тем, что элемент управления должен быть достаточно гибким для этого базового поведения и настраиваемости в системе Fluent Design. Визуальные эффекты, которыми я поделился, в основном были ссылками на ранее реализованные примеры.
Мы продолжим попытки найти баланс между перегрузкой одного элемента управления слишком большим количеством функций и обеспечением его настраиваемости и достаточной полезности для различных долгоживущих сценариев сообщений о состоянии всего приложения.

Будет ли/может ли это действовать как закрываемая панель CommandBar, как те, которые используются во время презентации/общего доступа к рабочему столу? Например

@Майкл Хоукер

Я думаю, что это интересный сценарий, который еще не поднимался в теме, и потенциально может поддерживаться этим элементом управления. Спасибо, что обратили на это наше внимание! Что касается охвата, это кажется сценарием с более низким приоритетом, но я согласен с тем, что дизайн/функциональность аналогичны за пределами приоритизации наложения.

Есть ли обновления по этому вопросу? В настоящее время мы планируем пользовательский интерфейс для отображения состояния операций с файлами в Files UWP, дизайн, к которому мы склоняемся, может выиграть от такой функции, предлагаемой здесь.

Привет @yaichenbaum , спасибо, что заглянули! В качестве обновления этого предложения я рад поделиться спецификацией , которую мы начинаем составлять.

Подводя итог тому, что было определено до сих пор, мы решили создать единый элемент управления с двумя визуальными режимами: «Панель» и «Тост» или «Карточка». Наши текущие усилия направлены на определение и создание прототипа режима «Bar». Компоненты этих двух режимов одинаковы и планируется различаться только визуальной компоновкой. Поскольку будет несколько визуальных режимов, в настоящее время я считаю, что этот элемент управления StatusBanner вместо InformationBar не ограничивается одним стилем «Bar», однако не стесняйтесь делиться своими идеями для именования 😊

Основные компоненты StatusBanner слева направо в макете:

• Цвет состояния
• Значок
• Заголовок
• Сообщение
• Кнопка действия
• Кнопка закрытия

Эти свойства являются необязательными, а настраиваемый контент через свойство «Содержимое» по-прежнему доступен.

Кроме того, мы планируем определить различные типы баннеров, которые может установить разработчик, которые имеют предустановленные комбинации значков и цветов в зависимости от статуса. Это может упростить выбор правильного значка или цвета баннера в зависимости от важности уведомления и обеспечить некоторую согласованность между приложениями. Также поддерживается настройка Icon или BannerColor.

Бумажный прототип StatusBanner в режиме «Bar» без кнопки действия или пользовательской кнопки закрытия.

Текущий дизайн макетов панели StatusBanner был в значительной степени вдохновлен дизайном карты статуса @mdtauk , спасибо!

Если вы хотите поделиться отзывом о текущем состоянии спецификации, не стесняйтесь оставлять комментарии в этом выпуске. Наши следующие шаги — укрепить дизайн и фрагменты кода (и расширить, чтобы охватить больше вариантов использования) и определить функциональные возможности, такие как стекирование и упаковка сообщений. Спасибо всем!

@yaichenbaum тем временем есть элемент управления Toolkit InAppNotification .

@gabbybilka Спасибо за обновление, важная функция, которая мне понадобится для моего варианта использования, — это возможность отображать несколько сообщений о состоянии одновременно, точно так же, как @hawkerm поделился ранее в этой ветке. Наличие элемента управления для размещения нескольких сообщений о состоянии будет плюсом.

@yaichenbaum тем временем есть элемент управления Toolkit InAppNotification .

@hawkerm Я мало смотрел на InAppNotification , но я бы предпочел дождаться версии WinUI, а не переключаться на новый элемент управления, когда он будет готов.

Всем привет!
Приносим извинения за нехватку времени между последним обновлением и сейчас, мы усердно работали над определением этого элемента управления 😊
Возможно, вы видели слияние прототипа @chenss3 в репозитории несколько недель назад, мы очень рады видеть, что это воплотилось в жизнь! На данном этапе мы заинтересованы в том, чтобы связаться с любыми потребителями этого элемента управления, которые были бы заинтересованы в создании прототипа и использовании его в своих приложениях. Пожалуйста, свяжитесь с нами и расскажите, какое приложение вы разрабатываете, сценарии использования этого элемента управления, если вам нужна помощь в начале работы, и ваши отзывы об использовании прототипа.

Поскольку мы начали выяснять детали реализации всплывающей версии этого элемента управления с поддержкой позиционирования и группирования нескольких уведомлений, мы решили продолжить работу над встроенной версией в ближайшем будущем . Мы слышим ваши отзывы о необходимости использования всплывающих окон для некоторых ваших сценариев и будем продолжать двигаться в этом направлении! Тем временем мы разрабатываем нашу следующую версию прототипа, которая больше похожа на макеты ниже.

Пожалуйста, ознакомьтесь со спецификацией , если вы хотите увидеть еще несколько примеров:

Спасибо всем, и я с нетерпением жду ответа от вас!

Доступно ли это только в WinUI 3 или в предварительной версии WinUI 2?

Предварительный выпуск @kmgallahan WinUI 2, пока не совсем уверен в точной версии поставки, поскольку мы хотим получить немного больше отзывов от сообщества и клиентов о прототипе и предварительных версиях.

Чтобы максимизировать раннюю обратную связь, я бы рекомендовал максимально упростить опробование подобных прототипов. Может быть, втолкнуть их в предварительные сборки с отказом от ответственности или предоставить выпуски для разработчиков / бета-версий.

Необходимость создать ветку разработки WinUI для опробования прототипов доставляет немало хлопот, особенно если вы в основном являетесь потребителем WinUI, а не участником (в любом случае, в кодовой базе).

Согласен, как только прототип будет в твердом состоянии (похожим на показанные макеты и с поддержкой различных параметров ввода), мы хотели бы поместить его в предварительную версию 2.5. Смогли бы вы/заинтересованы попробовать это в то время?

Мне интересно попробовать это прямо сейчас, я просто предпочитаю использовать NuGet, а не добавлять в свою сборку массивный проект, такой как WinUI.

А пока я подожду того, что попадет в превью.

И снова здравствуйте! Несколько обновлений:

• Спецификация продолжает пересматриваться и дорабатываться. Пожалуйста, не стесняйтесь проверить это в этом PR и оставить комментарии. Заметным изменением является добавление универсального свойства ActionButton, которое будет принимать ваш собственный контент, наследуемый от ButtonBase.

  • Несоответствие в текущих макетах, на которое я хотел бы указать, — это расположение этой кнопки ActionButton. В спецификации кнопка действия в настоящее время показана выровненной по правому краю непосредственно слева от кнопки закрытия, однако фактическое местоположение будет непосредственно справа от сообщения. Изображение, показанное в моем предыдущем комментарии и ниже, является правильным местоположением. Улучшенные макеты будут обновляться и добавляться в спецификацию по мере продолжения разработки 😊

• @teaP приступила к реализации собственной версии этого элемента управления по мере продвижения к предварительному выпуску WinUI 2.5 . Спасибо!

Как и прежде, если вы считаете себя потенциальным пользователем этого элемента управления, не стесняйтесь комментировать разрабатываемое вами приложение и сценарии, в которых вы будете использовать информационную панель. Спасибо всем!

И снова здравствуйте! Просто чтобы подчеркнуть, @teaP недавно открыл запрос на включение # 3325 для InfoBar, если вы хотите проверить это 😊

Почему это называется InfoBar? Информация — это только один небольшой класс информации, который он может содержать. Он также поддерживает ошибки и предупреждения, а также действия на их основе. Бар также искусственно ограничивает «форму» элемента управления. Помимо бара, у него есть несколько других вариантов использования.

На мой взгляд, NotificationView или MessageView и т. д. были бы лучшими именами.

Почему это называется InfoBar? Информация — это только один небольшой класс информации, который он может содержать. Он также поддерживает ошибки и предупреждения, а также действия на их основе. Бар также искусственно ограничивает «форму» элемента управления. Помимо бара, у него есть несколько других вариантов использования.

На мой взгляд, NotificationView или MessageView и т. д. были бы лучшими именами.

Первоначально он был предложен как StatusBanner
Затем он был изменен на InformationBar / InfoBar

Версия FluentUI этого элемента управления называется MessageBar .

Спасибо за резюме. Имя по-прежнему не имеет для меня особого смысла. Текущий элемент управления выполнен в виде уведомления. В более общем смысле это должно быть «сообщение», чтобы оно также могло поддерживать сценарии помощи/обучения. Обобщая различные концепции, вот лучший дизайн элементов управления:

1. ~ MessageView ~ или Tip : элемент управления для отображения состояния, подсказки или обучающей информации для пользователя с необязательным действием, заголовком, глифом, изображением и кнопками. Это может быть размещено где угодно и не является всплывающим окном. Он также будет поддерживать различные макеты.

2. TeachingTip : всплывающее/всплывающее окно с MessageView.

   • Размещенный совет

3. NotificationBar или StatusTip : уведомление всего приложения в формате «полосы» в верхней части приложения или представления.

   • Размещенный совет

4. Подсказка : теперь можно будет разместить подсказку, которая будет поддерживать действия, изображения и т. д.

   • Размещенный совет

Нам действительно нужно мыслить в общих чертах и ​​объединять концепции высокого уровня в одни и те же элементы управления. В противном случае мы создадим множество очень специализированных элементов управления с похожими, но разными свойствами.

Мысль об идеальном имени для общего элемента управления «MessageView»: назовите его «Tip». ToolTip также может разместить его. Обновлено соответственно.

Вот еще один «реальный» пример панели уведомлений в верхней части некоторых полей ввода. Текущий элемент управления был бы полезен для этого сценария:

Вот еще один «реальный» пример панели уведомлений в верхней части некоторых полей ввода. Текущий элемент управления был бы полезен для этого сценария:

Текстовые поля будут получать состояния проверки, которые могут охватывать некоторые из них, но вот как я рассматриваю различные элементы управления...

• Подсказка для одного элемента, который пользователь активно хочет идентифицировать;
• TeachingTip для отдельного элемента, который разработчик хочет, чтобы пользователь заметил (также можно не привязывать к элементу);
• InfoBar для всей области приложения/контента, где разработчик хочет предоставить некоторую информацию;
• Всплывающее окно/диалоговое окно, когда разработчик хочет, чтобы пользователь подтвердил, что он что-то прочитал, прежде чем закрыть это;
• Диалог содержимого , когда разработчик требует от пользователя сделать выбор или выполнить действие, прежде всего;

Я бы также не стал использовать слово « Уведомление », так как для этих уведомлений есть уведомление уровня ОС и центр уведомлений.

Я бы также не стал использовать слово «Уведомление», так как для этих уведомлений есть уведомление уровня ОС и центр уведомлений.

Что ж, я думаю, разработчики поймут разницу, но это, безусловно, справедливое замечание.

Также верно, что мы можем сделать много отдельных элементов управления. Но, безусловно, есть некоторые концепции высокого уровня, связанные с уведомлением/статусом/сообщениями/подсказками/обучением, которые можно объединить вместе. Надо хотя бы сделать из всего этого интерфейс.

Диалоговые окна всплывающих окон/содержимого — это отдельные понятия, поскольку по большей части они являются общими элементами управления содержимым.

Я придумал идеальное имя для обобщенного элемента управления типа «представление сообщения» для размещения в различных сценариях: назовите его «Совет». Я соответственно обновил свой комментарий выше: https://github.com/microsoft/microsoft-ui-xaml/issues/913#issuecomment -700307412

Я придумал идеальное имя для обобщенного элемента управления типа «представление сообщения» для размещения в различных сценариях: назовите его «Совет». Я соответственно обновил свой комментарий выше: # 913 (комментарий)

Мне было бы неудобно помещать важное предупреждение или сообщение об ошибке в подсказку ...

Также верно, что мы можем сделать много отдельных элементов управления. Но, безусловно, есть некоторые концепции высокого уровня, связанные с уведомлением/статусом/сообщениями/подсказками/обучением, которые можно объединить вместе. Надо хотя бы сделать из всего этого интерфейс.

Диалоговые окна всплывающих окон/содержимого — это отдельные понятия, поскольку по большей части они являются общими элементами управления содержимым.

Мне очень нравится эта идея. Я думаю, что в API-интерфейсах значков, заголовков, сообщений и кнопок действий есть общие черты, которые могут быть одинаковыми для всех этих элементов управления информацией. С InfoBar я не уверен, что мы можем реализовать что-то в этой текущей версии, но потенциально для нашего следующего элемента управления такого рода.

Я придумал идеальное имя для обобщенного элемента управления типа «представление сообщения» для размещения в различных сценариях: назовите его «Совет». Я соответственно обновил свой комментарий выше: # 913 (комментарий)

Мне было бы неудобно помещать важное предупреждение или сообщение об ошибке в подсказку ...

Я также согласен с этим ... необходимо провести дополнительные исследования.

Я придумал идеальное имя для обобщенного элемента управления типа «представление сообщения» для размещения в различных сценариях: назовите его «Совет». Я соответственно обновил свой комментарий выше: # 913 (комментарий)

Мне было бы неудобно размещать важное предупреждение или сообщение об ошибке в подсказке...

Я также согласен с этим ... необходимо провести дополнительные исследования.

Подумайте, насколько хорошо он сочетается со всеми существующими элементами управления и идеями — в этом отношении он идеален. Но да, это кажется неуместным в контексте ошибок/предупреждений. Я думаю, что люди быстро это поймут, но я не могу спорить с этой логикой.

Почему это называется InfoBar? Информация — это только один небольшой класс информации, который он может содержать. Он также поддерживает ошибки и предупреждения, а также действия на их основе. Бар также искусственно ограничивает «форму» элемента управления. Помимо бара, у него есть несколько других вариантов использования.

На мой взгляд, NotificationView или MessageView и т. д. были бы лучшими именами.

Я согласен с вашей точкой зрения, что информационная панель не всегда может быть панелью, однако я думаю, что включение «бара» в название означает, что она предназначена для сценариев всего приложения как визуально, так и концептуально. При поиске изображений «информационной панели» вы найдете изображения, похожие на IE (не то, чтобы мы обязательно пытались соответствовать IE), и я думаю, что это связано с ожидаемым визуальным и функциональным макетом. Я не вижу это как «Просмотр», но мне нравится фокус на сообщении или уведомлении.

@gabbybilka Да, он очень похож на старый StatusBar или новый AppBar ... CommandBar ... и т. д. Проблема в том, что использование элемента управления должно быть довольно обобщенным, чтобы также отображать подсказки и сообщения в произвольных местах. «Вид» тоже не подходит на 100%, но ближе к общему названию. На самом деле я беспокоюсь об унификации базовых концепций, чтобы у нас не было нескольких элементов управления, выполняющих вариации одного и того же.

Отредактировано для того, чтобы сбить меня с толку несколькими комментариями в двух местах.

Вторя мыслям, которые я опубликовал в одном из других выпусков...

_Отвечая на тот факт, что плавающий режим управления больше не рассматривается для V2_
Я могу понять, что изменение в поведении и форме заставит вас обратиться к Совету по обучению в качестве альтернативы, но я бы предположил, что отсутствие серьезности, цвета статуса и дизайна самого совета по обучению несовместимо с тем же типом сообщения, которые обслуживает элемент управления InformationBar.

Ширина экрана и различия в макетах пользовательского интерфейса между полноэкранным приложением WinUI, окном с узкой шириной и такими вещами, как Hololens и Xbox, не подходят для форм-фактора состыкованной панели.

Имея это в виду, возможно, следует обернуть информационную панель вместе с элементом управления InformationCard в AppMessage API, чтобы те же свойства Severity, Color, Title, Message, Action Buttons и т. д. можно было поместить в XAML или в код приложения — и способ их представления на экране меняется в зависимости от форм-фактора/семейства устройств.

Неприкрепленный совет по обучению может заменить, но он не будет поддерживать те настройки, которые подходят для сообщений о состоянии приложения, что является первоначальным намерением этого элемента управления.

Так что, если бы у нас был «Совет», который на самом деле был бы просто сообщением. У него есть глиф, изображения, текст сообщения, заголовок.

Затем, исходя из Tip, у нас есть AppMessage, который добавляет серьезность, действия и прочее. Подсказка тогда по-прежнему будет использоваться в TeachingTip и ToolTip, как они существуют сегодня. это также было бы полезно в моем сценарии для встроенных контекстных подсказок.

Так что, если бы у нас был «Совет», который на самом деле был бы просто сообщением. У него есть глиф, изображения, текст сообщения, заголовок.

Затем, исходя из Tip, у нас есть AppMessage, который добавляет серьезность, действия и прочее. Подсказка тогда по-прежнему будет использоваться в TeachingTip и ToolTip, как они существуют сегодня. это также было бы полезно в моем сценарии для встроенных контекстных подсказок.

TeachingTip без хвоста кажется идеальным для вашей ситуации...

TeachingTip без хвоста кажется идеальным для вашей ситуации...

Не знал, что вы можете сделать это с TeachingTip. Кроме того, мой элемент управления существует намного дольше, чем TeachingTip, поэтому до сих пор я никогда не исследовал его обновление. В любом случае, если вы можете это сделать, это моя оплошность.

Редактировать: Неважно, даже без хвоста это все еще наложение, которое так или иначе отклоняется. «Подсказка», которую я описываю, является встроенной и сохраняется до тех пор, пока пользователь не создаст первый элемент. Это просто элемент управления, который представляет информацию, а не всплывающее окно, всплывающее окно или другое непостоянное представление.

Я все еще убежден, что есть много общего, чтобы разбить интерфейсы/элементы управления, используемые в нескольких местах. Все эти элементы управления, которые мы обсуждаем, имеют гораздо больше общего, чем различий. Меняется только то, где и как представлена ​​основная информация. Это все созрело для упрощения.

TeachingTip без хвоста кажется идеальным для вашей ситуации...

Не знал, что вы можете сделать это с TeachingTip. Кроме того, мой элемент управления существует намного дольше, чем TeachingTip, поэтому до сих пор я никогда не исследовал его обновление. В любом случае, если вы можете это сделать, это моя оплошность.

Я все еще убежден, что есть много общего, чтобы разбить интерфейсы/элементы управления, используемые в нескольких местах. Все эти элементы управления, которые мы обсуждаем, имеют гораздо больше общего, чем различий. Меняется только то, где и как представлена ​​основная информация. Это все созрело для упрощения.

Когда вы разбиваете его, это только значок и текст, и с ним не связан никакой «контекст». Но мое предложение обернуть его в AppMessage , я думаю, может включать неприкрепленные советы по обучению в качестве еще одной формы пользовательского интерфейса.

Когда вы разбиваете его, это только значок и текст, и с ним не связан никакой «контекст». Но мое предложение обернуть его в AppMessage, я думаю, может включать неприкрепленные советы по обучению в качестве еще одной формы пользовательского интерфейса.

Извините, смотрите мое редактирование выше. Совет по обучению по-прежнему не является встроенным и просто плавает внизу, пока не будет закрыт. Есть также изображение и заголовок, которые следует учитывать.

Когда вы разбиваете его, это только значок и текст, и с ним не связан никакой «контекст». Но мое предложение обернуть его в AppMessage, я думаю, может включать неприкрепленные советы по обучению в качестве еще одной формы пользовательского интерфейса.

Извините, смотрите мое редактирование выше. Совет по обучению по-прежнему не является встроенным и просто плавает внизу, пока не будет закрыт.

Не обязательно внизу.

Встроенный, возможно, необычный вариант использования подсказки, поскольку он вытеснит другой контент вокруг него.

Вы можете предположить, что в V2 добавлена ​​поддержка встроенного/не плавающего режима отображения.

Чтобы дать комментарий @mdtauk немного больше контекста, вот мой первоначальный ответ на его вопрос об удалении плавающего режима из раздела «Предполагаемые функции для InfoBar V2» в спецификации.
От меня:

Зашел сюда для обсуждения дизайна. Обратите внимание, что предполагаемые функции V2 изменились 😉 Прямо сейчас мы не используем плавающий режим для InfoBar в версии V2 по нескольким причинам. Я хотел бы дополнительно изучить, должен ли плавающий режим быть в InfoBar или всплывающие уведомления должны быть вообще другим элементом управления. В ходе исследования мы поняли, что базовая реализация плавающего режима будет невероятно похожа на «Совет по обучению», и что для полного изучения таких функций сценариев всплывающих уведомлений, как стекирование, позиционирование и выбор наложения (см. WCT InAppNotification’s StackMode ), вероятно, потребуется. Это расширило бы область действия и предназначение информационной панели, чтобы она стала намного шире, чем ее первоначальный фокус. Следует отметить, что мы не полностью закрыли дверь для добавления плавающих возможностей в InfoBar, но склоняемся к тому, чтобы этого не делать.

Для предложений InformationBar и InformationCard, основанных на базовом классе AppMessage, мне нравится эта идея. Вы упомянули, что «то, как они отображаются на экране, будет меняться в зависимости от форм-фактора/семейства устройств», что я хотел бы изучить глубже. Я думаю, что есть сценарии, которые лучше подходят для карточного UX (особенно временные сообщения, сообщения об ошибках для конкретных страниц и приложения без закрепляемых поверхностей), чем для барного UX и наоборот.

Для меня существуют как различия в том, «когда» использовать InfoBar/InfoCard/Teaching Tip (привязанные к визуальным и функциональным потребностям), так и в «почему» использовать (на основе восприятия и опыта конечного пользователя). Временные сообщения являются для меня четким акцентом как нечто, что должно поддерживаться InfoCard и не поддерживаться InfoBar. Сообщения, которые не могут быть отклонены пользователем, являются примером обратного, поскольку постоянный наложенный контент сложно поддерживать с точки зрения доступности.

Не отвлекайтесь, однако :) Все эти различные элементы управления представляют, по большей части, один и тот же тип информации - только в разных областях/стилях. Это должно быть обобщено и унифицировано. Я думаю, мы можем объединиться вокруг одного общего элемента управления «AppMessage», если вы хотите его так назвать. Затем просто используйте разные контейнеры для представления этого «AppMessage» по-разному. Он может быть представлен в TeachingTIp, ToolTip, NotificationBar, в виде карточки в каком-либо месте и т. д. Каждый контейнер может изменять стиль в соответствии со своим вариантом использования. Однако базовые свойства и типы будут унифицированы.

Я не пытался неправильно истолковать контекст ответа @gabbybilka 😄

Для предложений InformationBar и InformationCard, основанных на базовом классе AppMessage, мне нравится эта идея.

Вот тут-то и вступает в дело именование. Мне нравится «AppMessage» («Совет» был бы потрясающим, хотя, похоже, это был план с самого начала), но если мы пойдем с этим, это должен быть хостинг «MessageBar» и «MessageCard». Это.

Для меня существуют как различия в том, «когда» использовать InfoBar/InfoCard/Teaching Tip (привязанные к визуальным и функциональным потребностям), так и в «почему» использовать (на основе восприятия и опыта конечного пользователя).

Я определенно согласен с этими различными вариантами использования и презентациями. Тем не менее, они по-прежнему представляют сообщение, которое можно обобщить и стандартизировать. Я думаю, что мы все согласны с этой концепцией сейчас :)

Пример карточного сообщения/подсказки

Одна из целей, я думаю, должна состоять в том, чтобы побудить почтовые ящики и сторонние приложения/оболочку Windows отказаться от своих пользовательских решений и использовать согласованный элемент управления почтовыми ящиками/API.

Вероятно, мне следует добавить, что в приложении UWP, над которым я работаю, некоторые из этих концепций уже были унифицированы. Упрощенная версия, имеющая отношение к этому обсуждению:

Существует класс «Сообщение» (это не элемент управления, а только структура данных) со следующими свойствами:

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

Приоритет в основном такой же, как вы уже решили (сейчас он довольно стандартизирован). DisplayMode поддерживает Notification, None и Popup. Когда сообщение генерируется внутренним кодом, оно передается внешнему интерфейсу, который соответственно отображает его либо в виде быстрого уведомления на «панели» в верхней части приложения, которое нужно закрыть. Или как блокирующее всплывающее окно для более серьезных сообщений.

Кроме того, есть элемент управления «MessageView», который принимает сообщение само по себе, но добавляет глиф и заголовок и представляет его как встроенную контекстную «подсказку», о которой мы говорили ранее.

Это именно то, что я бы предложил: сделать абстракцию на уровне приложений. Имейте простой класс ViewModel, который вы можете прикрепить к любому представлению. Это просто сделать и более гибко. Возможно, вы также хотите вести журнал с предпочитаемой вами структурой журналирования, вы хотите иметь собственные приоритеты, хотите добавлять свои собственные данные. Все легко сделать в вашей ViewModel.

Упомянутые вами элементы управления предназначены для обеспечения унифицированного способа выполнения определенных сценариев для многих приложений и вариантов использования ОС вместо того, чтобы каждое приложение имело немного отличающийся пользовательский интерфейс и поведение. ToolTips и InfoBar/MessageBar — хорошо известные концепции как для разработчиков, так и для конечных пользователей. Хотя оба представляют информацию, они используются для совершенно разных целей. Я не вижу особой пользы в том, чтобы иметь для них общий базовый класс или общую концепцию. Почему вы хотите поместить сообщение во всплывающую подсказку, которая уже отображается на информационной панели глобального приложения (и куда вы прикрепите эту всплывающую подсказку)? Не похоже, что это привело бы к повторному использованию.

Имеются и другие области, в которых общие концепции были бы гораздо полезнее, ИМО. Подумайте о кнопке, AppBarButton, MenuItem. Все они отображают текст и значок, все они используются для запуска действия. Часто вы предоставляете одни и те же команды как в MenuItem (ContextMenu), так и в AppBar/CommandBar. Здесь очень бы пригодилась общая концепция, куда можно было бы поместить свою команду, текст, иконку, может быть и длинное сообщение (тултип). Но иметь общую концепцию для ToolTip и MessageBar? Я действительно не вижу в этом необходимости. Конечно, если бы мы переписали UWP с нуля, мы могли бы создать общий базовый класс. Но я не думаю, что это необходимо или слишком полезно.

@lukasf Ваши очки имеют смысл; это можно сделать в самом приложении. Тем не менее, существует много очень похожих концепций, и каждый может извлечь выгоду из унификации.

В обсуждение была включена всплывающая подсказка, потому что было бы полезно иметь глиф и заголовок вместе с сообщением. Концептуально все эти элементы управления также являются сообщениями в той или иной форме, только где и как они отображаются по-разному. Даже если мы не будем проводить большую стандартизацию, MessageBar и MessageCard все равно потребуют много общих свойств/типов. Мы не хотим иметь MessageBarPriority вместе с врагами MessageCardPriority. Все еще необходимо подумать, чтобы убедиться, что даже базовые типы рассчитаны на будущее.

Объединение всего этого с существующими идеями в Совете для преподавателей кажется мне логичным. Я уверен, что направление, в котором нужно двигаться, имело бы смысл при параллельном сравнении всех упомянутых элементов управления и их свойств. Если у меня будет время, я сам сравню.

Ваши комментарии о Button/AppBarButton/и т.д. являются прекрасным примером мышления, которое мы не хотим распространять. Microsoft привыкла делать несколько похожих, но разных элементов управления, не тратя время и усилия на то, чтобы сделать их связными. Такая долгосрочная перспектива не годится для фреймворка любого рода по ряду причин.

Я собрал сравнение средств управления обменом сообщениями. Я отдам это как бесплатную консультацию, так как это так грубо, как это :)

Я ожидаю, что это своего рода сравнительная и стратегическая документация высокого уровня, созданная внутри Microsoft. Если бы я сам руководил проверками спецификаций/дизайна, я бы потребовал такого анализа, иначе никто не может рассчитывать на одобрение. Абсолютно важно:

1. Устранение пробелов в понимании между членами команды
2. Преодолейте «бункеры», которые возникают в больших командах и организациях
3. обеспечить согласованное будущее направление фреймворка, чтобы будущие функциональные возможности могли быть добавлены поверх хорошей основы (самое важное)

Microsoft каким-то образом утратила эти общие принципы после WPF, и кажется, что у руководства в этой области больше нет «высокоуровневого» видения. В любом случае, я не причастен к внутренним обсуждениям, поэтому я надеюсь, что гораздо больше планирования происходит внутри с некоторыми людьми, которые имеют большой опыт и долгую историю принципов работы с XAML.

С учетом сказанного не стесняйтесь разорвать приведенный ниже документ. Сама дискуссия важнее всего.

MessageControlComparison 20200929.xlsx

Спасибо за сравнительный документ, очень здорово увидеть ваши мысли об элементах управления информацией в целом! Я хочу продолжить обсуждение двух основных тем: 1. Почему _не должны_ подсказка для преподавателя и информационная панель иметь разные API/свойства/функциональность? и 2. В чем была бы разница между InfoBar и InfoCard, если бы InfoCard не была всплывающим окном, как указано в сравнительном документе?

Что касается первого вопроса, я могу выделить дизайнерские решения, принятые для элементов с красным текстом, и внести немного ясности:

• TeachingTip Subtitle vs InfoBar Message: Функционально да, они одинаковы! Это вторичное сообщение с невыделенным жирным шрифтом текстом в этих элементах управления. В совете по обучению это сообщение всегда будет отображаться под заголовком и имеет смысл называться подзаголовком. Для InfoBar это сообщение чаще всего будет встроенным и непосредственно справа от заголовка, который концептуально не имеет такого смысла, как подзаголовок.
• TeachingTip HeroContent и InfoBar Content: TeachingTip имеет как HeroContent, так и Content, в то время как InfoBar имеет только Content. Свойство HeroContent является уникальным для Teaching Tip из-за поддержки этих больших изображений, помогающих в обучении. InfoBar не поддерживает явно изображения, поскольку ориентирован на горизонтальную компоновку. Свойство Content для обоих элементов управления предназначено для дополнительного пользовательского содержимого и находится ниже остальных элементов пользовательского интерфейса в обоих.
• Стратегия кнопки «Совет преподавателя» и стратегия кнопки «Информационная панель»: основные различия здесь заключаются в том, что панель «Информация» поддерживает больше типов кнопок, помимо классической «Кнопки», и не поощряет настройку кнопки закрытия для включения текста.
  
  
  
  • Обычный сценарий для информационных панелей — включить кнопку гиперссылки. Из-за цветового контраста с цветом переднего плана кнопки гиперссылки по умолчанию и нашими разноцветными цветами фона мы хотели убедиться, что можем применить собственный стиль к любым кнопкам гиперссылок, включенным в информационную панель, чтобы они оставались доступными.
  
  
  • Мы решили не включать настройку кнопки закрытия (для текста, все еще есть свойство CloseButtonStyle, позволяющее при желании выполнить некоторые облегченные стили) в информационную панель после проверки дизайна, чтобы убедиться, что основное внимание остается на включенном тексте и отдельном действии. Соответственно, как упоминалось в спецификации, мы думаем о том, чтобы ActionContentArea в версии 2 поддерживала более одной кнопки действия здесь, и мы могли бы изучить возможность повторной настройки кнопки закрытия там.
  
  
• Информационная панель IsClosable и IsIconVisible: подсказка по обучению не имеет IsClosable, поскольку подсказка по обучению всегда должна быть закрыта, поскольку это всплывающее окно, отображающее неблокирующую/срочную информацию. У него также нет IsIconVisible, поскольку значок не отображается со стилем по умолчанию, который InfoBar делает с помощью разных уровней серьезности. Мы хотели предоставить разработчику возможность удалить предоставленный значок, если они этого хотят. Мы попытались установить для IconSource значение null, что вызвало множество забавных ошибок и упростило его с помощью свойства IsIconVisible.

Есть ли в этом смысл? Я считаю, что у обоих элементов управления разные цели, и различия в функциональности отражают это. Я надеюсь, что эти объяснения и обоснование дизайна были полезны!

Редактировать на предмет проблем с форматированием и опечаток😊 x2

Я бы не стал выступать за гармонизацию между этими элементами управления напрямую, поскольку есть основания для того, чтобы эти элементы управления выполняли свои функции в своих собственных контекстах.

Однако создание In App Messaging API, который действует как унифицирующая структура, но может адаптироваться к форм-фактору, не требует изменений в элементах управления.

Есть вопросы, которые нужно обсудить и ответить на этот вид API:

• Должен / Как вы, как разработчик, можете указать, какой тип управления вызовом сообщения отображается на экране?
• Если тип элемента управления не указан, берет ли API заданные свойства и «выбирает» наиболее подходящие?
• Как бы вы передавали выбор поведения в базовые элементы управления?
• Какие форм-факторы будут переопределять в зависимости от пригодности платформы?

И, наверное, многое другое, о чем я не подумал, лол

Использование Xbox в качестве платформы
Методы ввода очень разные, как и размер экрана/масштабирование.

Информационные панели полной ширины должны учитывать выход за пределы экрана по краям, поэтому для этих приложений информационная карта может быть более подходящей.

Но как бы вы справились с увольнением?

Нет курсора для перемещения по кнопке закрытия, но хотите ли вы, чтобы карта взяла на себя входы контроллера? Это делает его модальным. Но тогда, если он наложен поверх контента, как вы выбираете его и фокусируете на нем?

Значит ли это, что он отображается встроенным и толкает содержимое вниз, но не на всю ширину?

Кроме того, у Xbox есть собственная система уведомлений, похожая на тост, поэтому будет ли этот API работать с ней? С ним можно работать или это только System?

1. Почему у подсказки для преподавателя и информационной панели не должны быть разные API/свойства/функциональность?

Целью всегда должно быть предоставление общих API для одних и тех же вещей. Все это обсуждение касается сообщений, с которыми сталкиваются пользователи в целом, и после того, как они были поняты, появилось несколько сходств. Бесспорно, что варианты использования TeachingTip и элемента управления типа MessageBar различны. По сути, один представляет сообщение, а другой — совет. Я не ставлю под сомнение общий выбор дизайна здесь. Тем не менее, с этими элементами управления НАМНОГО больше сходства, чем различий. Просто взгляните на дизайн: все они имеют иконку, заголовок, подзаголовок, контент, кнопку действия и кнопку закрытия (но вы назвали их по-разному, и у них другая поверхность API). Если вы не понимаете, почему это хорошая идея стандартизировать хотя бы имена и перечисления здесь, я больше ничего не могу сказать. Это просто что-то фундаментальное для хорошей архитектуры.

Для кнопок оба элемента управления поддерживают кнопку действия и кнопку закрытия. Но вы сделали это совершенно другими способами. Вы объяснили некоторые причины выше, но теперь у нас есть «уродливый» API для использования кнопок в подобных ситуациях. Почему бы нам не обобщить это сейчас, чтобы у нас было что-то хорошее на будущее? Кнопки, подобные этой, применяются к нескольким элементам управления: ContentDialog, TeachingTip, InfoBar и кто знает, что дальше. Мы продолжаем проектировать, думая только о текущем управлении - плохая архитектура!

Для текста сообщения или подсказки один называется Subtitle , а другой Message , по сути, они могут быть одинаковыми, почему используются разные термины, кроме того, что над этими элементами управления работают разные менеджеры проектов?

В целом, разве не было бы полезно для разработчиков, если бы элементы управления работали одинаково? Ну конечно; естественно! Означает ли это, что под всем этим будет такой же контроль? Не обязательно, но мы должны использовать одни и те же имена свойств, одни и те же концепции кнопок действий и одни и те же типы. Я все еще надеюсь, что мы могли бы использовать структуру сообщений или интерфейс, чтобы связать все вместе. Разве не было бы здорово просто установить сообщение в MessageBar и отобразить его вместо того, чтобы задавать все эти свойства вручную?

В чем была бы разница между InfoBar и InfoCard, если бы InfoCard не была всплывающим окном, как указано в сравнительном документе?

Мой конечный вывод из сравнения заключается в том, что MessageBar/MessageCard должны быть одним и тем же элементом управления, а также поддерживать вариант использования моего встроенного примера подсказки или подсказки посредством настройки стиля.

• Можно объединить MessageBar/MessageCard и Tip в один элемент управления. Единственное беспокойство вызывает концептуальная разница между «сообщением» и «подсказкой».
• Должен быть один и тот же базовый элемент управления, хотя стиль должен быть легко настраиваемым для поддержки обоих случаев. Единственное беспокойство вызывает концептуальная разница между «сообщением» и «подсказкой». Дизайн очень похож.

Редактировать: В целом, я думаю, что моя основная проблема заключается в том, что мы каким-то образом отступили в архитектурном мышлении. Дизайн элементов управления теперь выполнен так, как будто это было во времена Windows Forms. Новые элементы управления UWP должны основываться на концепциях WPF. Элементы управления становятся узкоспециализированными, и я не вижу объединяющих потоков, охватывающих фреймворк, которые действительно «поразили» разработчиков, впервые прикоснувшихся к WPF. По моему мнению, мы должны вернуться к менталитету «большой картины».

Я на 100% согласен с @robloo в том, что имена свойств и имена перечислений для подобных вещей должны быть согласованы (насколько это возможно) с существующими элементами управления. Подобные элементы управления должны иметь аналогичную поверхность API. Если класс MessageCard будет добавлен позже (вместо расширения MessageBar, что лично я бы предпочел), он должен иметь, по крайней мере, очень похожий API, как MessageBar.

Имеются и другие области, в которых общие концепции были бы гораздо полезнее, ИМО. Подумайте о кнопке, AppBarButton, MenuItem. Все они отображают текст и значок, все они используются для запуска действия. Часто вы предоставляете одни и те же команды как в MenuItem (ContextMenu), так и в AppBar/CommandBar. Здесь очень бы пригодилась общая концепция, куда можно было бы поместить свою команду, текст, иконку, может быть и длинное сообщение (тултип).

@lukasf Знаете ли вы о классе XamlUICommand ? Это позволяет вам объединять эти свойства в одном месте, а затем назначать их вашей кнопке/MenuItem/...., просто передавая определенную XamlUICommand в API Command этих элементов управления.

@ Felix-Dev Да, ты прав. Я почти забыл об этом. Я не использую его, так как он не был доступен в WinUI, когда я пробовал его в прошлый раз, а также потому, что это не полное решение. В AppBar и ContextMenu есть больше, чем просто командные ссылки. Для полного решения нам потребуется:

• Команда XamlUI
• XamlToggleUICommand
• XamlUICommandSubItem (подменю/выпадающее меню)
• XamlUICommandSeparator

Чего также не хватает, так это свойства «Видимый» и/или свойства «HideIfDisabled».

Тогда нам понадобится ItemsSource на MenuFlyout и AppBar/CommandBar и аналогичные элементы управления. Затем элемент управления верхнего уровня будет создавать соответствующие подчиненные элементы управления для каждого элемента команды.

Только когда все это было на месте, мы могли иметь один набор команд в нашем приложении и привязывать их к MenuBar, ContextMenu, AppBar, NavigationView. Но сейчас мне нужно вести список специально определенных классов, вручную реализовывать и использовать такие вещи, как DataTemplateSelectors и другие надоедливые обходные пути, просто чтобы одно и то же определение команды работало в разных местах.

XamlUICommand был хорошим началом, но это еще не все.

Приносим извинения за задержку с ответом здесь, @robloo , спасибо, что поделились своей точкой зрения и сравнительной таблицей, сделанной пару недель назад. Я очень ценю все мысли и соображения, направленные на улучшение WinUI! 😊

Я считаю, что в InfoBar и во всей платформе при проектировании мы стремимся найти правильный баланс для элементов управления, которые должны быть специально разработаны для конкретных сценариев в качестве определенного шаблона пользовательского интерфейса — при этом они должны быть общими и достаточно настраиваемыми, чтобы расширяться на сценарии, которые мы еще не использовали. все же идентифицированы. Как новичок в команде, я хотел бы услышать, почему элементы управления WinUI должны вернуться к концепциям WPF. С какими повседневными проблемами сталкиваетесь вы и другие разработчики UWP, когда аналогичные концептуальные элементы управления не имеют одинаковой базовой структуры? Какие преимущества есть для вас, чтобы мы могли лучше понять, почему мы должны выделять ресурсы на создание этой структуры? Существуют ли другие элементы управления в WinUI, которые выиграли бы от унификации (я вижу разговор о кнопках выше от @lukasf). Я думаю, что мы также можем продолжить этот разговор в новом общем выпуске, если есть область, где мы можем изменить существующие элементы управления/подходы мозгового штурма для будущие элементы управления. @SavoySchuler за любой вклад здесь.

Для InfoBar я все еще не предвижу каких-либо изменений, так как он переходит в предварительный просмотр из этого разговора. Для API кнопки действия и кнопки закрытия, в частности, если есть определенные потребности, которые не удовлетворены, сообщите нам об этом, чтобы мы могли оценить любые потенциальные изменения. Я мог ожидать, что общий базовый класс или интерфейс AppMessage будет реализован с v2 в сочетании с элементом управления InfoCard или в качестве отдельного DisplayMode, чтобы включить функциональность «Авто» переменной компоновки @mdtauk , упомянутую ранее. Кроме того, команда WinUI пока не видит смысла в дальнейшем согласовании подсказки для преподавателя и информационной панели, однако мы можем продолжить обсуждение здесь, чтобы решить эту проблему, если какие-либо потребности в использовании не выполняются. После того, как InfoBar перейдет в предварительную версию и сможет быть реализована в приложениях, любой конкретный сценарий или отзыв об использовании было бы здорово услышать до официального релиза.

Как правило, если у вас есть сценарии, которые соответствуют назначению информационной панели, и есть аспекты ее функциональности или визуального дизайна, которые не соответствуют вашим потребностям, сообщите нам об этом, когда мы перейдем к предварительному просмотру. Еще раз спасибо за все ваши комментарии и общение!

Я считаю, что в InfoBar и во всей платформе при проектировании мы стремимся найти правильный баланс для элементов управления, которые должны быть специально разработаны для конкретных сценариев в качестве определенного шаблона пользовательского интерфейса — при этом они должны быть общими и достаточно настраиваемыми, чтобы расширяться на сценарии, которые мы еще не использовали. все же идентифицированы. Как новичок в команде, я хотел бы услышать, почему элементы управления 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 Я собираюсь использовать информационную панель в своем клиентском приложении Nightingale REST. Это идеально подходит для одного из моих сценариев. В моем быстром тестировании значок в информационной панели не поддерживает светлую тему? Или, может быть, я делаю что-то неправильно при использовании элемента управления XAML. Вот несколько снимков экрана

Не могли бы вы добавить событие «Открыто» в элемент управления? В некоторых случаях целесообразно автоматически закрыть информационную панель через несколько секунд. Обработчик события Opened был бы правильным местом для запуска таймера.

Я думаю, что цвет успеха в темной теме следует изменить. @YuliKl @anawishnoff @chigy @teaP
Текущий цвет темной темы — #393D1B — желто-зеленый, почти оливковый. Тогда как в светлой теме используется более чистый зеленый, почти мятный, как зеленый.

_Выше текущих цветов, ниже предложенного изменения_

#1d3d1b

Это связано не только с эстетической ценностью, но и с тем, что полоса более оливкового цвета не так отличима от предупреждающего цвета.

Вот как это будет выглядеть