{ "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\/apple\/", "feed_url": "https:\/\/ilyabirman.ru\/meanwhile\/tags\/apple\/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": "6774", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/iphone-page-legal-stuff\/", "title": "Юридическая туфта на странице Айфона", "content_html": "

Я зашёл на страницу Айфона<\/a> и заметил, что юридическая туфта занимает половину её высоты:<\/p>\n

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

Я считаю, что нужно внедрить новую правоприменительную практику, согласно которой весь этот текст не считается и не может быть использован в качестве доказательства или обоснования чего бы то ни было. Там ведь написаны какие-то слова, чтобы защититься в суде в случае чего? Ну вот суды должны будут проходить так:<\/p>\n

\n

Пользователь: Я купил Айфон, прочитав о нём на странице, но оказалось, что он работает иначе. Эпл ввёл меня в заблуждение.<\/p>\n

Защитник Эпла: Однако на странице снизу под сноской 64 указано, что он работает иначе.<\/p>\n

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

И всё. Пусть включают все свои уточнения в основное повествование или пишут так, чтобы двусмысленности не возникало.<\/p>\n", "summary": "Я зашёл на страницу Айфона и заметил, что юридическая туфта занимает половину её высоты", "date_published": "2026-07-14T12:16:07+05:00", "date_modified": "2026-07-14T12:15:34+05:00", "tags": [ "Айфон", "Эпл", "юристы" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/iphone-page-legal-stuff.jpg", "_date_published_rfc2822": "Tue, 14 Jul 2026 12:16:07 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6774", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/iphone-page-legal-stuff.jpg" ] } }, { "id": "6771", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/think-on-65\/", "title": "Думаем дальше № 65 — «Никто не пользуется стеклянными сферами» с Никитой Прокоповым", "content_html": "

С Никитой Прокоповым обсуждаем ВВДЦ 2026 и дизайн программ для ЭВМ.<\/p>\n

Все выпуски подкаста:
\nЭпл<\/a> · Ютюб<\/a> · Я.Музыка<\/a> · Спотифай<\/a> · Мейв<\/a> · РСС для подкастного приложения<\/a><\/p>\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
0:00<\/td>\n Какой сигнал мы получили на ВВДЦ 2026 и чего ждём через год<\/td>\n <\/tr>\n
4:38<\/td>\n Предзаписанные и живые презентации<\/td>\n <\/tr>\n
6:26<\/td>\n Полировка и скучающие журналисты<\/td>\n <\/tr>\n
11:08<\/td>\n Золотые ворота: иконки в меню и в Доке<\/td>\n <\/tr>\n
17:33<\/td>\n Скругления углов окон. Историческая справка<\/td>\n <\/tr>\n
26:27<\/td>\n Выбеление интерфейса, возвращение тулбаров и наведение резкости<\/td>\n <\/tr>\n
32:52<\/td>\n Мнение Никиты о прозрачности в интерфейсе и теория Ильи о прозрачности в реальной жизни<\/td>\n <\/tr>\n
40:03<\/td>\n Двигунок жидкости стекла<\/td>\n <\/tr>\n
44:38<\/td>\n Пружинистые кнопки<\/td>\n <\/tr>\n
48:25<\/td>\n Тулбары и группы кнопок на них<\/td>\n <\/tr>\n
51:49<\/td>\n Синхронизация фоток<\/td>\n <\/tr>\n
54:45<\/td>\n Всё не так тормозит, но зачем оно вообще тормозит?<\/td>\n <\/tr>\n
1:06:54<\/td>\n Ощущение качества и надёжности от софта<\/td>\n <\/tr>\n
1:10:32<\/td>\n Каким должен быть редизайн и путь к эталонному решению<\/td>\n <\/tr>\n
1:15:34<\/td>\n Красота и привлекательность интерфейса. Ортопедический дизайн<\/td>\n <\/tr>\n
1:17:56<\/td>\n Все хотят оторвать боковые панели, а зря<\/td>\n <\/tr>\n<\/table>\n", "summary": "С Никитой Прокоповым обсуждаем ВВДЦ 2026 и дизайн программ для ЭВМ", "date_published": "2026-07-10T11:42:22+05:00", "date_modified": "2026-07-10T11:45:54+05:00", "tags": [ "дизайн", "Думаем дальше", "Мак", "пользовательский интерфейс", "Эпл" ], "_date_published_rfc2822": "Fri, 10 Jul 2026 11:42:22 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6771", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6758", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/commenting-apple-design-principles-2026\/", "title": "Прокомментирую новые дизайн-принципы Эпла", "content_html": "

Прокомментирую новые дизайн-принципы Эпла<\/a>.<\/p>\n

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

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

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

Дальше они говорят, что нужно давать анду и не задалбывать переспрашиваниями. Ну да. Ждём, когда сам Эпл это внедрит и перестанет постоянно спрашивать, можно ли приложению «Напоминания» прислать мне напоминания!<\/p>\n

Responsibility.<\/b> Если эйдженси касалось пользователя, то респонсибилити касается уже разработчика. Короче, редактора позвать забыли. Здесь имеется в виду, что не нужно выспрашивать у пользователя персональные данные и не объяснять, зачем. То же самое касается и запросов доступов и прав. Это правильно, но не тянет на принцип. Ну и снова, Эплам бы самим это освоить.<\/p>\n

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

Familiarity.<\/b> Ну типа не изобретайте велосипед, а используйте удачные и привычные решения. В целом я за, но неясно, как отличать то, что все друг к друга копируют бездумно и что пора улучшить, от того, что отлично работает и не требует изменений ради изменений. Мы рассказываем об этом в теме «Привычка» более внятно.<\/p>\n

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

И сюда же они засунули последовательность в навигации. Мол, определитесь, у вас тут вкладки или кнопки или что-то ещё. Это всё верно, но это другая тема.<\/p>\n

Flexibility<\/b>. Люди разные, так что программа должна адаптироваться. Вроде легко согласиться, но что конкретно это значит? Ведь из такого захода можно легко сделать вывод, что должно быть 100500 настроек.<\/p>\n

Потом говорят, мол, на телефоне человек хочет быстро тык-тык, а на Маке — глубокое взаимодействие. Из этого легко можно сделать вывод, что айфонные версии программы должны быть урезаны до минимума (а ведь Стив Джобс смеялся над baby software других платформ, уже когда представлял Айфон в 2007 году!).<\/p>\n

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

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

Simplicity<\/b>. Тут много болтовни про то, что лишнее надо убрать и писать нужно ясно. Но есть важная практическая мысль: нефиг прятать все функции в бургер. Это может и выглядит «просто», но пользоваться этим нифига не просто. И что надо, чтобы было именно пользоваться просто, а для этого может быть даже понадобится добавить информацию.<\/p>\n

Craft<\/b>. Они говорят важную вещь, что люди чувствуют, когда софт сделан некачественно так же, как они чувствуют, что одежда или мебель сделаны некачественно. В качестве примера приводят невыровненные иконки! Вот бы кто-нибудь в Эпле посмотрел этот доклад.<\/p>\n

Delight<\/b>. Мне радостно, что они прямо говорят, что этот делайт создаётся не добавлением украшений, а как раз через внимание к более приземлённым требованиям из начала списка. Это то, что я тоже всё время рассказываю: уважение к привычкам и соблюдение закона Фиттса куда больше дадут приятных эмоций пользователю, чем вымученный «эмоциональный дизайн».<\/p>\n", "summary": "Прокомментирую новые дизайн-принципы Эпла", "date_published": "2026-06-27T17:34:21+05:00", "date_modified": "2026-06-27T17:38:15+05:00", "tags": [ "Эпл" ], "_date_published_rfc2822": "Sat, 27 Jun 2026 17:34:21 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6758", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6766", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/carplay-scrubbing\/", "title": "Двигунок для перемотки в Карплее", "content_html": "

Заодно<\/a> ещё один момент про Карплей. В Ай-ОСе 27 анонсировали возможность перематывать музыку в нём, потащив за двигунок. Это отлично, но тут тоже возникает вопрос: а чем думали разработчики предыдущие десять лет, когда не давали это сделать? Это ж стандартное поведение ползунка, что за него можно потянуть. Значит, для аудио в Карплее его кто-то специально ломал.<\/p>\n

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

Рад, что до Эпла дошло, наконец, — но блин.<\/p>\n", "summary": "Заодно ещё один момент про Карплей. В Ай-ОСе 27 анонсировали возможность перематывать музыку в нём, потащив за двигунок", "date_published": "2026-06-27T00:10:47+05:00", "date_modified": "2026-06-27T00:10:44+05:00", "tags": [ "Карплей", "пользовательский интерфейс", "Эпл" ], "_date_published_rfc2822": "Sat, 27 Jun 2026 00:10:47 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6766", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6765", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/carplay-temporary-messages\/", "title": "Временные сообщения в Карплее", "content_html": "

Если у тебя Карплей, когда приходит сообщение, ты видишь что-то такое:<\/p>\n

\n\"\"\n
Изображение с сайта appletoolbox.com<\/div>\n<\/div>\n

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

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

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

Но на автомобиле это втройне важно. Причём это кажется настолько очевидным, что я даже не знаю, какой был ход мысли разработчика, который писал код убирания сообщения с экрана. Вероятно, просто никакого не было, потому что если бы там была мысль, то такого кода просто бы не возникло.<\/p>\n", "summary": "Если у тебя Карплей, когда приходит сообщение, ты видишь что-то такое", "date_published": "2026-06-26T14:22:53+05:00", "date_modified": "2026-06-27T00:10:41+05:00", "tags": [ "Карплей", "модальность", "пользовательский интерфейс", "Эпл" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/carplay-message.jpg", "_date_published_rfc2822": "Fri, 26 Jun 2026 14:22:53 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6765", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/carplay-message.jpg" ] } }, { "id": "6760", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/think-on-64\/", "title": "Думаем дальше № 64 — «Цифры подтверждают необходимость ухудшений» с Вадимом Плешковым", "content_html": "

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

Все выпуски подкаста:
\nЭпл<\/a> · Ютюб<\/a> · Я.Музыка<\/a> · Спотифай<\/a> · Мейв<\/a> · РСС для подкастного приложения<\/a><\/p>\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n
0:00<\/td>\n Войсы<\/td>\n <\/tr>\n
5:24<\/td>\n Вадим дизайнил отзывы в Озоне<\/td>\n <\/tr>\n
10:36<\/td>\n Как улучшению дизайна мешает структура компании<\/td>\n <\/tr>\n
14:04<\/td>\n Преодоление корпсопротивления и партизанские методы<\/td>\n <\/tr>\n
19:16<\/td>\n Засасывающая способность главных страниц маркетплейсов и другие метрики успеха<\/td>\n <\/tr>\n
25:30<\/td>\n Как оценить раздражение пользователя<\/td>\n <\/tr>\n
32:22<\/td>\n У дизайнера даже нет полномочий, чтобы получить цифры<\/td>\n <\/tr>\n
36:41<\/td>\n Чего ждать от Эпла на ВВДЦ-2026 (выпуск записан за несколько дней до)<\/td>\n <\/tr>\n
43:04<\/td>\n Связь между метриками, научным прогрессом и значением объяснений<\/td>\n <\/tr>\n
49:51<\/td>\n Как писать понимания и вообще решать большие и сложные задачи клиентов<\/td>\n <\/tr>\n
58:18<\/td>\n Редактировать ли понимание задачи по ходу проекта<\/td>\n <\/tr>\n
1:04:20<\/td>\n Структура документа «Понимание задачи»<\/td>\n <\/tr>\n
1:13:26<\/td>\n Что считать процессом понимания задачи, а что — уже работой над решением?<\/td>\n <\/tr>\n<\/table>\n

Канал Вадима: @overvision<\/a><\/p>\n", "summary": "С Вадимом Плешковым обсуждаем дизайн в корпорациях, включая Эпл, а также работу с пониманием задачи", "date_published": "2026-06-22T01:13:33+05:00", "date_modified": "2026-06-22T22:10:06+05:00", "tags": [ "дизайн продуктов", "Думаем дальше", "исследования", "понимание задачи", "Эпл" ], "_date_published_rfc2822": "Mon, 22 Jun 2026 01:13:33 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6760", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "6759", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/liquid-glass-2028\/", "title": "Ликвид-гласс ещё через год", "content_html": "

Помните, когда-то в Винде каждая кнопка была на собственной выпуклости?<\/p>\n

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

А потом решили, что это перебор, и убрали?<\/p>\n

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

Со временем рамок стало ещё меньше. Ну и Мак тоже через подобное проходил.<\/p>\n

Ликвид-гласс просто запустил этот же процесс. В этом году сделали тулбар, а в следующем уберут отдельные капельки под кнопками:<\/p>\n

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

Не является прогнозом. Это было бы слишком хорошо, чтобы быть правдой.<\/p>\n", "summary": "Помните, когда-то в Винде каждая кнопка была на собственной выпуклости?", "date_published": "2026-06-19T20:08:30+05:00", "date_modified": "2026-06-19T20:07:18+05:00", "tags": [ "дизайн", "пользовательский интерфейс", "Эпл" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/microsoft-word-95.png", "_date_published_rfc2822": "Fri, 19 Jun 2026 20:08:30 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6759", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/microsoft-word-95.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/microsoft-word-97.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/liquid-glass-2028@2x.jpg" ] } }, { "id": "6754", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/rational-screen-area-usage\/", "title": "Рациональное использование площади экрана", "content_html": "

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

Квиктайм при просмотре видео рисует интерфейс перемотки лишь на небольшую часть ширины экрана:<\/p>\n

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

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

Налоговая в выбиралке валюты не даёт увидеть, какую валюту я выбираю:<\/p>\n

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

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

Аналогично Гугль-фонтс прячет настройку шрифта вот в такое меню с прокруткой:<\/p>\n

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

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

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

А вот обратные примеры. У Спотифая не вместилось «С возвращением» и три кнопки на большой экран:<\/p>\n

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

Даже если предположить, что вы не хотите «отвлекать» меня от входа ничем интересным, ну уместить-то можно было это всё хотя бы? Хотя, конечно, я был бы больше мотивирован войти, если бы чувствовал, что внутри меня что-то ждёт хорошее.<\/p>\n

Яндекс-музыка туда же:<\/p>\n

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

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

В дефолтном дизайне Айтюнса на огромном 32″ 6К мониторе в высоту экрана влезает три трека! Три:<\/p>\n

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

Тут я затрудняюсь дать комментарий.<\/p>\n

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

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

Ну какой идиот, а? Ну вон же полно место по бокам, и это при моей любимой ширине окна 1024 даже1 Нахрена, нахрена ты обрезал названия?<\/p>\n

Кинопоиск спрятал две кнопки («Неинтересно» и «Просмотрен») в многоточие:<\/p>\n

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

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

А вот классический Лончпад Эпла:<\/p>\n

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

У него много проблем, но сама идея прекрасна: для выбора приложения используется весь экран. Целиться в иконки одно удовольствие. Бывает, захватил откуда-то файл одной рукой, тащишь его на место нужной программы, в это время другой жмёшь шорткат Лончпада и бросаешь файл на программу, потому что она как раз оказывается под курсором где надо.<\/p>\n

А сейчас что? Только вот так:<\/p>\n

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

Всему тесно, и чуть что возникает прокрутка.<\/p>\n

Как будто дизайнеры постоянно забывают, зачем нужен интерфейс, который они рисуют. Это превращается в какую-то формальность, типа, надо запихать на экран такие-то элементы, а значимость этих элементов и роль в сценарии пользователя вообще никак на это запихивание не влияет.<\/p>\n", "summary": "Одна из проблем, встречающихся в дизайне многих продуктов — нерациональное использование площади экрана", "date_published": "2026-06-14T18:33:02+05:00", "date_modified": "2026-06-14T18:32:52+05:00", "tags": [ "вёрстка", "Гугль", "дизайн", "дизайн продуктов", "дизайн сайтов", "пользовательский интерфейс", "эпицентрический дизайн", "Эпл", "Яндекс" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/quicktime-small-drag.jpg", "_date_published_rfc2822": "Sun, 14 Jun 2026 18:33:02 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6754", "_rss_enclosures": [], "_e2_data": { "is_favourite": true, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/quicktime-small-drag.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/lkfl-currency-sizing@2x.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/google-fonts-dropdown@2x.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/spotify-size.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/yandex-music-setup.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/itunes-density@2x.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/google-docs-filenames-dont-fit@2x.png", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/kinopoisk-doesnt-fit.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/launchpad-high-sierra.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/app-library-tahoe@2x.jpg" ] } }, { "id": "6753", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/nikogda-ne-otryvayte-paneli-ot-krayov-ekrana\/", "title": "Никогда не отрывайте панели от краёв экрана", "content_html": "

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

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

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

Они это показали в бете третьей версии интерфейса. Поднялся шум, и к релизу это пришлось откатить и сделать нормально.<\/p>\n

В прошлом году Эпл придумал оторвать свои сайдбары от краёв. Тупой Алан Дай не только не знал ничего об интерфейсах, но даже не знал что на эти же грабли только что наступила Фигма. У Фигмы-то это хотя бы выглядело красиво, а у Эпла получилось просто говнище, с какой стороны ни посмотри:<\/p>\n

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

Эпл упрямый и неповоротливый, поэтому на починку им понадобился год.<\/p>\n

Дизайнеры! Перестанье вы это делать, ну сколько вам ещё надо примеров? Ноль плюсов у этого решения.<\/p>\n", "summary": "Из общей теории, опыта и здравого смысла мы знаем, что всякие боковые панели должны быть приклеены к краям окон", "date_published": "2026-06-13T13:26:51+05:00", "date_modified": "2026-06-13T13:26:43+05:00", "tags": [ "пользовательский интерфейс", "Фигма", "Эпл" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/figma-ui3.jpg", "_date_published_rfc2822": "Sat, 13 Jun 2026 13:26:51 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6753", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/figma-ui3.jpg", "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/tahoe-sidebars.jpg" ] } }, { "id": "6752", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/apple-text-wall\/", "title": "Стена текста у Эпла", "content_html": "

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

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

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

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

Так можно, если так и хотел.<\/p>\n", "summary": "«Золотые правила» типа правила семи элементов или правила трёх секуднд предлагают подменить реальное понимание ситуации и осмысленный выбор сравнением чисел", "date_published": "2026-06-12T13:23:41+05:00", "date_modified": "2026-06-12T13:23:27+05:00", "tags": [ "презентации и выступления", "Эпл" ], "image": "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/apple-text-wall.jpg", "_date_published_rfc2822": "Fri, 12 Jun 2026 13:23:41 +0500", "_rss_guid_is_permalink": "false", "_rss_guid": "6752", "_rss_enclosures": [], "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [ "https:\/\/ilyabirman.ru\/meanwhile\/pictures\/apple-text-wall.jpg" ] } }, { "id": "6749", "url": "https:\/\/ilyabirman.ru\/meanwhile\/all\/principy-dizayna-epla-2026\/", "title": "Принципы дизайна Эпла (2026)", "content_html": "

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

В этом году доклад неплохой по смыслу. Он слишком абстрактный, в духе «за всё хорошее против всего плохого», но всё-таки то, что́ Эплы в этом году считают хорошим, мне нравится:<\/p>\n

\n