UX за пределами приложения: островки, виджеты, часы и системные интерфейсы

Обновлено: 6 ноября 2026.

Хорошее приложение помогает человеку и тогда, когда его экран закрыт. Островок показывает, когда приедет машина. Часы позволяют остановить тренировку. Виджет напоминает о следующей задаче. Билет открывается у турникета. Этот материал — практический атлас таких взаимодействий: что выбрать, где это работает, как подключить и как не превратить полезный сервис в постоянный источник отвлечений.

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

Срез документации: 5 ноября 2026 года. Это обзор механизмов и проектных решений, а не лабораторный тест всех устройств. Наличие API, доступ приложения к нему и фактическое отображение на телефоне — три отдельных условия. Примеры ниже авторские и условные; они объясняют состав информации, а не воспроизводят интерфейс конкретной ОС. Под «поверхностью» будем понимать место взаимодействия: экран блокировки, виджет, часы, системную карточку или физический индикатор.

1. Главный принцип: уменьшать усилие, а не увеличивать присутствие

Заказчик часто формулирует задачу так: «Сделаем Dynamic Island, чтобы пользователь чаще видел наш бренд». Полезнее спросить: «Какой вопрос человеку приходится снова и снова задавать приложению?» Если ответ — «когда приедет курьер», компактный статус оправдан. Если ответ — «не забывай о нашей подписке», дополнительная поверхность, вероятно, станет рекламой.

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

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

2. Полная карта: от уведомления до физического мира

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

Ещё один слой — встроенные в приложение баннеры, snackbar, toast, bottom sheet, coach mark, чат поддержки и центр сообщений. Они полезны, когда человек уже находится в продукте. Их не стоит смешивать с системными поверхностями: плавающая кнопка сайта не превращается в системный островок после закрытия вкладки.

3. Как выбрать поверхность: шесть вопросов перед дизайном

1. Человек ждёт изменения или сам ищет информацию? Для неожиданного важного события нужен сигнал. Для ежедневной проверки часто достаточно виджета.
2. Процесс происходит прямо сейчас? Текущая поездка и доставка через три дня требуют разных способов показа.
3. Можно ли понять главное за один взгляд? Если нужно сравнить десять параметров, маленькая поверхность должна открывать полноценный экран.
4. Нужно ли действие? «Пауза» подходит для короткого управления; «изменить сложный заказ» обычно требует приложения.
5. Кто ещё увидит данные? Экран блокировки, часы, дисплей автомобиля и колонка создают разные риски раскрытия информации.
6. Что произойдёт без разрешения или связи? Этот вариант проектируют вместе с основным, а не после жалоб пользователей.

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

4. Live Activities и Live Updates: похожая задача, разные механизмы

Apple: ActivityKit управляет жизненным циклом

Live Activity — представление текущей задачи; Dynamic Island — одно из мест её показа. ActivityKit управляет созданием, обновлением и завершением, а WidgetKit и SwiftUI задают интерфейс. Проектируются разные состояния: compact, minimal, expanded и экран блокировки. Устройства без островка также остаются частью сценария.

Ограничения длительности и данных, действия через App Intents, серверные обновления APNs и поддержка других экранов разобраны в практическом руководстве по Dynamic Island и Live Activities. Возможности кнопок на Apple Watch нельзя автоматически переносить на CarPlay.

Android: семантическое уведомление, представление которого выбирает система

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

Отдельное руководство по Android Live Updates показывает Kotlin-примеры, разрешения, стили, обновления из фона, завершение и проверку OEM-интеграций. Пользовательский сценарий, допустимость API и реальный показ проверяются отдельно.

Чего не надо переносить между платформами

Не переносите лимит Apple на Android, правила Google на китайский OEM-канал, а поддержку формы на поддержку интерактивности. Не обещайте один общий пиксельный макет. Общими могут быть состояние заказа, смысл текста и команда; размеры, кнопки, срок жизни и транспорт обновления остаются платформенными.

5. Android-производители: карта доступа, а не парад логотипов

Samsung Now Bar, Xiaomi HyperIsland, OPPO Fluid Cloud, vivo Origin Island и HONOR Magic Capsule решают похожую задачу, но не образуют единого SDK. Где-то достаточно подходящего системного механизма; где-то нужен допуск сценария, специальный шаблон и фирменный канал обновлений.

