Обратная совместимость UI
2026-02-26 15:01 Diff
https://ru.hexlet.io/blog/posts/ui-compatibility

Это перевод статьи Дэна Лу UI backwards compatibility.

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

Zulip

Как-то Zulip (конкурент Slack) поменял своё поведение и комбинация ctrl + enter стала отправлять сообщение, вместо вставки новой строки. После этого изменения я отправил несколько неполноценных сообщений и, как оказалось, таких как я было не мало.

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

Двери

Не так давно я был в кафе Black Seed Bagel, у них дверь на 75% выглядит как дверь, которую нужно толкать и снаружи и изнутри, а на самом деле её нужно толкать снаружи и тянуть на себя изнутри. Дополнительная догадка, которая сильнее ассоциирует дверь с открывающейся в сторону улицы: в большинстве заведений двери нужно толкать (это требование распространяется в США, при условии, что наполненность помещения более 50 человек, но многие бизнесы и в более мелких пространствах добровольно следуют этому соглашению). В течение часового разговора я видел множество людей, которые входили и выходили, и, кажется, десять человек провалили первую попытку открыть дверь при выходе. Когда люди приходили парами или группами, тот человек, который шёл первым обычно говорил: «Вот я идиот. Мы же заходили сюда минуту назад». Но это не люди идиоты. Если тут и есть проявление идиотизма, то оно в создании дверей, которые заставляют пользователя запоминать, какие двери ведут себя как нормальные, а какими нужно пользоваться по обратной схеме.

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

Facebook

Когда-то Facebook изменил свой интерфейс, и привычный набор кликов стал сохранять пост, вместо того, чтобы скрывать его. Сохранение, можно сказать, прямая противоположность скрытию! Противоположность и с точки зрения пользователя, и с точки зрения сигнала для счётчика фида. Что самое «крутое»: когда вы измеряете «степень вовлечённости пользователя» количеством кликов после таких изменений, А/B тесты проходят с невероятным успехом в пользу нововведения, потому что многие пользователи случайно сохраняют пост, а в реальности планировали скрыть его. Twitter сделал нечто подобное, поменяв расположение секций "moments" и "notifications".

Даже если тот, кто делал эти изменения, не задумывал обмануть пользователей для искусственного усиления вовлечённости, такие изменения всё равно проблематичны — они травят аналитические данные. Хоть это и возможно технически, построить модель, которая будет отличать случайные и целенаправленные клики, этим редко кто занимается (лично я не знаком ни с одним А/B тестом, в котором кто-то реализовал подобный механизм). Даже в моделях, где очевидно, что пользователи случайно запустят процесс, я до сих пор встречаю разработчиков и project-менеджеров, оправдывающих какую-нибудь фичу только из-за её невероятного влияния на наивную статистику, вроде DAU/MAU.

Обратная совместимость программных интерфейсов (API)

Когда дело касается софтовых API, есть точка зрения: никогда не стоит нарушать обратную совместимость некоторых классов широко используемого софта. Известный пример — Линус Торвальдс:

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

Я отказываюсь вводить в свою практику заявления, вроде: «вы можете обновить ядро только если обновите эту программу». Если система обычно работала для вас, правило — она продолжает работать для вас. …Я видел и могу указать на множество проектов, которые существуют в стиле: «Ради прогресса нужно ломать положительные впечатления пользователя» или «вы полагались на недокументированное поведение, хреново оказаться на вашем месте» или «есть улучшенный способ делать то, что вы делаете, и вам придётся пользоваться этим новым улучшенным способом». И я не считаю, что такое допустимо где-либо кроме ранних альфа-релизов для экспериментальных пользователей, которые знают, на что согласились. Ядро Линукса последние два десятилетия так себя не вело. …Мы ломаем внутрисистемный интерфейс постоянно. Мы исправляем внутренние проблемы, говоря «вам нужно сделать XYZ», но затем всё и остаётся только на уровне внутреннего API системы, а люди, которые всё это сделали, очевидно, должны всё починить для внутрисистемных пользователей API. Никто не должен говорить: «Я ломаю API, которым вы пользуетесь, а чинить его будете вы сами».

Кто бы что не сломал, чинит он это сам. …Мы просто не ломаем пространство пользователя.

Реймонд Чен (Microsoft) отвечает на комментарий:

Посмотрите на сценарий с точки зрения заказчика. Вы покупаете программы X, Y и Z. Затем обновляете систему до Windows XP. В вашем компьютере теперь в случайном порядке происходят сбои, а программа Z не работает вообще. Вы советуете друзьям: «Не обновляйтесь до Windows XP. Он временами ломается и не совместим с программой Z». Планируете ли вы делать дебаг системы, чтобы определить, что программа Х вызывает сбои, а программа Z не работает, потому что использует незадокументированные детали API? Конечно, нет. Вы планируете вернуть Windows XP продавцу (Вы купили программы X, Y и Z несколько месяцев назад. 30-дневный срок возврата закончился. Единственная вещь, которую вы можете сделать — вернуть Windows XP).

