Comments 115
В первом варианте сложнее программировать (надо запоминать, что изменилось).

Во втором теряется функциональность - если я точно знаю, что мне надо поменять, я сразу нажимаю "Ок", а в таком варианте я буду вынужден нажать две кнопки.
По поводу сложнее запрограммировать - согласен, но только если посмотреть, у нас ведь не 95 год на дворе!

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

Если подходить с точки зрения кодера то половина программ не имела бы GUI как такового. Зачем он нужен то? :)
Да. если учесть, что львиная доля этих окон - это просто массив данных, применяемый на систему (как например окна Display Properties и Sytem Properties в винде, то это вообще не проблема: по нажатию на Cancel надо воccтановить начальное состояние. Я думаю в майкрософте писали вещи и по-сложнее :)
Из всех бед и косяков MS Windows - это меньший, на который можно было бы закрыть глаза.
Оставить так как и есть, но после нажатия кнопки "Apply", она должна измениться на кнопку "Вернуть все как было".
Хорошая идея. По крайней мере она не ухудшает текущее положение вещей, которое мне кажется вполне удобным.
на мой взгляд элемент не должен динамически менять смысла...
А почему, собственно нет? Ведь кнопка "Cancel" меняет свой смысл, но название у нее не меняется :)
Проблема в том, что мы все сейчас рассматриваем какое-то абстрактное окно диалога. Поэтому кто правее сказать сложно.
По большому счету - кнопка "Apply" - это костыль, который приделывается там, где не смогли реализовать диалог по-другому. Но дело в том, что за столько лет использования такая извращенная логика стала привычной, и если получится сделать так как должно быть, то многим и многим миллионам пользователей прийдется переучиваться.
и кнопка [Cancel] неправильно работает... :) а по поводу привычности - согласен, несомненно переучиваться никто не хочет :)
Все зависит от контекста.
В iTunes кнопки "Play" и "Pause" подменяют друг друга в зависимости от состояния проигрывания трека. Вы же не будете спорить, что это решение плохое?
безусловно не буду спорить - но пара Play/Stop - уже давно, лет 20 как устоявшееся двойное использование одной кнопки...
и с этим не спорю... :) что тяжело переучиваться будет - несомненно... но с точки зрения логичности [Ok], [Cancel], [Preview] на мой взгляд, правильнее.
Не стоит путать — здесь разница очевидна. Смена состояний кнопки идет из-за того, что на бытовой технике, чей интерфейс в той или иной мере принято копировать, это было принято для экономии места ввиду миниатюризации. И все равно, там эти кнопки подсвечивались, чем определялось состояние on/off (скажем, видеомагнитофоны). Смена Play/Stop идет именно из такого разряда, следующий шаг от подсветки.

Но там все очевидно — таким образом совмещать эти кнопки стоит только тогда, когда состояния противопоставляются. Здесь же все не столь очевидно. Что противопоставить "Apply"? "Cancel"? Вернуть все как было? Тем более, что в аналоговой технике такого не встречалось, посему в любом случае, это будет не более очевидно, чем этот триплет.
Где я сказал, что их надо совмещать? :) Читайте пост внимательнее, особенно первое предложение.
Думаю, что в большинстве случаев кнопка Apply не нужна вовсе.
Теперешние технологии позволяют отображать изменения сразу по мере их внесения. Если, конечно, речь не идет о действиях вызывающих какие-то массивные пересчеты данных. Но в таких случаях и сам Apply не показывают.
Ну а если выбирать из двух вариантов, то 1й конечно лучше, тем более что он довольно активно используется.
Погодите, то есть вы хотите сказать, что как только я вношу изменения они сразу отображаются в реальном времени. Ну а как быть если мне нужен целый комплекс из допустим десяти изменений в настройках при пересжатии видео и даже секунда на обработку каждого (а каждый по отдельности мне не нужен!) будет раздражать.
Бывает, что надо внести несколько изменений и посмотреть сразу их совокупный эффект, чтобы разницу ощутить.
Ну так никаких вопросов. Я уверен, что с ростом мощностей компьютеров мы к этому придем. А пока - для маломощных задач используем немедленный просмотр или как в photoshop чекбокс "preview". Ну а для тяжелых пересчетов - вариант 1 с превью.
Плохая статья. Я тоже сейчас возьму, перепишу своими словами выдержки из книги Владислава Головача "Дизайн пользовательского интерфейса". А толку?