При оценке интеграции проверяйте четыре вещи: модель и прошивку, рынок, доступ конкретного приложения, фактически поддерживаемый сценарий. Продуктовая демонстрация подтверждает пользовательскую функцию, но не обязательно открытый путь для стороннего APK. Huawei дополнительно требует различать EMUI и нативную HarmonyOS.

Полная таблица производителей и условия подключения вынесены в Android-руководство. Для Glyph Matrix и других задних панелей есть исследование дополнительных экранов: доступ к острову не равен доступу к любому дисплею устройства.

6. Виджеты, Controls и быстрые действия: часто полезнее острова

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

На Android есть App Widgets с разными размерами и типами взаимодействия. Jetpack Glance помогает писать такие интерфейсы декларативно, но Glance не равен произвольному экрану Jetpack Compose: возможности и окружение отличаются. На Apple WidgetKit объединяет виджеты, complications и Controls; его документация показывает, где эти представления доступны.

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

Quick Settings Tile уместна для короткой повторяемой операции: начать запись, включить режим приложения, запустить таймер. На Apple аналогичную продуктовую задачу могут решать Controls и App Shortcuts. Через App Intents действия становятся доступны Siri, Shortcuts, Spotlight и другим системным входам.

Для shortcut хороша формулировка «Сканировать документ», а не «Открыть приложение». Для переключателя необходимо показать состояние: «Запись идёт», «На паузе», «Нет разрешения». Для команды, отправляемой на сервер, сначала показывают ожидание, затем подтверждённый результат. Нажатие кнопки ещё не означает, что дверь открылась или заказ отменён.

Как создать полезный виджет, а не уменьшенную главную страницу

Начните с повторяющегося вопроса: «Что у меня дальше?», «Какой заказ сейчас в пути?», «Выключен ли свет?». У небольшого виджета должен быть один главный ответ и понятный следующий шаг. В большем размере можно добавить контекст, но не новую независимую версию состояния приложения.

• Задачи: выбранный список, ближайший пункт и подтверждённое выполнение конкретной задачи.
• Умный дом: выбранное устройство, актуальность статуса и явная команда; пока устройство не ответило, показывается ожидание.
• Поездки: ближайший рейс или текущий заказ с точным переходом к деталям. Непрерывное наблюдение за коротким процессом может лучше подходить live-активности.
• Фокус-сессия: известное время окончания и поддерживаемое управление. Обновление виджета не должно изображать постоянно работающий таймерный сервис.

На Apple нужны Widget Extension, конфигурация, provider и timeline с реальными данными. Для пользовательского выбора объекта служат WidgetConfigurationIntent и AppIntentTimelineProvider; для доступных на целевой версии интерактивных кнопок — App Intents. Общий контейнер данных приложения и расширения должен быть действительно настроен. Запрос WidgetCenter на перезагрузку timeline не гарантирует точное время обновления.

На Android реализация включает GlanceAppWidget, receiver, метаданные provider, размеры и обработчики действий. После сохранения новых данных нужно отдельно запросить обновление нужного экземпляра. Руководство Glance показывает связь provider, данных и обновления, а SizeMode помогает подготовить содержимое для разных размеров. У двух виджетов могут быть разные аккаунты и объекты; их настройки нельзя случайно объединять.

Проверьте добавление, настройку, минимальный размер, растягивание, удаление, отсутствие связи, выход из аккаунта и повторное нажатие. Предпросмотр может использовать учебные данные; реальный виджет должен честно показывать отсутствие результата. Обычная веб-страница может иметь полезные панели, но её HTML не устанавливает виджет WidgetKit или Glance на домашний экран.

7. Умные часы: не уменьшенный телефон

Человек смотрит на часы на ходу, во время тренировки, с занятыми руками. Поэтому полезная watch-интеграция начинается с отбора информации. Если на экране телефона десять полей, это не причина переносить десять полей на запястье.

Различайте пять механизмов: пересланное уведомление, показатель на циферблате, карточку в стеке или Tile, текущую активность и самостоятельное приложение. Первое может работать без собственного watch-приложения; последнее нужно для автономной логики, датчиков, записи тренировки и сложных действий. Нельзя обещать автономность лишь потому, что телефонное уведомление видно на часах.

