Hacker News Digest

Графические интерфейсы не должны уступать терминальным в поддержке клавиатурного управления — это вопрос дизайна, а не технической невозможности. Многие считают, что TUI предпочтительны, потому что они «клавиатурные», но на самом деле проблема в недоработанных GUI, а не в их природе. Современные фреймворки, включая GNOME, явно требуют, чтобы каждое действие в GUI было доступно исключительно через клавиатуру — так же, как и через мышь. Это не дополнительная фича, а базовый стандарт доступности и удобства.

Реализовать полную клавиатурную навигацию в GUI несложно: достаточно продумать логику фокуса, сочетания клавиш и последовательность взаимодействия. Автор создал своё первое GUI-приложение Klisi именно с акцентом на клавиатурное управление — и это повысило его удобство. Клавиатурное управление не заменяет мышь, но делает интерфейс предсказуемым, быстрым и подходящим для пользователей, которые работают в терминале или предпочитают минимизировать движения рук. Решение — не в выборе между GUI и TUI, а в том, чтобы GUI действительно соответствовали стандартам доступности.

Проблема не в природе GUI, а в игнорировании клавиатурной навигации современными фреймворками и разработчиками, что снижает доступность и производительность. В нативных фреймворках (Cocoa/AppKit) она легко реализуется через nextKeyView и системные сочетания, а в Windows 3.1 была стандартом. Современные ненативные фреймворки сознательно от него отказываются, создавая барьеры: пропуск элементов при табуляции, отсутствие индикации фокуса. От клавиатурной навигации зависят пользователи с ограниченными возможностями и опытные пользователи. Идеальный GUI должен давать визуальные подсказки (как Vimium, Tridactyl, StarCraft с подсветкой букв на кнопках), а не прятать сочетания в меню. Microsoft Office — редкий пример высокого уровня: мнемоники, буферизация ввода, минимум нажатий. В HP-40G редактирование выражений через визуальные «коробки» не ломало синтаксис — клавиатура была интегрирована в дизайн, а не просто совместима. Аргумент о кривой обучения для обычных пользователей не оправдывает игнорирование прав доступа и производительности. TUI (Midnight Commander) быстрее не потому, что GUI не могут быть столь же эффективны, а из-за недоработанной реализации. Опытные пользователи предпочитают Vim, потому что он устраняет интерфейсное трение — в иерархии сенсорный экран < мышь < клавиатура он даёт максимальную скорость. Для эффективной клавиатурной навигации в GUI необходимо явно связывать элементы по логическому порядку фокуса, визуально подсвечивать сочетания, проектировать клавиатуру и мышь как равноправные и дополняющие друг друга без переключения контекста. В веб-приложениях — использовать HTML-стандарты и инструменты вроде Vimium вместо кастомных решений. Клавиатурная навигация требует постоянного сопровождения при изменении интерфейса, иначе пользовательский опыт разрушается. Пользователи, перешедшие с терминальных POS-систем на современные GUI, отмечают падение скорости из-за потери привычных горячих клавиш.

HTML всё больше заменяет функции, которые раньше требовали JavaScript. Сегодня можно реализовать всплывающие окна, диалоги, аккордеоны и автодополнение без единой строчки кода — достаточно современных атрибутов и элементов. Главное нововведение: popover позволяет создавать выезжающие панели с поддержкой закрытия по ESC и клику вне, а <dialog> делает возможным модальные окна через чистый HTML. Оба решения требуют внимания к доступности: например, использование popovertargetaction="hide" вместо ручного управления z-index.

Особенно стоит обратить внимание на группировку <details> через атрибут name — это простой способ сделать аккордеон без JS, где открытие одного пункта автоматически закрывает остальные. Также полезны <datalist> для нативного автодополнения и новые типы ввода (color, range, date), хотя их кросс-браузерная поддержка и доступность ещё требуют улучшений. Важно помнить: даже «без JavaScript» решения часто нуждаются в полифиллах или тщательной проверке на разных устройствах. Пробуйте эти фичи, но всегда ставьте пользователей на первое место.

