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

Использование готовых библиотек компонентов, таких как HeroUI, помогает сохранять единообразие. Важно применять их "как есть", без кастомизации, и ограничивать набор стилей, чтобы избежать беспорядка. Такой подход экономит усилия и делает интерфейс целостным, даже если отдельные элементы не идеальны.

• Подчёркивается важность фундаментальных принципов дизайна (таких как гештальт), которые не зависят от технологий, в отличие от фреймворков и паттернов.
• Критикуется подход, ставящий эстетику выше функциональности и удобства использования; акцент делается на юзабилити, логику и чёткую структуру интерфейса.
• Обсуждается ценность глобальной консистентности и использования готовых библиотек компонентов против кастомных, но часто неудачных решений.
• Отмечается, что хороший дизайн начинается с глубокого понимания пользователя, а не просто со следования набору правил или созданию "красивого" интерфейса.
• Упоминаются конкретные ресурсы для обучения (книги вроде "The Design of Everyday Things", "Refactoring UI") и критика их дороговизны или поверхностного применения.

При обращении к данным пользователя в интерфейсах часто возникает вопрос: использовать «мой» или «ваш»? Например: «Мой аккаунт» или «Ваш аккаунт»? Но часто префикс не нужен вовсе — достаточно просто «Аккаунт», «Заказы», «Дела», как это делает Amazon.

Однако если в продукте есть элементы, принадлежащие и пользователю, и другим (например, система дел, где есть «мои дела» и «все дела»), возникает сложность. Использование «мои дела» в меню навигации кажется уместным, но вне меню — в onboarding, email-уведомлениях или справке — фраза «перейдите в мои дела» звучит неестественно. Если я скажу вам «перейдите в мои дела», вы подумаете о своих, а не о моих. Поддержка может рекомендовать «перейдите в ваши дела», что конфликтует с интерфейсом, где написано «мои дела».

С «ваш» таких проблем не возникает — этот подход проверен на множестве продуктов и не вызывает затруднений у пользователей.

Но есть нюанс: если пользователь общается с системой, например, через радиокнопки, корректнее использовать «мой». Например, на вопрос «Хотите поделиться своим фото профиля?» варианты ответа должны звучать как «Да, поделиться моим фото» и «Нет, не делиться моим фото». Использование «ваш» здесь некорректно, так как звучит как инструкция для компьютера поделиться своим фото, а не фото пользователя.

Итог:

• Используйте «ваш», когда обращаетесь к пользователю.
• Используйте «мой», когда пользователь обращается к системе.

