Кнопки и пиктограммы

[Proxy]

Наверняка каждый встречал во многих приложениях в GUI компактные кнопки без подписи (но есть подсказка/ToolTip). Или же часто подпись и всплывающая подсказка не отражает текущее положение переключателя. Т.е. если подразумевается, что по контексту кнопка определяет одно из двух значений, то перед пользователем как бы возникает мнимый альтернативный вопрос (вполне определённый), на который он может ответить либо "да", либо "нет". И "да" ассоциируется с нажатой кнопкой (чаще всего рамка меняет объём с выпуклого на вогнутый), а "нет" наоборот.
В этом случае проблем не возникает, но бывают иные случаи: кнопка не подписана, всплывающая подсказка не является инфинитивом (и неизменна) и ситуация по контексту мысленно вызывает не один вопрос или вопрос с отрицанием ("отключить лятор?" -"нет, не отключать" -"нет, отключить, лятор не нужен". Ну в речи была бы верная ситуация, не смотря на то, что вызывает сомнения (второй ответ явно некорректен), а в виде кнопки очень пользователю непросто сопоставить двойное отрицание и положение кнопки. Ещё в пример "Байпас" — он тоже сам по себе несёт смысл отрицания использования генератора эффектов) или вопрос, на который нельзя ответить "да" или "нет" ("в каком режиме производить поиск, в ускоренном или обычном"). И вот пользователь видит перед собой кнопку (везде под кнопкой на самом деле я имел ввиду переключатель (флаг, аналог чекбокса и т.п, как будет угодно), у которого два устойчивых положения, которые он меняет по клику и фиксирует до повторного клика), на которой присутствует лишь пиктограмма. Пиктограмма явно содержит символ состояния объекта, но совершенно не ясно состояние это объекта в текущий момент времени, или же это состояние объекта, которое возникнет после нажатия кнопки (т.к. у разных разработчиков разное понимание о пиктограмме на кнопке).

ЗЫ. Натолкнул на мысли QIP 2005 для Windows с его неадекватными кнопками: антиспам/антифлад отражает текущее состояние антиспама, а выключатель уведомления о наборе не меняет пиктограмму вовсе (притом во всплывающей подсказке следующий вопрос: "включить/отключить отправку уведомлений о наборе", что наводит на мысль, что первоначальное положение выключателя — включено, т.к. указано первым). Ошибки тут нет ("включить" обозначает действие), но пользователя вводит в ступор. Хочется ответить "да наверное нет", но такое положение у выключателя отсутствует.

[Хакер]

Я в таким случаях беру пример с Play/Pause.

[Debugger]

Меня тоже волновал это вопрос. И решил, что должен индикатор и кнопку лучше не совмещать.

[Proxy]

Я в таким случаях беру пример с Play/Pause.

В каком смысле? Не вижу ничего такого особенного в Play/Pause, просвяти?

UPD. Вспомнил где видел кнопки с вменяемыми индикаторами, которые не выглядят нелогично: на авто. На Самаре (второе поколение) у каждой кнопки (почти у каждой) есть встроенный индикатор (помимо подсветки), который отражает текущее состояние объектов (притом у кнопки визуально включено и выключено отличается по утопленности только у переключателя света, остальные возвращаются после отпускания в одно и тоже положение вне зависимости от включено/выключено, а после выключения зажигания "сбрасываются"). Не вводит в заблуждение из-за того, что не содержит изменяемую пиктограмму, а индикатор — простой светодиод. У софта же как-то более привычно видеть будущее состояние на пиктограмме. Ну сам я проголосовал за третий вариант, как за самый непротиворечивый. Если постараться, то он будет занимать площадь не больше, чем компактная кнопка без подписи с пиктограммой-индикатором.

[Хакер]

В каком смысле? Не вижу ничего такого особенного в Play/Pause, просвяти?

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

[Proxy]

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

Но пиктограмма на Play/Pause не меняется на "Pause/Play" после приостановки воспроизведения. Теперь возьмём ситуацию не с воспроизведением (ну или не обязательно воспроизведением, не важно), а с чем-то, состояние чего без индикатора не известно. К примеру выброс/приём трея BD-ROM на удалённой машине (неестественный пример, но вполне имеет право на жизнь на каком-нибудь аналоге радмина). Идею с Play/Pause нахожу вполне приемлемой, но её стоит дополнить изменением пиктограммы в зависимости от состояния объекта.

Имхо: цвета, не привязанные к пиктограмме однозначно ассоциируются с текущим состоянием. Зелёный чаще всего указывает на состояние running (не могу подобрать подходящее русское), жёлтый с состоянием перехода (или временной остановкой), красный с остановкой, отключением (или критическим состоянием), синий ни с чем явно не ассоциируется. Но к статическим состояниям цвета привязать довольно непросто. Имхо.
А пиктограммы самые вменяемые, как сказал Хакер, отражающие не состояние, а действие (пускай даже из двух половин, читаемых слева-направо, если иное невозможно). Как на иностранных слесарных станках различных (токарные, сверлильные, фрезерные). Ну это только при невозможности сделать отдельный индикатор.

[Хакер]

Но пиктограмма на Play/Pause не меняется на "Pause/Play" после приостановки воспроизведения.

После нажатия на |> начинается проирывание, и приктограмма меняется на ||.

[Proxy]

После нажатия на |> начинается проирывание, и приктограмма меняется на ||.