HTML теперь способен заменить JavaScript для многих интерактивных элементов, но практическое применение ограничено неполной поддержкой браузерами, сложностью позиционирования и необходимостью серверной валидации, что снижает готовность к полному переходу. Popover и dialog работают надёжно в продакшене благодаря автоматическому стекингу и каскадному закрытию — признак продуманности стандарта. Позиционирование контекстных меню относительно триггера остаётся сложным из-за ограниченной поддержки anchor positioning. Datalist не подходит для строгого контроля ввода: пользователь может ввести произвольный текст, а серверная валидация всё равно обязательна. Даже при использовании HTML-элементов клиентская валидация (например, цветовые подсказки) и серверная проверка остаются необходимы для надёжности. На textlog.cc всё, кроме Web Push, работает на чистом HTML — доказательство возможности создания сложных интерфейсов без JS. Правильно именованные поля в формах позволяют минимизировать JavaScript, делая отправку и валидацию на бэкенде простыми и надёжными. Элементы вроде <details> и name-атрибута могут заменить JS-аккордеоны, но их анимация и поведение при поиске (например, в Firefox) непредсказуемы. Внедрение новых HTML-функций усложняет мультибраузерную совместимость, особенно когда аналогичные решения существуют десятилетиями. Пользователи с NoScript в 2026 всё ещё полагаются на HTML-интерактивность: HTMX и новые элементы позволяют избегать JavaScript без потери функциональности. В мультиязычных системах даты в input[type=date] должны передаваться в ISO-формате — локальный формат ОС вызывает путаницу у администраторов. Многие JS-функции теперь реализуемы через HTML, но «можно» не значит «нужно». Некоторые считают popups и модальные окна устаревшим, раздражающим подходом, часто применяемым необоснованно, несмотря на техническую возможность.

Apple quietly introduced a hidden anti‑nausea trick in iOS: a constellation of tiny, slowly drifting white dots that appear on the screen when a user enables the “Reduce Motion” accessibility option. The dots create a stable visual reference point, counteracting the mismatch between what the eyes see and what the inner ear feels while riding in a moving vehicle.

In my own test, turning the feature on eliminated the queasy feeling I usually get on car trips, and internal Apple testing cited a roughly 30 % drop in self‑reported motion‑sickness symptoms among participants who used the pattern for a week. The design stems from research showing that subtle, slow‑moving patterns can calm the brain’s motion‑processing circuits, and the implementation is deliberately understated—just a faint galaxy of specks that most people would never notice unless they looked for it. Apple has not announced the feature publicly, but it is now live for anyone willing to dig into the Accessibility settings.

• Обсуждается функция «точек», которая снижает тошноту при чтении в движении за счёт визуального маркера.
• Пользователи делятся как положительным опытом (работает, помогает), так и отрицательным (не помогает, вызывает дискомфорт).
• Есть альтернативные решения: Android‑приложения, специальные очки с жидкостью, а также простые методы вроде закрытия глаз или вентиляции.
• Вопросы о переносе на компьютеры, влиянии качества воздуха и о потенциальной помощи людям с сильной морской или автомобильной тошнотой.

Чтобы ускорить процесс получения услуг у регулируемой монополии, где падение удовлетворённости ниже 96 % грозит миллионами штрафов, команда решила заменить устаревший ASP‑форму и дорогой React‑приложение на полностью HTML‑ориентированный сайт. Используя Astro, они построили сайт, где каждая стадия формы — отдельная страница, отправляемая на сервер, а данные сохраняются в базе. Такой подход позволил работать без JavaScript, поддерживать древние браузеры и сохранять ввод даже при плохом соединении. Результат — количество пользователей мгновенно удвоилось.

