Должны несанкционированные действия в UI быть скрытыми, отключенными или привести к ошибке? [закрытый]
Строгие стандарты: нестатический метод [& lt; class> :: & lt; method>] не следует называть статически
Происходит при попытке вызова не- статический метод для класса, поскольку он был статичным, и вы также имеете флаг E_STRICT в настройках error_reporting().
Пример:
class HTML {
public function br() {
echo '
';
}
}
HTML::br() или $html::br()
Вы действительно можете избежать этой ошибки, не добавляя E_STRICT к error_reporting(), например
error_reporting(E_ALL & ~E_STRICT);
, поскольку, как и для PHP 5.4.0 и выше, E_STRICT включен в E_ALL [ ref ]. Но это не рекомендуется. Решение состоит в том, чтобы определить вашу предполагаемую статическую функцию как фактическую static:
public static function br() {
echo '
';
}
или вызвать функцию условно:
$html = new HTML();
$html->br();
Похожие вопросы:
12 ответов
Как почти со всеми вопросами о UI, ответ, "он зависит".
необходимо взвесить discoverability с удовлетворенностью пользователей, среди прочего. Например, разрешение недопустимого действия дает Вам возможность объяснить, почему что-то недопустимо. Это особенно полезно, если ответ на, "почему это отключено", не очевиден. Для приложения, где большинство пользователей является новичками, это важно.
, С другой стороны, может быть сильно печально видеть управление, нажать на него, только быть вознагражденным "жаль, Вы не можете сделать этого теперь" сообщение. Приложение я наследовал пару лет назад, изобиловало таким материалом, и это сделало использование UI упражнением в разочаровании.
Полностью скрывающаяся функциональность является, вероятно, редко хорошей идеей. Предположите знать, что некоторая функция "была там минуту назад", но теперь она пошла. Является ли это пунктом меню или кнопкой на панели инструментов, или что-то еще полностью, делая его скрытым может быть упражнением в разочаровании для конечного пользователя.
Попытка, делающая немного тестирования удобства пользования, если только путем выяснения у следующего человека Вы видите "эй, делает имеет смысл отключать это или показывать Вам информативное диалоговое окно". Просто еще одно мнение достаточно часто, чтобы заставить Вас смотреть на проблему от другого направления.
Нижняя строка: сделайте что лучшие подачи пользователь. Все сценарии, которые Вы упоминаете, действительны при определенных обстоятельствах. Как со всеми вопросами о UI, спросите себя (или лучше, Ваши пользователи), что лучше всего удовлетворяет их потребности.
Скрытый - Это - лучший подход для действий, которые никогда не доступны текущему пользователю. Нет, никакой смысл в наличии пользователя не тратит впустую умственное усилие, выясняющее, почему что-то отключено, если нет никакого действия, они могут взять для изменения этого.
Отключенный - Это - лучший подход для действий, которые иногда доступны, но не в данный момент или в текущем контексте. Отключенная опция должна передать две вещи: во-первых, действие не доступно прямо сейчас, и во-вторых, существует что-то, что пользователь мог сделать для предоставления доступа к действию доступным (измените некоторые настройки или разрешение, выберите объект, введите необходимые как условие данные, и т.д.). Если можно указать что потребности быть сделанными для включения действия в подсказке - тем лучше. При включении/отключении действий, поскольку пользователь вводит данные или изменяется, контекст обеспечивает превосходную обратную связь о том, чего требует программа.
Сбой с Ошибкой - Это - худший выбор. Необходимо только обратиться к сообщению об ошибке для операций, которые могли бы работать: Вы не можете сказать, что это перестанет работать кроме путем попытки.
Я отключаю элементы вместо того, чтобы скрыть их. Тем путем пользователь знает, что опция обычно была бы доступна, и я предоставляю подсказку для объяснения, почему элемент не в настоящее время доступен.
Это зависит. Вы хотите, чтобы пользователь знал, что действие возможно, просто не для них? В этом случае покажите им кнопку, но отключите ее. Пример мог бы быть то, если пользователь не имеет, удаляют полномочия, но другие пользователи делают, они должны знать, что CAN записей удален, таким образом, они могут попросить, чтобы кто-то сделал это для них, если им нужно действие.
, С другой стороны, если пользователь, как предполагается, даже не знает о действии (например, пользователь, у которого нет доступа для чтения к контрольным журналам, вероятно, не должен знать, что эти журналы существуют) не должен быть в состоянии видеть кнопку, поэтому скрывать его полностью.
Большой вопрос!
Несколько соображений:
, Если Вы помещаете элементы на странице, но отключаете их, существует все еще удаленный шанс, что пользователь мог доктор система и включать им использующий javascriptlet.
, Если Вы не показываете им вообще, полная функциональность может немного сбивать с толку обычного пользователя. "Разве кнопка редактирования не должна там быть здесь?"
, Если Вы собираетесь или отобразить и отключить или отобразить и проверить элементы, я был бы определенно , делают проверку серверной стороны. Не оставляйте проверку в руках JavaScript; я думаю, что причины этого очевидны.
Я склонен обрабатывать два различных типов ситуаций по-другому. Это действие, которым управляет полномочие и по состоянию объекта.
, Если у человека нет достаточных полномочий сделать действие, я скрываю опцию, они не знают, что могут выполнить действие.
, Если опция не доступна, потому что объект не находится в состоянии, которое может использовать ту опцию, я отключаю ее, позволяя опции быть видимым пользователю, но никакое действие не может быть сделано.
От Ваших примеров:
-
я не имел бы, "Создают Основное Событие" как опцию. У пользователя есть недостаточные полномочия просмотреть его.
-
у меня была бы кнопка Delete видимой администраторам. Тогда в зависимости от того, как Вы делаете остальную часть сайта (много видимого текста, подсказок, помогает значку, и т.д.) я следовал бы тому соглашению об информировании пользователя, почему кнопка не применима в это время. И возможно ставя таймер, выше, около кнопки или с тем, какого возраста сообщение или сколько времени, пока это не может быть удалено.
В зависимости от объекта мы или скроем их или отключим их. Если у пользователя будет доступ к большой функции, но не к меньшей части в нем, то мы скроем меньшую часть. Однако, если у пользователя будет доступ к нескольким большим функциям, но не другим, мы оставим их видимыми, но отключенными как маркетинговая уловка напомнить им, что функции доступны для покупки, если они должны решить, что хотят их.
Я также видел некоторые программы, которые отключают пункт меню и изменяются, текст его для "Входа в систему действительно болтают..."
мне нравится это, потому что это не оставляет меня с, "почему это не работает?" чувство и говорит мне сразу, что сделать для получения его работа. Не применимый в каждом случае, но это - хороший подход, если можно реализовать его.
Общее правило является отключением использования, если пользователь может сделать что-то в UI для получения права. Отключенный означает, что “you может сделать эту команду, но просто не прямо сейчас способ, которым вещи. ” “way вещи are” включают текущий выбор, так включение/отключение использования, если у пользователя есть полномочие EditEvent для старых объектов, но не для новых объектов. Должен быть ясный признак, который объекты, удаляют - способный, таким образом, пользователи понимают, почему связанные команды отключены для некоторых объектов (например, если пользователи обычно знают, что учет нужно вести в течение 5 лет, простое поле Age, возможно, быть достаточным, возможно, укрепить с графическим различием для записей более чем 5 лет).
окна сообщения Использования вместо того, чтобы отключить, если нет никакого способа сделать причину отключения ясной пользователю, предполагающему, что у них есть среднее знание домена. Подсказки для отключенных средств управления, BTW, являются прекрасной идеей, но не могут быть достаточными собой.
сокрытие Использования, если у пользователя никогда нет полномочия, неважно, что они делают в UI, учитывая их текущую позицию в организации (например, они не Администратор приложений). Это создает помехи и разбивает для использования отключения или окон сообщения для этого случая. Насколько пользователи заинтересованы, действия они, don’t имеют полномочие для, не их задание (иначе they’d, имеют полномочие), и таким образом, связанные средства управления не должны просто существовать в своем UI. Документация или организационные руководства процедуры могут сказать пользователям, как такие действия выполняются (например, супервизор “Your создает новые события для Вас. ”).
I’ve больше деталей в http://www.zuschlogin.com/?p=40 .
Я сказал бы, отключают с парением, содержащим причину.
Это препятствует тому, чтобы пользователь задался вопросом что, черт возьми, продолжается, одновременно позволяя им знать определенные действия возможны при правильных условиях.
У меня есть конкретная ненависть к приложениям, которые отключают кнопки. Если Вы - конечный пользователь - Вы хотите знать, почему Вы не можете использовать ту кнопку. При наличии его greyed ничего не говорит Вам. Как пройти состояние для включения его? Подсказки являются одним решением, но они не являются лучшими, много пользователей будет бороться с подсказками (если Вы не будете работать с опытными пользователями).
Мое личное отношение - то, что элементы должны всегда присутствовать. Если у пользователя нет достаточного количества полномочий сделать их, они должны генерировать ошибку, когда нажато на.
я знаю, что переводчики действительно не любят создавать огромное количество различных "разрешений, отклоненных" сообщения об ошибках, таким образом, это часто не делается в локализованных приложениях, которые имеют тенденцию скрывать элементы вместо этого.
На практике много людей склонно скрывать опции вместо этого даже в нелокализованных приложениях.