Должны ли несанкционированные действия в пользовательском интерфейсе быть скрыты, отключены или приводить к ошибке?

Как и почти на все вопросы о пользовательском интерфейсе, ответ «это зависит».

Среди прочего, вам нужно взвесить возможность обнаружения с удовлетворенностью пользователей. Например, разрешение недопустимого действия дает вам возможность объяснить, почему что-то недопустимо. Это особенно полезно, если ответ на вопрос «почему это отключено» не очевиден. Для приложения, в котором большинство пользователей являются новичками, это важно.

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

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

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

Итог: делайте то, что лучше всего подходит пользователю. Все упомянутые вами сценарии действительны при определенных обстоятельствах. Как и в случае со всеми вопросами пользовательского интерфейса, спросите себя (или, что еще лучше, ваших пользователей), что лучше всего соответствует их потребностям.

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

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

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

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

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

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

Отличный вопрос!

Несколько соображений:

Если вы разместите элементы на странице, но отключите их, все еще есть небольшой шанс, что пользователь сможет изменить систему и включить их с помощью javascriptlet.

Если вы их вообще не показываете, общая функциональность может немного сбить с толку обычного пользователя. "Разве здесь не должна быть кнопка редактирования?"

Если вы собираетесь отображать и отключать или отображать и проверять элементы, я бы определенно выполнил проверку на стороне сервера. Не оставляйте проверку в руках JavaScript; Я думаю, что причины этого очевидны.

Я склонен справляться с двумя разными типами ситуаций по-разному. Является ли это действием, которое регулируется привилегией и состоянием объекта.

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

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

Из ваших примеров:

1. У меня не было бы опции «Создать мастер-событие». У пользователя недостаточно прав для просмотра.

2. Я хотел бы, чтобы кнопка «Удалить» была видна администраторам. Затем, в зависимости от того, как вы делаете остальную часть сайта (много видимого текста, всплывающие подсказки, значок справки и т. д.), я бы следовал этому соглашению об информировании пользователя о том, почему кнопка не может использоваться в настоящее время. И, возможно, включение таймера вверху рядом с кнопкой, указывающей либо возраст поста, либо время до его удаления.

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

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

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

Общее правило — использовать отключение, если пользователь может сделать что-то в пользовательском интерфейсе, чтобы получить привилегию. Отключено означает, что «вы можете выполнить эту команду, но не сейчас, как обстоят дела». «То, как обстоят дела» включает в себя текущий выбор, поэтому используйте включение/отключение, если у пользователя есть привилегия EditEvent для старых объектов, но не для новых объектов. Должно быть четкое указание, какие объекты можно удалить, чтобы пользователи понимали, почему соответствующие команды отключены для некоторых объектов (например, если пользователи обычно знают, что записи должны храниться в течение 5 лет, может быть достаточно простого поля «Возраст», возможно, усиленного с графической разницей для записей старше 5 лет).

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

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

У меня есть более подробная информация на http://www.zuschlogin.com/?p=40.

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

Это мешает пользователю задаться вопросом, что, черт возьми, происходит, и в то же время дает ему понять, что определенные действия возможны при правильных условиях.

У меня особая ненависть к приложениям, отключающим кнопки. Если вы конечный пользователь, вы хотите знать, почему вы не можете использовать эту кнопку. То, что он серым, ни о чем не говорит. Как вы попадаете в состояние, чтобы включить его? Всплывающие подсказки — это одно из решений, но они не самые лучшие, многим пользователям будет сложно работать с всплывающими подсказками (если только вы не работаете с опытными пользователями).

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

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

На практике многие люди склонны скрывать параметры даже в нелокализованных приложениях.

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

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

Например, допустим, пользователям какой-то роли предоставляется доступ к записям продавцов в системе.

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

Разработчик спрашивает: "Значит, мы просто снимаем разрешение "Читать продавцов" с этой роли, верно?" Но аналитик отвечает: «Нет! Эта роль все равно должна иметь возможность просматривать продавцов на странице «Продавцы». Это просто эта единственная форма, где мы должны скрыть список для некоторых ролей и показать его для некоторых других ролей».

Итак, разработчик добавляет разрешение «Показывать выпадающий список продавцов на форме X».

Упс, теперь у нас проблема. Доступ к одним и тем же данным контролируется двумя отдельными разрешениями. Теперь нам нужно придумать, как их совместить. А что, если есть несколько форм, в которых для некоторых ролей должен быть скрыт список продавцов? Как совместить это с "Прочитать список продавца"? Для нас, разработчиков, несколько ясно, что разрешение «Чтение» должно иметь более высокий приоритет, чем «Просмотр», поэтому, даже если пользователь может «Просмотреть» список, он все равно не должен его видеть (или видеть пустым или отключенным с помощью полезной подсказка), если у него нет разрешения «Чтение». Мы, разработчики и аналитики системы, это знаем. Но откуда системному администратору это знать? Должны ли мы научить его этому? Как мы можем гарантировать, что администратор не перепутает все эти «Просмотр» и «Чтение» для единого списка данных?

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

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

Разрешения относятся к доступу и операциям с некоторыми конкретными данными. Пользовательский интерфейс может реагировать на разрешения только согласованным образом во всей системе (отключение с помощью подсказок, скрытие и т. д.). Мы никогда не должны изобретать новые записи разрешений только для целей пользовательского интерфейса.

Теперь остается вопрос: а как на самом деле скрыть элементы пользовательского интерфейса для некоторых пользователей системы, чтобы не перегружать их огромным количеством всегда отключенных элементов? Одним из решений могут быть ролевые рабочие области. Если мы точно знаем, что пользователям какой-то роли никогда не понадобится доступ к определенным данным, мы создаем набор элементов управления пользовательского интерфейса, похожих на разрешения, но на этот раз мы не называем их разрешениями. И здесь мы можем проявить фантазию, даже позволив самим пользователям свободно настраивать свое рабочее пространство и выбирать, что они могут или не могут видеть. Конечно, разрешения всегда будут иметь наивысший приоритет, но они будут влиять только на данные и состояние элементов пользовательского интерфейса, а не на видимость.

Это мои два цента. К сожалению, я сам не работал над такой системой, где разрешения и параметры рабочей области пользовательского интерфейса четко разделены, потому что я всегда как-то слишком поздно прихожу к проекту, когда «ущерб уже нанесен». Но я надеюсь, что когда-нибудь у меня будет шанс. Я просто надеюсь найти хороший пример, как это сделать правильно, но почему-то поиски в Интернете не дают мне ничего полезного. Значит ли это, что никто другой не пришел к тем же выводам, что и я? Я не верю в это, кто-то в мире шаблонов корпоративного дизайна должен был давно заметить это несоответствие импеданса UI‹-> Permission.