Должен ли значок показывать текущее состояние или следующее состояние?

Ответ 1

На этом нет ни стандартизации, ни общей человеческой тенденции. Например, в Руководстве по взаимодействию MS Windows UX указано четыре основных типа переключения прогрессивного управления раскрытием. Три из четырех показывают состояние при активации, тогда как одно показывает текущее состояние.

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

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

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

• Используйте текст в дополнение к значку или вместо него. При маркировке глаголом (например, "Подключиться" ) элемент управления указывает состояние, которое пользователь получает. При маркировке прилагательным или существительным (например, "On Line" ) это означает текущее состояние.

• Если ваша библиотека не поддерживает переключение значков, рассмотрите возможность использования элемента управления флажком, если это разрешено.

• Если ваш lib не поддерживает флажки, тогда рассмотрите два элемента управления: один для установки каждого состояния, где текущее состояние отключено. Не слишком хорошо для чтения текущего состояния, но есть некоторые приоритеты для этого в раскрывающемся меню.

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

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

  • Элементы панели инструментов обычно показывают состояние, которое они приводят, поэтому поставьте значок в верхней части окна, если указывает состояние, которое пользователь получает. Напротив, значки в "рабочей области" окна указывают объекты или атрибуты, поэтому значки должны показывать текущее состояние. Значки в нижней части окна (в строке состояния) также должны показывать текущее состояние.

Ответ 2

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

Однако в других контекстах это не всегда так. Стрелка "Воспроизведение" отображается в фильме, когда фильм не воспроизводится, и отображается значок паузы во время воспроизведения. Наверное, вам нужно сделать все возможное, чтобы ваше мнение, а затем опросить своих пользователей. Если преобладание людей, которых вы тестируете, путают ваши варианты значков, переключите их. Затем проверьте их снова и проверьте, не начался ли ваш первоначальный тест.:)

Ответ 3

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

Вы привели пример текста, который минимизирован/максимизирован. Подумайте о любом расширяемом дереве, который вы когда-либо видели в Windows. Сведенное к минимуму дерево имеет рядом с ним [+], потому что нажатие кнопки приведет к расширению дерева. И с максимизированным деревом рядом с ним есть [-] по той же причине.

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

Ответ 4

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