--
см. стр.66 указанной книги.
Брателло, не было идеи переписать своими словами. Действиельно, замечательная книга Влада Головача уже в первой своей версии содержала данную проблему (2002). Я действительно читал когда-то эту книгу. Но статья написана чисто из собственного опыта, быть может и "по мотивам" этой статьи.

Если ты предлагаешь вставить ссылку на автора (повторюсь, это не перессказ - а мои мысли по этому поводу) - я с радостью это сделаю.

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

В любом случае спасибо за комментарий.
В HIG описан гораздо более удобный вариант - Apply вообще не нужен, все изменения видны сразу, но их можно отменить нажав Cancel.
Возникает резонный вопрос- как нажать Cancel, если диалоговое окно уже закрыто нажатием ОК? )
По-моему в "Apply" нет смысла, если "Cancel" не может отменить результат ( а это осуществимо не всегда ). Первый вариант мне ближе, но он тоже не идеален.
Думаю не нужно все валить на "Мicrosoft" - в конце концов у каждого разработчика есть возможность применять "Apply" или нет в своих приложениях.
Есть большая форма с кучей полей. Она разбита на табы. Вопрос: когда я перехожу на следующий таб с настройками, то сохранятся ли настройки в текущем табе? Спасает кнопка "Применить".
По тому же HIGу пока форма открыта смена таба не должна сбрасывать измененные настройки предыдущего
Это замечательно. Но если насроек много, то я, например, начинаю нервничать. И мне много спокойней, когда я сначала сохраняю, а потом получаю порцию новой информации в следубщем табе.
Опять же, это по HIGу, но это не значит что все разработчики следуют ему неукоснительно, поэтому могу Вас понять
Немного не так. Значение табов сохраняется всегда. Аплай тут не причем. Она в винде именно для просмотра сделана
Мне очень нравится реализация в Adobe InDesign CS2 (и более ранних версиях), там есть кнопки «Ok», «Cancel» и галочка «Preview», если ее включить, то все изменения будут отображаться в реальном времени, а кнопки не теряют своей функциональности, а наобарот — точно следуют ей.
+1. Очень удобная фича! Но, Вы наверное заметили, что в некоторых окнах эта самая галочка отсутствует. Apply-функциональность не всегда нужна. Иногда достаточно только OK и Cancel, а иногда одного OK с головой хватает.:)
Подходит только для тех сред, где изменения можно наблюдать визуально. Следовательно - в довольно узкой группе ПО.
Вообще говоря я тут вижу 4, а не три варианта развития событий:
1. Применить и закрыть. (он же ОК)
2. Отменить и закрыть. (он же Cancel)
3. Применить. (Apply)
4. Отменить изменения ничего не закрывая.

В фотошопе, в диалоговых окнах есть кнопка Cancel - так вот, если ее нажать с зажатым alt-ом, она не закрывает окно, а только сбрасывает изменения. Как по мне, очень удобно. Итого, оставляем две кнопки "OK" и "Cancel" - с зажатым alt-ом они просто не закрывают окно. Единственная проблема здесь - научить юзера пользоваться alt-ом.
UFO landed and left these words here
На подсознательном уровне я читаю: Применить — тут все понятно. Вторая кнопка — и закрыть. И вот тут меня клинит и я начинаю думать, что вторая кнопка отвечает все равно только за закрытие.

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

Ваша визитка — говно. =)
А в чём состоит проблема?

