Колин Бенделл из Cloudinary в статье "Microbrowsers are Everywhere" рассказал про микробраузеры, и почему они важны.

В статье микробраузерами называется механизм, который скачивает по ссылке html-страницу, парсит её и отображает короткое содержание страницы, используя мета-теги Open Graph, OEmbed, Twitter Cards или обычный description. Обычно такие превью можно увидеть в мессенджерах: Telegram, WhatsApp, Slack. Колин пишет про то, что в современном мире, первое впечатление о сайте как раз формируется благодаря таким превью. Владельцы сайтов не могут узнать, что страница была запрошена в превью режиме, так как одни мессенджеры маскируются под мобильные браузеры, а другие кешируют у себя на сервере результат парсинга и только им известно сколько человек увидело превью.

Пользователей мессенджеров огромное количество, поэтому важно сделать так, чтобы превью страниц работало без проблем. В статье есть несколько советов как оптимизировать страницу под микробраузеры, например, использовать только один мета-тег favicon (iMessage качает все ресурсы в синхронном режиме), не использовать UA-сниффинг для скрытия мета-тегов, предоставлять не более трёх изображений в <meta property="og:image".

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

#mobile #ux

https://24ways.org/2019/microbrowsers-are-everywhere/

Попалась на глаза статья Марси Саттон про использование кнопок и ссылок в современных web-интерфейсах — "Links vs. Buttons in Modern Web Applications".

Можно с лёгкостью найти сайты, в которых кнопки в разметке страницы представлены как ссылки и наоборот. Например, на github есть три кнопки: "Create new file", "Upload files", "Find file". В коде странице "Create new file" испльзует тег <button>, "Upload files", "Find file" используют тег <a>. Из-за это пользователи сталкиваются со странностями в интерфейсе: "Почему я могу открыть поиск файла в новой вкладке с помощью контекстного меню, а страницу создания файла открыть не могу?" Марси призывает использовать каждый элемент там, где он подходит больше всего: ссылки для перехода со страницы на страницу, или для переключения страниц в SPA-приложении; кнопки для открытия модальных окон и проигрывания медиа-контента.

Очень рекомендую почитать статью — именно такие мелочи, про которые пишет Марси, формируют хороший пользовательский опыт.

#a11y #ux

https://marcysutton.com/links-vs-buttons-in-modern-web-applications

Диего Гонзалес из команды разработки Samsung Internet рассказал про лучшие практики разработки веб сайтов для устройств с гнущимися экранами.

На данный момент по всему миру продано более одного миллиона Galaxy Fold. То есть девайсами с гнущимися экранами пользуются реальные люди. Самая большая проблема при разработке сайтов под такие устройства — доступное экранное пространство. Окно браузера в режиме многозадачности на Galaxy Fold может быть очень маленьким (229px x 187px). Диего рекомендует использовать отзывчивый дизайн с обязательной проверкой отображения в разных браузерах с маленькой шириной окна.

В статье есть упоминание полезной фичи Firefox Dev Tools — в режиме инспектора все элементы, у которых есть скролл, помечаются лейблом "scroll". Это удобно при фиксе проблем вёрстки, вызывающих двойной скролл на странице.

#mobile #ux #css

https://medium.com/samsung-internet-dev/current-web-on-galaxy-fold-ad12d7f57c26

Увидел сегодня в ленте твиттера ссылку на серию статей Лео Фабриканта про оптимизацию производительности контрола автодополнения — "Secrets of JavaScript: A tale of React, Performance Optimization and Multi-threading".

Автор решал задачу отзывчивого автодополнения для названий научных организаций. Так как эти названия длинные, пользователь с большой вероятностью может сделать опечатку, поэтому важно было сделать поиск нечётким (fuzzy search), что увеличивало общее время поиска и создавало лаги при вводе текста. В статьях описаны разные подходы, которые Лео попробовал реализовать для уменьшения лагов: от setTimeout до пулла Web Worker'ов.

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

#performance #react #ux

https://levelup.gitconnected.com/secrets-of-javascript-a-tale-of-react-performance-optimization-and-multi-threading-9409332d349f

Разработчики Chrome и Edge в прошедшем году работали над элементами управления форм в браузере. В блоге Chromium появилась статья, в которой рассказывается о проделанной работе — "Updates to form controls and focus ".

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

В итоге все элементы были приведены к единому внешнему виду и адаптированы под тач-устройства. У всех элементов и диалогов появилась полноценная поддержка управление с клавиатуры, например, диалогом выбора цвета теперь можно пользоваться без мыши/тачпада. Был доработан фокус у элементов. Теперь это рамка чёрного цвета с белой обводкой. Так было сделано, для того чтобы фокус был виден на светлых и тёмных фонах. Эти изменения уже доступны в Edge, включение новых элементов для пользователей Chrome запланировано в версии 83.

Для того чтобы системно собирать обратную связь по новым элементам, разработчики Edge создали сайт open-ui.org. Если вы работаете над дизайн-системой или набором компонентов, разработчики приглашают присоединиться к обсуждению элементов управления браузера.

#ux #a11y

https://blog.chromium.org/2020/03/updates-to-form-controls-and-focus.html

Прочитал пост Видита Бхаргавы про проблемы тёмных тем на OLED дисплеях — "Designing a Dark Theme for OLED iPhones".

В темах, которые используют настоящий чёрный цвет (#000), возникает две проблемы при отображении на OLED-дисплеях: смазывание изображения и эффект халяции.

Изображение смазывается из-за того, что чёрные пиксели в OLED-дисплеях по сути отключены. При их включении проходит небольшой промежуток времени, что при движении контента приводит к смазыванию изображения. Для того, чтобы от него избавиться, нужно настоящий чёрный цвет заменить на почти чёрный серый цвет (#050505). Таким образом пиксели не будут выключаться и эффекта смазывания не будет. Такой подход вызывает немного большее потребление энергии, но эти затраты практически неотличимы от энергозатрат при отображении чёрного цвета.

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

Хорошая статья. Если на вашем сайте (или в приложении) есть чёрная тема, то статью стоит почитать.

#mobile #a11y #ux

https://medium.com/lookup-design/designing-a-dark-theme-for-oled-iphones-e13cdfea7ffe

Нашёл в дизайн-доках 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/