Ключевой принцип — «простое HTML работает везде». Как отмечает Теренс Эден, даже браузеры типа PSP, способные открыть лишь три вкладки и часто терять память, без проблем отображают страницы GOV.UK, написанные в лёгком HTML. Команда использовала кастомные веб‑компоненты, которые перехватывают стандартную валидацию браузера, выводят ошибки в aria‑describedby и очищают их при вводе, избегая тяжёлых React‑валидаторов. Доступность достигла уровня AA, а всё приложение оставалось лёгким: без 20 МБ JavaScript‑пакетов, только небольшие улучшения в виде CSS и минимального скрипта. Это показывает, что для публичных форм достаточно чистого HTML и грамотного серверного хранения, а современные фреймворки лишь дополняют, а не заменяют базовый веб‑технологический фундамент.

• Простой HTML‑first подход с минимальным JavaScript может значительно повысить доступность и производительность сайтов.
• Использование технологий вроде HTMX и серверных фреймворков (Go, Rails, Django) позволяет реализовать сложные функции без тяжёлых клиентских библиотек.
• Проблемы с поддержкой старых браузеров и устройств часто решаются через полифиллы, ограничение функционала и fallback‑варианты.
• Успешные кейсы показывают, что правильный дизайн и понимание пользователей важнее выбора конкретного фреймворка.

Mozilla представила новую функцию управления профилями Firefox, запускаемую 14 октября. Каждый профиль будет представлять отдельное пространство с собственными закладками, входами, историей, расширениями и темами, что поможет пользователям организовать разные аспекты онлайн-жизни: работу, учебу, семью и личные проекты. Функция снижает когнитивную нагрузку, предотвращая смешение данных и неловкие ситуации, когда личная информация появляется в профессиональном контексте.

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

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

• Пользователи обсуждают, что профили Firefox существуют уже много лет, но новый UI не решает проблему с их использованием и не показывает старые профили.
• Создание нового профиля через новый интерфейс не создаёт отдельную папку профиля, что вызывает вопросы о том, как перенести данные.
• Некоторые пользователи отмечают, что новый интерфейс не позволяет выбрать, какой профиль использовать при открытии ссылки из внешнего приложения.
• Обсуждается, что контейнеры и профили разные вещи, но новый UI не делает это ясным.
• Несколько комментаторов выражают разочарование в том, что Mozilla не делает ясным, что именно нового вносит новый UI, и что именно он улучшается.

Джеймс Падольски, разработчик software, перенесший геморрагический инсульт в височной доле с эпилепсией, делится советами для коллег с похожими проблемами. Инсульт случился с ним в 29 лет после 12 лет карьеры, и за прошедшие 6 лет он выработал стратегии адаптации. Ключевые рекомендации: немедленно останавливаться при появлении усталости, тошноты или странных ощущений; использовать наушники, беруши и учиться говорить "нет"; ставить здоровье выше производительности; использовать юридическую защиту; минимизировать переключение контекста; применять ИИ как помощника; выполнять сложную работу в период ментального пика; избегать долгих встреч и отключать уведомления.

Автор признает, что ему трудно следовать собственным советам, особенно в отказе от встреч и вежливости, когда это истощает. "Внимание — это дорого, и нам оно нужно гораздо меньше, чем мы думаем", — отмечает он. Падольски подчеркивает, что разработчики с последствиями инсульта не должны чувствовать себя обязанными справляться в одиночку из-за какого-то "культурного фетишизма чистоты".

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

Apple представила новый интерфейс Liquid Glass с прозрачностью и эффектами размытия во всех своих операционных системах, но многим пользователям эти эффекты мешают или затрудняют чтение. В статье подробно описано, как контролировать эти эффекты для повышения удобства использования. Наиболее важной настройкой является "Системные настройки > Специальные возможности > Дисплей > Уменьшить прозрачность", которая делает строку меню непрозрачной, скрывает обои за виджетами, центром управления и доком, а также устраняет прозрачность в боковой панели системных настроек.

