No magic
Stanislav Dombrovsky
Mobile Developer in the past. Former product manager in AppCode. Engineer.
· 5 min read

Будущее интерфейсов мобильных ОС

Язык этого эссе предельно тяжел, автор давно не писал. Дальше будет лучше.

Тихая революция, которую никто не заметил

Никто не заметил Meego Harmattan. Изначальный хайп вокруг новой мобильной ОС быстро стих, пара-тройка устройств, которые выматывали нервы фанатам ещё до Harmattan, N900, который владельцы потом хранили годами как «лучший телефон с клавиатурой», N950, который получили только разработчики, чтобы наполнить магазин приложений для N9, N9, который никому особенно не был нужен, Элоп, крах производства смартфонов Nokia — весь этот круговорот событий не дал заметить тихую революцию, которую каким-то чудом успели совершить инженеры и дизайнеры.

Инженеры показали, как из дешёвого кодека и правильно спроектированного корпуса можно выжать практически студийное качество звукозаписи — я говорю это потому, что мой N950 мог записать рок-концерт из первого ряда с таким качеством звука, что многие хватались за голову, воя: «Да как, чёрт побери, это вообще возможно». А еще потому, что как-то раз на конференции разгворился с инженером из Nokia, который участвовал в создании корпуса N950.

А дизайнеры случайно убили концепцию бизнес-приложений. Заодно они убили концепцию «уникального набора контролов», показав, что набор будет одинаковым для всех и на деле он не имеет значения. Это было тысячу лет назад, и этого никто не заметил.

В плане набора контролов всё было просто — дизайнеры смогли увязать глянец iOS с практичностью андроидных концептов. Сейчас сложно аргументированно ткнуть в тысячи мелких совпадений, здесь скорее важно ощущение от интерфейса, которое возникало тогда — в этом «тогда» ещё, кажется, только-только появился Android 4. И эта гибкость дала понять, что в будущем основной набор компонентов пойдёт по одному и тому же, наиболее простому и функциональному пути. Иллюзия возможности уникального пути рухнула.

Но более критичными были отдельные элементы интерфейса, которые практически убирали необходимость в десятках приложений. Тебе хочется посмотреть новые посты из Facebook или Twitter? Уже есть отдельный экран, который после добавления аккаунта соцсети в настройках покажет тебе их. Тебе надо отправить сообщение в одну из них? Мессенджер уже это может.

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

Приложения не нужны

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

Скептики тогда говорили, что невозможно увязать в универсальный набор контролов Android и iOS, не говоря уже о мелких маргинальных ОС типа Windows Phone. На деле это оказалось более чем возможным даже на уровне кроссплатформенных фреймворков, не говоря о мультиплатформе (Kotlin Multiplatform). Они же говорили, что невозможно выслать с сервера логику приложений или пользовательский интерфейс — и они опять ошиблись. Пришла эра A/B‑тестирования, и необходимый механизм пришлось реализовать.

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

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

Недостаток кастомизации здесь легко можно компенсировать подписками на расширение возможностей того же источника контента — если нужен сильно изменённый UI, плати и получишь чуть больше. Но нет, никто не даст тебе ставить сто пятьдесят кнопок типа Send в окно дефолтного приложения для обмена сообщениями. Хватит одной.

Легаси

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

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

Зачем нам баг-трекер, если он повторяет мессенджер? Или ветку электронных писем, отображённую слегка по‑другому? Зачем нам вики, в которую дублируется информация из трекера (если повезёт), обсуждений на митингах (если повезёт), мессенджерах (опять — если сильно повезёт)? Зачем нам дублировать одну и ту же информацию в десятках различных представлений, при этом вручную? По инерции никто не задумывается и продолжает «делать как делали».

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

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

А как же уникальный полёт бабочки?

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

А нужна ли мобильная ОС как самостоятельная сущность?

В чистом виде — да не так, чтобы. На процессоре средних самсунгов уже спокойно можно запустить IntelliJ IDEA в линуксовой подсистеме. Я годами работал в Samsung Dex, и для абсолютного большинства задач среднего ноутбука мне вполне хватало телефона и монитора. Мобильный форм-фактор как самостоятельная сущность себя фактически изжил. Не нужен ноутбук, не нужен отдельно мобильник. Нужен мобильник с доком в виде среднего ноутбука. Учитывая, что будущее IDE (сред разработки, или того, что придёт им на смену) — в переносе всей тяжёлой работы на бэкенд с максимально легковесным фронтом, мощный ноутбук остаётся реально нужным лишь в малом количестве отраслей, где он имеет смысл не столько «ноутбук, который можно носить с собой», сколько «десктоп, который можно таскать с собой».

В этом смысле вся «мобильность» такой ОС — это урезанное представление десктопа и не более того.

Резюме

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