Хоть это мнение — в меньшинстве, это меньшинство достаточно громкое и влиятельное.

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

Контраргумент этому мнению — сохранение совместимости вгоняет в технический долг. Это правда! Для примера. Linux полон как слегка, так и довольно сильно шатких программных интерфейсов из-за правила «не ломать пространство пользователя». Пример — int recvmmsg(int sockfd, struct mmsghdr *msgvec, unsigned int vlen, unsigned int flags, struct timespec *timeout);. Можно ожидать, что таймаут не сработает если нет получения пакета, но документация гласит:

The timeout argument points to a struct timespec (see clock_gettime(2)) defining a timeout (seconds plus nanoseconds) for the receive operation (but see BUGS!).

А в секции BUGS такое:

The timeout argument does not work as intended. The timeout is checked only after the receipt of each datagram, so that if up to vlen-1 datagrams are received before the timeout expires, but then no further datagrams are received, the call will block forever.

И это, возможно, не самая худшая особенность recvmmsg, которая возвращает ssize_t в поле размером с int.

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

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

Аргументировать обратную совместимость UI, одновременно, сложнее, чем совместимость API, потому что совместимость API малозатратна — если какой-то программный интерфейс неполноценен, можно сделать новый, а старый задокументировать как что-то, что не рекомендуется использовать (вы увидите множество подобных штук если заглянете в системные вызовы Linux). С GUI так не получится, поскольку элементы UI конкурируют друг с другом за небольшое количество доступного пространства экрана.

Изменение UI — не настолько прекрасная затея, как кажется большинству компаний. Сильно устаревший внешне UI, который не обновлялся в угоду трендам, может быть вполне успешным (например, plentyoffish и craigslist). Компании могут чрезвычайно преуспесть без каких-либо обновлений UI, не говоря уже о редизайне. Большой процент масштабного роста Linkedin пришёлся на период, когда изменения пользовательского интерфейса были практически заморожены. Заморозка UI была не взвешенным решением, напротив, это был побочный эффект тяжёлой технической задолженности, и что UI разморозили в тот же момент, когда обновления позволили спокойно изменять интерфейс. Linkedin добавил множество грязных механизмов после разморозки фронтэнда, но предыдущий UI, казалось, работал вполне удачно, учитывая рост.

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

Депрекация UI

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

Zulip тоже мог сделать что-то подобное.

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

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

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

Учитывая, сколько вкладывается усилий для того, чтобы исключить враждебные пользователям изменения и учитывая доминацию мантры «быстро двигаться и ломать вещи» ("move fast and break things"), дополнительные сложности ради улучшения пользовательского опыта, вероятно, не приживутся в большинстве компаний. Но теоретически такие подходы возможны.

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

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

Судя по исследованиям, всего 500мс задержки при загрузке страницы негативно сказываются на удержании пользователей. Если это правда, то частые изменения UI, такие, что пользователь вынужден по 5 секунд проводить на отмену действия или на то, чтобы публично опубликовать личное сообщение и не иметь возможности отменить это, должны иметь заметное влияние на удержание, хотя я не знаком ни с одним открытым исследованием подобной темы.

Вывод

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

Было бы здорово, если бы шорткаты не ломались так часто, и я не проводил бы столько времени сознательно останавливая себя, сколько я реально трачу на использование приложения. Но, вероятно, есть причины, такие штуки сложно тестировать и вводить в использование. Многообразие платформ, под которые нужно всё тестировать, превращают тестирование в сложную задачу, даже без добавления подобного теста. И даже когда мы говорим о проблемах функциональной корректности, «двигаться быстро и ломать вещи» намного популярнее, чем «пытаться ломать относительно мало вещей».

Поскольку «правильность» UI часто имеет даже меньший приоритет, чем функциональная корректность, не совсем понятно, как кто-то может склонять компании уделять интерфейсам больше внимания.

С другой стороны, несмотря на все эти оговорки, Google иногда делает абсолютно такие же ходы, как описаны в этом посте. Когда Chrome отменил шорткат для возврата на предыдущую страницу при клике на клавишу backspace, то при нажатии на backspace, появлялось сообщение, что вам нужно воспользоваться alt+left. А когда Google Maps поменял местами фичи, они вставили на место старых заглушки, которые указывали людям на новое расположение.

Это не значит, что Google всегда в этих вопросах делает всё хорошо: на 1 апреля в 2016 году Gmail заменил кнопку "send and archive" (отправить и заархивировать) на "send and attach a gif that's offensive in some contexts" (отправить и прикрепить gif, который оскорбителен в определённых контекстах), но эти примеры указывают, что поддержка старых версий при весомых изменениях, не просто гипотетическая идея — её могут реализовать и реализуют.