Для тех, кто часто делает скриншоты, эта функция особенно важна, так как обеспечивает единообразный фон. Автор отмечает, что настройки специальных возможностей для контроля Liquid Glass похожи в macOS, iOS, watchOS и tvOS, но их полезность различается в каждой системе. Статья содержит сравнительные скриншоты, демонстрирующие разницу между стандартными настройками и уменьшенной прозрачностью, что позволяет пользователям визуально оценить эффекты изменений.

• Обсуждение в основном вращается вокруг критики нового дизайна "Liquid Glass" в iOS 26 и macOS Sequoia, который пользователи считают неудобным, непрактичным и вызывающим проблемы с читаемостью.
• Участники жалуются на снижение контрастности, нечитаемость текста и общее ухудшение пользовательского опыта, особенно в темной теме.
• Некоторые участники высказывают мнение, что Apple теряет фокус на удобстве пользователя в пользу визуальных эффектов.
• Обсуждение также затрагивает влияние этих изменений на продуктивность и удобство использования, а также то, как Apple обрабатывает обратную связь от сообщества.
• Участники также обсуждают, как обойти или отключить эти изменения, и обсуждают, будет ли Apple учитывать эту обратную связь в будущем.

HTML-тег <output> почти не используют, но он решает две задачи: делает результат вычислений доступным для скринридеров и избавляет от необходимости вручную подключать ARIA live-регионы. Пример: калькулятор, слайдеры, индикаторы сложности пароля. Тег работает без JavaScript и ARIA-атрибутов, поддерживается всеми браузерами и скринридерами.

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

Igalia получил грант от Sovereign Tech Fund на поддержку движка Servo. В течение года команда займётся тремя направлениями: внедрение базовой поддержки специальных возможностей, завершение WebView API для встраивания Servo в приложения и рутинная поддержка проекта. Это позволит движку оставаться жизнеспособным и совместимым с экосистемой Rust.

• Финансирование и гранты: Немецкий Sovereign Tech Fund выделяет гранты на разработку Servo, но суммы (€545,400) вызывают сомнения в их адекватности, особенно на фоне сравнения с другими инициативами.
• Проблема зависимости от США: Обсуждение подчеркивает, что ЕС по-прежнему зависит от технологий США, и вопрос остаётся открытым, несмотря на усилия по финансированию open-source проектов.
• Сравнение с другими проектами: Участники обсуждения отмечают, что в отличие от других проектов, таких как Ladybird, у которого есть 8 разработчиков, Servo не имеет столь же широкой поддержки, что может затруднить его развитие.
• Финансирование open-source: Участники подчеркивают важность устойчивого финансирования open-source проектов, особенно в контексте государственных инвестиций в такие проекты как Servo.

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

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

• Современные смартфоны, особенно iPhone, критикуются за излишнюю сложность интерфейса, непонятные жесты и запутанный процесс первоначальной настройки, что создает серьезные барьеры для пожилых пользователей.
• Многие пользователи предлагают создание упрощенных режимов (вроде Assistive Access) и возможность кастомизации интерфейса с самого начала настройки устройства, оставляя только самые необходимые функции (звонки, сообщения).
• Отмечается, что проблема не только в Apple, но и в общей тенденции усложнения UX across all platforms (Android, Windows), а также в плохо спроектированных приложениях (банки, госуслуги), которые часто требуются для повседневной жизни.
• Подчеркивается важность терпения и индивидуального подхода при обучении, фокусируясь только на тех задачах, которые действительно нужны пользователю, а не на демонстрации всех возможностей устройства.
• Обсуждается, что пожилые пользователи — не монолитная группа; некоторым удается успешно освоить устройства, в то время как для других даже упрощенные смартфоны остаются слишком сложными, и иногда более подходящим решением может быть простой кнопочный телефон.

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

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

