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

<p>для меня это постоянный вопрос, который я так и не решил, поэтому я хотел бы услышать ваше мнение. если у меня есть действия, которые, как я знаю, пользователь не сможет выполнить из-за недостаточных привилегий или состояния объекта, должны ли элементы пользовательского интерфейса для этих действий быть скрыты от пользователя, видимы, но отключены или видимы и привести к ошибке при попытке? каково будет обоснование вашего ответа? если вы отключены, расскажите о причине и, если да, то как?</p><p>это веб-интерфейс, так что я уже знаю, что мне нужно проверять входящие сообщения и получать разрешения и обрабатывать там ошибки. я в первую очередь говорю о том, как обращаться с пользовательским интерфейсом.</p><p>это похоже на <a href="https://stackoverflow.com/questions/79033/rules-about-disabling-or-hiding-menu-items">правила отключения или скрытия пунктов меню</a> , хотя меня интересуют все типы элементов пользовательского интерфейса, а не только меню.</p><p>примеры:</p><ol> <li> <p>у меня есть новая страница, которая позволяет пользователю создавать новое событие. события могут быть основными событиями или вложенными событиями. создание главного события требует привилегии "editmasterevent", в то время как создание дополнительного события требует только привилегии "editevent". у меня есть выпадающий список, который позволяет выбрать существующее событие в качестве родителя (главное событие) или нет родителя (это главное событие). должен ли быть выбран вариант "создать главное событие" в раскрывающемся списке или пропущен, если пользователь имеет только привилегии "editevent".</p> </li> <li> <p>для удаления событий требуется, чтобы вы были администратором приложения или имели соответствующие разрешения на редактирование для типа события. в последнем случае мероприятию также должно быть больше 5 лет. удаление события приводит к значительному каскадному удалению связанных данных в системе, и по юридическим причинам эти данные должны храниться не менее 5 лет после события. поскольку эта операция редка для обычного пользователя, типичным случаем является то, что действие недоступно. должен ли он показываться всегда или только когда это возможно?</p> </li> </ol>

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

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

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

<p>это зависит. вы хотите, чтобы пользователь знал, что действие возможно, только не для них? в этом случае покажите им кнопку, но отключите ее. в качестве примера можно привести, если у пользователя нет прав на удаление, но другие пользователи имеют, они должны знать, что записи могут быть удалены, поэтому они могут попросить кого-то сделать это для них, если им нужно действие.</p><p>с другой стороны, если пользователь не должен даже знать о действии (например, пользователь, который не имеет доступа для чтения к журналам аудита, вероятно, не должен знать, что эти журналы существуют) не должен видеть кнопку так что скрывай это полностью.</p>

<p>я имею тенденцию обращаться с двумя различными типами ситуаций по-разному. это действие, которое регулируется привилегиями и состоянием объекта.</p><p>если у человека недостаточно прав для выполнения действия, я скрываю эту опцию, они не знают, что могут выполнить действие.</p><p>если опция недоступна, потому что объект не находится в состоянии, которое может использовать эту опцию, я отключаю его, чтобы опция была видимой для пользователя, но никакие действия не могут быть выполнены.</p><p>из ваших примеров:</p><ol> <li> <p>у меня не было бы "создать главное событие" в качестве опции. у пользователя недостаточно прав для его просмотра.</p> </li> <li> <p>я бы хотел, чтобы кнопка "удалить" была видна администраторам. затем, в зависимости от того, как вы делаете остальную часть сайта (много видимого текста, всплывающие подсказки, значок справки и т.д.), я следую этому соглашению об информировании пользователя о том, почему кнопка в настоящее время не используется. и, возможно, установка таймера выше кнопки рядом с тем, сколько лет посту или как долго, пока он не будет удален.</p> </li> </ol>

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

<p>общее правило - отключение использования, если пользователь может сделать что-то в пользовательском интерфейсе, чтобы получить привилегию. отключено означает "вы можете сделать эту команду, но только не сейчас, как сейчас". "то, как все", включает текущий выбор, поэтому используйте включение/отключение, если у пользователя есть привилегия editevent для старых объектов, но не для новых объекты. должно быть четко указано, какие объекты могут быть удалены, чтобы пользователи понимали, почему связанные команды отключены для некоторых объектов (например, если пользователи обычно знают, что записи должны храниться в течение 5 лет, может быть достаточно простого поля возраст, возможно, усиленного с графической разницей для записей старше 5 лет).</p><p>используйте окна сообщений вместо отключения, если нет способа объяснить причину отключения пользователю, если он имеет средние знания о домене. кстати, всплывающие подсказки для отключенных элементов управления - отличная идея, но их может быть недостаточно.</p><p>используйте скрытие, если пользователь никогда не имеет привилегии, независимо от того, что он делает в пользовательском интерфейсе, учитывая его текущее положение в организации (например, он не является администратором приложения). в этом случае неудобно и неудобно использовать блокировку или окна сообщений. что касается пользователей, то действия, для которых у них нет привилегий, не являются их работой (в противном случае они имели бы эту привилегию), и поэтому соответствующие элементы управления просто не должны существовать в их пользовательском интерфейсе. руководства по документации или организационным процедурам могут сообщать пользователям, как выполняются такие действия (например, "ваш руководитель создает для вас новые события".).</p><p>подробнее об этом можно узнать на <a href="http://www.zuschlogin.com/?p=40">http://www.zuschlogin.com/?p=4</a> .</p>

