Почему GUI должны быть полностью управляемыми с клавиатуры

Доступность с клавиатуры — одна из тех вещей, которые обычно заметают под ковёр или вообще забывают, как и доступность в целом. Забавно, что первое обычно вытекает из второго.

Частично вина лежит на популярных UI-фреймворках (или, в случае тех, кто предпочитает их не использовать, на разработчиках, сделавших такой выбор). Старые фреймворки обычно делают это довольно легко; например, в Cocoa/AppKit (нативный UI-фреймворк для Mac) можно довольно легко настроить весь интерфейс для правильной навигации с клавиатуры чисто визуально (в основном это сводится к соединению nextKeyView между контролами для создания логической цепочки для таб-фокуса). Определение горячих клавиш тоже просто: добавьте пункт меню для команды и задайте соответствующий шорткат (что, в свою очередь, позволяет пользователю переназначать шорткат в Системных настройках по желанию).

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

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

Настойчивость HN в том, чтобы вести себя так, будто все пользователи — перфекционисты-хакеры из Arch Linux, просто невыносимо.

(Это звучит резче, чем я хотел. Извините. Я люблю людей из Arch Linux. Просто думаю, что служить обычному Джо не менее благородно, чем создавать идеальный инструмент для продвинутых пользователей.)

Что значит, чтобы GUI был управляемым с клавиатуры?

Очевидный способ — просто назначить каждому действию шорткат.

Мой контраргумент: это не совсем управление с клавиатуры, а лишь совместимость с клавиатурой. Есть проблема обнаружимости. Сейчас лучшая практика, похоже, — показывать шорткаты кнопок в подсказках, пунктах меню или при нажатии другого шортката.

Я бы утверждал, что кнопки фундаментально несовместимы с клавиатурой. В интерфейсе, управляемом с клавиатуры, не должно быть кнопок.

Проблема в том, что по-настоящему управляемые с клавиатуры интерфейсы, такие как CLI или TUI, страдают от ужасной обнаружимости, что и стало причиной появления мышиных интерфейсов. Так можем ли мы получить управляемый с клавиатуры интерфейс, такой же интуитивный, как клики мышью?

В прошлый раз, когда я создавал CRUD-приложение (ой, лет 24 назад), я специально сделал это. Помню, как смотрел на людей из отдела зарплат, которые молниеносно работали в своих терминальных приложениях VAX VMS с такой скоростью и ловкостью, что любой админ Unix, хорошо знающий командную строку, покраснел бы, и я подумал: «Ага, все эти точечно-кликовые GUI 90-х всё делают неправильно. Если людям приходится интенсивно использовать систему на работе, они предпочтут кривую обучения, за которой следует скорость, комфорт и ловкость, а не более лёгкую кривую обучения, которая жертвует ловкостью ради обнаружимости».

Это был веб-фреймворк, но… все экраны просмотра/списков включали идентификаторы строк и сфокусированное текстовое поле — так что ввод идентификатора строки и Enter выбирали её. Все кнопки действий имели подчёркивание, указывающее, какая комбинация Ctrl+Shift их активирует. Все экраны редактирования по умолчанию фокусировались на первом редактируемом текстовом поле, и мышь ни в какой момент не была необходима. Наконец, время загрузки было оптимизировано до 75 мс.

Забавно, что отзывы пользователей были: «Управление с клавиатуры довольно хорошее, но не могли бы вы сделать его быстрее».

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

Согласен, но думаю, что просто быть управляемым с клавиатуры недостаточно, потому что шорткаты часто трудно обнаружить и запомнить. Я думаю, идеал — как в хороших TUI — GUI должны показывать на экране очевидные подсказки о том, как перемещаться с помощью клавиатуры.

Было бы здорово иметь GUI-фреймворки для распространённых платформ (включая веб!), разработанные для этого и имеющие мнение о распространённых шорткатах для типовых действий, чтобы мы могли стандартизироваться.

Автор приводит отличный аргумент. Слишком много плохих терминальных интерфейсов создаётся просто ради того, чтобы иметь TUI. Часто они плохо продуманы или недостаточно проработаны, чтобы быть эффективными/продуктивными.

Но более широкая тенденция в GUI-приложениях — нацеливаться на долю рынка, а не повышать продуктивность пользователей клавиатуры. В 80-х и 90-х Photoshop, Illustrator и другие стали гигантами, которыми они являются сегодня, потому что они позволяли профессионалам быть чрезвычайно эффективными благодаря множеству мощных клавиатурных шорткатов. В 2026 году, когда софтверные компании умирают от KPI-ита и оценивают своих продакт-менеджеров по созданию убедительных подписочных моделей для привлечения клиентов, внимание к реальной продуктивности пользователей клавиатуры часто остаётся на задворках. Мобильные приложения не имеют клавиатурных шорткатов, а десктопные приложения всё чаще рассматриваются как узкий «крайний случай» с несколькими сотнями миллионов целевых пользователей против миллиардов на мобильных устройствах. Это возможность для тех, кто серьёзно относится к созданию ценности, используя мощь клавиатурных шорткатов, чтобы сделать свои GUI высокопродуктивными и полностью управляемыми с клавиатуры. При всех своих недостатках Microsoft сделала это правильно с VSCode.

> На самом деле, многие руководства по GUI-фреймворкам явно поощряют разработчиков приложений делать так.

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

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

Мне пришло в голову, что это замечательный способ проектирования ПО: вы сразу знаете клавиатурные шорткаты, потому что вы уже смотрите на них. Я работаю над тем, чтобы взять то, что я построил для qwerty-midi-клавиатурного контроллера (который построен на hammerspoon), и сделать его просто универсальным интерфейсом для любого приложения.

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

Мой проект, если интересно: https://github.com/mattdanielmurphy/qwerty-midi-hammerspoon

Не могу не согласиться, но думаю, что это в основном «гиковская» штука. Я использую i3 на своём личном Linux и aerospace на рабочем Mac; vimium в браузере, Neru в других приложениях (делает что-то похожее на Neru). Недавно я нашёл способ создавать пользовательские скрипты для electron-приложений, и с тех пор добавляю расширения в стиле vimium (например, в Teams) везде, где бываю.

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