Статический UI по сравнению с динамическим [закрытым] UI

Я предпочитаю скрывать все дополнительные параметры в кнопку "Больше >>" / "Меньше <<" или "

И то, и другое может иметь смысл, если вы используете парадигмы, с которыми знакомы пользователи.

Элемент управления вкладкой в ​​основном представляет собой динамический пользовательский интерфейс, который изменяется в зависимости от состояния.

Модальный пользовательский интерфейс вводит ошибки режима. Всегда.

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

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

A combination of the two.

If a function is not applicable in the current state, disable the button but also place an icon next to the button and associate a tooltip with the icon. The tooltip should explain why the user can't use the button right now.

Attaching the tooltip directly to the button doesn't work so well. Most users won't even hover over the button as they won't expect it to do anything.

And avoid exclamation mark icons. They suggest the user has entered an invalid value (unless they actually have.)

I'd like to say I always do this, but unfortunately it does take significantly more coding time, and clients aren't always willing to pay for that.

По словам Джоэла - ни : -)

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

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

Что бы вы ни выбрали, используйте постоянное положение кнопок. Пользователи часто не читают текст на кнопках.

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

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

Просто чтобы заново повторить то, что на самом деле сказал Митч Уит.

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

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

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

динамический лучше, если вы не хотите расстраивать своих пользователей

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

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

Я видел хорошие примеры того и другого, и плохие примеры того и другого.

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

Что ж, это идея последнего MS Office, верно? Окружающие элементы управления зависят от контекста. Это по сравнению с более старыми версиями с множеством выделенных серым цветом меню и кнопок панели инструментов.

Я работал несколько лет над системами управления, и в этих средах мы имитировали элементы управления оборудованием (переключатели, регуляторы, кнопки), которые были, или конечно, статичный, хотя и не всегда пригодный для использования. Это было требованием заказчика, и их позиция заключалась в том, что оператор, использующий систему, ожидал, что кнопка X всегда будет в одном и том же месте. Но с точки зрения дизайнера и разработчика меня разочаровал загроможденный пользовательский интерфейс, и мне не понравилось, когда 95% кнопок на экране были затенены.

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

Чем меньше, тем лучше.

Я не думаю, что есть правильный или неправильный ответ на этот вопрос, я думаю, что это просто вопрос мнения / предпочтений.

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

• Параметры администрирования (вероятно, не хочу раскрывать это пользователям с более низкими привилегиями)
• Функциональность RunOnce (активация продукта / регистрация)

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

Надеюсь, что это поможет.

Я всегда рекомендовал максимально неизменный пользовательский интерфейс:

• Не удивляйте пользователей

• Если действие недоступно потому что профиль пользователя запрещает его использование не показывать на все

• Только если действие недоступно потому что другое действие должно быть сначала завершено либо:

  • Затенено серым, либо

  • Оставить активным, но при выполнении отобразить сообщение с четким объяснением почему его нельзя выполнить

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

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

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

Динамический пользовательский интерфейс также актуален, если у вас есть обширный административный раздел, который вошедший в систему пользователь НИКОГДА не должен иметь возможности использовать. Скрывая раздел администрирования, вы избегаете путаницы и интерфейса "

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

Тонкая, но явно неактивная кнопка (не исчезающая) - мой предпочтительный выбор для разработки пользовательского интерфейса. ..

.. Думаю, это вариант 1 :)

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

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

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

Почему бы не сделать и то, и другое и позволить A / B-тестированию подсказать вам, что предпочитают ваши пользователи?

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

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

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

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

• Контролируйте поведение пользователя с помощью политики организации, а не программного обеспечения. Политики легче изменить при изменении бизнес-правил, в случае исключения или чрезвычайной ситуации.

Используйте отключение, когда:

• Пользователь может сделать что-то в приложении, чтобы действие стало доступным.

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

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

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

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

Использовать скрытие («динамический интерфейс»):

• Для действий, которые никогда не доступны пользователю в его или ее текущей работе.

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

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

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

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

Дополнительные сведения и обоснование см. На http://www.zuschlogin.com/?p=40 .