Нашёл в дизайн-доках Chromium статьи про создание форм авторизации: "Password Form Styles that Chromium Understands", "Create Amazing Password Forms".

Браузеры и менеджеры паролей помогают пользователям автоматически заполнять поля форм авторизации. Для того чтобы вся эта "магия" работала правильно, нужно использовать семантическую вёрстку и придерживаться определённых правил. Например, чтобы менеджеры паролей смогли подхватить отправленные данные, после успешного логина должен произойти переход на новую страницу или этот переход должен быть сэмулирован с помощью history.pushState или history.replaceState. Для ускорения заполнения формы, поля ввода пароля и логина нужно разметить атрибутами autocomplete="current-password" и autocomplete="username". Если у поля стоит атрибут autocomplete="new-password" браузер или менеджер паролей будут показывать интерфейс для создания пароля.

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

#html #ux

https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://www.chromium.org/developers/design-documents/create-amazing-password-forms

Эдди Османи недавно написал статью об оптимизации метрики CLS для списков с бесконечным скроллом — "Infinite Scroll without Layout Shifts".

Для организации больших списков в web'е используют пагинацию, подгрузку по кнопке "загрузить больше" и бесконечную подгрузку элементов списка при прокрутке контента. Бесконечная прокрутка считается самым проблемным решением с точки зрения a11y. Если не прилагать особых усилий, то подвал сайта будет постоянно сдвигаться из-за подгрузки новой порции контента, ухудшая метрику CLS (Cumulative Layout Shift).

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

Очень полезная статья. Обязательно почитайте, если в вашем проекте используются списки с бесконечной прокруткой.

#performance #ux

https://addyosmani.com/blog/infinite-scroll-without-layout-shifts/

В Chrome 86 будет запущен эксперимент с изменением адресной строки — "Helping people spot the spoofs: a URL experiment".

В фишинге часто используют измененённые доменные имена известных сайтов, которые у обычных пользователей не вызывают подозрения. В исследовании команды Chrome 60% пользователей были введены в заблуждение, когда в URL находилось название бренда с опечаткой. Чтобы вывести адрес сайта на первый план, Chrome будет отображать в адресной строке только домен (при наведении на него курсором будет отображаться полный URL).

Если вы попадёте в эксперимент, то включить привычное отображение можно будет с помощью пункта "Always show full URLs” в контекстном меню адресной строки. Посмотреть новую фичу можно в Chrome Canary или Dev, включив флаги #omnibox-ui-reveal-steady-state-url-path-query-and-ref-on-hover, #omnibox-ui-sometimes-elide-to-registrable-domain.

#ux #chrome

https://blog.chromium.org/2020/08/helping-people-spot-spoofs-url.html?m=1

Крис Уэллонс написал статью про устоявшиеся подходы реализации опций CLI-утилит — "Conventions for Command Line Options".

В Unix-системах есть соглашения о том, как утилиты должны обрабатывать опции. Крис пишет про то, что их следует придерживаться, если нет веских причин, чтобы это не делать.

Если опции состоят из одной буквы, то они должны следовать за знаком минус ( -a -b -c ). Если опций много, то их можно объединить ( -abc ). Если у опции есть аргумент, то его можно передать после пробела или без него ( -ifile.txt и -i file.txt одно и то же).

Также в статье разбирается логика работы с длинными опциями (GNU-style). Они должны следовать за двумя знаками минус ( --option ). Слова в опциях отделяются минусом ( --long-option ). Аргументы можно передать после пробела ( --input file.txt`) или знака равенства ( `--input=file.txt ). Иногда у опций есть взаимоисключающий аналог, который начинается с --no ( --sort, --no-sort ).

В общем, очень хорошая статья. Рекомендую почитать всем.

#cli #ux

https://nullprogram.com/blog/2020/08/01/

Тим Кадлек написал статью про лучшие практики использования скелетных экранов — "Effective Skeleton Screens".

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

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

Хорошая статья. Рекомендую почитать.

#performance #ux

https://timkadlec.com/remembers/2020-11-02-skeleton-screens/