На Apple Watch Live Activity с iPhone может появляться в Smart Stack, а собственная watchOS-компоновка позволяет точнее выбрать содержимое. Apple объясняет и различия перехода при наличии или отсутствии watchOS-приложения. Complication на циферблате решает ещё более короткую задачу: один показатель и понятный вход.

У Wear OS набор включает приложения, уведомления, complications, Tiles и виджеты. Поэтому актуальную карту интерфейсов Wear OS полезнее использовать, чем старую схему «циферблат плюс плитки». Начиная с Wear OS 7 документированы локальные и переданные с телефона Live Updates; передачу определяет также OEM, а слишком частые обновления могут приводить к скрытию данных ради батареи.

Garmin — отдельная экосистема. Connect IQ различает циферблаты, поля данных, виджеты, приложения и поставщиков аудиоконтента. Для спортивного продукта собственное поле данных внутри привычной тренировки иногда полезнее самостоятельного приложения. Часы других производителей и умные кольца необходимо оценивать по конкретному SDK: доступ к измерениям не означает доступ к интерфейсу или произвольной вибрации.

Для тренировки разумный минимум — время, одна ключевая метрика и крупная пауза. Окончание занятия должно отличаться от паузы и защищаться от случайного нажатия. Потеря связи с телефоном не должна выдавать старое значение пульса за текущее: доступность датчика, записи и синхронизации описывают отдельно.

8. Медиа, звонки, переписка и плавающие окна

У этих сценариев уже есть системная семантика. Android MediaSession передаёт состояние плеера и команды системе, наушникам, Android Auto и Wear OS. Реализованная корректно медиасессия может дать больше полезных входов, чем собственная декоративная капсула. В экосистеме Apple для воспроизведения также используют системные механизмы Now Playing и удалённых команд, а не маскируют плеер под доставку.

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

Для общения есть уведомления с ответом и conversation bubbles. Но это не единственный смысл слова Bubbles: Android 17 добавляет App Bubbles как режим оконной многозадачности, отдельно от API переписки. Приложение должно корректно жить в маленьком изменяемом окне, сохранять состояние и не требовать фиксированного полноэкранного размера.

Собственный overlay поверх чужих приложений — ещё одна технология, требующая отдельного доступа. Он не становится частью системного острова и не получает его гарантий. Для обычного сервиса не стоит начинать с такого решения: сначала проверьте системную поверхность, которая соответствует задаче.

9. Wallet, QR и App Clips: иногда приложение вообще не нужно открывать

Посадочный талон, билет, пропуск, карта лояльности и цифровой ключ — отдельный класс интерфейсов. Главный вопрос пользователя здесь: «Смогу ли я пройти или воспользоваться услугой?» Красивое напоминание не заменяет действительный пропуск.

Google Wallet предлагает разные категории цифровых объектов. У Apple путь создания и распространения Wallet passes включает подпись сертификатом. Не все типы объектов и возможности доступны каждому издателю: билет с кодом и защищённый цифровой ключ — существенно разные интеграции.

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

QR и NFC могут открыть нужный контекст: столик, парковку, аренду устройства. На Apple App Clip позволяет выделить короткую часть сценария без установки полного приложения. Это требует отдельной подготовки и условий платформы. Обычная мобильная страница по QR проще, если задача действительно укладывается в веб.

10. Внешние экраны, автомобиль, голос и физические сигналы

Задний дисплей: пять разных программных контрактов

Дополнительные экраны есть и у обычных нескладных смартфонов. Но это разные поверхности: обычное окно Android, дисплей для Presentation, область складного устройства через WindowAreaController, фирменная матрица с SDK или системная панель с ограниченным набором карточек. До выбора макета нужно установить, какой контракт доступен приложению.

У Nothing есть публичный Glyph Matrix Developer Kit: вывод из приложения через setAppMatrixFrame() и отдельные Glyph Toys с собственным жизненным циклом. У Ulefone Armor 30/33 Pro документированы обычный задний экран и зеркалирование, поэтому первой задачей может быть адаптация приложения. Пользовательские карточки Xiaomi и редактор анимаций ASUS сами по себе не доказывают наличие открытого API произвольной отрисовки.