• Рекомендуется использовать местоимение «your» (ваш/ваша/ваше) в интерфейсах, когда система обращается к пользователю, и «my» (мой/моя/моё), когда пользователь дает команду системе.
• Многие участники выступают против использования местоимений вообще, считая их избыточными и предлагая убирать притяжательные формы для упрощения (например, «Pictures» вместо «My Pictures»).
• Критикуется использование местоимения «we» (мы) системой, так как это создает ощущение патернализма и ложной вовлеченности пользователя в процесс («Let's add your account»).
• Подчеркивается важность контекста и согласованности в формулировках, особенно при локализации, поскольку в разных языках существуют разные нормы вежливости и формальности.
• Отмечается, что неправильное использование местоимений может приводить к путанице, особенно если продукт или функция уже содержит слово «My» в названии (например, «Your My Card»).
• Некоторые участники предпочитают, чтобы интерфейсы и системы общались более формально и машинообразно, без попыток казаться «дружелюбными» или человечными.
• Указывается на проблемы перевода и локализации, когда недостаток контекста для строк интерфейса приводит к ошибкам и неоднозначностям.
• Обсуждается, что лучшей практикой является обработка элементов интерфейса как собственных имен (использование кавычек, выделение) в инструкциях и поддержке, чтобы избежать путаницы с местоимениями.

Телефоны на Linux важнее, чем когда-либо

Android всегда был довольно открытой платформой, но в последние месяцы мы наблюдаем стремительную деградацию экосистемы:

1. Закрытие разработки всё большего числа компонентов в AOSP.
2. Samsung, Xiaomi и OnePlus убрали возможность разблокировки загрузчика. Google, вероятно, последует их примеру.
3. Внедрение Play Integrity API, которое поощряют разработчиков. Даже европейский кошелёк для верификации личности требует его использования, вопреки законам ЕС.
4. Обязательная верификация разработчиков на Android. Это затронет 99,9% устройств, и многие разработчики open-source могут просто прекратить создавать приложения для Android. SyncThing уже прекратил разработку из-за проблем с Google Play.

Google больше не конкурирует с Apple — он перенимает её методы. Android, каким мы его знаем, мёртв или скоро умрёт. Нам нужна открытая альтернатива.

Примечание: это не призыв переходить на Linux сегодня, а указание на необходимость ускорения разработки.

---

Комментарии

y0kai: Мой следующий телефон будет работать на Linux, даже если это неудобно. Как только этот телефон будет оплачен, я также уйду от Google Fi.

MasterOKhan: Я с тобой, я перевёл все свои компьютеры на Linux по похожим причинам. Недавно купил Android-телефон и установил на него Linux, хотя ещё есть над чем работать, например, со звуком и микрофоном. Жду не дождусь, когда смогу отказаться от iPhone.

• Пользователи выражают недовольство ограничениями Android, такими как блокировка скриншотов и записи звонков, несмотря на их законность в некоторых юрисдикциях.
• Обсуждаются возможные альтернативы: использование двух телефонов (один — для банковских приложений, другой — с открытой ОС) или переход на Linux-смартфоны.
• Отмечаются проблемы Linux-телефонов: короткое время работы от батареи, отсутствие поддержки популярных приложений (банки, мессенджеры) и сырой пользовательский опыт.
• Предлагаются решения: форк AOSP, создание устройств без модема (по аналогии с iPod Touch) или использование внешнего модема для разделения trusted/untrusted частей.
• Поднимается вопрос о необходимости открытой мобильной ОС из-за растущей зависимости от проприетарных платформ (Google/Apple) для доступа к госуслугам, банкингу и другим сервисам.
• Высказывается мнение, что усилия сообщества стоит направить на развитие реальных альтернатив (например, PostmarketOS), а не на кастомные прошивки Android.
• Отмечается, что ключевая проблема — не ОС, а экосистема приложений, которые зачастую требуют наличие Google Play Services и блокируются на нестандартных устройствах.
• Некоторые пользователи считают, что регулирование на уровне ЕС (например, форк Android) могло бы улучшить ситуацию с открытостью и безопасностью.

Восторг угасает

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

Речь идёт о событии Apple 9 сентября, где представили новую линейку iPhone, AirPods Pro и Apple Watch. Честно говоря, мне всё меньше хочется обсуждать Apple — я чувствую, что компания потеряла связь со мной и другими давними пользователями.

Чем больше Apple ведёт себя как другие tech-гиганты, тем менее особенной она становится. Да, я признаю, что Apple всё ещё вызывает у меня эмоции, но это не значит, что мне небезразлична сама компания. Меня беспокоят последствия их действий: плохие дизайнерские решения и упрощение интерфейсов, которые могут стать трендом и повлиять на всю индустрию.

Цитата Стива Джобса

Мероприятие началось с известной цитаты Джобса: «Дизайн — это не только то, как продукт выглядит и ощущается. Дизайн — это то, как он работает». Это вызвало у меня недоумение. Зачем сейчас эта цитата, после месяцев критики нового дизайна Liquid Glass? Возможно, это троллинг критиков, самообман Apple или просто попытка произвести впечатление. В любом случае это прозвучало неуместно.

AirPods и Watch

Эти продукты Apple меня интересуют меньше всего. Я всегда пропускаю эти части презентаций. Дизайн Apple Watch кажется мне невыразительным, а интерфейс — перегруженным функциями. Вместо множества опций я бы предпочёл возможность отключать целые наборы функций, чтобы использовать часы только как шагомер и монитор сердечного ритма.

• Пользователи отмечают потерю связи Apple с давними клиентами, чувствуя смещение фокуса компании на массового потребителя.
• Критикуется отсутствие инноваций и «созревание» продуктов: новые iPhone и iOS воспринимаются как инкрементальные улучшения без прорывных функций.
• Высказывается разочарование в экологической политике, особенно касательно AirPods и невозможности замены батареи, что ведёт к увеличению электронных отходов.
• Подвергается сомнению маркетинг Apple (например, слоган «awe-dropping»), который воспринимается как неубедительный и не соответствующий реальным впечатлениям от продуктов.
• Отмечается, что многие проблемы интерфейса и функциональности (например, Siri) выглядят легко устранимыми, но Apple не спешит их решать.
• Дискуссия включает ностальгию по временам Стива Джобса и споры о том, продолжил бы он текущую стратегию компании.
• Часть пользователей защищает Apple, указывая на долгую поддержку устройств, качество экосистемы и отсутствие реальной альтернативы на рынке.
• Обсуждается региональная ограниченность функций (например, отсутствие поддержки языков), что создаёт неравенство среди пользователей из разных стран.

The Sagrada Família stands as both architectural marvel and cultural paradox—a century-long project blending Gaudí’s organic Art Nouveau vision with modern construction pragmatism. It’s now set to become the world’s tallest church, yet deliberately stays just shy of Barcelona’s natural peak, Montjuïc, as Gaudí believed human creations shouldn’t compete with divinity. The basilica draws over 5 million paid visitors annually, funding its own completion through tourism revenue rather than traditional donations, a shift from its original expiatory purpose.

Its design features morphing geometries inspired by nature: columns that branch like trees, honeycomb windows, and ceramic grape clusters. Construction accelerated recently under chief architect Jordi Faulí, with 14 of the planned 18 towers now standing. The project’s slow progress once symbolized endless delay in Catalan slang, but today it races toward a 2026 completion—proof that Gaudí’s wild aesthetic can endure even as modern builders interpret his legacy.

• Архитектурное величие и эмоциональное воздействие: Посетители единодушно описывают Sagrada Família как ошеломляюще красивое, уникальное и впечатляющее сооружение, которое превосходит ожидания и вызывает благоговение. Внутреннее пространство с игрой света через витражи особенно выделяется как шедевр.
• Гений Гауди и инженерное искусство: Обсуждается новаторский подход Антонио Гауди, сочетающий функциональность, красоту и сложные инженерные решения (например, использование перевернутых моделей из струн). Его наследие служит вдохновением для художников и инженеров, в том числе в IT-сфере.
• Долгострой как символ амбиций: Проект рассматривается как символ грандиозных долгосрочных начинаний, требующих десятилетий (и даже столетий) на реализацию. Отмечается как медленный прогресс в прошлом, так и ускорение в последние годы.
• Практические советы и критика: Даются рекомендации посетителям (бронировать билеты онлайн заранее, посещать в солнечный день), а также критические замечания о китчевости, диссонансе между фасадами и трагической судьбе самого Гауди.
• Контекст Барселоны и культурное влияние: Подчеркивается, что уникальность Sagrada Família заключается еще и в том, что городу хватило смелости позволить построить такое здание. Его эстетика повлияла на поп-культуру, а сам проект стал нарицательным для масштабных и сложных начинаний.

Разработчики часто тяготеют к сложности, хотя принцип KISS («будь проще») хорошо известен. Почему так происходит?

Маркетинг важнее простоты

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

Что внутри «пирамид»?

Современные системы напоминают пирамиды: много слоёв, зависимостей и абстракций, но внутри может быть пустота. Сложность кричит «посмотри на меня!», а простота остаётся незаметной, пока не проявится её гениальность. В долгосрочной перспективе побеждает именно простота.

React против ванильного JavaScript

React навязывает множество концепций: рендеринг, хуки, состояния, маршрутизация. Отказ от него может сделать вас «аутсайдером», хотя ванильный JavaScript часто решает задачи эффективнее. Компании вкладывают миллионы в продвижение фреймворков, что усложняет выбор в пользу простых решений.

Глубинные причины любви к сложности

1. Творческий соблазн: Создание сложных систем — интеллектуальный вызов, который приносит удовлетворение.
2. Технический долг: Наследие старых проектов вынуждает добавлять новые слои вместо упрощения.
3. Командная динамика: Разработчики добавляют абстракции для «универсальности», что усложняет систему.
4. Давление инноваций: Конкуренция подталкивает к созданию сложных решений, чтобы выделиться.

Стройте с умом

Создавайте системы с чёткой целью и ценным содержимым, а не пустые лабиринты, которые усложнят жизнь тем, кто будет поддерживать код в будущем. Прежде чем писать сложную абстракцию, спросите себя: решаете ли вы реальную проблему или просто удовлетворяете своё эго?

• Сложность часто возникает из-за добавления быстрых исправлений вместо переосмысления архитектуры с учетом новых требований.
• Простые решения требуют больше усилий для проектирования и поддержки, чем сложные, которые появляются быстрее.
• Реальность полна деталей, и простые решения редко охватывают всю сложность проблемы, что ведет к наращиванию сложности системы.
• Разработчики могут добавлять сложность для демонстрации навыков, интереса или ощущения достижения, что поощряется в индустрии.
• Долгоживущие кодобазы неизбежно накапливают сложность из-за постоянных изменений и адаптации к новым требованиям.
• Простота субъективна и требует глубокого понимания основ и дисциплины для достижения и поддержания.
• Бизнес-среда и отсутствие прямого контакта с пользователем могут способствовать выбору сложных решений вместо фокуса на ценности.
• Сложность иногда искусственно создается для обеспечения job security или из-за организационных проблем и политик.
• Эволюция технологий и библиотек часто следует за обобщением паттернов, что добавляет абстракции и сложности.

Интернет-архив урегулировал многолетний судебный спор с крупными лейблами, включая UMG, Capitol и Sony, по поводу проекта Great 78, оцифровывавшего хрупкие записи на шеллаке. Детали соглашения остаются конфиденциальными, но стороны официально уведомили суд о завершении дела. Изначально издатели требовали компенсацию в $400 млн, утверждая о потере потокового дохода, а позже увеличили сумму до $700 млн, добавив новые претензии.

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

• Internet Archive подвергается судебным искам за нарушение авторских прав, в отличие от крупных платформ вроде YouTube, которые защищены системами вроде Content ID.
• Существуют опасения, что из-за спорного контента и неоднозначных решений (например, «Национальной Чрезвычайной Библиотеки») будущее архива под угрозой, несмотря его огромную ценность для человечества.
• Некоторые пользователи критикуют организацию за превращение в подобие пиратского сайта из-за размещения современного, а не только архивного контента.
• Обсуждаются проблемы управления и финансирования архива, бюджет которого сравнительно мал, а также роль его совета директоров.
• Предлагаются радикальные решения, такие как перемещение юрисдикции архива в страну без строгих законов об авторском праве, чтобы избежать давления.

Группа Massive Attack превратила свой концерт в эксперимент по распознаванию лиц. Во время выступления в Бристоле использовалась система live-идентификации лиц зрителей. Это было частью художественного проекта, призванного создать дискомфорт и поднять вопросы о культуре наблюдения.

• Использовалась технология обнаружения лиц, а не распознавания, с выводом случайных описательных характеристик
• Многие участники обсуждения сочли это художественной провокацией, иллюстрирующей проблемы слежки и сбора данных
• Отсутствие явного согласия и ясности в хранении данных было воспринято как осознанный художественный выбор
• Проводится параллель с массовым сбором данных корпорациями и государствами без ведома людей
• Некоторые усомнились в новизне и этичности инсталляции, назвав её гиммиком
• Упомянуты подобные примеры в искусстве (Aphex Twin, SNL) и реальной жизни (аэропорты, фастфуд)
• Часть обсуждения свелась к шуткам о связи группы с Бэнкси и отсутствию у них нового материала
• Статья-первоисточник была раскритикована за кликбейтный заголовок и возможное использование ИИ

React победил по умолчанию — и это убивает фронтенд-инновации

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

Команды редко начинают с вопроса «Какие ограничения и какой инструмент подходит лучше?». Чаще звучит: «Давайте использовать React — все его знают». Это создаёт цикл, где архитектуру определяют сетевые эффекты, а не техническая целесообразность.

Между тем, фреймворки с реальными инновациями борются за внедрение. Svelte устраняет накладные расходы компиляцией, Solid предлагает детальную реактивность без виртуального DOM, Qwik обеспечивает мгновенный запуск через возобновляемость. Эти подходы часто превосходят модель React, но редко получают оценку, потому что React выбирают по умолчанию.

Проблема не в самом React, а в мышлении «React по умолчанию».

Потолок инноваций

Технические основы React объясняют современные трудности. Виртуальный DOM был умным решением для проблем 2013 года, но, как отметил Рич Харрис, он вводит издержки, которых можно избежать с помощью компиляторов.

Хуки решили проблемы классовых компонентов, но добавили сложности: массивы зависимостей, устаревшие замыкания, неправильное использование эффектов. Даже документация React призывает к сдерженности: «Вам может не понадобиться эффект». Серверные компоненты улучшают время до первого байта, но добавляют архитектурную сложность.

Компилятор React — умное решение для автоматизации useMemo/useCallback, но его существование сигнализирует: мы оптимизируем вокруг ограничений модели.

Альтернативы предлагают иные подходы: Runes в Svelte 5 упрощают реактивность на этапе компиляции, детальная реактивность Solid обновляет только изменённые части, возобновляемость Qwik устраняет традиционную гидратацию. Это не инкрементные улучшения React, а другие модели с иными пределами.

Инновации без внедрения не меняют результаты. Внедрение невозможно, когда выбор делается рефлекторно.

Технический долг, который мы несём

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

Исследования производительности единодушны: JavaScript дорог на критическом пути.

Мы сосредоточили ментальные модели вокруг «React-паттернов» вместо основ веба, снижая переносимость навыков и увеличивая архитектурную инерцию.

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

Фреймворки, которым не дают развиваться

Svelte: революция компилятора

Svelte переносит работу на этап компиляции: нет виртуального DOM, минимальный runtime. Компоненты становятся целевыми операциями DOM. Ментальная модель соответствует основам веба.

Но «недостаточно вакансий» искусственно сдерживает внедрение Svelte, несмотря на технические преимущества.

• React побеждает благодаря композиции функций JavaScript, интуитивной модели и стабильности, а не только из-за сетевых эффектов.
• Веб-компоненты рассматриваются как путь к совместимости между фреймворками и снижению зависимости от экосистемы React.
• Многие разработчики ценят React за предсказуемость, лёгкость найма и богатую экосистему, что делает его безопасным выбором.
• Критики указывают на сложности React (хуки, зависимости, ререндеры) и чрезмерный boilerplate-код.
• Альтернативы вроде Svelte или Solid предлагают упрощённые модели и лучшую производительность, но проигрывают в распространённости.
• Инновации во фронтенде часто воспринимаются как «суета», ведущая к устареванию проектов и постоянным переписываниям.
• React доминирует частично из-за React Native, что позволяет использовать единую кодобазу для web и мобильных платформ.
• Браузеры и стандарты Web обвиняются в недостаточной скорости развития, что вынуждает полагаться на фреймворки.
• Стабильность и стандартизация ценятся выше постоянных изменений и «инноваций» в индустрии.

macOS Tahoe

Свежий вид.

Вечно Mac.

macOS Tahoe представляет новый дизайн Liquid Glass — красивый, приятный и мгновенно узнаваемый.

Основные возможности

• Liquid Glass — новый дизайн с прозрачными элементами и динамическими эффектами.
• Приложение "Телефон" — теперь на Mac с поддержкой Live Activities для улучшенной интеграции с iPhone.
• Spotlight — выполняйте сотни действий, не отрывая рук от клавиатуры.
• Умные сокращения — создавайте мощные сценарии с помощью Apple Intelligence.

Дизайн

macOS Tahoe переосмыслен с помощью Liquid Glass, сочетающего свежесть и узнаваемость. Приложения фокусируются на контенте, а персонализация Mac выходит на новый уровень.

• Новый дизайн — Liquid Glass отражает контент в реальном времени, добавляя ясности навигации и элементам управления.
• Обновлённые иконки — персонализируйте Mac с новыми вариантами оформления, включая светлые и тёмные темы, цветные иконки или прозрачный стиль.
• Персонализированные элементы — прозрачная строка меню и расширенные возможности настройки Control Center, включая сторонние приложения.

• Пользователи крайне негативно оценили новый дизайн Liquid Glass в macOS Tahoe, называя его уродливым, непрофессиональным и похожим на дешёвую Android-тему или игрушку.
• Ключевые претензии к интерфейсу: чрезмерно скруглённые углы окон, избыточные отступы (padding), потеря плотности информации, прозрачность, ухудшающая читаемость, и визуальная несогласованность элементов.
• Многие отмечают большое количество багов, неисправленых с бета-версий, и общее ощущение незавершённости и низкого качества релиза.
• Обновление критикуют за ухудшение юзабилити и производительности (например, лагающий запускатель приложений), а также за игнорирование потребностей людей с ограниченными возможностями.
• Некоторые пользователи впервые решили пропустить мажорное обновление macOS и остаться на предыдущей версии или перейти на Linux (KDE), который хвалят за функциональность и стабильность.
• Есть единичные положительные отзывы о новой стилистике, большей «персонализации» и улучшенной производительности в iOS 26, но они тонут в общей массе критики.
• Пользователи отмечают, что Apple отошла от своих прежних принципов дизайна (доступность, ясность, функциональность) в угоду моде.
• Под сомнение ставится сама целесообразность встраивания генерации AI-изображений в операционную систему как её основная функция.
• Общий совет от опытных пользователей — не обновляться до версии x.1 или x.2, чтобы дождаться исправления ошибок и улучшения стабильности.