Вы сначала описываете задокументированное поведение, а потом предлагаете пути решения "проблемы". Напишите сначала, в чём состоит проблема дублирования смысла кнопок Ok/Cancel после нажатия Apply. Ну то есть зачем её решать?
Проблема в том, на мой взгляд, что после нажатия Apply - Ok/Cancel выполняют одну и ту же функцию - закрывают диалог, и вернуть "как было" нажатием одной кнопки может не получиться, то есть теряется их смысл. Нам бы хотелось :), чтобы была возможность посмотреть на результат и если нужно отменить изменения. В этом случае кнопка/чекбокс Preview как раз решение проблемы.
короче говоря, кэнсл не нужен, так как у окошка и так есть крестик чтобы закрыть в начале
Не надо экономить на кнопках. Попасть в крестик в заголовке окна в несколько раз сложнее, чем в настоящую кнопку "Отменить", которая стоит в одном ряду с остальными.

Такие окна без Кансела были у OS/2 Presentation Manager. Вспоминаю их с ужасом.
описание проблемы:
- кнопка кэнсл - отмены, но как кнопка отмены она не адекватна, т. к. после применения настроек, уже ничего не отменяет
- ту же функцию что и кэнсл играет крестик, абсолютно так же.

Иначе говоря, для закрытия окна достаточно одной крупной кнопки.
После Ok или Apply нельзя отменить изменения — вот, где проблема. И её решение в том, что ВСЕГДА должно быть доступно глобальное действие Undo.
Дорогой kappa, проблема вот в чем - если ты нажал один раз на Аплай - то кнопки Ок и Кэнсел уже не они. Они просто выполняют действие Close.
Вы неправы. Если у меня n настроек в m табах, то Apply играет роль _логического_ завершения работы с этим табом, а также аналог кнопки Save для настроек (вдруг прилогуха упадёт).
Например в Opera мне очень нехватает этой кнопки, ибо она у меня иногда падает из-за моих же экспериментов с ней, и сейчас когда захожу в настройки чтобы изменить 3 опции - 3 раза жму Ok, ибо для меня проще пару лишних раз нажать Alt+p, чем переделывать всё заново.
А я с тезисами статьи не согласен.

Если бы разработчики из Microsoft начали заботиться о пользователях чуть раньше


Такое впечатление, что все кругом умные, а в Microsoft специально тупых одбирают :)

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


Сколько пользуюсь этой кнопкой и не разу не задумывался над её смыслом. А это и есть главное предназначение интерфейса - незаметность.

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

Для пущей убедительности можно переименовать «Apply» в «Preview»


Не каждый «Apply» является «Preview» презультатам нажатия. Есть много окон, где результаты видны не станут.

В общем я не согласен ни что "Apply мешает и не так работает", ни с другими вариантами кнопок.
В том-то и дело что НЕ Apply не так работает, а Ok и Cancel.

Кратко: если Cancel ОТМЕНЯЕТ что-то, то почему он просто ЗАКРЫВАЕТ окно?

Касательно привычки - я, например, постоянно думаю нажать либо на Cancel либо на Ok - и в голове мелькает мысль - нажимай на что хочешь - результат один. Это слегка раздражает.
OK - сохраняет изменения и закрывает окно.
Cancel - всегда закрывает окно ничего не сохраняя.
Applу - сохраняет изменения, закрывает окно. Кроме того, кнопка Apply меняет свою активность в зависимости от наличия изменений.

Не вижу нелогичностей.
Другие тут уже писали, зачем им эти много вариантов. Apply как раз и появилась на окнах настроек для удобства пользователей.
действительно, кнопка типа apply или preview нужна в сложных случаях, особенно в случаях цепочечных действий. Но для простых задач, например в окнах с изменениями типа "да-нет", где пара чекбоксов - эта кнопка не нужна.

у вас в предыдущем комментарии кнопки ок и аппли работают одинаково, кстати. Зачем?
Это я очепятался.

