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

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

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

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

Пара соображений:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подробности на http://www.zuschlogin.com/?p=40.

Я бы сказал, что отключите с указанием причины.

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

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

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

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

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

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

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

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

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

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

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

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

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