Мэтт Хоббс рассказал о нюансах использования CSS-свойства font-display с учётом производительности и UX — "A font-display setting for slow connections".

Свойство font-display определяет стратегию рендеринга web-шрифта и его фоллбэка: auto, block, swap, fallback, optional. С точки зрения скорости отображения контента наиболее интересны последние три значения. При использовании swap браузер рендерит фоллбэк-шрифт сразу же и ждёт бесконечное количество времени, пока не загрузится шрифт, после загрузки происходит замена шрифта. Значение fallback похоже на swap, но браузер ждёт три секунды для замены шрифта. Самое агрессивное свойство optional, если в течение 100мс браузер не загрузит шрифт, то будет отображаться фоллбэк без подмены. Загруженный шрифт будет взят из кэша при переходе на новую страницу.

Мэтт пишет, что на сайте правительства Великобритании, над которым он работал, используется font-display: fallback, чтобы пользователи не сталкивались с внезапным сдвигом контента.

Очень интересная статья. Рекомендую почитать всем, кто использует web-шрифты.

#performance #ux #fonts

https://calendar.perfplanet.com/2020/a-font-display-setting-for-slow-connections/

Дэниэл Дестефанис из Discord рассказал о том, как разработанные ими плагины для Figma упрощают жизнь разработчикам и дизайнерам — "Building open-source design tools to improve Discord’s design workflow".

Ребята из Discord сделали несколько плагинов для Figma, которые им помогают в работе. Плагин "Auto Theme" используется для автоматической генерации светлой/тёмной темы экранов приложения. Плагин "Design Lint" помогает быстро находить проблемные места в макете, когда в нём используются параметры, которых нет в дизайн-системе (цвет, радиус скругления углов и т.п.) Плагин "Table of Contents" генерирует список ссылок на основные части макета для помощи в навигации по документу. Плагин "Inspect" используется для упрощения разработки плагинов. Все плагины доступны на GitHub.

Интересная статья. Очень рекомендую заглянуть, если работаете с Figma.

#ux #tool

https://blog.discord.com/building-open-source-design-tools-to-improve-discords-design-workflow-9a25c29f9143

Кэти Хемпениус написала статью о лучших практиках создания каруселей — "Best practices for carousels".

С точки зрения производительности не рекомендуется использовать JS для динамического создания каруселей, так как такой подход негативно влияет на метрику LCP (Largest Contentful Paint). Для создания каруселей рекомендуется использовать обычную HTML-разметку и Scroll Snap API.

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

Полезная статья. Рекомендую почитать.

#performance #ux

https://web.dev/carousel-best-practices/

Барри Поллард рассказал про новые CSS-дескрипторы директивы @font-face, помогающие уменьшить сдвиг контента после загрузки шрифта, — "A New Way To Reduce Font Loading Impact: CSS Font Descriptors".

Для управления загрузкой шрифтов используется директива font-display. Очень часто её используют со значением swap, так как текст страницы с ней появляется сразу и посетителям страницы не нужно ждать загрузки шрифта. Но при использовании font-display: swap возникает проблема со сдвигом контента, из-за которой посетители во время чтения текста могут потерять текущую позицию в тексте.

Для решения этой проблемы был придуман подход с использованием Font Loading API и сопоставлением метрик фоллбек-шрифта с метриками загружаемого шрифта. Этот подход работает, но он не очень удобен в реализации. По этой причине в рамках спецификации CSS Fonts Module Level 5 были добавлены новые дескрипторы size-adjust, descent-override, line-gap-override, advance-override, с помощью которых можно задать дополнительные метрики для фоллбек-шрифта, уменьшая непредсказуемый сдвиг контента. В коде это выглядит так:

@font-face {
  font-family: 'Lato';
  src: url('/fonts/Lato.woff2') format('woff2');
  font-weight: 400;
}

@font-face {
  font-family: "Lato-fallback";
  size-adjust: 97.38%;
  ascent-override: 99%;
  src: local("Arial");
}

h1 {
  font-family: Lato, Lato-fallback, sans-serif;
}

На данный момент поддержка descent-override, line-gap-override, advance-override уже есть в Chrome и Firefox. Поддержка size-adjust появилась недавно в Chrome Canary и в Firefox за экспериментальным флагом.