Для сайтов действует та же граница: браузер на втором дисплее позволяет адаптировать страницу, но PWA не получает доступ к закрытой панели. Отдельное исследование задних экранов сравнивает Xiaomi, Nothing, Ulefone, ASUS и DOOGEE и показывает работу с Presentation, WindowManager и OEM SDK.

Складные устройства, AOD и перенос между экранами

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

Handoff переносит саму задачу. В Android 17 предусмотрен API межустройственной передачи активности, включая передачу данных для восстановления контекста. Проектная ценность возникает, когда на втором устройстве открывается нужный документ, заказ или этап работы. Запуск главной страницы сам по себе ещё не создаёт непрерывного опыта.

Flip, Fold и обычные телефоны: адаптируйте доступное окно

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

Для сайта и PWA сначала нужна полноценная адаптация обычного окна: Grid/Flexbox, ограничения ширины, перенос действий, container queries для компонентов в разных панелях и доступная прокрутка. Проверяйте короткий landscape, клавиатуру, масштабирование, вырезы и браузерные панели. Единица dvh полезна для динамической высоты, но сама по себе не решает поведение любой экранной клавиатуры.

Если браузер действительно сообщает сегменты экрана, можно учитывать horizontal-viewport-segments и геометрию viewport-segment. Без этих данных нельзя придумывать расположение шарнира по строке модели. Базовая страница должна корректно работать как в обычном изменяемом окне.

В Android-приложении используйте актуальные для проекта библиотеки adaptive layout: классы размеров окна учитывают и ширину, и высоту. Для связанных списка и деталей есть готовые scaffold-компоненты. WindowManager сообщает состояние и геометрию сгиба: разделяет ли он области и закрывает ли контент. Не всякий сгиб требует пустого зазора, и не всякий большой экран нуждается в двух колонках.

В Apple-приложении опирайтесь на контейнер, safe areas и Dynamic Type. ViewThatFits помогает перестроить локальную группу действий, а NavigationSplitView — связанные панели на поддерживаемых платформах. Перенос Android-правил о шарнире на устройство Apple без соответствующего API был бы предположением.

1. Откройте конкретную карточку и начните вводить черновик.
2. Измените ширину, поверните окно или раскройте устройство; затем вернитесь обратно.
3. Откройте клавиатуру и проверьте доступность поля, ошибки и основного действия.
4. Увеличьте текст, проверьте длинный перевод и порядок фокуса.
5. Убедитесь, что выбор, черновик, навигация и выполняемая операция сохранились без повторного запуска.

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

Автомобиль, наушники и голосовые команды

Android Auto и Android Automotive OS поддерживают определённые категории приложений; CarPlay также задаёт свой набор возможностей и требований. Автомобильный экран нельзя считать ещё одним местом для любой карточки. При движении важнее краткая команда, крупный ориентир и минимальная нагрузка на внимание.

Наушники полезны для навигации, управления воспроизведением и коротких подтверждений. Голосовой сценарий должен уметь уточнить неоднозначное: «Какой таймер остановить?» — вместо остановки случайного. Успех команды нужно подтверждать, а чувствительные данные не стоит произносить без учёта контекста. Умная колонка или очки требуют проверки конкретной платформы и доступных стороннему приложению интерфейсов; наличие общего API «показать на любых очках» нельзя предполагать.

Тактильная отдача, свет, NFC, BLE и UWB

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

NFC подходит для касания и запуска контекста, BLE — для связи с близкими устройствами, UWB — для поддерживаемых сценариев определения расстояния и положения. Ranging API Android 16 объединяет несколько технологий измерения расстояния, но не добавляет отсутствующее оборудование. Сначала проверяют возможности пары устройств; затем проектируют взаимодействие. Близость сама по себе не удостоверяет личность и не даёт права открыть замок или выполнить платёж.

Биометрия и passkeys помогают подтвердить личность в подобных цепочках. Их роль — авторизация и сокращение трения на чувствительном шаге; это не отдельный канал сообщений и не основание переносить все операции на заблокированный экран.

11. Что из этого доступно сайту и PWA

