А есть ли где‐то исследования на большой выборке?
Но скорее всего так оно и есть. Тогда нужно ещё добавлять подстветку ячейки при наведении. А с подстветкой, наверное, граница уже не столь важна.
Именно нужны, иначе её бесполезно увеличивать. Закон Фиттса работает ведь на человеке, а не на программе. Если человек не видит размеры области нажатия из‐за отсутствия границ, то он склонен считать областью саму надпись и будет целиться именно в неё.
Так и в Visual Studio можно драгэнддропать кнопочки на формочку. А можно руками писать. Но вот если сделать ее интерфейс монотонным, исключив хоть тот способ, хоть этот…
А исключать не надо. Нужен третий способ, который будет лучше этих двух вместе взятых. Тут есть где развернуться — тоже перспективное направление.
Я со своим накопленным опытом десятипальцевого набора буду совершенно не рад обнаружить клавиатуру на 210 клавиш, где будут присутствовать одновременно кириллические и латинские клавиши
Я не просто так добавил «где только можно». Ниже есть обсуждение, где на примере кейса предложенного Алхимиком я показал, как можно успешно избавляться от модальных окон.
А увеличение количества кнопок — это явно неправильный путь избавления от модальных раскладок, поскольку есть законы Фиттса и Хика. И количество пальцев на руках тоже ограничено. Кнопок на нынешней клавиатуре даже слишком много — можно было бы уменьшить.
Но способ всё‐таки есть даже в этом сложном и, казалось бы, неразрешимом случае.
Mozhno nabiratj tekst russkoj latinicej, a potom konvertirovatj yego v kirillicu. Takim sposobom mozhno poljzovatjsya xhotj desyatjyu pisjmennostyami, xhotj vsemi srazu. Yazyikovyixh kodov mnogo. ru
Tab↓↑
Можно набирать текст русской латиницей, а потом конвертировать его в кириллицу. Таким способом можно пользоваться хоть десятью письменностями, хоть всеми сразу. Языковых кодов много.
Привычные хоткеи нельзя выбрасывать из приложений для существующих систем, конечно же. Суть здесь в том, чтобы не плодить нарушение монотонности там, где это не нужно, где нет никакого пользовательского опыта.
В случае режимов опыт никак не помогает, поскольку привыкнуть к ним нельзя — модальные ошибки всё равно будут. От режимов нужно избавляться везде, где только можно. С модальными окнами аналогично.
А этот Риббон слепому десятипальцевому набору уж точно никак не мешает. Но у него проблема в том, что визуально искать в нём сложнее, чем в вертикальных списках меню. Ему бы мог помочь поиск подобный поиску по меню в macOS.
В 3D‐редакторах Drag and Drop очень широко используется.
Раскин говорит о том, что к монотонности нужно стремиться. Но немонотонный интерфейс приводит к значительно меньшим проблемам, чем режимы. Просто интерфейс будет сложнее изучать. И реализация будет сложнее.
А в разделе 5.2.2. «Команды» Раскин пишет о возможном направлении повышения монотонности в контексте графического интерфейса, хоткеев и коммандной строки. Описываемый подход в перспективе мог бы заменить текущую реализацию. Но именно в перспективе, поскольку такое не реализовать в рамках нынешней архитектуры операционных систем.
Но в рамках имеющихся возможностей и текущей целесообразности стремление к монотонности ведёт к упрощению как освоения интерфейса, так и его реализации, что тоже полезно. А Купер более подробно фокусируется на том, что и как можно делать в рамках существующих систем.
Нет, это защита от случайного нажатия на левую кнопку мыши, когда курсор случайно оказался над кнопкой. Это замена модального окна именно для этого случая. А от целеноправленного действия по отправке модальное окно всё равно не помогает. Тут уже вся надежда на внимательность пользователя, а внимельным быть проще, когда интерфейс не выносит мозг.
Это надуманные проблемы: и последняя, и предпоследняя. Не стоит делать из пользователя идиота — он знаком и с идиомой неактивной кнопки, и с идиомой закрытия окна. Закрытие окна никак не может и не должно приводить к отправке транзакции — это никак не связанные действия. Типичная ошибка программиста в UX дизайне состоит в том, что он рассматривает все возможные варианты, но не учитывает вероятность их наступления.
Если проблема забытых транзакций имеет место, то её нужно и решать, а не прикручивать костыли к кнопке закрытия окна, делая её мультифункциональной. Можно, к примеру, организовать наглядный стек подготовленных, но не отправленных транзакций. Возможно, можно ещё что‐то придумать — это уже нужно смотреть по ситуации.
Если человек принял решение отправлять, то он уже будет нажимать кнопки на автомате. Это как если сделать отправку по двойному или тройному клику на кнопку — толку не будет. Единственое, что может надёжно сделать модальное окно — это предотвратить отправку при случайном нажатии на кнопку. Но этого же можно добиться и без модального окна, если повесить отправку не на кнопку, а на Drag and Drop, например.
Ну то есть должна быть кнопка, после которой наступают финансовые последствия, будь то «Отправить транзакцию» или что‐то ещё. А автосохранение должно сохранять в виде черновика. Чтобы предотвратить случайное нажатие, вместо кнопки можно повесить это действие на Drag and Drop, например. И случайного клика уже не будет, и модального окна со всеми его минусами тоже.
А я думал, что есть какой-то приемчик, типа менять модальное окно каждый раз внешене
Количество внешних видов всё равно будет ограничено, поэтому не сработает. И даже если их будет очень много, то они все будут для пользователя на одно лицо, типа как реклама на сайтах, которая мозгом автоматически игнорируется.
Долихо- и брахицефалы смотрят на вас с подозрением.
Я всё же имел в виду переносное значение, под которым подразумевал психофизиологию. Мне нужно было взять в кавычки, уточнить или вовсе сформулировать иначе.
То, про что я говорю, он [Раскин] называет монотонностью.
Да, это так. Но он не предлагает отказаться от управления клавиатурой или от управления мышью. Дальше по книге он даже приводит возможное направление решения этой проблемы. Но это больше про перспективные направления. А в текущих системах конкретно в этом вопросе, к сожалению, имеем то, что имеем. Но если в каком‐то кейсе есть возможность это исправить, то нужно исправлять. Но главное, не втаскивать подобные проблемы в те интерфейсные решения приложения, которые собственно разрабатываются, а не навязаны системой.
На счет финансовых продуктов. Не то, что бы там прям нужны особые красивости, но юсер не должен его громко ненавидеть через 8 часов\неделю\год работы, сидя в очереди к окулисту или психиатору)).
А вот именно к этому и приводят модальные окна. И это серьёзнее, чем красивый графический дизайн, хотя он тоже важен.
Нет, светофор — это хороший интерфейс: красный — стой, зелёный — едь. А модалка — это шлагбаум на нерегулируемом перекрёстке, который нужно вручную поднимать. Как думаете, такой вариант обрадует автомобилистов?
Не. Деньги списаны, получателю ушла смс-ка, день закрылся, отчеты в налоговой, поезд ушел.
Ну так и в случае с окном подтверждения будет то же самое, поскольку пользователь пропустит его на автомате. Загуглите сколько вопросов о том, как отменить ошибочную транзакцию. Оно не работает.
1) Вариант 1. А у нас сразу при вводе все автосохраняется. Сперва 1 000 000, а через 15 мин, когда по договору параллельно прошли денежные движения, оператор перепроверил ввод и сказал «ой я ошибся», там должно было быть 10 000. Не вариант.
Ну так и исправит, и новое значение заново автосохранится. Он же до отправки транзакции проверяет. В чём здесь проблема? Или я как‐то не так понял кейс?
2) Вариант 2. Автосохраняется не при вводе, а при выходе без окна подтверждения. Но потом обязательно окажется, что сохранять не нужно было. В ходе заполнения формы, чувак кому-то перезвонил, переуточнил данные и просто хотел выйти, ничего не сохраняя. Перебивать все поля формы обратно перед выходом — не серьезно. Делать кнопку — «вернуть все как было», которую можно забыть нажать перед выходом — тоже не вариант. Отдельная кнопка — «выйти без сохранения» — да, нафиг, если есть крестик в углу окна, кликнул и убежал. А последствия автосохранения, еще раз — мнгновенные и финансовые. Не лучше или просто переспросить — вам уйти с сохранением али без?
Автосохраняться должно при вводе. Должна быть возможность откатить изменения типа как в git (не с ручными коммитами, конечно) — именно для тех редких случаев, когда это понадобится. Но это не будет портить весь остальной основной опыт взаимодействия. Переспросить хуже, потому что окно будет на автомате проигнорировано, как в большинстве случаев — у людей вырабатываются привычки.
И почему мгновенные потери? Потери будут только после нажатия кнопки «Отправить тразакцию». Если кнопку нужно нажимать два или три раза, то это не решает проблему, а создаёт новую.
3) Вариант 3. При выходе автосохранения нет и предупреждений тоже, т.е. все теряется. Но пользователь молод и имеет такой экспириенс, что за него все должна делать программа, поэтому действительно предпочел нажать кнопку «выйти», вместо сперва «сохранить», а потом «выйти» в расчете, что и так сохранится. А деньги в итоге не провелись там где должны были, в нужный срок. Опять же — не спросить ли подтверждения сохранить или как?
Нет, лучше сделать автосохранение.
Модальное окно работает, но для новичка — первый опыт.
Да, именно в этом их проблема. Середняк его пропустит — их большинство. Опытный путём тренировок и серьёзных когнитивных усилий, возможно, не будет пропускать. Но это приведёт к снижению его работоспособности, а при этом опытным специалистам ещё и платить нужно больше. Хорошо ли это для бизнеса?
И в некоторых случаях оно кажется безальтернативным (это к предложению отказаться от них вообще).
Ну в случае форматирования накопителя, наверное, да. Но это системные фишки, а в прикладном софте модальное окно почти никогда не нужно.
Вот здесь уже тема для UX — может в окне подтверждения слово «деньги» делать зеленым, «будут» — желтым, а «списаны» — фиолетовым?
Не поможет. В книгах, которые я здесь упоминал, это всё разбирается.
Но скорее всего так оно и есть. Тогда нужно ещё добавлять подстветку ячейки при наведении. А с подстветкой, наверное, граница уже не столь важна.
Для контента, с которым не нужно интерактивно взаимодействовать, оно так и есть. Но закон Фиттса говорит в пользу границ.
А исключать не надо. Нужен третий способ, который будет лучше этих двух вместе взятых. Тут есть где развернуться — тоже перспективное направление.
Я не просто так добавил «где только можно». Ниже есть обсуждение, где на примере кейса предложенного Алхимиком я показал, как можно успешно избавляться от модальных окон.
А увеличение количества кнопок — это явно неправильный путь избавления от модальных раскладок, поскольку есть законы Фиттса и Хика. И количество пальцев на руках тоже ограничено. Кнопок на нынешней клавиатуре даже слишком много — можно было бы уменьшить.
Но способ всё‐таки есть даже в этом сложном и, казалось бы, неразрешимом случае.
Mozhno nabiratj tekst russkoj latinicej, a potom konvertirovatj yego v kirillicu. Takim sposobom mozhno poljzovatjsya xhotj desyatjyu pisjmennostyami, xhotj vsemi srazu. Yazyikovyixh kodov mnogo. ru
Tab↓↑
Можно набирать текст русской латиницей, а потом конвертировать его в кириллицу. Таким способом можно пользоваться хоть десятью письменностями, хоть всеми сразу. Языковых кодов много.
В случае режимов опыт никак не помогает, поскольку привыкнуть к ним нельзя — модальные ошибки всё равно будут. От режимов нужно избавляться везде, где только можно. С модальными окнами аналогично.
А этот Риббон слепому десятипальцевому набору уж точно никак не мешает. Но у него проблема в том, что визуально искать в нём сложнее, чем в вертикальных списках меню. Ему бы мог помочь поиск подобный поиску по меню в macOS.
В 3D‐редакторах Drag and Drop очень широко используется.
А в разделе 5.2.2. «Команды» Раскин пишет о возможном направлении повышения монотонности в контексте графического интерфейса, хоткеев и коммандной строки. Описываемый подход в перспективе мог бы заменить текущую реализацию. Но именно в перспективе, поскольку такое не реализовать в рамках нынешней архитектуры операционных систем.
Но в рамках имеющихся возможностей и текущей целесообразности стремление к монотонности ведёт к упрощению как освоения интерфейса, так и его реализации, что тоже полезно. А Купер более подробно фокусируется на том, что и как можно делать в рамках существующих систем.
Должно быть что‐то типа этого:
Если проблема забытых транзакций имеет место, то её нужно и решать, а не прикручивать костыли к кнопке закрытия окна, делая её мультифункциональной. Можно, к примеру, организовать наглядный стек подготовленных, но не отправленных транзакций. Возможно, можно ещё что‐то придумать — это уже нужно смотреть по ситуации.
А крестик можно просто убрать и сделать две кнопки: «Отменить изменения» и «Обновить». И в результате модальные окна по‐прежнему не нужны.
Количество внешних видов всё равно будет ограничено, поэтому не сработает. И даже если их будет очень много, то они все будут для пользователя на одно лицо, типа как реклама на сайтах, которая мозгом автоматически игнорируется.
Я всё же имел в виду переносное значение, под которым подразумевал психофизиологию. Мне нужно было взять в кавычки, уточнить или вовсе сформулировать иначе.
Да, это так. Но он не предлагает отказаться от управления клавиатурой или от управления мышью. Дальше по книге он даже приводит возможное направление решения этой проблемы. Но это больше про перспективные направления. А в текущих системах конкретно в этом вопросе, к сожалению, имеем то, что имеем. Но если в каком‐то кейсе есть возможность это исправить, то нужно исправлять. Но главное, не втаскивать подобные проблемы в те интерфейсные решения приложения, которые собственно разрабатываются, а не навязаны системой.
А вот именно к этому и приводят модальные окна. И это серьёзнее, чем красивый графический дизайн, хотя он тоже важен.
Ну так и в случае с окном подтверждения будет то же самое, поскольку пользователь пропустит его на автомате. Загуглите сколько вопросов о том, как отменить ошибочную транзакцию. Оно не работает.
Ну так и исправит, и новое значение заново автосохранится. Он же до отправки транзакции проверяет. В чём здесь проблема? Или я как‐то не так понял кейс?
Автосохраняться должно при вводе. Должна быть возможность откатить изменения типа как в git (не с ручными коммитами, конечно) — именно для тех редких случаев, когда это понадобится. Но это не будет портить весь остальной основной опыт взаимодействия. Переспросить хуже, потому что окно будет на автомате проигнорировано, как в большинстве случаев — у людей вырабатываются привычки.
И почему мгновенные потери? Потери будут только после нажатия кнопки «Отправить тразакцию». Если кнопку нужно нажимать два или три раза, то это не решает проблему, а создаёт новую.
Нет, лучше сделать автосохранение.
Да, именно в этом их проблема. Середняк его пропустит — их большинство. Опытный путём тренировок и серьёзных когнитивных усилий, возможно, не будет пропускать. Но это приведёт к снижению его работоспособности, а при этом опытным специалистам ещё и платить нужно больше. Хорошо ли это для бизнеса?
Ну в случае форматирования накопителя, наверное, да. Но это системные фишки, а в прикладном софте модальное окно почти никогда не нужно.
Не поможет. В книгах, которые я здесь упоминал, это всё разбирается.