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. Доступ до панелі перевіряється окремо, а перебудова інтерфейсу — усередині дозволеного вікна. Знімок настільного браузера з вузькою шириною також не підтверджує роботу фізичного згину або реальної мобільної клавіатури.

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

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.

Відповіді на часті запитання

Гарний зовнішній інтерфейс вчасно зникає

Сила цих технологій у тому, що людині не доводиться постійно обслуговувати застосунок своєю увагою. Вона отримує відповідь, приймає рішення та продовжує займатися своєю справою. Для цього потрібно більше, ніж приваблива анімація: зрозуміла модель завдання, достовірні дані, повага до налаштувань та перевірена сумісність.

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