Для веб-команды это ключевое различие. Установленная PWA не становится автоматически нативным приложением с ActivityKit, Android Live Updates, собственными complications или OEM-капсулами. Если продукту нужна такая интеграция, требуется документированный нативный путь, а иногда отдельное расширение или companion-приложение.

При этом сайт может закрыть значительную часть задачи: понятная страница состояния заказа, deep link, добавление билета в Wallet через серверную интеграцию, Web Push там, где он поддерживается, системное меню «Поделиться», календарное событие и вход по QR. WebKit поддерживает Web Push для добавленных на домашний экран веб-приложений начиная с iOS/iPadOS 16.4; запрос разрешения должен следовать действию пользователя. Это уведомления, а не разрешение создать произвольную Live Activity.

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

12. Сообщения внутри приложения: баннеры, подсказки и чат

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

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

Для AI-помощника различайте ответ, предложение действия и выполненное действие. «Я могу перенести запись» не означает «запись перенесена». Перед изменением покажите выбранный объект и существенные последствия; после — подтверждённый результат. Когда ответ не найден, назовите ограничение и предложите доступный путь к поддержке, сохранив контекст обращения.

Email, SMS и сообщения в мессенджерах — ещё один класс: внешние каналы доставки сообщений. Их выбирают по согласию пользователя, срочности и необходимой долговечности информации. Квитанцию полезно сохранить, а статус каждой минуты поездки не стоит дублировать во все каналы. Сбой push сам по себе не даёт основания отправлять SMS без заранее определённых правил и согласия.

13. Практические сценарии: что именно вынести наружу

Разбираем доставку по времени

Заказ оформлен: подтверждение и доступ к деталям. Идёт приготовление: спокойный статус, если сценарий допущен платформой. Курьер приближается: ETA и место встречи становятся главным. Курьер приехал: меняется смысл карточки — теперь нужно действие, а не ещё один процент. Заказ получен: активное отслеживание заканчивается; история остаётся в приложении. Просьба поставить оценку — отдельная задача, а не причина удерживать островок.

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

Разбираем AI-задачу

При генерации документа полезны реальные этапы: «анализируем материалы», «собираем черновик», «проверяем результат». Если сервер не измеряет завершённость, процент лучше не рисовать. Завершение должно вести к конкретному результату, ошибка — к понятному объяснению и допустимому повтору. Live-поверхность уместна только после проверки критериев платформы и необходимости непрерывного наблюдения.

14. Самая важная часть дизайна — невидимые состояния

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

• Задача: создана, активна, приостановлена, требует действия, завершена, отменена, ошибочна.
• Данные: актуальны, устарели, недоступны.
• Представление: не создано, показ запрошен, доступ ограничен, скрыто пользователем, окончено.

«Пользователь убрал карточку» не означает «пользователь отменил такси». «Приложение выгружено» не означает «заказ завершён». «Push принят провайдером» не означает «экран обновился». Разделение этих понятий предотвращает целый класс ошибок в поддержке и аналитике.

Определите срок актуальности для каждого вида данных. ETA доставки и время начала встречи устаревают по-разному. При истечении срока карточка должна перестать изображать подтверждённое текущее состояние. Иногда достаточно подписи «данные на 12:06», иногда нужно убрать метрику или завершить представление. Правило выбирают по сценарию и доступным API.

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

15. Архитектура: единая задача, отдельные адаптеры

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

Иллюстративная модель события может выглядеть так. Это собственная схема приложения, не формат SDK:

{
  "activityId": "delivery_204",
  "revision": 18,
  "phase": "courier_approaching",
  "updatedAt": "2026-11-05T12:06:00Z",
  "validUntil": "2026-11-05T12:08:00Z",
  "estimatedArrivalAt": "2026-11-05T12:10:00Z",
  "allowedActions": ["open_order", "contact_courier"],
  "privacyClass": "personal"
}

revision помогает отклонить запоздавшее обновление. validUntil задаёт срок доверия к данным. estimatedArrivalAt хранит прогноз времени, а не заранее отформатированную строку «4 мин». Локализация и представление остаются задачей адаптера. Поле приватности определяет, какие сведения вообще могут попасть на общедоступную поверхность.

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

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

