Должен ли пользовательский интерфейс отображать недоступные действия?

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

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

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

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

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

Если вообще не показывать вариант, это непоследовательно, но, возможно, это не так запутывает.

До вчерашнего дня я бы даже не задавал этот вопрос и сразу выбрал бы вариант 2 (Затенение), однако, наблюдая, как пользователь много раз пытается нажать на серое изображение и в конце концов спрашивает меня, почему они не могут нажать на кнопку Я больше не уверен, какой вариант лучше.

Что люди с опытом юзабилити и тестирования пользовательского интерфейса считают лучшим вариантом?

Ответов (11)

Решение

Мой подход (и рекомендация) заключается в том, чтобы кнопка была неактивна в соответствии с вашим вариантом №2.

Когда пользовательский интерфейс скуден и доступно достаточно места, есть встроенные (предварительные) контекстные подсказки (например, подход с вопросительным знаком, предложенный Фредди, рядом с кнопкой, с подробным описанием проблемы в строке, например, всегда отображаются под отключенными кнопка «Нет пользователей для удаления. Добавить некоторых, перейдя (ссылка) на эту вкладку (/ ссылка)!») может быть желательной.

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

Вышеуказанное должно относиться ко всем (как типичным, так и патологическим) случаям. Он сочетает в себе преимущества вариантов №2 и №3 без каких-либо недостатков.

Для этого сценария используйте 2, но добавьте вопросительный знак, объясняющий, почему он отключен. Обновление 1: обратите внимание, что это дает вам возможность четко определить, когда он будет активен / отключен.

Я предпочитаю показывать варианты, но неактивные. Вот почему. Если действие иногда доступно, а иногда нет, пользовательский интерфейс запутывается. Кажется волшебством, что иногда я вижу удаление, а иногда нет. С другой стороны, если он неактивен, по крайней мере, я знаю, где искать этот вариант позже.

Меня всегда учили, что удаление объектов из пользовательского интерфейса гораздо больше сбивает с толку пользователя, чем отключение. Не проектируйте для 0,01%, которым ничем нельзя помочь!

Бывают случаи, когда удаление кнопок панели инструментов является правильным способом, но в целом.

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

Второй вариант, отключение опции удаления серым цветом, должно быть достаточно. Мне кажется хорошей идеей добавить вопросительный знак для объяснения, как было предложено. В противном случае пользователь, вероятно, понятия не имеет, почему он может удалять некоторых клиентов, а некоторых нет.

Но вы всегда должны учитывать возможность того, что, хотя пользователь A уже открыл пользовательский интерфейс, с включенной опцией удаления, пользователь B заключает новый активный контракт. Поэтому, если пользователь A хочет удалить клиента, вам все равно нужно проверить, нет ли активных контрактов, и показать сообщение об ошибке, если они есть. Другими словами, вам еще предстоит реализовать все, что требует первый вариант. По этой причине я бы, вероятно, выбрал первый вариант, всегда показывать, оставлять параметр удаления видимым и активным, чтобы избежать дублирования кода и предложить наиболее последовательное поведение.

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

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

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

Просто примените принцип наименьшего удивления : не делайте ничего неожиданного.

Серый цвет означает, что он недоступен в текущем контексте.
Отсутствующий вариант может означать что угодно.

Одна из областей, где вы могли бы рассмотреть полное удаление элементов пользовательского интерфейса из поля зрения, - это когда ваше приложение предоставляет несколько уровней доступности (например, новичок, средний уровень, эксперт) или когда учетные записи пользователей следуют некоторым ролям безопасности, где `` гость '' не подразумевается. для доступа к полному интерфейсу, который, например, мог бы получить пользователь-менеджер.

Предлагаю вариант 1). Я вам скажу почему.

Вариант 3) (Худший) «Не показывать вообще возможность удаления». Это даже не дает пользователю понять, что такая функция существует. Так что это худший способ отрицать.

Вариант 2) «Показать вариант удаления, но неактивный

Лучше, чем 3), но пользователь может продолжать задаваться вопросом, почему ему отказывают в функциональности. Он также может начать думать, что он не является привилегированным пользователем и не имеет прав.

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

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

Раймонд Чен (известный как The Old New Thing) дает хорошие рекомендации:

Когда отключить параметр, а когда удалить?

Из записи в блоге:

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

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

Для этого конкретного случая вариант 2 - лучший выбор. Решая, скрыть что-то или отключить, я следую общему правилу:

Если пользователь не может выполнить операцию и есть что-то, что он может сделать, чтобы включить ее, то ее следует отключить.

Если пользователь не может выполнить операцию и ничего не может сделать для ее включения, ее следует скрыть.

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

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

Кстати, если пользователи пытаются нажимать ваши отключенные кнопки, может быть недостаточно очевидно, что эти кнопки отключены. Попробуйте изменить стиль кнопок, чтобы было больше различий между включенными и отключенными (при условии, что вы не используете стандартные элементы управления).