Статический интерфейс и динамический интерфейс

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

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

  • Серый цвет или

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

Ответ 6

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

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

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

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

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

Использовать отключить, если:

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

• Доступность достигается с помощью элементов управления в том же окне или его родительском объекте.

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

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

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

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

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

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

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

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

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

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

Ответ 7

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

Ответ 8

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

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

Ответ 9

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

Ответ 10

Хорошо, что идея последнего MS Office, не так ли? Элементы управления, которые основаны на контексте. Это, в сравнении с более старыми версиями с большим количеством серых меню и кнопок на панели инструментов.

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

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

Меньше лучше.

Ответ 11

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

Ответ 12

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

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

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

Ответ 13

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

Ответ 14

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

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

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

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

Ответ 15

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

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

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

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

Ответ 16

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

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

Ответ 17

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

Ответ 18

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

Ответ 19

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

Ответ 20

Согласно Джоэл - ни: -)

Ответ 21

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

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

Ответ 22

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

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

.. Поэтому я предполагаю, что вариант 1:)

Ответ 23

Комбинация двух.

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

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

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

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

Ответ 24

Мне нравится держать все расширенные опции скрытыми под "More → " / "Less < < или" Расширенный режим", в зависимости от контекста и приложения.

После нажатия/проверки окно расширяется, чтобы показать больше параметров.

С точки зрения доступности действий (например, Wizard с кнопками Next/Previous), я всегда показываю их и включаю/выключаю их в зависимости от того, какая функциональность возможна.

Ответ 25

Динамический пользовательский интерфейс выполняется, как пользовательский интерфейс может меняться. Поля могут меняться. Поэтому, в зависимости от того, что информация о поле, полученном из Интернета, спроектирована ui. Rembr! все аналогичные поля имеют одинаковый дизайн, поэтому вы можете продолжать изменять дизайн пользовательского интерфейса и, следовательно, приложение. не загружая более новую версию приложения в облачный или игровой магазин, вы можете изменить дизайн пользовательского интерфейса. В качестве примера шаблон и поля пользовательского интерфейса заполняются листом excel и загружаются в облако, и приложение имеет доступ к загрузке листа excel.

приведенное выше объяснение хорошо подходит для разработки динамических приложений Android.