#performance #fonts #ux #css

https://www.smashingmagazine.com/2021/05/reduce-font-loading-impact-css-descriptors/

Почему ссылки синие?

Элиза Бланшар написала статью про то, почему на многих сайтах ссылки синего цвета — "Why are hyperlinks blue?"

В первых интерфейсах для гиперссылок использовался чёрный цвет с подчёркиванием или рамками. С распространением цветных мониторов гиперссылки стали приобретать разные цвета, например, в клиенте Gopher (предтеча веб) использовался зелёный цвет. Mosaic стал первым браузером, который закрепил за ссылками привычные цвета: синий для обычных ссылок и тёмно-фиолетовый для посещённых. Почему был выбран синий цвет для обычных ссылок, точно неизвестно. Есть теория, что на этот выбор повлиял интерфейс Windows, который закрепил за синим цветом сигнал интерактивности.

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

#web #history #ux

https://blog.mozilla.org/en/internet-culture/deep-dives/why-are-hyperlinks-blue/

Автоматическая тёмная тема в Chrome

В Origin Trial Chrome 96 на Android появится поддержка автоматической тёмной темы — "Auto Dark Theme".

Автоматическая тёмная тема — это автоматическая адаптация цвета фона страницы и текста под тёмную тему операционной системы без вмешательства разработчика.

Сейчас автотема находится на этапе эксперимента, поэтому при её использовании есть неудобства. Для тонкого управления цветами отдельных элементов нужно с помощью JavaScript определить поддержку автотемы, выставить класс на корневом элементе и использовать его в CSS-правилах.

Есть возможность отказа от автотемы с помощью метатега <meta name="color-scheme" content="only light">. Также для отключения автотемы на всей странице или отдельных её элементах можно использовать CSS-декларацию color-scheme: only light.

#ux #chrome

https://developer.chrome.com/blog/auto-dark-theme/

В поиске лучшего способа балансировки переносов слов

Попробовал сегодня по-быстрому сделать удобочитаемые переносы слов заголовков статей на сайте defront. Оказалось, что не всё так просто.

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

Причины отсутствия поддержки AVIF в
Safari

хотелось бы, чтобы текст выглядел так:

Причины отсутствия
поддержки AVIF в Safari

В последнем варианте текст сбалансирован и не отвлекает внимание.

Для решения этой проблемы можно воспользоваться готовыми балансировщиками переноса слов. Есть две популярные реализации: от New York Times и от Adobe. Реализация от Adobe для меня слишком тяжёлая, реализация от New York Times полегче, но она хорошо работает только с небольшими объёмами текста.

Реализация New York Times для небольших заголовков подходит идеально, также она работает быстрее балансировщика Adobe благодаря использованию простого алгоритма на базе бинарного поиска. Но у неё есть проблема с видимым сдвигом позиции слов. Дениэл Александерсен в статье про форк балансировщика от New York Times предлагает скрывать текст заголовка до тех пор, пока не сработает балансировка, но мне это кажется очень хрупким решением. Если по каким-то причинам скрипт окажется сломан, то пользователь не увидит заголовка статьи. Также есть сомнения, что все скринридеры будут хорошо интерпретировать появляющийся из ниоткуда заголовок статьи.

Ещё можно сделать автоматическую вставку <br> в нужном месте разрыва заголовка. На больших экранах заголовки будут выглядеть хорошо, на маленьких экранах в редких случаях перенос будет выглядеть странно:

Использование
SomeNewApi
и
OtherNewApi
в Node.js

Также в стандарте CSS Text Level 4 есть упоминание CSS-свойства text-wrap: balance. Оно было предложено Adobe в 2013 году, и его поддержки до сих пор нет ни в одном браузере.

Сначала хотел использовать форк балансировщика New York Times, но его недостатки перевешивают все преимущества. Возможно, что потом попробую покопать в сторону варианта с <br>, но пока оставлю всё без изменений. Балансировка переноса слов — это коварная штука.

#html #ux #a11y

https://defront.ru/posts/2022/01-january/11-in-search-of-best-line-wrap-balance/