Стиль интерфейса Fluent Design в Windows 10 Spring Creators Update
Spring Creators Update продолжило процесс «переодевания» системного функционала Windows 10 в новый дизайн интерфейса Fluent Design. Этот процесс начался в Fall Creators Update – предыдущем, осеннем масштабном обновлении системы, и в ней обновлённой увидим улучшенный формат самого дизайна, а также его применение к новым системным областям. Что такое Fluent Design в концептуальном смысле, как он прогрессировал со времён предыдущего апдейта, и как его при необходимости отключить – обо всём этом ниже.
1. Что есть Fluent Design в концептуальном смысле?
Скудность внешнего оформления UWP-приложений «Десятки», по всей видимости, не оправдала планируемых доходов Microsoft от продажи сенсорных маломощных устройств, и компания решила «приодеть» современный функционал системы во что-то более стоящее. Таким стоящим решением стал впервые внедрённый в предыдущий апдейт системы стиль интерфейса Fluent Design.
Fluent Design – это:
• Уход от плоскости оформления Modern UI, сложная многослойная прорисовка элементов интерфейса;
• Более динамическое, более эффектное реагирование интерфейса на подведение пользователем курсора;
• Улучшенная адаптивность под разные размеры экранов.
Основной компонент Fluent Design – эффект акрила, применяемый к отдельным областям штатных приложений «Десятки». Это нечто новой инкарнации Aero Glass Windows 7 – стиль с такой же сутью придания внешнему виду приложений текстуры и свойств физического материала, но на этот раз не стекла, а акрила. Ну и, конечно же, в современном формате лёгкости и ненавязчивости дизайн-решений.
2. Fluent Design внутри Windows 10 Spring Creators Update
Эффект акрила в обновлённой «Десятке» стал более прозрачным, вместе с тем более примечательным. Примечательное акриловое одеяние получили штатные параметры, новые области Microsoft Edge, штатные карты. Панель часов и календаря стала отзывчиво, с эффектами свечения реагировать на подведение курсора – выделением области элементов вокруг него.
А при подведении курсора к определённой области кнопок калькулятора те услужливо прогибаются внутрь в ожидании нашего выбора. Сморится такой «бесконтактный массаж» потрясающе.
В тёмной теме оформления современного функционала «Десятки» эффект акрила чуть более прозрачный, сквозь него немного чётче просвечиваются фоновые объекты.
Напомним, в число штатного функционала, получившего Fluent Design первоочерёдно, с выпуском предыдущего апдейта вошли приложения «Скайп», «Калькулятор», «Фотографии», Paint 3D, «Кино и ТВ», «Запись голоса», «Музыка Groove», «Люди», «Будильник и часы», браузер Microsoft Edge.
3. Обратная сторона медали
Отрисовка эффекта акрила в окнах приложений требует аппаратных затрат. Дополнительная нагрузка ложится на процессор, а, соответственно, и на батарею портативных устройств. Лишние аппаратные затраты, вероятно, и являются причиной, почему акрил присутствует в интерфейсе приложений лишь частично – на боковых панелях, вверху окон, на всплывающих панелях. Даже в калькуляторе, окошко которого полностью покрыто эффектом акрила, а к кнопкам применена динамика реагирования, всё равно плоской и угрюмой остаётся область меню выбора режимов.
Fluent Design автоматически отключается при переходе ноутбуков и планшетов в режим экономии батареи. Но эффектный стиль интерфейса также можно отключить отдельно от режима экономии.
4. Как отключить Fluent Design
В настройках Windows 10 интерфейс Fluent Design как понятие нигде не встречается. В операционной системе фигурирует простой, понятный обывателю термин «эффекты прозрачности». Отключаются такие эффекты прозрачности в разделе параметров персонализации.
В параметрах Spring Creators Update отдельные настройки дисплея продублированы в разделе специальных возможностей, а к ним в довесок подобран ещё ряд опций по упрощению внешнего оформления Windows 10. Здесь также реализован тумблер отключения эффектов прозрачности. Плюс к этому, на совсем уж слабых устройствах дополнительно можем убрать анимацию и обои на рабочем столе.
Положение дел у Windows: сколько разношёрстных уровней UI в Windows 10?
Все мы слышали байку: если в Windows 10 копнуть достаточно глубоко, можно найти элементы, относящиеся еще ко временам Windows 3.x. Но так ли это на самом деле? В этой статье мы узнаем, сколько уровней пользовательского интерфейса присутствует в Windows и когда они были впервые представлены.
Для этого эксперимента я выбрал последнюю сборку Windows 10 Insider Preview билд 21301 (по состоянию на 6 февраля 2021 г.).
Итак, с места в карьер!
Уровень первый: Fluent Design
Начнем мы с новейшего и прекрасного Fluent Design. Анонсированный в 2017 году и представленный с обновлением Windows 10 1803 Fluent Design представляет собой серьезную переработку Modern Design Language 2 (MDL2), направленную на привнесение таких элементов, как свет, глубина, движение, материальность и масштаб. Также появился эффект подсвечивания и акриловый полупрозрачный фон.
На данный момент большинство встроенных UWP-приложений были обновлены с использованием элементов Fluent такие, как элементы вроде меню «Пуск», «Центра уведомлений» и экрана входа в систему.
Хотя Fluent Design получил высокие оценки, большинство энтузиастов сочли этот шаг слишком незначительным и запоздалым, поскольку новый стиль используется лишь в небольшой части системы.
Уровень 2: Metro
Если мы немного углубимся в ОС, то увидим элементы, которые не обновлялись со времен Windows 8/8.1.
Некоторые из них — явные недоработки, как всплывающее меню громкости, всплывающее меню USB, а также некоторые элементы на экране входа в систему.
Другими элементами Metro, хотя и не такими заметными, являются загрузочный экран (который скоро будет заменен на более новый) и WinRE.
Знаете ли вы, что впервые вращающиеся точки были представлены в Windows 8, билд 7989?
Так, ладно, перейдем к третьему уровню: к элементам Windows 8 Win32
Как и Windows 10, Windows 8 также страдала от проблем с целостностью (лучше или хуже). Однако в Windows 8 были внесены существенные улучшения в основные пользовательские элементы такие, как проводник Windows и диспетчер задач. Хотя в последующих обновлениях Windows 10 они получат некоторые качественные улучшения, изменения будут минимальными.
Кроме того, важным изменением с выходом Windows 8 стала переработка диалоговых окон передачи файлов.
Некоторые из этих изменений начались в Windows 7, что подводит нас к четвертому уровню: элементам пользовательского интерфейса Windows 7
Windows 7, без сомнения, — одна из самых любимых версий Windows всех времен, которую хвалят за большие улучшения по сравнению с Windows Vista. Она принесла много новых функций, которые, хотя и не были столь значительными как те, что предлагает Vista, сделали Windows 7 очень надежной ОС — настоящим преемником Windows XP. Однако, одним из самых печально известных изменений, привнесенных Windows 7, является ленточный интерфейс, пришедшим из Office 2007. Paint и Wordpad были первыми приложениями, которые его получили.
Хотя в какой-то момент Microsoft решила отказаться от классического Paint в пользу нового Paint 3D (представленного в Windows 10 Creators Update), после негативной реакции они отменили свое решение.
Другие функции, которые были обновлены в Windows 7 и с тех пор остались прежними: Windows Media Player 12, подключение к удаленному рабочему столу и некоторые диалоговые окна с файлами.
Теперь перейдем к 5-му уровню пользовательского интерфейса: Windows Vista
Релиз Windows Vista имел огромную важность, принесшим столь необходимую модернизацию платформы. Почти все основы ОС были так или иначе улучшены, от загрузчика до модели драйвера. Однако, как мы все уже знаем, Windows Vista станет одним из худших выпусков Windows за всю историю, с самого начала страдающего от проблем. Однако одной из немногих расхваленных функций был пользовательский интерфейс. В нем были переработаны некоторые основы, которые не обновлялись со времен Windows 95. Одним из главных способствующих факторов этого изменения было введение так называемых мастеров «Aero Wizards», пришедших на смену предыдущему стандарту мастеров, Wizard97.
Другие функции, которые были переработаны в Windows Vista, стали в основном все те же, что и в Windows 10: панель управления, программа поиска, факсы и сканирование Windows.
Кстати о Windows Vista: знали ли вы, что при определенных обстоятельствах Windows 10 возвращается к загрузочному экрану Vista? Это случается, когда ваша видеокарта не поддерживает режим видео, который используется на стандартном экране загрузки.
Теперь перейдем к 6-му уровню: Windows XP
Вы не поверите, но в Windows 10 встроено не так много элементов XP. Вероятно, это связано с тем, что большинство основ уже обновлены к Windows 2000. Однако Windows 10 содержит некоторые диалоговые окна файлов из XP, которые видны при установке драйвера.
Уровень 7: Windows 2000
Windows 2000 стала важной вехой в линейке операционных систем Microsoft NT. Это также была ступенька, которая ознаменовала начало перехода к новому унифицированному видению Windows. Однако Windows 2000 по-прежнему оставалась ОС, ориентированной на корпоративный сектор, а это значит, что она принесла много новых функций, разработанных для специалистов.
Консоль MMC стала одной из наиболее значительных дополнений, элементы которого с тех пор практически не изменились.
Еще одна функция, представленная по умолчанию в Windows 2000, — установщик Windows, который по-прежнему имеет все тот же значок, когда впервые был представлен!
Еще один элемент пользовательского интерфейса, который не изменился (кроме фирменного стиля, конечно), — это winver, дизайн которого был представлен в Windows 2000, билд 1946.
В то время, как Windows 2000 представила множество функций, предназначенных для опытных пользователей, Windows 95, вероятно, является самым знаковым релизом Windows на сегодняшний день. Он установил фундаментальные парадигмы, которые действуют и по сей день: меню «Пуск», контекстные меню, панель задач и корзину. Хотя эти функции, конечно, обновлялись в течение многих лет, некоторые из них остались почти такими же.
Теперь о восьмом уровне: элементы Windows 95/NT 4.0
Элемент, который в основном является пережитком старых компьютерных привычек, когда нужно было защищать свой драгоценный ЭЛТ-экран, — это настройки заставки.
Еще один поразительно похожий элемент — это поле «Выполнить».
Еще одним распространенным элементом пользовательского интерфейса, прошедшим проверку временем, является экран свойств папки.
А есть и множество других элементов пользовательского интерфейса, которые не менялись со времен Windows 95. Это ли не пример дизайна, над которым время не властно? Судите сами.
Уровень 9: Windows 3.1 и DOS. В общем-то…
Что ж, на самом деле это не «уровень пользовательского интерфейса», так как я не смог найти никаких элементов интерфейса, предшествующих Windows 95 (хотя у меня есть ощущение, что они, безусловно, есть). Однако в Windows 10 есть специфический файл moricons.dll, который содержит множество старых значков времен DOS. Сами поглядите:
Ну вот и все. Как вы, возможно, уже знаете, с выходом «Sun Valley» Microsoft планирует модернизировать пользовательский интерфейс Windows, целью которого является унификация дизайна ОС. Однако, как мы видим, Windows — это гигантская операционная система. Увенчаются ли успехом их усилия по созданию единого пользовательского интерфейса? Время покажет.
А для тех, кто хочет тонко настроить актуальные версии Windows 10: LTSC 1809, 20H1 (2004) и 20H2 (2009), можете скачать с GitHub мой PowerShell-модуль «Windows 10 Sophia Script».
Как мы делали приложение под Windows 10 с Fluent Design (UWP/C#)
Мы в ivi давно собирались обновить наше приложение под Windows 10 (которое для ПК и планшетов). Мы хотели сделать его эдаким «уютным» уголком для отдыха. И поэтому анонсированная недавно Microsoft-ом концепция fluent design пришлась нам очень кстати.
Но я не буду здесь рассказывать про стандартные компоненты, предлагаем Microsoft-ом для fluent design-а (Acrylic, Reveal, Connected-анимации и др.), хотя мы их, конечно, используем тоже. С ними всё просто и понятно — бери документацию и пользуйся.
Но приключения обычно начинаются тогда, когда ты уходишь с проторенной дорожки. Поэтому я лучше расскажу про то, как мы делали один кастомный контрол, который доставил нам много хлопот. Вот такой:
Идея в том, что мы используем depth и motion из fluent design system. Центральный элемент как бы слегка приподнимается надо всеми остальными. Это достигается за счёт анимации его размера и тени во время скролла.
Контрол FlipView сразу не подошёл, т.к. он не умеет показывать кусочки следующего и предыдущего элементов (мы их называем «ушами»). И мы начали поиски решения.
Путь 1. Пробуем использовать GridView
Логичным решением было попробовать использовать GridView. Чтобы выстроить элементы в горизонтальную строку задаём в качестве ItemsPanel задаём:
Чтобы центрировать текущий элемент используем свойства ScrollViewer-а в шаблоне GridView:
Пример такой реализации можно посмотреть, например, здесь.
Вроде всё ок, но есть проблемы.
GridView. Проблема 1. масштабирование контрола на всю ширину экрана
По задумке дизайнеров наш контрол должен тянуться на всю ширину окна. Само по себе это не проблема. Но при изменении размера контрола должны синхронно изменяться и размеры всех его дочерних элементов (Items):
Из коробки GridView такого не умеет. Решение мы подсмотрели в реализации контрола AdaptiveGridView из UWPToolkit:
Более подробно реализацию можно посмотреть в исходниках UWPToolkit.
Вроде всё ок, работает. Но…
GridView. Проблема 2. При изменении размера item-ов текущий элемент уходит из области видимости
Особенно сильно эффект заметен при максимизации окна (из-за резкого изменения размеров). И ещё при просто больших значениях HorizontalOffset.
Казалось бы можно было бы это проблему решить попросив GridView проскроллиться к нужному элементу:
Но это работает только при постепенном изменении размера окна. При максимизации окна это часто даёт неправильный результат. Скорее всего, причина в том, что новое рассчитанное нами значение HorizontalOffset оказывается слишком большим и выходит за границы ExtentWidth (ширины контента внутри ScrollViewer-а). А т.к. GridView использует UI-виртуализацию, то автоматически после изменения ширины Item-ов ExtentWidth может не пересчитываться.
В общем, адекватного решения этой проблемы найти не удалось.
На этом можно было бы остановиться и начать поиск следующего варианта решения. Но я опишу ещё одну проблему с этим подходом.
GridView. Проблема 3. Вложенные ScrollViewer-ы ломают горизонтальный скроллинг мышкой
Мы хотим, чтобы колёсико мышки всегда выполняло скроллинг по вертикали. Всегда. По вертикали.
Но если мы ставим на страницу GridView с горизонтальной прокруткой, то находящийся в его недрах ScrollViewer захватывает события колёсика мышки на себя и не пропускает выше. В итоге, если курсор мышки находится над нашим контролом-листалкой, то колёсико мышки делает горизонтальный скролл в нём. Это неудобно и запутывает пользователей:
Решений у этой проблемы два:
Touch screen терять не хотелось и мы продолжили поиск более хорошего решения.
Путь 2. Carousel из UWPToolkit
Следующим вариантом решения стал контрол Carousel из UWPToolkit. Со всех сторон очень интересный и познавательный контрол. Рекомендую всем для изучения его реализацию.
Он довольно неплохо закрывал наши потребности. Но в итоге тоже не подошёл:
В общем, от этого подхода мы тоже решили отказаться. Если уж тратить время, то будем делать по уму.
Путь 3. Наша реализация
Делаем «TOUCH ONLY» ScrollViewer
Напомню, что стандартный ScrollViewer мы использовать не хотим, из-за того, что он захватывает все события от колёсика мышки (см. выше раздел «GridView. Проблема 3»).
Реализацию из Carousel нам не нравится, т.к. использует анимации на UI-потоке, а предпочтительный для UWP-приложений способ создания анимаций — это Composition-анимации. Их отличие от более привычных Storyboard-ов в том, что они работают на отдельном Composition-потоке и за счёт этого обеспечивают 60 кадров/сек даже тогда, когда UI поток чем-то занят.
Для реализации нашей задачи нам понадобится InteractionTracker — компонент, который позволяет использовать touch-ввод в качестве источника для анимаций. Собственно, первое, что нам нужно научиться делать — это перемещать UI-элементы по горизонтали в зависимости от перемещения пальца по экрану. Фактически, нам придётся начать с реализации своего кастомного ScrollViewer-а. Так и назовём его — TouchOnlyScrollViewer:
Здесь пока всё строго по доке от Mircosoft. Разве что вызов TryRedirectForManipulation пришлось обернуть в try-catch потому что он иногда кидает внезапные исключения. Это случается довольно редко (навскидку, примерно в 2-5% случаев) и выяснить причину нам не удалось. Почему об этом ничего не сказано в документации и официальных примерах Microsoft — мы не знаем 😉
TOUCH ONLY ScrollViewer. Формируем HorizontalOffset и события ViewChanging и ViewChanged
Раз мы делаем подобие ScrollViewer-а, то нам понадобится свойство HorizontalOffset и события ViewChanging и ViewChanged. Их будем реализовывать через обработку callback-ов InteractionTracker-а. Для их получения при создании InteractionTracker-а надо указать объект, реализующих IInteractionTrackerOwner, который эти callback-и и будет получать:
Для полноты картины позволю себе скопировать картинку из документации с состояниями и событиями InteractionTracker-а:
Событие ViewChanged будем бросать по входу в состояние Idle.
Событие ViewChanging будем бросать по срабатыванию IInteractionTrackerOwner.ValuesChanged.
Сразу скажу, что ValuesChanged может случаться, когда InteractionTracker находится и в состоянии Idle. Это случается после вызова TryUpdatePosition у InteractionTracker-а. И выглядит как баг в платформе UWP.
Ну что ж, с этим придётся мириться. Благо, нам не сложно — в ответ на ValuesChanged будем выбрасывать либо ViewChanging, либо ValuesChanged, в зависимости от текущего состояния:
TOUCH ONLY ScrollViewer. Snap Points, чтобы пролистывалось ровно на 1 элемент
Для обеспечения пролистывания ровно на 1 элемент есть замечательное решение — «snap points with inertia modifiers».
Смысл в том, что мы задаём точки, в которых скроллинг имеет право остановиться после выполнения свайпа на touch экране. А всю остальную логику берёт на себя InteractionTracker. По сути он модифицирует скорость замедления так, чтобы остановка после свайпа произошла плавно и при этом ровно в том месте, где нам надо.
Наша реализация чуть отличается от той, что изложена в примере в документации. Потому что мы не хотим давать скроллить более чем на один элемент за раз, даже если пользователь «крутанул» нашу листалку слишком быстро.
Поэтому мы добавляем только три snap-point-а — «на один шаг влево», «на один шаг вправо» и «остаться в текущей позиции». И после каждого пролистывания будем их обновлять.
А чтобы не пересоздавать snap point-ы каждый раз после прокрутки, мы сделаем их параметризуемыми. Для этого заводим PropertySet с тремя свойствами:
И в формулах для Condition и RestingValue используем свойства из этого PropertySet:
Поэтому в формулах для Contition мы используем коэффициенты 0.25 и 0.75, чтобы даже «медленный» свайп производил прокрутку к соседнему элементу.
Ну и после каждой прокрутки к соседнему элементу будем вызывать вот такой метод для обновления параметров snap point-ов:
Панель с UI-виртуализацией
Следующим шагом нам нужно было построить на основе нашего TouchOnlyScrollerViewer-а полноценный ItemsControl.
Для справки. UI-виртуализация — это когда контрол-список вместо, скажем, 1000 дочерних элементов создаёт только те, что видны на экране. И переиспользует их по мере скроллинга, привязывая к новым дата-объектам. Это позволяет сократить время загрузки страницы при большом количестве элементов в списке.
Т.к. всё-таки очень не хотелось реализовывать свою UI-виртуализацию, то первое, что мы, конечно, попытались сделать — это использовать стандартную панель ItemsStackPanel.
Хотелось подружить её с нашим TouchOnlyScrollerViewer-ом. К сожалению, не удалось найти ни документации об её внутреннем устройстве, ни исходного кода. Но ряд экспериментов позволил предположить, что ItemsStackPanel ищет ScrollViewer в Visual Tree в списке родительских элементов. И способа это как-то переопределить, чтобы вместо стандартного ScrollViewer-а оно искало наш, мы не нашли.
Ну что ж. Значит панель с UI-виртуализацией придётся всё-таки делать самостоятельно. Лучшее, что удалось найти на эту тему — это вот этот цикл статей аж 11-летней давности: раз, два, три, четыре. Он, правда, про WPF, а не про UWP, но идею передаёт очень неплохо. Ей мы и воспользовались.
Собственно, идея проста:
Ищем события Tapped, потерявшиеся после перенаправления touch-ввода в composition-поток
После того, как мы это собрали вместе вскрылась ещё одна интересная проблема. Иногда пользователь тапает по элементам внутри нашего контрола в процессе того, пока touch ввод перенаправлен в InteractionTracker. Это случается, когда происходит скроллинг по инерции. В этом случае события PointerPressed, PointerReleased и Tapped просто не случаются. И это не надуманная проблема, т.к. инерция у InteractionTracker-а довольно долгая. И даже, когда визуально скроллинг почти закончился, по факту может происходит медленное доскролливание последних нескольких пикселей.
В итоге пользователь расстраивается — он ожидает, что по тапу откроется страница выбранного фильма. Но этого не происходит.
Поэтому будем идентифицировать тап по паре событий от InteractionTracker-а:
Это работает. Но, правда, не позволяет узнать элемент, по которому был осуществлён тап. В нашем случае это не критично, т.к. наши элементы занимают почти всю видимую ширину TouchOnlyScrollViewer-а. Поэтому мы просто выбираем тот, что находится ближе к центру. В большинстве случаев — это именно то, что нужно. Пока никто даже не заметил, что иногда тап во время скроллинга может привести не туда. Это не так просто поймать, даже если знаешь про это 😉
Хотя в общем случае, это конечно ещё не полноценное решение. Для полноценной реализации пришлось бы городить ещё и свой hit testing. Но и его непонятно как сделать, т.к. координаты тапа неизвестны…
Бонус. Expression-анимации для opacity, scale и теней. Чтобы стало, наконец, красиво
И, наконец, вишенка на торте — то, ради чего всё это и затевалось. По мере скроллинга мы хотим изменять размер, тень и прозрачность элементов. Чтобы создать ощущение, что тот, который в центре — слегка приподнят.
Для этого мы воспользуемся Expression-анимациями. Они тоже являются частью подсистемы Composition, работают на отдельном потоке и поэтому не подтормаживают при занятости UI-потока.
Создаются они так. Для свойства, которое должно анимироваться мы задаём формулу (expression), которая определяет зависимость этого свойства от каких-либо других свойств. Формула задаётся в виде текстовой строки.
Ещё их прелесть в том, что их можно выстраивать в цепочки. Этим мы и воспользуемся:
Источником для всех анимаций будет смещение из InteractionTracker-а в пикселях. На основе него мы для каждого дочернего UI-элемента сгенерируем свойство progress, которое будет принимать значения в диапазоне от 0 до 1. И уже на основе progress-а будем вычислять все остальные визуальные свойства.
Итак, формируем _progressExpression таким образом, чтобы оно принимало значения:
И создаём PropertySet со свойством progress, которое будет вычисляться посредством нашего _progressExpression. Это нужно, чтобы на основе этого свойства строить следующие анимации:
Теперь на основе нашего свойства progress создаём уже настоящие «визуальные» анимации с использованием линейной интерполяции (системные функции Lerp и ColorLerp). Полный список функций, которые можно использовать в Expression-анимациях можно найти здесь.
Ну и для остальных свойств формулы аналогичны.
Эпилог
На этом всё. Справедливости ради, надо сказать, что этот контрол оказался, пожалуй, чуть ли ни самым сложным с точки зрения реализации. Остальной fluent design дался намного проще 🙂
→ Посмотреть, как это всё работает можно, установив приложение.
