{ "version": "https:\/\/jsonfeed.org\/version\/1.1", "title": "Пользовательский интерфейс", "_rss_description": "Принципы и методы Решение по-эпловски Ховер из овер", "_rss_language": "ru", "_itunes_email": "ilyabirman@ilyabirman.ru", "_itunes_categories_xml": "<\/itunes:category>\r\n<\/itunes:category>\r\n\r\n", "_itunes_image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic-square@2x.jpg?1573933764", "_itunes_explicit": "no", "home_page_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/ui\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/ui\/json\/", "icon": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764", "authors": [ { "name": "Илья Бирман", "url": "https:\/\/ilyabirman.ru\/meanwhile\/", "avatar": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/userpic\/userpic@2x.jpg?1573933764" } ], "items": [ { "id": "6735", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/fresh-ideas-wont-help\/", "title": "Если интерфейс плохой, дело не в недостатке идей", "content_html": "

Оказался участником обсуждения некоего интерфейса. Пригласивший меня человек говорил, что им нужны свежие идеи. Мол, интерфейс плохой, и мы никак не можем придумать, как улучшить — уже всех дизайнеров в компании попросили предложить свои варианты, а всё равно чё-то не то. Говорит, может, ты каких-то ещё свежих идей принесёшь.<\/p>\n

Разумеется, как всегда оказалось, что дело не в недостатке свежих идей. Дело в том, что никто не хочет делать обычную работу проектировщика: выделять сценарии, применять теорию близости и закон Фиттса, редактировать текст. Хороший интерфейс появляется не в результате озарения, а в результате вдумчивого проектирования. Но, похоже, большинству людей это кажется скучным и занудным, и они мечтают, чтобы у них хороший интерфейс появился как-нибудь чудом.<\/p>\n", "summary": "Оказался участником обсуждения некоего интерфейса. Пригласивший меня человек говорил, что им нужны свежие идеи", "date_published": "2026-05-18T22:44:05+05:00", "date_modified": "2026-05-18T22:43:05+05:00", "tags": [ "пользовательский интерфейс", "сценарный подход" ], "_date_published_rfc2822": "Mon, 18 May 2026 22:44:05 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6735", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "6729", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/toasts-obstruct\/", "title": "Тосты загораживают интерфейс", "content_html": "

Плохим интерфейсом являются так называемые «тосты» — уведомления, временно выезжающие из-под низа. Разумеется, они являются частным случаем попапа, а значит, согласно теореме Горбунова о попапах, это самое тупое, что можно сделать.<\/p>\n

\n\"\"\n<\/div>\n

Когда публикуешь фотографию в экстремистской соцсети, а потом готовишься опубликовать ещё одну, соцсеть решает уведомить тебя тостом об успехе предыдущей публикации, и этот тост загораживает синюю кнопку публикации или перехода к следующему шагу. Очень точным движением тост можно смахнуть вниз, но если не научиться этому, то остаётся просто ждать несколько секунд, пока он исчезнет.<\/p>\n

Можно представить интерфейс, в котором уведомление именно такого вида и именно в этом месте будет наиболее удобно, но если такой вид уведомлений становится частью дизайн-системы и показать его становится вопросом одной строчки кода, то он неизбежно начнёт использоваться везде, ведь разработка кастомного удачного уведомления будет расцениваться как нецелесообразная трата ресурсов. Поэтому в хорошей дизайн-системе такого элемента просто не должно быть.<\/p>\n", "summary": "Плохим интерфейсом являются так называемые «тосты» — уведомления, временно выезжающие из-под низа. Разумеется, они являются частным случаем попапа, а значит", "date_published": "2026-05-12T20:54:18+05:00", "date_modified": "2026-05-12T20:57:57+05:00", "tags": [ "пользовательский интерфейс" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/instagram-toasts@2x.jpg", "_date_published_rfc2822": "Tue, 12 May 2026 20:54:18 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6729", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/instagram-toasts@2x.jpg" ] } }, { "id": "6728", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/sort-vs-filter\/", "title": "Сортировка и фильтрация", "content_html": "

Заметил, что многие дизайнеры интерфейса не отличают сортировку и фильтрацию. Говорят: «тут можно отсортировать квартиры по конкретному району». Иногда это просто оговорка и на понимание не влияет. Но в моей жизни такие разговоры чаще всего случаются как раз в обсуждении деталей поведения сложных интерфейсов. За неверным выбором слов часто скрывается и недопонимание сути, а как следствие — фиговое проектирование.<\/p>\n

Сортировка — это когда у вас есть массив данных, и вы выбираете в каком порядке показывать эти данные: по убыванию цены, по возрастанию рейтинга или по дате изменения.<\/p>\n

Фильтрация — это когда у вас есть массив данных, и вы выбираете, какую его часть показать: только у моря и с завтраком, с массой в пределах от 0,5 до 3 масс Солнца или только содержащие подстроку «жопа».<\/p>\n

Если у вас 1183 записи, то как их ни сортируй, их останется 1183, а при фильтрации будет показана только их часть.<\/p>\n

Значения какого-то поля у многих записей могут совпадать, скажем, у сотни треков в музыкальной коллекции может быть один и тот же исполнитель. Тогда сортировка может быть вложенной, например треки можно отсортировать по названию исполнителя; внутри исполнителя — по дате релиза; внутри релиза — по произвольному порядковому номеру трека в релизе. Дать пользователю управлять такими нюансами в интерфейсе — нетривиальная задача.<\/p>\n

Ещё замечу, что когда мы говорим «сортировать по тому-то», мы можем иметь в виду как само поле, которое используется для упорядочивания (по имени), так и принцип этого упорядочивания (по убыванию, по алфавиту). Мы можем брать даже какую-то производную поля и уже её упорядочивать, например, можно отсортировать студентов по убыванию длины имени или города по возрастанию населения.<\/p>\n

Строго говоря, сортировка по алфавиту это тоже сортировка по производной поля: мы упорядочиваем по возрастанию порядковых номеров букв в алфавите. Причём это сортировка вложенная: все слова, у которых первая буква одинаковая, мы ещё сортируем по возрастанию порядковых номеров вторых букв в алфавите и так далее. Разумеется, мы об этом не задумываемся, когда говорим «сортировать по алфавиту», но это полезно понимать для стройности мыслей при проектировании сложных систем.<\/p>\n

Путаница между сортировкой и фильтрацией возникает потому, что и то и другое связано с полями отображаемых записей. Какая-нибудь вклада «новые» в интерфейсе может как сортировать сообщения по времени, например, показывать более новые в начале, так и фильтровать их, например, показывать только добавленные с прошлого раза.<\/p>\n

Отсортировать по району можно: сначала показать записи из Аннина, потом из Бутова, потом из Внукова. Придётся ещё решить, как сортировать записи уже внутри района, ведь их явно будет много в каждом. Но вот отсортировать «по конкретному району» невозможно: это всё равно что отсортировать всех по конкретному росту 172 см.<\/p>\n

Когда вы проектируете систему, в которой люди будут работать со сложными данными, у вас должны быть сценарии использования, связанные с необходимостью взгляда на эти данные под разным углом, и понимание буквального смысла каждого из этих углов. Если вы путаетесь в сортировке и фильтрации, скорее всего, у нас нет ясности о том, что именно человек сможет увидеть в интерфейсе и каким образом он этого добьётся.<\/p>\n", "summary": "Заметил, что многие дизайнеры интерфейса не отличают сортировку и фильтрацию. Говорят: «тут можно отсортировать квартиры по конкретному району»", "date_published": "2026-05-12T11:58:59+05:00", "date_modified": "2026-05-12T11:58:51+05:00", "tags": [ "пользовательский интерфейс", "ясность" ], "_date_published_rfc2822": "Tue, 12 May 2026 11:58:59 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6728", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [] } }, { "id": "6727", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/github-desktop-verify-identity\/", "title": "Гитхаб-десктоп зачем-то пытается верифицировать идентичность", "content_html": "

\n\"\"\n<\/div>\n

Гитхаб-десктоп зачем-то всё время пытается верифицировать идентичность какого-то своего сервера. И если у него это не получается, то он мне об этом сообщает, фокусируя собственное окно поперёк всего.<\/p>\n

А мне вообще насрать, дорогой, я даже не смотрел в тебя последние две недели! Ну не побегу я щас разбираться, чего тебе не хватает или почему не работает интернет.<\/p>\n

Да и даже если бы я что-то делал в Гитхаб-десктопе прямо сейчас. Дался ему этот сервер! Я не пользуюсь гитхабом, у меня репозиторий вообще в другом месте.<\/p>\n", "summary": "Гитхаб-десктоп зачем-то всё время пытается верифицировать идентичность какого-то своего сервера. И если у него это не получается, то он мне об этом сообщает", "date_published": "2026-05-10T20:20:51+05:00", "date_modified": "2026-05-10T20:20:40+05:00", "tags": [ "модальность", "пользовательский интерфейс", "привычка" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/github-desktop-verify-identity@2x.jpg", "_date_published_rfc2822": "Sun, 10 May 2026 20:20:51 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6727", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/github-desktop-verify-identity@2x.jpg" ] } }, { "id": "6725", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/saved-for-later\/", "title": "Интерфейсное место для отложенного на потом", "content_html": "

Интерфейсы постоянно донимают людей и что-то им предлагают, как назойливые торговцы на популярных пляжах. И часто у них встречаются кнопки типа «Потом», «В другой раз», «Не сейчас».<\/p>\n

Понятно, что обычно это просто такое «Нет», которое как бы оставляет авторам моральное право спросить ещё раз. Как если бы ты позвал девушку на свидание, а ей было бы запрещено говорить «нет»; максимум «в другой раз».<\/p>\n

Но я снова хочу рассмотреть случай, когда я действительно заинтересовался предложением и хочу его изучить, просто не сейчас. Проблема, напомню, в том, что когда у меня будет время, я нигде ваше предложение не найду.<\/p>\n

Раз уж у всех операционных систем уже есть подсистема уведомлений, то что, если мы там предусмотрим стандартное место для всего, что «Не сейчас»? Чтобы я хотя бы смог вернуться и найти там то, что ранее отмёл.<\/p>\n

Если я жму «Потом», то я хочу сам контролировать, когда это потом наступит, а не ждать, что какая-то внешняя сила решит, когда пристать ко мне снова.<\/p>\n", "summary": "Интерфейсы постоянно донимают людей и что-то им предлагают, как назойливые торговцы на популярных пляжах", "date_published": "2026-05-09T20:26:28+05:00", "date_modified": "2026-05-09T09:08:36+05:00", "tags": [ "пользовательский интерфейс" ], "_date_published_rfc2822": "Sat, 09 May 2026 20:26:28 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6725", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6717", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/kak-vlezat-k-polzovatelyu-so-svoey-fignyoy\/", "title": "Как влезать к пользователю со своей фигнёй", "content_html": "

Есть разные способы рассказывать пользователю о своих новых фичах, часть из них плохие, а часть — нормальные. Предлагаю простой критерий для отделения плохих вариантов от нормальных без использования слова «попап» и вообще интерфейсных терминов и моральных оценок. Важно понять суть конфликта и использовать действующие силы максимально эффективно.<\/p>\n

Вот вы сообщаете, что у вас что-то новое, приглашаете этим воспользоваться.<\/p>\n

Вопрос: есть ли у пользователя очевидная возможность всё-таки продолжить делать то, за чем он пришёл, не теряя ваше сообщение?<\/i> Вот почему это важно для бизнес-целей вашего сообщения.<\/p>\n

Если пользователь может продолжить своё, только отклонив ваше,<\/b> то у сообщения очень мало шансов заинтересовать, ведь желание его закрыть огромно — всё внимание направлено на избавление, а не на суть сообщения. Получается, вы вызываете раздражение у каждого<\/i> пользователя, но за эту цену обращаетесь лишь к немногим<\/i>.<\/p>\n

Более того, рассмотрим отдельно этих немногих, кто всё-таки успел заинтересоваться. Им теперь нужно выбирать<\/i> между вашим сообщением и тем, что они хотели изначально! Им нужно и то и то, но они вынуждены взять что-то одно. Ваше сообщение должно не просто заинтересовать и пробиться сквозь раздражение; оно должно разгромно выиграть конкуренцию с изначальным намерением пользователя! Получается абсурд: для пользователя лучше, чтобы ваше сообщение оказалось бесполезным, тогда он хотя бы просто отмахнётся от него и испытает меньше страданий.<\/p>\n

Если пользователь может продолжить своё, только отклонив ваше, вы вызываете максимум раздражения и получаете минимум полезного эффекта.<\/p>\n

Если пользователь может продолжить своё, не отклоняя ваше,<\/b> то на пользователя никак не давит необходимость сделать выбор. Ваше сообщение не мешает ему продолжать делать своё дело, а значит его внимание не тратится на избавление от вашего сообщения. Освободившееся внимание может быть потрачено на суть сообщения, а значит сообщение с большей вероятностью заинтересует.<\/p>\n

Более того, все те, кого ваше сообщение заинтересовало, смогут воспользоваться предложением в нём, причём независимо от того, выиграло ли оно конкуренцию с исходным планом. Если выиграло разгромно, пользователь с радостью пойдёт за вами. Если просто заинтересовало, пойдёт или сначала за вами, потом по своим делам, или наоборот. Если вообще не заинтересовало, оно вызвало намного меньше раздражения, потому что ничему не помешало.<\/p>\n

Если пользователь может продолжить своё, не отклоняя ваше, вы вызываете минимум раздражения и получаете максимум полезного эффекта.<\/p>\n

Итак, не так важно, какие именно элементы интерфейса вы используете. Просто проверьте, вынуждаете ли вы пользователя отмахиваться от вас или всё-таки даёте себе шанс получить достаточное внимание.<\/p>\n", "summary": "Есть разные способы рассказывать пользователю о своих новых фичах, часть из них плохие, а часть — нормальные", "date_published": "2026-04-22T22:42:39+05:00", "date_modified": "2026-04-22T22:45:33+05:00", "tags": [ "дизайн продуктов", "пользовательский интерфейс" ], "_date_published_rfc2822": "Wed, 22 Apr 2026 22:42:39 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6717", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6703", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/skeleton-state\/", "title": "«Скелет» как состояние компонента и экрана", "content_html": "

Столкнулся с дизайн-системой, где у всех компонентов отрисованы состояния «скелет» — это типа как выглядит элемент, пока он не загрузился. Дизайнеры вообще говорили «скелетон», но скелетон — это такой бобслей для одиночек, а skeleton — это скелет. С этим состоянием есть проблема, сейчас объясню.<\/p>\n

\n\"\"\n<\/div>\n

Пока экран приложения загружается, вместо индикаторов загрузки хорошо показывать скелет экрана. Тогда вместо того, чтобы привлекать внимание к тормозам, мы создаём у пользователя впечатление, что экран почти загрузился. Секундные задержки перестают ощущаться, человек успевает сориентироваться на экране.<\/p>\n

Так что же не так с состоянием компонента «скелет»? То, что скелет — это состояние экрана целиком, а не отдельного компонента. (Если уж на то пошло, у компонента может быть состояние «кость», а не «скелет».)<\/p>\n

Во-первых, рисование отдельных скелетных состояний компонентов провоцирует дизайнеров на рисование излишне детализированных скелетов экранов. Вот Вконтакте например:<\/p>\n

\n\"\"\n<\/div>\n

Зачем столько мусора? Чтобы показать, что экран ещё грузится, достаточно такого:<\/p>\n

\n\"\"\n<\/div>\n

Да и ещё спокойнее можно.<\/p>\n

Во-вторых, во время загрузки экрана он обычно не знает, какие именно компоненты на нём будут, чем они будут наполнены, какого они будут размера. То есть даже непонятно, какие именно компоненты в этом состоянии «скелет» туда ставить, приходится выдумывать. В то же время, если какие-то элементы на экране нужны независимо от подгружаемых данных, скажем, кнопки навигации, то их стоит сразу показывать в нормальном виде, безо всяких скелетов.<\/p>\n

В-третьих, даже если представить, что сам набор элементов известен сразу, а подгружается только их наполнение, то получается довольно неприятный эффект, когда во время загрузки на экране в случайные моменты появляются разные блоки, постоянно что-то прыгает, отталкивает то, что ниже. То есть даже в этом случае лучше нарисовать весь экран в скелетном состоянии, а когда загрузилось достаточно данных для его стабильного построения — тогда показать всё на своих местах.<\/p>\n", "summary": "Столкнулся с дизайн-системой, где у всех компонентов отрисованы состояния «скелет» — это типа как выглядит элемент, пока он не загрузился", "date_published": "2026-03-31T12:38:47+05:00", "date_modified": "2026-04-01T00:35:20+05:00", "tags": [ "обратная связь", "пользовательский интерфейс" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/skeleton@2x.png", "_date_published_rfc2822": "Tue, 31 Mar 2026 12:38:47 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6703", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/skeleton@2x.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/vk-skeleton-detailed@2x.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/vk-skeleton-sane@2x.png" ] } }, { "id": "6636", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/kniga-andreya-markelova-putevoditel-po-knopkam\/", "title": "Книга Андрея Маркелова «Путеводитель по кнопкам»", "content_html": "

Прочитал книгу Андрея Маркелова «Путеводитель по кнопкам<\/u>»<\/a>:<\/p>\n

\n\"\"\n
Картинка с сайта издательства<\/div>\n<\/div>\n

Никогда не слышал об Андрее Маркелове, а он вдруг написал большую книгу об интерфейсе.<\/p>\n

В целом книга полезная, и я рекомендую её прочитать всем дизайнерам интерфейса после того, как они прочитают мою книгу<\/a>.<\/p>\n

И всё же к книге есть вопросы. Во-первых, я несогласен с некоторыми мыслями:<\/p>\n