Транспорт выбирают отдельно: APNs/ActivityKit, Android-механизм уведомлений, OEM-push, локальное обновление или синхронизация часов. Нельзя предполагать, что живой интерфейс сохраняет процесс приложения в памяти. Нельзя и использовать foreground service только как способ удержать рекламную карточку. План фоновой работы должен соответствовать реальной задаче и правилам ОС.

16. Разрешения, приватность, доступность и цена внимания

Начиная с Android 13 большинство уведомлений требуют POST_NOTIFICATIONS. Запрашивать разрешение стоит в момент понятной пользы: после выбора «следить за поездкой», а не поверх первого знакомства с приложением. При отказе покажите, где проверить состояние вручную; не повторяйте один и тот же запрос при каждом запуске.

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

Для приватности подготовьте отдельное безопасное содержание: «Есть обновление заказа» вместо адреса, имени и суммы. Чувствительное действие должно проходить требуемую проверку личности. Открыть детали и подтвердить финансовую операцию — разный уровень полномочий, даже если обе кнопки помещаются в одну карточку.

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

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

17. Что проверять перед выпуском

Матрица тестирования строится по комбинации устройство × сборка ОС × регион × версия приложения × настройки × сценарий. Бренда и номера Android недостаточно. Для критической OEM-интеграции нужна проверка реального устройства целевого рынка, а не только эмулятора.

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

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

18. Как измерять пользу, если открытий приложения стало меньше

Успешная интеграция может уменьшить количество открытий. Если раньше человек пять раз проверял курьера, а теперь один раз посмотрел на часы, падение app opens не означает ухудшение продукта. Поэтому метрики нужно привязать к выполненной задаче.

• Усилие: число переходов и время до ответа на конкретный вопрос.
• Результат: успешные посадки, завершённые действия, доля пропущенных важных изменений.
• Надёжность: задержка обновлений, случаи устаревшего состояния, ошибки команд.
• Цена: батарея, сеть, стоимость поддержки разных интеграций.
• Контроль пользователя: отключения, скрытия, жалобы на повторные сигналы.

Разделяйте ступени воронки: устройство поддерживает механизм → разрешение выдано → запрос принят → состояние представления подтверждено доступным API → человек взаимодействовал → задача выполнена. Доступного API для фактического просмотра может не быть. Не записывайте «показ» только потому, что сервер отправил push, а отсутствие нажатия не трактуйте автоматически как отсутствие пользы.

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

19. Практический план внедрения

1. Опишите одну задачу. Кто ждёт какого изменения, что делает дальше и когда показ заканчивается.
2. Проверьте аудиторию. ОС, модели, рынки, часы, частота сценария. Не выбирайте OEM по эффектности презентации.
3. Соберите базовый путь. Достоверное состояние в приложении или на сайте, нужные уведомления, корректные ссылки и разрешения.
4. Выберите одну внешнюю поверхность. Доставка — текущая активность; привычки — виджет; аудио — медиасессия; тренировка — часы.
5. Опишите все состояния и действия. В том числе устаревание, скрытие и завершение. Затем рисуйте размеры и анимацию.
6. Проверьте платформенный доступ. Публичный API, версии, OEM-допуск, регион, лимиты, правила распространения.
7. Запустите на ограниченной совместимой группе. Проверьте результат задачи и цену внимания; расширяйте после подтверждения пользы.

Такой порядок не задаёт универсального «сначала острова, потом часы». Для музыкального приложения первая инвестиция — медиасессия, для спортивного — самостоятельный сценарий на запястье, для билетов — Wallet. Лучшей будет поверхность, которая помогает вашей аудитории в её реальном контексте.

Сначала найти возможности проекта, затем выбрать сценарии

Оба скилла поддерживают отдельный режим исследования. Агент изучает реальные экраны, пользовательские задачи, данные, нативные targets и уже подключённые API, затем предлагает подходящие сценарии: какую повторяющуюся работу они снимают, где будут доступны, чего не хватает для реализации и насколько велик объём изменений. Форматы и интеграции, которые проекту не подходят, должны получить понятное объяснение, а не попасть в обязательный список.