Apply и появляется вроде только на многотабовых окнах и то не всегда.
Но эти недодумки идут намного дальше. Никто не задумывается, что кнопка старт должна отвечать за запуск чего-либо. Но каким-то таинственным образом именно она же предлагает нам выход из системы/завершение работы. Нужно просто никак было не называть кнопку.
Я бы не стал так категорично это называть "недодумкой". Просто был сделан такой выбор из разных вариантов.
Да и ваше логическое построение "кнопка старт должна отвечать за запуск чего-либо" тоже спорно очень.
Я говорю так, потому, что я знаю историю этого дела. Вся эта идеология кнопки старт позаимствована из OS/2. Но там была и кнопка непомню с каким названием, но для всяческого завершения.
полностью согласен, удобнее всего было бы переименовать [Apply] -> [Preview].
- при нажатии на [Cancel] -> ничего не происходит, любые изменения сделаные в диалоге не принимаются , окно закрывается (нажата до этого была кнопка [Preview] или нет неважно).
- при нажатии на [Ok] -> принимаются текущие настройки в диалогов окне...
Давным-давно Be inc. в системных и не только диалогах BeOS вообще не стала ставить никаких кнопок ок-кансел-аппли. По своему опыту могу сказать, что действительно очень часто эти кнопки вообще не нужны.

В таких окошках любые изменения применяются сразу.

Вот один из примеров, не совсем чистый (не оригинальная BeOS, а Zeta OS)



Добавлю, что не надо думать, что кнопок Ок или Отменить там нет совсем. Просто ненужные кнопки отсутствуют.
Для закрытия этого окошка надо метко попасть в жёлтый квадратик слева от заголовка? А если ошибся на 5 пикселей влево или вверх, то окно потеряет фокус, а наверх вылезет то окно, которые было под этим?

Круто.
только ради попадания обладателем трясущихся с бодуна рук?
Но-но :)
Даже у тех, которые не с бодуна, попадание занимает тем больше времени, чем меньше объект и чем дальше он от остальных объектов.

У Раскина в книжке даже формулы есть.
Переключение внимания с мыши на клавиатуру тоже занимает время. А совсем безмышиных интерфейсов в природе почти не осталось.
Чтобы правше или переученному левше закрыть окно - необязательно снимать руку с мыши. Нажимать Alt+W или Ctrl-W удобнее левой рукой.
А вообще это называется "закон Фитса":
Время достижения цели прямо пропорционально дистанции
до цели и обратно пропорционально размеру цели.
Согласен. Главное правило (для меня) - должно быть понятно. Кнопки нужны.
когда три кнопки, каждая из которых работает по своему алгоритму - намного понятней?
один желтый квадратик лучше трех бессмысленных кнопок.
можно закрыть по alt/ctrl-w
я правильно понимаю, что не нравится только отсутствие кнопки "закрыть"?
с остальным разногласий нет?
В интерфейсах компьютерных программ уже сложилось, что кнопка - это действие.

Меняю я настройки, меняю и хочу их потом сохранить. И начинаю думать "как?" :)

В Gmail вот, например, на странице настроек же есть кнопка "Сохранить" :)
я ещё раз повторю - это сила привычки к плохим интерфейсам. И я, конечно, не утверждаю, что в BeOS идеальный интерфейс. Я предлагаю стараться абстрагироваться от привычных интерфейсов мэйнстрим-систем и думать шире.
Я согласен с вами.
Стереотипы - это не всегда плохо, но в данном случае (и в данном месте - блоге о юзабилити) их можно ломать и это будет оправданно.
гмэйл в силу своей вебинтерфейсности не пример. Мы тут разве не про standalone-софт?
Мы как раз про standalone, просто даже web какие-то вещи делаются привычно.

Абстрагировать можно и нужно в новых продуктах (iPod тот же), вэбе (тот же Gmail)... Но в некоторых вещах нужно соблюдать консервативность.

