Комментарии 115
В первом варианте сложнее программировать (надо запоминать, что изменилось).
Во втором теряется функциональность - если я точно знаю, что мне надо поменять, я сразу нажимаю "Ок", а в таком варианте я буду вынужден нажать две кнопки.
Во втором теряется функциональность - если я точно знаю, что мне надо поменять, я сразу нажимаю "Ок", а в таком варианте я буду вынужден нажать две кнопки.
По поводу сложнее запрограммировать - согласен, но только если посмотреть, у нас ведь не 95 год на дворе!
По второму варианту согласен, но я и написал, что он хуже. Кроме того, второй вариант надо использовать только тогда, когда чаще всего окно будет висеть на экране большую часть времени.
По второму варианту согласен, но я и написал, что он хуже. Кроме того, второй вариант надо использовать только тогда, когда чаще всего окно будет висеть на экране большую часть времени.
Согласен но мы всё же говорим о юзабилити, а не о сложностях программирования. Мне первый вариант симпатичен.
Если подходить с точки зрения кодера то половина программ не имела бы GUI как такового. Зачем он нужен то? :)
Если подходить с точки зрения кодера то половина программ не имела бы GUI как такового. Зачем он нужен то? :)
Из всех бед и косяков MS Windows - это меньший, на который можно было бы закрыть глаза.
Оставить так как и есть, но после нажатия кнопки "Apply", она должна измениться на кнопку "Вернуть все как было".
Хорошая идея. По крайней мере она не ухудшает текущее положение вещей, которое мне кажется вполне удобным.
на мой взгляд элемент не должен динамически менять смысла...
А почему, собственно нет? Ведь кнопка "Cancel" меняет свой смысл, но название у нее не меняется :)
Проблема в том, что мы все сейчас рассматриваем какое-то абстрактное окно диалога. Поэтому кто правее сказать сложно.
По большому счету - кнопка "Apply" - это костыль, который приделывается там, где не смогли реализовать диалог по-другому. Но дело в том, что за столько лет использования такая извращенная логика стала привычной, и если получится сделать так как должно быть, то многим и многим миллионам пользователей прийдется переучиваться.
Проблема в том, что мы все сейчас рассматриваем какое-то абстрактное окно диалога. Поэтому кто правее сказать сложно.
По большому счету - кнопка "Apply" - это костыль, который приделывается там, где не смогли реализовать диалог по-другому. Но дело в том, что за столько лет использования такая извращенная логика стала привычной, и если получится сделать так как должно быть, то многим и многим миллионам пользователей прийдется переучиваться.
Все зависит от контекста.
В iTunes кнопки "Play" и "Pause" подменяют друг друга в зависимости от состояния проигрывания трека. Вы же не будете спорить, что это решение плохое?
В iTunes кнопки "Play" и "Pause" подменяют друг друга в зависимости от состояния проигрывания трека. Вы же не будете спорить, что это решение плохое?
безусловно не буду спорить - но пара Play/Stop - уже давно, лет 20 как устоявшееся двойное использование одной кнопки...
Не стоит путать — здесь разница очевидна. Смена состояний кнопки идет из-за того, что на бытовой технике, чей интерфейс в той или иной мере принято копировать, это было принято для экономии места ввиду миниатюризации. И все равно, там эти кнопки подсвечивались, чем определялось состояние on/off (скажем, видеомагнитофоны). Смена Play/Stop идет именно из такого разряда, следующий шаг от подсветки.
Но там все очевидно — таким образом совмещать эти кнопки стоит только тогда, когда состояния противопоставляются. Здесь же все не столь очевидно. Что противопоставить "Apply"? "Cancel"? Вернуть все как было? Тем более, что в аналоговой технике такого не встречалось, посему в любом случае, это будет не более очевидно, чем этот триплет.
Но там все очевидно — таким образом совмещать эти кнопки стоит только тогда, когда состояния противопоставляются. Здесь же все не столь очевидно. Что противопоставить "Apply"? "Cancel"? Вернуть все как было? Тем более, что в аналоговой технике такого не встречалось, посему в любом случае, это будет не более очевидно, чем этот триплет.
Думаю, что в большинстве случаев кнопка Apply не нужна вовсе.
Теперешние технологии позволяют отображать изменения сразу по мере их внесения. Если, конечно, речь не идет о действиях вызывающих какие-то массивные пересчеты данных. Но в таких случаях и сам Apply не показывают.
Ну а если выбирать из двух вариантов, то 1й конечно лучше, тем более что он довольно активно используется.
Теперешние технологии позволяют отображать изменения сразу по мере их внесения. Если, конечно, речь не идет о действиях вызывающих какие-то массивные пересчеты данных. Но в таких случаях и сам Apply не показывают.
Ну а если выбирать из двух вариантов, то 1й конечно лучше, тем более что он довольно активно используется.
Погодите, то есть вы хотите сказать, что как только я вношу изменения они сразу отображаются в реальном времени. Ну а как быть если мне нужен целый комплекс из допустим десяти изменений в настройках при пересжатии видео и даже секунда на обработку каждого (а каждый по отдельности мне не нужен!) будет раздражать.
Бывает, что надо внести несколько изменений и посмотреть сразу их совокупный эффект, чтобы разницу ощутить.
хорошая статья, хоть и на избитую тему... жду других работ авторов...
Хорошая статья - надо было захабрить!
Плохая статья. Я тоже сейчас возьму, перепишу своими словами выдержки из книги Владислава Головача "Дизайн пользовательского интерфейса". А толку?
--
см. стр.66 указанной книги.
--
см. стр.66 указанной книги.
Брателло, не было идеи переписать своими словами. Действиельно, замечательная книга Влада Головача уже в первой своей версии содержала данную проблему (2002). Я действительно читал когда-то эту книгу. Но статья написана чисто из собственного опыта, быть может и "по мотивам" этой статьи.
Если ты предлагаешь вставить ссылку на автора (повторюсь, это не перессказ - а мои мысли по этому поводу) - я с радостью это сделаю.
Уверен что в английской литературе достаточно много подобных размышлений, просто она для нас не так недоступна, как русская.
В любом случае спасибо за комментарий.
Если ты предлагаешь вставить ссылку на автора (повторюсь, это не перессказ - а мои мысли по этому поводу) - я с радостью это сделаю.
Уверен что в английской литературе достаточно много подобных размышлений, просто она для нас не так недоступна, как русская.
В любом случае спасибо за комментарий.
...вперед. Будет что обсудить.
В HIG описан гораздо более удобный вариант - Apply вообще не нужен, все изменения видны сразу, но их можно отменить нажав Cancel.
Возникает резонный вопрос- как нажать Cancel, если диалоговое окно уже закрыто нажатием ОК? )
Кстати, вы про какой HIG говорите?
GNOME HIG http://developer.gnome.org/projects/gup/…
про другие просто не слышал...
про другие просто не слышал...
Да. отличный вариант.
По-моему в "Apply" нет смысла, если "Cancel" не может отменить результат ( а это осуществимо не всегда ). Первый вариант мне ближе, но он тоже не идеален.
Думаю не нужно все валить на "Мicrosoft" - в конце концов у каждого разработчика есть возможность применять "Apply" или нет в своих приложениях.
Думаю не нужно все валить на "Мicrosoft" - в конце концов у каждого разработчика есть возможность применять "Apply" или нет в своих приложениях.
Есть большая форма с кучей полей. Она разбита на табы. Вопрос: когда я перехожу на следующий таб с настройками, то сохранятся ли настройки в текущем табе? Спасает кнопка "Применить".
Мне очень нравится реализация в Adobe InDesign CS2 (и более ранних версиях), там есть кнопки «Ok», «Cancel» и галочка «Preview», если ее включить, то все изменения будут отображаться в реальном времени, а кнопки не теряют своей функциональности, а наобарот — точно следуют ей.
+1. Очень удобная фича! Но, Вы наверное заметили, что в некоторых окнах эта самая галочка отсутствует. Apply-функциональность не всегда нужна. Иногда достаточно только OK и Cancel, а иногда одного OK с головой хватает.:)
Гениально )
+1 Да. самый лучший вариант на мой взгляд
Подходит только для тех сред, где изменения можно наблюдать визуально. Следовательно - в довольно узкой группе ПО.
Вообще говоря я тут вижу 4, а не три варианта развития событий:
1. Применить и закрыть. (он же ОК)
2. Отменить и закрыть. (он же Cancel)
3. Применить. (Apply)
4. Отменить изменения ничего не закрывая.
В фотошопе, в диалоговых окнах есть кнопка Cancel - так вот, если ее нажать с зажатым alt-ом, она не закрывает окно, а только сбрасывает изменения. Как по мне, очень удобно. Итого, оставляем две кнопки "OK" и "Cancel" - с зажатым alt-ом они просто не закрывают окно. Единственная проблема здесь - научить юзера пользоваться alt-ом.
1. Применить и закрыть. (он же ОК)
2. Отменить и закрыть. (он же Cancel)
3. Применить. (Apply)
4. Отменить изменения ничего не закрывая.
В фотошопе, в диалоговых окнах есть кнопка Cancel - так вот, если ее нажать с зажатым alt-ом, она не закрывает окно, а только сбрасывает изменения. Как по мне, очень удобно. Итого, оставляем две кнопки "OK" и "Cancel" - с зажатым alt-ом они просто не закрывают окно. Единственная проблема здесь - научить юзера пользоваться alt-ом.
?
На подсознательном уровне я читаю: Применить тут все понятно. Вторая кнопка и закрыть. И вот тут меня клинит и я начинаю думать, что вторая кнопка отвечает все равно только за закрытие.
Голубой овал тоже на подсознательном уровне говорит мне, что раз уж здесь написано что-то осмысленное, то куда ни ткни, действие будет одинаковым.
Ваша визитка говно. =)
Голубой овал тоже на подсознательном уровне говорит мне, что раз уж здесь написано что-то осмысленное, то куда ни ткни, действие будет одинаковым.
Ваша визитка говно. =)
А в чём состоит проблема?
Вы сначала описываете задокументированное поведение, а потом предлагаете пути решения "проблемы". Напишите сначала, в чём состоит проблема дублирования смысла кнопок Ok/Cancel после нажатия Apply. Ну то есть зачем её решать?
Вы сначала описываете задокументированное поведение, а потом предлагаете пути решения "проблемы". Напишите сначала, в чём состоит проблема дублирования смысла кнопок Ok/Cancel после нажатия Apply. Ну то есть зачем её решать?
Я тоже сяду рядом и послушаю (согласен).
Проблема в том, на мой взгляд, что после нажатия Apply - Ok/Cancel выполняют одну и ту же функцию - закрывают диалог, и вернуть "как было" нажатием одной кнопки может не получиться, то есть теряется их смысл. Нам бы хотелось :), чтобы была возможность посмотреть на результат и если нужно отменить изменения. В этом случае кнопка/чекбокс Preview как раз решение проблемы.
короче говоря, кэнсл не нужен, так как у окошка и так есть крестик чтобы закрыть в начале
Не надо экономить на кнопках. Попасть в крестик в заголовке окна в несколько раз сложнее, чем в настоящую кнопку "Отменить", которая стоит в одном ряду с остальными.
Такие окна без Кансела были у OS/2 Presentation Manager. Вспоминаю их с ужасом.
Такие окна без Кансела были у OS/2 Presentation Manager. Вспоминаю их с ужасом.
После Ok или Apply нельзя отменить изменения вот, где проблема. И её решение в том, что ВСЕГДА должно быть доступно глобальное действие Undo.
Дорогой kappa, проблема вот в чем - если ты нажал один раз на Аплай - то кнопки Ок и Кэнсел уже не они. Они просто выполняют действие Close.
Вы неправы. Если у меня n настроек в m табах, то Apply играет роль _логического_ завершения работы с этим табом, а также аналог кнопки Save для настроек (вдруг прилогуха упадёт).
Например в Opera мне очень нехватает этой кнопки, ибо она у меня иногда падает из-за моих же экспериментов с ней, и сейчас когда захожу в настройки чтобы изменить 3 опции - 3 раза жму Ok, ибо для меня проще пару лишних раз нажать Alt+p, чем переделывать всё заново.
Например в Opera мне очень нехватает этой кнопки, ибо она у меня иногда падает из-за моих же экспериментов с ней, и сейчас когда захожу в настройки чтобы изменить 3 опции - 3 раза жму Ok, ибо для меня проще пару лишних раз нажать Alt+p, чем переделывать всё заново.
А я с тезисами статьи не согласен.
Такое впечатление, что все кругом умные, а в Microsoft специально тупых одбирают :)
Сколько пользуюсь этой кнопкой и не разу не задумывался над её смыслом. А это и есть главное предназначение интерфейса - незаметность.
Рассуждая про кнопки можно привести кучу своих вариантов с разумными обоснованиями (замечательный пример, куда могут завести рассуждения - результаты задания Лебедева на дизайн панели управления лифта).
Не каждый «Apply» является «Preview» презультатам нажатия. Есть много окон, где результаты видны не станут.
В общем я не согласен ни что "Apply мешает и не так работает", ни с другими вариантами кнопок.
Если бы разработчики из Microsoft начали заботиться о пользователях чуть раньше
Такое впечатление, что все кругом умные, а в Microsoft специально тупых одбирают :)
пользователи настолько привыкли использовать эту неправильную раскладку кнопок, что уже давно не замечают проблему
Сколько пользуюсь этой кнопкой и не разу не задумывался над её смыслом. А это и есть главное предназначение интерфейса - незаметность.
Рассуждая про кнопки можно привести кучу своих вариантов с разумными обоснованиями (замечательный пример, куда могут завести рассуждения - результаты задания Лебедева на дизайн панели управления лифта).
Для пущей убедительности можно переименовать «Apply» в «Preview»
Не каждый «Apply» является «Preview» презультатам нажатия. Есть много окон, где результаты видны не станут.
В общем я не согласен ни что "Apply мешает и не так работает", ни с другими вариантами кнопок.
В том-то и дело что НЕ Apply не так работает, а Ok и Cancel.
Кратко: если Cancel ОТМЕНЯЕТ что-то, то почему он просто ЗАКРЫВАЕТ окно?
Касательно привычки - я, например, постоянно думаю нажать либо на Cancel либо на Ok - и в голове мелькает мысль - нажимай на что хочешь - результат один. Это слегка раздражает.
Кратко: если Cancel ОТМЕНЯЕТ что-то, то почему он просто ЗАКРЫВАЕТ окно?
Касательно привычки - я, например, постоянно думаю нажать либо на Cancel либо на Ok - и в голове мелькает мысль - нажимай на что хочешь - результат один. Это слегка раздражает.
OK - сохраняет изменения и закрывает окно.
Cancel - всегда закрывает окно ничего не сохраняя.
Applу - сохраняет изменения, закрывает окно. Кроме того, кнопка Apply меняет свою активность в зависимости от наличия изменений.
Не вижу нелогичностей.
Cancel - всегда закрывает окно ничего не сохраняя.
Applу - сохраняет изменения, закрывает окно. Кроме того, кнопка Apply меняет свою активность в зависимости от наличия изменений.
Не вижу нелогичностей.
слишком много вариантов
Другие тут уже писали, зачем им эти много вариантов. Apply как раз и появилась на окнах настроек для удобства пользователей.
действительно, кнопка типа apply или preview нужна в сложных случаях, особенно в случаях цепочечных действий. Но для простых задач, например в окнах с изменениями типа "да-нет", где пара чекбоксов - эта кнопка не нужна.
у вас в предыдущем комментарии кнопки ок и аппли работают одинаково, кстати. Зачем?
у вас в предыдущем комментарии кнопки ок и аппли работают одинаково, кстати. Зачем?
Но эти недодумки идут намного дальше. Никто не задумывается, что кнопка старт должна отвечать за запуск чего-либо. Но каким-то таинственным образом именно она же предлагает нам выход из системы/завершение работы. Нужно просто никак было не называть кнопку.
полностью согласен, удобнее всего было бы переименовать [Apply] -> [Preview].
- при нажатии на [Cancel] -> ничего не происходит, любые изменения сделаные в диалоге не принимаются , окно закрывается (нажата до этого была кнопка [Preview] или нет неважно).
- при нажатии на [Ok] -> принимаются текущие настройки в диалогов окне...
- при нажатии на [Cancel] -> ничего не происходит, любые изменения сделаные в диалоге не принимаются , окно закрывается (нажата до этого была кнопка [Preview] или нет неважно).
- при нажатии на [Ok] -> принимаются текущие настройки в диалогов окне...
Давным-давно Be inc. в системных и не только диалогах BeOS вообще не стала ставить никаких кнопок ок-кансел-аппли. По своему опыту могу сказать, что действительно очень часто эти кнопки вообще не нужны.
В таких окошках любые изменения применяются сразу.
Вот один из примеров, не совсем чистый (не оригинальная BeOS, а Zeta OS)
Добавлю, что не надо думать, что кнопок Ок или Отменить там нет совсем. Просто ненужные кнопки отсутствуют.
В таких окошках любые изменения применяются сразу.
Вот один из примеров, не совсем чистый (не оригинальная BeOS, а Zeta OS)
Добавлю, что не надо думать, что кнопок Ок или Отменить там нет совсем. Просто ненужные кнопки отсутствуют.
Для закрытия этого окошка надо метко попасть в жёлтый квадратик слева от заголовка? А если ошибся на 5 пикселей влево или вверх, то окно потеряет фокус, а наверх вылезет то окно, которые было под этим?
Круто.
Круто.
Да, это уж слишком )
Кнопки должны быть
Кнопки должны быть
только ради попадания обладателем трясущихся с бодуна рук?
Но-но :)
Даже у тех, которые не с бодуна, попадание занимает тем больше времени, чем меньше объект и чем дальше он от остальных объектов.
У Раскина в книжке даже формулы есть.
Даже у тех, которые не с бодуна, попадание занимает тем больше времени, чем меньше объект и чем дальше он от остальных объектов.
У Раскина в книжке даже формулы есть.
Согласен. Главное правило (для меня) - должно быть понятно. Кнопки нужны.
один желтый квадратик лучше трех бессмысленных кнопок.
можно закрыть по alt/ctrl-w
можно закрыть по alt/ctrl-w
я правильно понимаю, что не нравится только отсутствие кнопки "закрыть"?
с остальным разногласий нет?
с остальным разногласий нет?
В интерфейсах компьютерных программ уже сложилось, что кнопка - это действие.
Меняю я настройки, меняю и хочу их потом сохранить. И начинаю думать "как?" :)
В Gmail вот, например, на странице настроек же есть кнопка "Сохранить" :)
Меняю я настройки, меняю и хочу их потом сохранить. И начинаю думать "как?" :)
В Gmail вот, например, на странице настроек же есть кнопка "Сохранить" :)
я ещё раз повторю - это сила привычки к плохим интерфейсам. И я, конечно, не утверждаю, что в BeOS идеальный интерфейс. Я предлагаю стараться абстрагироваться от привычных интерфейсов мэйнстрим-систем и думать шире.
гмэйл в силу своей вебинтерфейсности не пример. Мы тут разве не про standalone-софт?
Иногда apply занимает много времени и лучше его не делать автоматически на каждый чих, а завести отдельную кнопку. Конечно в настройках мыши это не нужно. Но вообще это мелочь по сравнению с отсутствующей кнопкой закрытия.
Любой интерфейс проходит проверку временем. Сейчас же BeOs массово встречается лишь как схема для KDE.
не согласен с автором. очень часто встречаются окна, в которых я меняю какие-то настройки и сразу же применяю их. нравится - закрываю. не нравится - снова меняю и снова Apply. пример такого окна - окно настройки рабочего стола. когда выбираю обои
а если система будет сразу применять действия по изменению, то этой аппли и нужно не будет.
вот что значит сила привычки
вот что значит сила привычки
Применит система сама и сразу и полетит куда-нибудь ракета с незаконченными настройками :)
вы, кажется, не все мои комментарии прочитали. Я уже говорил, что вариант с поным отсутствием кнопок - не обязательная панацея.
Вариант 2. Помещать лишь две кнопки в окно: «Apply» и «Close»
Предлагаю доработать этот вариант.
- При клике на "Apply" должно происходить визуальное применение изменений без сохранения конфигурации, а кнопка должна меняться на "OK" в классическом варианте.
- В случае повторного возникновения каких-либо изменений кнопка "OK" снова должна меняться на "Apply" для возможности предпросмотра.
- Кнопку "Close" стоит изменить на "Cancel", который будет отменять все изменения, сделанные при помощи "Apply".
- Кнопка "OK" должна сохранять все изменения в конфигурацию.
Также можно оптимизировать кнопку "Apply", выполняя при долгом нажатии на неё сразу действие "OK".
В результате имеем простой двукнопочный интерфейс, логичный и понятный :)
это ужасное решение.
какие то замены заголовков кнопок, какие-то хитрые алгоритмы.
ничего логичного не вижу.
какие то замены заголовков кнопок, какие-то хитрые алгоритмы.
ничего логичного не вижу.
Они в описании хитрые, а по факту две кнопки: OK и Cancel.
А если сделаны какие-то изменения, то Apply и Cancel.
Плюс для гиков возможность быстро применить и закрыть окно по дабл-клику на Apply, ну или по длинному нажатию на ней.
А если сделаны какие-то изменения, то Apply и Cancel.
Плюс для гиков возможность быстро применить и закрыть окно по дабл-клику на Apply, ну или по длинному нажатию на ней.
Хуже динамической замены кнопок местами или также смены их действий и придумать нельзя — сразу не будет никакой интуитивной понятности (читай, дружелюбности интерфейса), а также в разы увеличиться время обучения работы с программой ввиду аллогичности происходящего: пользователь нажимает, кнопка исчезает. Что нужно нажать, чтобы ее вернуть?
Как оффтоповую хохму могу высказать свое предположение. Что кнопка Apply ни что иное как название Apple которое досталось Microsoft в наследство при заимствовании кода. А так как разработчики не знали как избавится от этой злощастной кнопки, то заменили последню букву на 'y' и назначили на нее то действие которое нам всем извсетно. %)))
Глупости. После нажатия Apply другие кнопки (OK и Cancel) имеют различную функциональную нагрузку, а не просто закрывают окно, как утверждает автор.
Например, сначала пользователь может поменять ряд параметров, в которых он уверен, и сохранить изменения кнопкой Apply, после чего поэкспериментировать с рядом других параметров и либо оставить их кнопкой ОК, либо отказаться от изменений кнопкой Cancel.
А варианты автора ничем не лучше. Слава богу, его правильный второй вариант никогда не увидит свет в массовом ПО.
Например, сначала пользователь может поменять ряд параметров, в которых он уверен, и сохранить изменения кнопкой Apply, после чего поэкспериментировать с рядом других параметров и либо оставить их кнопкой ОК, либо отказаться от изменений кнопкой Cancel.
А варианты автора ничем не лучше. Слава богу, его правильный второй вариант никогда не увидит свет в массовом ПО.
apply должна отжиматься,
нажал apply, посмотрел изменения, не понравилось отжал apply (как галочку). изменил настройки, опять нажал.
нажал apply, посмотрел изменения, не понравилось отжал apply (как галочку). изменил настройки, опять нажал.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Кнопка «Apply»: хорошая идея и плохая реализация от Microsoft