Предложения получают короткие ID. Человек выбирает, что реализовать сейчас, отложить или исключить; агент сохраняет этот выбор и переходит к реализации выбранного. Рекомендованный набор сам по себе не считается решением пользователя. Если конкретная задача уже поставлена — например, сделать виджет заказов, — повторный выбор не нужен.

Пример запроса: $interaction-surfaces — «Проанализируй мой проект, предложи полезные сценарии с пользой, зависимостями и оценкой сложности. Дай выбрать нужные до реализации». Для перестройки интерфейса по размерам окна и положению устройства тот же режим есть в $adaptive-interfaces.

Отдельный скилл для адаптивных сайтов и приложений

По результатам этого исследования мы создали скилл Interaction Surfaces для Codex и Claude Code и скилл Adaptive Interfaces. Они помогают проанализировать существующий сайт или приложение, определить доступные API и предложить полезные сценарии: виджеты, текущие активности, часы, дополнительные экраны и адаптацию интерфейса. Вы выбираете, что внедрить, отложить или исключить; затем агент реализует выбранные изменения и проверяет результат в пределах доступных платформ и устройств.

Для работы с форматами окна можно установить Adaptive Interfaces из репозитория на GitHub. Английский пакет охватывает веб/PWA, Android, Apple, React Native и Flutter: узкие окна, landscape, Flip/Fold, сгиб, клавиатуру, safe areas, масштаб текста и сохранение задачи при переходах.

В Codex можно передать команду встроенному установщику:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/adaptive-interfaces

После клонирования репозитория разместите содержимое папки skills/adaptive-interfaces в ~/.agents/skills/adaptive-interfaces/. Для явного вызова используйте $adaptive-interfaces; автоматический выбор по подходящей задаче тоже разрешён. Доступ к фирменному экрану и реальная проверка на устройстве по-прежнему нужны для соответствующей интеграции.

Скилл для Codex и Claude Code: применить подход в своём проекте

Подход этой серии можно передать ИИ-агенту: установить скилл Interaction Surfaces из GitHub. Пакет написан на английском и помогает выбирать полезные поверхности взаимодействия при разработке интерфейса, даже когда в задаче ещё не названы островки, виджеты или часы.

Внутри — инструкции по реализации, примеры и ссылки на официальную документацию:

• Полезные виджеты: выбор повторяющейся задачи, WidgetKit, Android App Widgets/Glance, конфигурация, действия, данные и обновления.
• Android: Live Updates, разрешения, ProgressStyle и MetricStyle, Kotlin-пример, диагностика продвижения и подключение OEM-сценариев.
• Apple: ActivityKit, WidgetKit, состояния Dynamic Island, Swift-пример, App Intents и обновления через APNs.
• Часы: Apple Watch и Wear OS, complications, виджеты и Tiles, HealthKit, Health Services, WatchConnectivity и Data Layer.
• Дополнительные экраны: DisplayManager, Presentation, WindowManager, Glyph Matrix и проверка реального доступа к фирменным панелям.

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

Установка из GitHub: в Codex можно передать эту команду встроенному установщику скиллов:

$skill-installer install https://github.com/wladislaw353/agent-skills/tree/main/skills/interaction-surfaces

В Claude Code можно установить всю коллекцию из этого же GitHub-репозитория как плагин. Отдельная инструкция для Claude Code содержит команды установки и обновления. После установки доступны /agent-skills:adaptive-interfaces и /agent-skills:interaction-surfaces. При ручной установке отдельных папок в ~/.claude/skills/ используются короткие имена /adaptive-interfaces и /interaction-surfaces.

Установка: склонируйте репозиторий с GitHub и скопируйте папку skills/interaction-surfaces целиком в ~/.agents/skills/. Файл должен оказаться по пути ~/.agents/skills/interaction-surfaces/SKILL.md; папки references и agents сохраните рядом. Это пользовательский каталог из документации OpenAI по локальным скиллам.

Для явного вызова напишите в Codex: $interaction-surfaces и опишите задачу, например: «Спроектируй отслеживание заказа для iOS и Android, выбери подходящие внешние поверхности и реализуй их в текущем проекте». Автоматический выбор скилла тоже разрешён. Если он не появился после установки, перезапустите Codex.

Ответы на частые вопросы

Хороший внешний интерфейс вовремя исчезает

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

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