В общем никто ничего не запрещает, главное чтобы клиент пользовался и платил :)
Иногда apply занимает много времени и лучше его не делать автоматически на каждый чих, а завести отдельную кнопку. Конечно в настройках мыши это не нужно. Но вообще это мелочь по сравнению с отсутствующей кнопкой закрытия.
Любой интерфейс проходит проверку временем. Сейчас же BeOs массово встречается лишь как схема для KDE.
он остался в системах-потомках, как минимум.

плюс некоторые идеи растаскивают разработчики других систем, например группировка нескольких окон одного приложения в XP.
Давайте от темы не отходить. Ясно что BeOs много чего дала. Не было осей которые не оставили бы следа хоть какого то. Но вы топик то перечитайте.
да я, в общем то, всё, что хотел сказать - сказал.

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

вот что значит сила привычки
Применит система сама и сразу и полетит куда-нибудь ракета с незаконченными настройками :)
вы, кажется, не все мои комментарии прочитали. Я уже говорил, что вариант с поным отсутствием кнопок - не обязательная панацея.
Мое резюме: модель OK-Cancel-Apply - уже устоявшаяся окнах настроек, в частности многотабовых окнах, и привычная для пользователей. Все перечисленные здесь альтернативы имеют только больше недостатков.
Да я сам удивляюсь количеству комментариев :)

Но пообсуждать всегда полезно )
Вариант 2. Помещать лишь две кнопки в окно: «Apply» и «Close»

Предлагаю доработать этот вариант.
  • При клике на "Apply" должно происходить визуальное применение изменений без сохранения конфигурации, а кнопка должна меняться на "OK" в классическом варианте.
  • В случае повторного возникновения каких-либо изменений кнопка "OK" снова должна меняться на "Apply" для возможности предпросмотра.
  • Кнопку "Close" стоит изменить на "Cancel", который будет отменять все изменения, сделанные при помощи "Apply".
  • Кнопка "OK" должна сохранять все изменения в конфигурацию.
    Также можно оптимизировать кнопку "Apply", выполняя при долгом нажатии на неё сразу действие "OK".

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

ничего логичного не вижу.
Они в описании хитрые, а по факту две кнопки: OK и Cancel.
А если сделаны какие-то изменения, то Apply и Cancel.

Плюс для гиков возможность быстро применить и закрыть окно по дабл-клику на Apply, ну или по длинному нажатию на ней.
Хуже динамической замены кнопок местами или также смены их действий и придумать нельзя — сразу не будет никакой интуитивной понятности (читай, дружелюбности интерфейса), а также в разы увеличиться время обучения работы с программой ввиду аллогичности происходящего: пользователь нажимает, кнопка исчезает. Что нужно нажать, чтобы ее вернуть?
Раз уже второй человек об этом написал, я всерьёз задумался...
В принципе, предложенный мной вариант был бы оптимален прежде всего для меня или для тех, кто может и хочет тратить время на обучение работы с системой, а не для массового сектора... Так что склонен согласиться, посему замолкаю :)
Как оффтоповую хохму могу высказать свое предположение. Что кнопка Apply ни что иное как название Apple которое досталось Microsoft в наследство при заимствовании кода. А так как разработчики не знали как избавится от этой злощастной кнопки, то заменили последню букву на 'y' и назначили на нее то действие которое нам всем извсетно. %)))
Глупости. После нажатия Apply другие кнопки (OK и Cancel) имеют различную функциональную нагрузку, а не просто закрывают окно, как утверждает автор.

Например, сначала пользователь может поменять ряд параметров, в которых он уверен, и сохранить изменения кнопкой Apply, после чего поэкспериментировать с рядом других параметров и либо оставить их кнопкой ОК, либо отказаться от изменений кнопкой Cancel.

А варианты автора ничем не лучше. Слава богу, его правильный второй вариант никогда не увидит свет в массовом ПО.
apply должна отжиматься,

нажал apply, посмотрел изменения, не понравилось отжал apply (как галочку). изменил настройки, опять нажал.
Only those users with full accounts are able to leave comments. Log in, please.