Нолан Лоусон недавно написал пост про особенности разработки сайтов под KaiOS — "The joy and challenge of developing for KaiOS".

KaiOS — это набирающая популярность операционная система для бюджетных телефонов. Она очень популярна в Индии. По количеству устройств KaiOS занимает второе место после Android.

В статье рассказывается, как начать разрабатывать под эту операционную систему. KaiOS построена на базе Firefox OS, в основе которой лежит Firefox 48. То есть все приложения в системе — это запакованные web-приложения (html, js, css). Устройства на базе KaiOS, очень ограничены в характеристиках, например, в статье для разработки автор использует Nokia 8110 4G. У этого телефона обычный экран (не сенсорный) с разрешением 240x320. Навигация в системе происходит с помощью клавиатуры. Нолан пишет, что адаптация его проекта под KaiOS помогла с a11y, так как интерфейс стал полностью доступен с клавиатуры.

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

#mobile #web

https://nolanlawson.com/2019/09/22/the-joy-and-challenge-of-developing-for-kaios/

Колин Бенделл из 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/

Большие сайты начинают использовать адаптивную загрузку. Что это такое, рассказала Милика Михайлия в статье — "Adaptive loading: improving web performance on slow devices".

Адаптивная загрузка — набор практик для адаптации загружаемых ресурсов, учитывая характеристики устройства. Сайт может узнать тип соединения, объём памяти, количество ядер CPU и, если ресурсов недостаточно, отключить автовоспроизведение видео, заменить 3d-вьюер статическим изображением и т.п. Подобный подход используется Twitter, eBay, Tinder и Facebook. Facebook делит устройства клиентов на пять категорий, каждой категории соответствует свой набор фич. Данные для классификации берутся из navigator.hardwareConcurrency, navigator.deviceMemory и UA-строк. Эти же данные используются в мониторингах сайта, облегчая поиск регрессий производительности.

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

#mobile #performance

https://web.dev/adaptive-loading-cds-2019/

Увидел сегодня в канале веб-стандартов ссылку на статью Эди Османи о разработке сайтов для фичефонов — "Loading web pages fast on a $20 feature phone".

Фичефон (Feature Phone) — это общее название дешёвых телефонов. Они отличаются от смартфонов традиционным форм-фактором (цифровая клавиатура + D-pad), отсутствием тачскрина, одноядерным CPU 1GHz, 256-512Mb RAM, маленьким дисплеем (чаще всего QVGA — 320x240). Фичефоны очень популярны в развивающихся странах, где могут быть дорогие интернет-тарифы.

Большие международные проекты и проекты, нацеленные на развивающиеся рынки, должны учитывать эти особенности и максимально адаптировать сайт под ограниченные ресурсы устройства. В статье Эди предлагает использовать бюджет в 30kb на весь загружаемый JavaScript, так как парсинг и исполнение кода на слабых девайсах может легко занять более двух секунд. Ещё есть совет проверять HTTP-заголовок Save-Data, для определения включения "лёгкого" режима в Chrome под Android.

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

#mobile #performance

https://dev.to/addyosmani/loading-web-pages-fast-on-a-20-feature-phone-8h6
https://habr.com/p/482470/ (перевод на русский язык)

Диего Гонзалес из команды разработки 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

Чарльз Клермон опубликовал статью про влияние производительности на бизнес-метрики SPA-приложения — "The Impact of Web Performance".

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

Для измерения производительности пользователи были разделены на группы по разным категориям устройств. Для разделения пользователей по типу iPhone использовались значения device.screenResolution и device.mobileDeviceBranding (980x1000 это iPhone X/Xr). Измерялось количество отрендеренных браузером фреймов в течении первой секунды после клика (60 — отличный показатель, 0 — плохой).

В общем, интересная статья. Рекомендую почитать, если интересуетесь темой оптимизации.

#performance #mobile

https://simplified.dev/performance/impact-of-web-performance#ref-iphone-categories

Фредерик О'Брайен в статье "What Does A Foldable Web Actually Mean?" размышляет о будущем web в контексте распространения устройств со складывающимися экранами.

