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

Ответ 1

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

Ответ 4

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

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

Ответ 5

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

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

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

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

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

Ответ 6

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

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

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

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

• У меня не было бы "Create Master Event" в качестве опции. У пользователя недостаточно прав для его просмотра.

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

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

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

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

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

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

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

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

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

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

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

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

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

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

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