<p>я бы сказал, отключить с указанием причины.</p><p>он не дает пользователю задуматься о том, что, черт возьми, происходит, и в то же время дает ему понять, что определенные действия возможны при правильных условиях.</p>

<p>в зависимости от предмета мы их либо скрываем, либо отключаем. если у пользователя есть доступ к большому элементу, но не к меньшему фрагменту внутри него, мы скрываем меньший элемент. однако, если у пользователя есть доступ к нескольким крупным функциям, но не к другим, мы оставим их видимыми, но отключим их в качестве маркетингового уловки, чтобы напомнить им, что функции доступны для покупки, если они решат, что хотят их.</p>

<p>у меня особая ненависть к приложениям, которые отключают кнопки. если вы конечный пользователь - вы хотите знать, почему вы не можете использовать эту кнопку. серый цвет ничего вам не скажет. как добраться до государства, чтобы включить его? подсказки - это одно из решений, но они не самые лучшие, многие пользователи будут бороться с подсказками (если вы не работаете с опытными пользователями).</p>

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

<p>другие люди предоставили хорошие ответы с обоснованным предложением избегать сокрытия элементов, а вместо этого отключить их и дать некоторые подсказки по причинам.</p><p>итак, я хотел бы взглянуть на это с другой точки зрения - но как скрыть некоторые элементы пользовательского интерфейса в тех случаях, когда пользователю не нужно их видеть, независимо от того, имеет ли он или нет разрешения для определенных действий, связанных с элементами?</p><p>например, скажем, пользователям некоторой роли предоставляется доступ к записям продавцов в системе.</p><p>но затем бизнес-аналитик говорит: "посмотрите, есть список со списком продавцов в этой форме, и мы не должны позволять некоторым конкретным ролям видеть его".</p><p>разработчик спрашивает: "итак, мы просто удалили разрешение" чтение продавцов "из этой роли, верно?" но аналитик отвечает: "нет! эта роль должна иметь возможность просматривать продавцов на странице" продавцы ". это просто единственная форма, в которой мы должны скрыть список для некоторых ролей и показать его другим ролям".</p><p>итак, разработчик добавляет разрешение под названием "показать выпадающий список продавцов на форме x".</p><p>ой, теперь у нас есть проблема. доступ к одним и тем же данным контролируется двумя отдельными разрешениями. теперь мы должны выяснить, как объединить их обоих. а что если есть несколько форм, где список продавцов должен быть скрыт для некоторых ролей? как мы можем объединить это с "прочитать список продавца"? для нас, разработчиков, несколько очевидно, что разрешение "чтение" должно иметь более высокий приоритет, чем "просмотр", поэтому даже если пользователь может "просмотреть" список, он все равно не должен его видеть (или видеть пустой или отключенный с помощью полезного намек) если у него нет разрешения на "чтение". мы, разработчики и аналитики системы, знаем это. но как системный администратор должен знать это? должны ли мы научить его этому? как мы можем гарантировать, что администратор не перепутает все эти "просмотр" и "чтение" для единого списка данных?</p><p>как вы видите, все становится беспорядочным по одной причине - мы смешиваем разрешения на обработку данных с удобствами пользовательского интерфейса в списке разрешений ролей.</p><p>я видел много проектов, в которых это становится беспорядочным, потому что разрешения на стороне сервера слишком сильно связаны с пользовательским интерфейсом, что требует проблем и возможных брешей в безопасности (потому что у вас есть несколько элементов в редакторе разрешений ролей для одних и тех же действий над одними и теми же данными) ,.</p><p>разрешения касаются доступа и операций с некоторыми конкретными данными. пользовательский интерфейс может только одинаково реагировать на разрешения во всей системе (отключение с помощью подсказок, скрытие и т.д.). мы никогда не должны изобретать новые записи разрешений только для целей пользовательского интерфейса.</p><p>теперь остается вопрос - а как на самом деле скрыть элементы пользовательского интерфейса для некоторых пользователей системы, чтобы не перегружать их огромным количеством всегда отключенных элементов? одним из решений могут быть рабочие области ролей. если мы четко знаем, что пользователям какой-либо роли никогда не понадобится доступ к некоторым конкретным данным, мы создаем набор элементов управления пользовательским интерфейсом, аналогично разрешениям, но на этот раз мы не называем их разрешениями. и здесь мы действительно можем придумать, даже позволяя пользователям самим свободно настраивать свое рабочее пространство и выбирать то, что они могут или не могут видеть. конечно, разрешения всегда будут иметь самый высокий приоритет, но это будет влиять только на данные и состояние элементов пользовательского интерфейса, а не на видимость.</p><p>это мои два цента. к сожалению, я сам не работал в такой системе, где разрешения и параметры рабочего пространства пользовательского интерфейса аккуратно разделены, потому что я всегда каким-то образом опаздываю в проект, когда "ущерб нанесен". но я надеюсь, что когда-нибудь у меня будет шанс. я просто надеюсь найти хороший пример, как это сделать правильно, но поиски в интернете почему-то не дают мне ничего полезного. неужели никто не пришел к тем же выводам, что и я? я не верю, что кто-то в мире шаблонов корпоративного дизайна должен был заметить это несоответствие разрешений ui <-> давным-давно.</p>