Устройств со складывающимися экранами становится больше: Galaxy, Huawei и Motorola уже выпустили девайсы с гнущимся экраном, а Microsoft анонсировала Surface Duo — устройство с двумя независимыми экранами. Для того чтобы можно было адаптировать страницы и web-приложения под такие экраны, разрабатываются новые спецификации. Microsoft работает над новой спецификацией для CSS и JavaScript API. В CSS предлагается использовать новое медиа-выражение spanning, которое будет органично вписываться в концепцию отзывчивого дизайна. Для получения информации о сегментах в JS (например, для WebGL-приложения), предлагается использовать window.getWindowSegments. Благодаря этим возможностям можно будет реализовать новые пользовательские сценарии. Например, когда на одной половине устройства отображается web-карта, а на другой — список организаций,

Маловероятно, что foldable-устройства окажут такой же эффект на web, какой в свое время оказало появление iPhone, но работа над адаптацией web-платформы уже идёт.

#mobile #web

https://www.smashingmagazine.com/2020/02/foldable-web-meaning/

Прочитал пост Видита Бхаргавы про проблемы тёмных тем на 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

На сайте Developer Apple была опубликована статья про использование одноразовых SMS-кодов, привязанных к домену, — "Enhance SMS-delivered code security with domain-bound codes".

Современные смартфоны предоставляют средства для автозаполнения поля с SMS-кодом, который отправляется пользователю при включённой двухфакторной аутентификации или подтверждения каких-либо операций. Сейчас автодополнение кодов работает на любых страницах, которые используют поле ввода с атрибутом autocomplete=one-time-code. Проблема в том, что этим могут пользоваться фишинговые сайты.

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

123456 is your Example code.

@example.com #123456

Привязанные к домену коды можно использовать в iOS 14 и macOS Big Sur. На Android эта фича скорее всего появится в одном из следующих релизов.

#security #mobile

https://developer.apple.com/news/?id=z0i801mg
https://github.com/WICG/sms-one-time-codes

Недавно Adobe объявила о прекращении поддержки PhoneGap — инструмента для разработки кроссплатформенных мобильных приложений на базе web-технологий. В официальном анонсе компания пишет о том, что PhoneGap больше неактуален, так как он может быть заменен PWA. Пользователям PhoneGap предлагается мигрировать на форк PhoneGap — Apache Cordova.

Максимилиано Фиртман провёл анализ возможностей PWA и сравнил их с текущей версией PhoneGap — "Is the Phone Gap closed in 2020?"