• Участники обсуждают личный опыт аутизма и ADHD, включая сенсорную чувствительность, трудности с маскировкой и выгорание на работе.
• Критики задаются вопросами о механике симулятора, отмечая неясность логики выбора и его последствий для игровых показателей.
• Поднимается вопрос о разнообразии аутистического спектра и необходимости учитывать индивидуальный опыт, а не обобщать.
• Обсуждается проблема стигматизации и недостаточной поддержки нейроотличных людей на рабочем месте.
• Некоторые пользователи видят ценность симулятора как инструмента для развития эмпатии и понимания трудностей нейроотличных коллег.

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

В архиве представлено 362 сайта с фильтрацией по тегам — от 3D-анимации и типографики до звукового дизайна и глитчей. Примеры вроде rude-captcha.xyz или slingshot.trudy.computer демонстрируют, как можно творчески использовать возможности телефона. Цель проекта — стимулировать сообщество к обсуждению и эксперименту в mobile-first дизайне.

• Пользователи обсуждают нестандартный веб-дизайн представленных сайтов, отмечая как их креативность и ностальгическую ценность, так и проблемы с юзабилити и доступностью.
• Критике подвергаются отдельные элементы, такие как изменение поведения ссылок при наведении и невозможность добраться до нижней части страницы из-за бесконечной подгрузки контента.
• Участники делятся воспоминаниями о легендарных сайтах прошлого (Kaliber 10000) и обмениваются ссылками на аналогичные ресурсы и агрегаторы необычных сайтов.
• Высказываются опасения, что подобный дизайн часто непрактичен для представления реального контента и создания призывов к действию, а также создает барьеры для доступности.
• Часть сообщества ценит представленные работы за их художественную ценность и вдохновляющий потенциал, призывая не зацикливаться на мелких недостатках.

Текст в интерфейсах должен оставаться доступным для копирования — это основа понимания и доступности. Автор приводит личный пример: в приложении Bumble нельзя выделить текст профиля на немецком, что мешает перевести его и понять смысл. Это вынуждает пользователей идти на обходные пути, вроде скриншотов и OCR, что снижает удобство и заставляет отказаться от взаимодействия.

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

• Пользователи активно выражают раздражение из-за невозможности выделить или скопировать текст на сайтах и в приложениях, что мешает переводу, поиску и другим задачам.
• Разработчики и дизайнеры обсуждают технические причины блокировки выделения (например, для кликабельных элементов) и предлагают обходные решения через скрипты, расширения или OCR.
• Многие отмечают, что блокировка текста не защищает контент, а лишь ухудшает пользовательский опыт и воспринимается как враждебная мера.
• Приводятся примеры проблем в популярных сервисах (GitHub, Teams, Instagram, dating-приложения), где невозможность копирования текста создаёт неудобства.
• Пользователи делятся инструментами и методами для обхода ограничений (браузерные расширения, скрипты, системные утилиты типа Powertoys, скриншоты с OCR).

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

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

• Проект EU возрастной верификации изначально ориентирован только на мобильные платформы (Android/iOS), что исключает пользователей десктопов и вызывает критику о дискриминации и нарушении доступности.
• Ключевые опасения включают привязку к экосистемам Apple/Google, потерю приватности, цифровой суверенитет и риск усиления контроля Big Tech над доступом к базовым услугам и идентификации.
• Обсуждается конфликт инициативы с ценностями ЕС: зависимость от неевропейских технологий, противоречие законам о доступности и приватности, а также потенциально дистопический сценарий тотальной цифровой идентификации.
• Участники отмечают, что проект является лишь прототипом, и технически возможны альтернативные решения (например, смарт-карты), но политическая воля к их реализации отсутствует.
• Многие видят в этом шаге часть тревожной тенденции ЕС к внедрению контролирующих цифровых систем (наряду с chat control), что может привести к массовому сопротивлению и использованию обходных путей.

Почему PostHog стал похож на ОС
Мы устали от типичных сайтов: бесконтентные скроллы, одинаковые вкладки, пустое пространство. Новый PostHog.com работает как ОС в браузере: окна «прилипают», есть горячие клавиши, закладки, можно читать новости, смотреть демо и играть одновременно.