В такой вариации символ ближе к устоявшемуся пониманию состояния после нажатия. Лично я всегда такое трактовал, как "когда я нажму на эту кнопку, нечто будет находиться в приостановленном состоянии", либо как "нечто станет running (работать?)". Ничто не указывает на то, что это действие, а не будущее состояние. И если бы это конкретное применение не было устоявшимся (есть ведь и примеры, которые я привёл в первом посту, которые довольно нетривиальны), то я бы не мог однозначно сказать, что от меня ожидает приложение (что это: индикатор текущего состояния или пиктограмма, обозначающая действие кнопки/будущее состояние). Как быть к примеру с компактным переключателем механизма поиска (эвристический/обычный)? Изобразить лупу (которая ещё и с масштабом ассоциируется, не только с поиском) с 4 точками по порядку и менять её на лупу с точками, расположенными хаотично? Ну тогда как объяснить пользователю, что это подразумевает действие (изменить механизм поиска), а не текущее состояние? Тут (имхо) лучше всё же сдвоенная пиктограмма, где слева текущее состояние, а справа будущее (потенциальное).

[FaKk2]

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

[Хакер]

То есть когда ты видишь кнопку «Плей» ( I> ), ты считаешь, что это сейчас идёт воспроизведение, и нажатие всё остановит?

[Proxy]

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

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

То есть когда ты видишь кнопку «Плей» ( I> ), ты считаешь, что это сейчас идёт воспроизведение, и нажатие всё остановит?

Нет, но это только благодаря тому, что кнопка play/pause устоялась (часто встречается и её поведение изучено). Поставь вместо "|>" и "||" что-либо другое и мне придётся глубоко задуматься к сторонникам какой идеи относится разработчик, прежде чем нажать (шанс где-то примерно 50/50). Тот же QIPовский пример, на вдавленной кнопке нарисован знак "кирпич" (когда антиспам включен). Возникает мысль, что "при нажатии на эту кнопку будет включен антиспам" (или "будет отключен обход антиспама". чисто для примера) по аналогии с play/pause, но... наоборот в QIPе, кнопка с кирпичиком означает только то, что в текущий момент антиспам включен.

[Хакер]

мне придётся глубоко задуматься к сторонникам какой идеи относится разработчик, прежде чем нажать (шанс где-то примерно 50/50).

Если на кнопке не source state или destination state, а state changement, state difference — о чём думать?

[arthur2]

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

[Proxy]

Если на кнопке не source state или destination state, а state changement, state difference — о чём думать?

Думать как по одной лишь пиктограмме понять, что подразумевал разработчик: source state, destination state или state changement.
Понятно, если для подачи каретки в правое крайнее положение изображена каретка со стрелочкой вправо, что речь идёт однозначно про state changement. Но если просто нарисована каретка в крайнем правом положении без всяких стрелок, то тут все 3 варианта возможны. Как в варианте с пресловутым кирпичиком, ломающем стереотипы.

Если кнопка залипает, она должна показывать текущее состояние.

Не факт... вон сколько мнений уже.

[FaKk2]

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

Например возьмем медиа плейер. Кнопка play |> намекает, что при нажатии, начнется проигрывание. И правда если нажать, то будет музыка, и кнопка сменится на ||. Повторное нажатие, приведет к ожидаемой паузе, и надпись опять вернется на |>.
Теперь посмотрим на кнопку Shuffle. Если на неё нажать, то она не поменяет надпись, но подсветит иконку. Своим внешним видом она показывает в каком состоянии сейчас проходит воспроизведение музыки: по умолчанию или вразброс. Это правильный, логичный дизайн. Меня раздражают ситуации, где это не так.

[Proxy]

Теперь посмотрим на кнопку Shuffle. Если на неё нажать, то она не поменяет надпись, но подсветит иконку. Своим внешним видом она показывает в каком состоянии сейчас проходит воспроизведение музыки: по умолчанию или вразброс. Это правильный, логичный дизайн. Меня раздражают ситуации, где это не так.

Насчёт "подсвечивает" меня тоже устраивает вполне, понятно, что это индикация активности в текущий момент времени и ничто иное (я приводил пример с некоторыми аналогичными автомобильными выключателями/переключателями). А вот насчёт изменения пиктограмм меня очень раздражает тот факт, что при наличии двух возможных трактовок (даже трёх, как выяснилось), разработчики не удосуживают себя сделать однозначно понятную кнопку. Если бы все считали, что на кнопке как по некоторому стандарту, не может быть изображено текущее состояние, то и сомнений бы не возникало. Ну даже голосование показало, что большинство не считают это верным.
И к слову: у того же AIMP для Windows (в минималистической обложке "Black Stilismo V", например, но не только в ней) кнопка Shuffle состоит только из пиктограммы (без рамки, надписи и т.д). Отображает текущее состояние упорядочивания. Тоже небольшой ступор вызывает при первой встрече.

[arthur2]

Не факт... вон сколько мнений уже.

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

Другое дело, когда кнопка отжата - тут можно воспринять хоть так, хоть эдак.

[Денис]

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

+1

[Proxy]

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

Если "залипающая" кнопка представляет собой чекбокс, то всё замечательно, но если она визуально не отличима от "не залипающей", то придётся её нажать, чтобы проверить... Это лишнее телодвижение — раз; не всегда допустимо — два. К тому же далеко не все "залипающие" имеют рамку. Тот же Light Alloy... Play/pause, неизменная, но залипающая (но "залипание" визуально не за счёт вогнутой рамки).
Если старый добрый чекбокс не всегда вписывается, то тем не менее он должен быть отличим от обычной кнопки.

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