PhoneGap был популярен 10 лет назад, когда на рынке существовало много платформ: iOS, Android, WebOS, Bada, Ubuntu Touch, Symbian, Windows Phone и т.п. К 2020 году остались только две популярные платформы: iOS и Android. Но несмотря на то что многие возможности PhoneGap могут быть покрыты PWA (работа оффлайн, доступ к приложению с домашнего экрана), всё ещё есть API, которые недоступны для web-приложений (информация о устройстве, доступ к контактам (iOS). Ситуация усугубляется ещё тем, что разные платформы поддерживают разный набор API. Лучше всего дела обстоят у Android, у iOS поддержка PWA слабее.

#mobile #pwa

https://firt.dev/phonegap-end/

Эдди Османи написал статью про использование паттерна PRPL — "Faster Web App Delivery with PRPL".

PRPL — это паттерн для структурирования и улучшения производительности web-приложений (SPA и PWA).

PRPL описывает четыре этапа жизненного цикла приложения от этапа доставки кода в браузер до его отрисовки:
— Push — при первом открытии приложения, самые необходимые ресурсы доставляются как можно быстрее с помощью server push или preload;
— Render — затем отрисовывается экран приложения с использованием минимального количества необходимых ему ресурсов;
— Pre-cache — после того как приложение было отрисовано, оно может подгрузить ресурсы тех страниц приложения, которые с большой вероятностью будут открыты пользователем;
— Lazy-load — при работе с приложением его куски доставляются в браузер по мере необходимости, это обычно реализуется с помощью code splitting и динамических импортов.

Хорошая статья. Обязательно загляните, если занимаетесь разработкой web-приложений.

#performance #mobile #js

https://addyosmani.com/blog/the-prpl-pattern/

Стэфан Гису и Мартин Ширли в блоге web.dev рассказали о том, как собирать аналитику, когда устройство находится в оффлайне — "Measuring offline usage".

Собирать аналитику в оффлайне можно с помощью сервис воркеров. В статье для этого используется библиотека workbox, которая использует сервис воркеры под капотом. В workbox в свою очередь есть расширение, с помощью которого можно собирать оффлайн-аналитику и отправлять её в Google Analytics после перехода устройства в онлайн. Это расширение использует Background Sync API (поддерживается только в Chrome).

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

Рекомендую почитать статью всем, кто думал над тем, чтобы добавить оффлайн-режим в свой проект.

#serviceworker #mobile

https://web.dev/measuring-offline-usage/

Патрик Лаук опубликовал статью про использование медиафич для определения устройств ввода — "Interaction Media Features and Their Potential (for Incorrect Assumptions)".

В разделе Interaction Media Features CSS-спеки Media Queries Level 4 определяются несколько медиафич, с помощью которых можно проверить поддержку hover, тача, стилуса и соответствующим образом адаптировать интерфейс.

Медифичи pointer и hover предоставляют информацию о возможностях ввода того устройства, которое браузер считает основным. Медиафичи any-pointer и any-hover представляют обобщённую информацию о всех подключенных устройств ввода. Последние две медиафичи наиболее полезны, так как к девайсу, на котором отображается сайт, может быть подключено несколько устройств ввода. Например, к iPad могут быть одновременно подключены Apple Pencil, bluetooth-клавиатура и мышь.

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

Статья большая и полезная. Рекомендую почитать.

#css #mobile

https://css-tricks.com/interaction-media-features-and-their-potential-for-incorrect-assumptions/

Алекс Рассел из Google рассказывает о том, как современный фронтенд влияет на веб в целом, и что можно с этим сделать — "The Mobile Performance Inequality Gap, 2021".

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

Одна из главных причин медленного веба — выбор неподходящих инструментов и неконтролируемый рост JS-бандлов. В 2017 году Алекс призывал ограничивать размер JS до 130-170KiB. Сейчас он предлагает поднять эту границу до 350KiB для JS и 100KiB для HTML/CSS/шрифтов. Это связано с тем, что в последние годы операторы сотовых сетей активно внедряли 4G. При этом вычислительная мощность среднестатистического смартфона, наоборот, не выросла. Сейчас до сих пор в бюджетных смартфонах часто используются устаревшие процессоры, построенные на базе 28нм технологического процесса. Эта ситуация в ближайшие годы изменится, так как пользователи неизбежно будут обновлять свои устройства и границу в 350KiB можно будет подвинуть ещё дальше.

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

#performance #mobile

https://infrequently.org/2021/03/the-performance-inequality-gap/

Девид Соммерс рассказал о том, почему при разработке сайтов не нужно фокусироваться на айфонах, даже если они преобладают в аналитике — "Stop building websites for iPhones".

Девид разрабатывает сервисы для аренды жилья в Соединённых Штатах. В аналитике одного из его проектов видно значительное преобладание айфонов. Это результат того, что строка User-Agent Safari не меняется для разных устройств (iPhone 5, SE, 6, 7, 8, X, 11), тем самым создавая иллюзию того, что у пользователей производительные устройства. Проанализировав данные по айфонам с учётом разрешения экрана (благодаря разрешению можно примерно предсказать конкретную модель iPhone) и других моделей смартфонов оказалось, что примерно 38%-45% посетителей сайта используют медленные устройства.

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

#performance #mobile

https://blog.rentpathcode.com/analyzing-performance-e7aed196df64

VirtualKeyboard API — управление поведением виртуальной клавиатуры

Томас Штайнер написал статью про VirtualKeyboard API — "Full control with the VirtualKeyboard API".

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

VirtualKeyboard API решает подобные проблемы. С его помощью можно отслеживать открытие и закрытие клавиатуры, получать её размеры и адаптировать необходимым образом страницу. Для этого используется объект navigator.virtualKeyboard. В рамках этого API также появилась возможность настройки поведения виртуальной клавиатуры для полей ввода с помощью атрибута virtualkeyboardpolicy.

В данный момент поддержка VirtualKeyboard API есть только в бете Chrome 94.

#api #mobile

https://web.dev/virtualkeyboard/

VirtualKeyboard API на практике

Брамус Ван Дамм написал статью про практическое применение VirtualKeyboard API — "Prevent content from being hidden underneath the Virtual Keyboard by means of the VirtualKeyboard API".

В статье рассказывается о том, как реализовать раскладку элементов страницы с адаптацией под открытие виртуальной клавиатуры. Для решения подобных задач можно использовать переменные окружения CSS, которые были добавлены в рамках VirtualKeyboard API: keyboard-inset-top, keyboard-inset-right, keyboard-inset-bottom и т.п. Например, адаптация нижнего блока под открытие клавиатуры на CSS может выглядеть так:

.bottom-box {
  position: fixed;
  bottom: 0;
  margin-bottom: calc(20px + env(keyboard-inset-height));
}

Есть небольшой нюанс. Чтобы воспользоваться VirtualKeyboard API, браузеру необходимо сообщить о своём намерении управлять перекрытием с помощью вызова кода
navigator.virtualKeyboard.overlaysContent = true. Это не очень удобно, поэтому Брамус завёл ишью с обсуждением альтернативных механизмов включения VirtualKeyboard API.

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

#css #api #mobile

https://www.bram.us/2021/09/13/prevent-items-from-being-hidden-underneath-the-virtual-keyboard-by-means-of-the-virtualkeyboard-api/

Новые единицы измерения CSS, зависящие от области просмотра

Брамус Ван Дамм рассказал про новые единицы измерения, которые недавно были добавлены в спецификацию CSS Values and Units Level 4 — "The Large, Small, and Dynamic Viewports".

Довольно давно в браузерах появилась поддержка единиц измерений vw, vh, vmax, vmin. Их используют для ограничения размера элемента размером доступной области просмотра и для заполнения вьюпорта содержимым на мобилках. Когда создавалась спецификация, всё было логично. Однако ситуация изменилась, когда Safari стал скрывать части интерфейса во время прокрутки. Размер вьюпорта стал меняться динамически, и страницы, использующие vh, стали перекрываться интерфейсом браузера.

Для решения этой проблемы были придуманы разные хаки, а CSSWG разработала новые единицы измерения, более тонко учитывающие поведение вьюпорта:

— lvw, lvh, lvmax, lvmin — единицы относительно вьюпорта браузера со скрытыми элементами интерфейса (префикс "l" — large viewport)
— svw, svh, svmax, svmin — единицы относительно вьюпорта браузера без скрытых элементов интерфейса (префикс "s" — small viewport)
— dvw, dvh, dvmax, dvmin — единицы относительно вьюпорта, учитывающие динамическое изменение интерфейса (префикс "d" — dynamic viewport)

На данный момент новые единицы измерения не поддерживаются ни в одном браузере, но первые коммиты для их поддержки уже были добавлены в WebKit.

#css #spec #mobile

https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/

Важность тестирования сайтов на слабых устройствах

Эрик Бейли призывает тестировать сайты на слабых устройствах — "Test Your Product on a Crappy Laptop".

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

Чтобы контролировать доступность сайта для всех категорий устройств, Эрик предлагает проводить регулярные юзабилити-тесты на слабых устройствах. Также он предлагает купить дешёвый ноутбук (crapbook) и периодически вести на нём разработку.

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

#performance #mobile

https://css-tricks.com/test-your-product-on-a-crappy-laptop/

Встроенный браузер Facebook

Томас Штайнер проанализировал работу встроенного браузера Facebook (In-App Browser — IAB), чтобы разобраться, чем он отличается от обычных браузеров — "Inspecting Facebook's WebView".

Некоторые приложения открывают ссылки во встроенном браузере на базе WebView, потому что это даёт им больше возможностей для работы со страницей. На сайтах, открытых с помощью IAB Facebook, встраивается код сбора метрик производительности и информации о доступных возможностях WebView, в window добавляются свойства TEMPORARY и PERSISTENT, модифицируется отправляемый HTTP-заголовок User-Agent.

WebView не поддерживает все возможности браузеров, поэтому некоторые страницы в нём могут быть сломаны или отображаться неправильно. Так как пользователей Facebook несколько миллиардов, вероятность встречи с подобными ошибками довольно высока. Для упрощения решения проблем в IAB включён режим отладки, чтобы разработчики могли подключиться к WebView удалённо с помощью DevTools браузера.

#facebook #debug #mobile

https://blog.tomayac.com/2019/12/09/inspecting-facebooks-webview/