Что внутри

• Проводник Windows для магазина мерча
• Продуктовые страницы в стиле PowerPoint
• Редактор документов с возможностью правки
• Форумы как Outlook Express
• Плеер QuickTime, таблицы вместо дизайна, скринсейвер и обои
• 50+ горячих клавиш

Техника
Контент отделён от визуального слоя: продукты описаны в JSON, темы и цветовые схемы настраиваются, клиентские цитаты и логотипы хранятся в одном месте и подтягиваются автоматически. Всё собрано в прод-ветке на Tailwind + TypeScript.

• Сайт PostHog выглядит как десктоп ОС в браузере: окна, таски, «окна в окнах».
• Кому-то нравится визуальный стиль и ностальгия по 90-м, но почти все жалуются на тормоза, жрущий CPU JS и поломанные привычные хоткеи/кнопки.
• Пользователи теряются: непонятно, где контент, как начать читать и что вообще продаёт компания.
• Критика сводится к «изобретаю заново мой менеджер окон», «ломает SEO и accessibility», «не работает Back, не скроллится, на мобиле ужасно».
• Некоторые считают это крутым маркетинг-ходом и «growth-hack», но сомневаются, что кто-то будет реально пользоваться.

Alterego — «почти телепатический» интерфейс: мини-девайс считывает немую речь, превращая задуманные фразы в команды AI.
Работает без экрана, клавиатуры и голоса; мысли остаются при вас.

Следи за новостями и получи уведомление о запуске.

• Участники сомневаются в реальности Alterego: нет публичных демо, видео выглядит как fake, данных мало.
• Основная идея — «бесшумный ввод»: челюстные/ушные EMG-датчики ловят субвокализацию, превращают в текст без звука.
• Скорость не проблема; удобство — в отсутствии need доставать телефон, говорить вслух или уметь печатать.
• Ниши: люди без грамотности, locked-in syndrome, шумные кафе, велосипед, AR-очки, «телепатический» чат.
• Критика: точность 92-95 % для маленького словаря = раздражает; требует персонального обучения; риск сбора «мыслей» и утечки данных.

Анимации не всегда нужны

Хорошая анимация делает интерфейс предсказуемым и живым, плохая — раздражает и снижает доверие.
Перед добавлением спроси себя: зачем она нужна?

• Объясняет (как на linear.app/ai) — ок.
• Подтверждает действие (кнопка слегка уменьшается) — ок.
• Просто «красиво» — допустимо, если пользователь видит это редко.

Частота использования
Если элемент открывают сотни раз в день (Raycast, список команд), анимации быть не должно — они только тормозят.
Клавиатурные переходы никогда не анимируются.

Скорость
Всё, что дольше 300 мс, воспринимается как лаг.
Спиннеры быстрее = кажется, что грузит быстрее.
Тултипу нужна задержка при первом появлении, но при наведении на соседние — мгновенно и без анимации.

Итог
Добавляй анимацию, если она:

1. решает задачу,
2. видна редко,
3. длится < 300 мс.
   Иначе — не добавляй.

• Большинство участников сходятся: анимация должна быть почти невидимой (<150 мс) или вовсе отключаться, иначе она превращается в тормоз.
• Главный критерий целесообразности — объясняет ли анимация изменение состояния; если пользователь ждёт её окончания, чтобы продолжить, значит, она лишняя.
• «Делайт» и «восторг» нужны в основном самим дизайнерам; обычные пользователи после третьего раза хотят выключить всё, что мешает работать.
• Частые повторяющиеся действия (разблокировка, чекаут, корпоративные формы) требуют минимума анимации; для единичных экранов-онбордингов допустима более заметная, но быстрая подсказка.
• Практически каждый советует добавлять системную настройку «отключить анимацию» и уважать prefers-reduced-motion.