Если это, например, настройки Proxy или ещё чего-то связанного с сетевым подключением, включая различные ограничения и тому подобное — я однозначно за «OK». Сперва хочется полностью всё натыкать, чтоб одно с другим вместе имело смысл, а потом уже применить.
Если это настроки внешнего вида, вроде размера шрифта, то приятнее видеть изменение сразу, когда двигаешь ползунок, чтоб не тыкать Apply 100500 раз, пока подгоняешь.
В любом случае, если есть «OK» и «Cancel», обязательно должна быть кнопка «Apply», которая применяет настройки, но не закрывает окошко с ними. Если её нет, это может довольно сильно раздражать.
В целом я в большинстве случаев за «OK», но с исключением для настроек внешнего вида.
P.S. Громкости ещё, помимо внешнего вида. Громкость точно должна именно в реальном времени регулироваться, потому что так уж устроен наш мозг, что по циферкам довольно сложно оценить, чего ты хочешь (за исключением совсем натренированных звуковиков наверное), надо сразу слышать обратную связь. Даже в AlsaMixer всё регулируется и применяется сразу, без подтверждения, и это правильно.
P.P.S. А ещё иногда бывает проще закрыть программу, открыть конфиг в текстовом редакторе и там исправить. Даже если такое не особо предполагается разработчиком, и конфиг в каком-нибудь зубодробительном XML, бывает так, что в итоге удобнее.
Если это настроки внешнего вида, вроде размера шрифта, то приятнее видеть изменение сразу, когда двигаешь ползунок, чтоб не тыкать Apply 100500 раз, пока подгоняешь
Это решается добавлением третьей кнопки, «Применить». Много где есть, удобно.
Это решается добавлением третьей кнопки, «Применить». Много где есть, удобно.
В принципе да (я упомянул её важность в следующем абзаце). Ещё как вариант это можно решить небольшой превьюшкой прямо под соответствующим пунктом меню. Помимо кнопки «Применить», само собой. Она в принципе всегда мастхэв.
Впрочем, как минимум громкость точно должна сразу регулироваться. Даже с «Применить» уже неудобно.
Согласен. Но я бы расширил тогда, для тех случаев где размер шрифта и прочее - где реально выгоднее не иметь кнопки вида OK/Применить/Отмана - а применять сразу - чтобы была где-нибудь сверху в углу кнопочка отмены всех изменений за сессию.
Которая работает так: она сохраняет в памяти все настройки которые были на момент открытия настроек - и можно тыкать куда угодно но если что не понравится нажатием на эту конпку все возвращается на как было.
Ктати такое есть в systemsettings из KDE, но к сожаланию вроде как только там, а ведь такой подход можно было применять шире.
В общем да - в идеалне сложные настройки - с ок/отмена
а настройки внешнего вида без ок/отмена но с возможнотью отката всего что было натыкано с момента появления окна настроек.
Никакой, вернее оба. В графическом интерфейсе в зависимости от контекста действия должны быть
Мгновенная реакция
автоматическая
на каждое изменение
ручное активирование
на каждое изменение
на множественное изменение
Отложенная реакция
в зависимости от умолчания
с предупреждением по выходу из интерфейса настроек
выход без явного применения настроек - откат
без предупреждения с обязательным ручным применением
выход без явного применения настроек - откат
Возврат части значений на значения по умолчанию
Отображение изменённых частей через визуальное тегирование
Подписи указывающие на состояния по умолчанию для ориентирования
Всё это и даже больше надо принять во внимание и хорошенько подумать, в каких случаях что применять, при этом не допустить чтобы везде всё было слишком по разному, найти баланс, чтобы человеком воспринималось естественно, для него было логично, почему вот это вот так. И подходяще, не стремиться делать всё абсолютно одинаково.
почему авторы этих подходов что настройки применяются без ОК
Создание графического интерфейса типа, накидать контролов чтобы просто они были, это одно. Проектирование графического интерфейса это другое.
наличие кнопок ОК/ОТМЕНА сильно перегрузит их GUI
Когда ты просто накидываешь интерфейс, у тебя чаще ситуация когда есть некий вызов типа onclick, по нажатию и всё и обычно туда суют просто непосредственно прямое действие. Для ОК/ОТМЕНА, тебе как разработчику надо явно, навешать колбеки которые изменят состояние некой структуры/конфига и только по нажатию ОК, запуститься обход конфигурации, её проверка (бывают же ещё всякие взаимоисключающие штуки) и последовательное применение, а на ОТМЕНА, надо за ранее обеспокоиться и при входе в настройки считать все текущие параметры, сделать копию, и затем поменять местами всё. Короче сделать типа в лоб button_on_click("makeit",makeit_callback) и готово проще, чем тоже самое но button_on_click("makeit",makeit_callback_toggle) затем
Скорее Настройки не применятся пока не нажал ОК, но вообще зависит. В обычных приложениях хочу с подтверждением, в видеоиграх - немедленное применение для большинства, но подтверждение для некоторых (разрешение экрана, инпуты итд).
Вообще можно было бы на этом остановиться, но я понимаю, откуда ТС шагает: в последние годы наступило засилье интерфейсов, в которых опции применяются немедленно при вводе, нередко - там, где так точно делать не надо.
Скорее всего этот антипаттерн пришёл из дизайнов графических интерфейсов на мобилах. Нашли балбесы, откуда воровать идеи.
Ты спрашиваешь или агитируешь? Возможно, личным мнением лучше поделиться в комментариях, чтобы не перекашивать результаты голосования.
почему авторы этих подходов что настройки применяются без ОК - не видят этого сценария
Вопрос риторический. Я так понимаю, ты ожидаешь согласия, но готов выслушать возражения.
Нет, не то чтобы я против субъективно заряженного опроса. Это по-своему интересно и вполне соответствует нашему обычному паттерну: почекать галочки/крыжики, обсудить тему, посмотреть на шеренги пингвинов. Но предлагаю подумать.
Ну а два взаимоисключающих варианта как-то маловато. Возможно, кому-то хотелось бы проголосовать за «Оба лучше, даешь свободу авторскому видинию», кому-то за «Оба хуже, настраивать надо через текстовые конфиги». @CrX и @LINUX-ORG-RU высказали позицию в духе «В зависимости от настроек». Я с ними согласен.
Вариант для затрудняющихся и пофигистов добавил. А вот упоминание текстовых конфигов опрос размоет, он именно про то, как GUI организовывать. Про более фундаментальные подходы целесообразно отдельный опрос сделать.
Лично я за ОК, потому что очень легко отменить. Особенно ценно когда настраиваешь прогу, где куча опций, случайно тыкнул не туда и не заметил это, но прекрасно осознаешь что это случилось.
И крайне интересно – почему авторы подхода, когда настройки применяются без ОК, не видят этого сценария, и неужто им кажется что наличие кнопок ОК/ОТМЕНА сильно перегрузит их GUI и сделает его архаичным, что ли?
Скажу по практике - я обычно стараюсь делать минималистично - нажал и сразу применилось. Так вот, юзеры очень часто критикуют этот подход. Им надо, оказывается, подумать и явно после применить изменения.
Если не хочешь кучу жалоб «ой а чего это у меня сам удалился аддон», всегда делай конечную кнопку применения.
Не люблю GUI. Можно мискликнуть. Неинформативны. Особенно писать их ненавижу. Единственный более-менее вменяемый GUI видел в dvdisaster, где, при наведение на название настройки, выводилось полное её описание, а подменюшки прятались в отдельных окнах, доступных при клике на названии.
Который используется в 90% случаев. А индивидуальный режим используется для индивидуальных случаев, как это делают остальные 10% для своих индивидуальных случаев.
Ну как бы да. Но если поразмыслить, таких «не тех» настроек находится порядочное количество. Какой-нибудь там цвет фона, если его в GUI настраивать, тоже гораздо удобнее, когда прям водишь по палитре мышкой, плавно настраивая, и сразу видишь, как выглядит, без необходимости тыкать «применить». А где цвет фона, там и цвет текста…
Это и неудобства с их отменой создаёт и просто запутывает - сходу непонятно сохранились они или нет.
Надеюсь разработчику (и пользователю) хватит ума вместо кнопок «применить» или «ок» использовать «закрыть», что означает, что настройки применяются сразу, а кнопка просто убирает окно. У Notepad++ кстати так сделано в настройках и стилях.
А опция перезапустить программу есть? Я вот недавно как любитель микропрог и максимальных оптимизаций заметил, что окно настроек часто увеличивает размер программы и усложняет код. Какая-то мини программа с небольшим конфигом и как только кто-то осуждает за отсутствие визуальных настроек, понимаешь что надо цикл переделывать на много-оконное, в окне куча вкладок, куча элементов на каждый флаг, куча проверок правильности ввода данных, если используется поле ввода, какой нибудь анализатор ini-файла, чтобы заполнить комбобокс и проверка что эти файлы существуют. А чуть переделал концепцию и опять переписывай. Мне понравился вариант проги CLCL, у которой отдельная утилита настройки, то есть сама прога не содержит функционал настройки и это правильно, прога в автозагрузке, запускается 365 раз в год, зачем ей держать в памяти редко используемый (раз в 5-10 лет) функционал? Она вызывает исполняемый файл, который тупо работает с ini-файлом и все галочки просто сохраняет в ini. Но больше интересно как он передаёт основной проге, что надо перечитать ini-файл, через stdout что-ли.
Речь конкретно о GUI-настройках в GUI-софте. Текстовые конфиги или аргументы командной строки — это дефолт и есть в большинстве софта. Какие-нибудь там отдельные утилиты, ясное дело, применяют настройки только при подтверждении, а не в реальном времени. Это всё отельное, не про этот опрос.
Так-то я сам за текстовый конфиг в удобном формате в большинстве случаев. Желательно изменяемых ещё и аргументами командной строки и/или переменными окружения.
Вы додумываете за топикстартера то, о чём он не говорил.
Во-первых, это работает в обе стороны. Да, «GUI-настройки» можно понять двояко. И как «настройки графического интерфейса», и как «настройки посредством графического интерфейса». Я понял так, ты понял эдак — как минимум мы оба «додумали» каждый по своему, и каждый прав или неправ одинаково.
А проблема в том, что вот эта калька(?) с английского с написанием через дефис в русском — запутывающая. Если бы было «настроек GUI» или «настроек в GUI», было бы более однозначно. В английском, кстати, тоже «GUI settings» без дефиса это первое, а «GUI-settings» скорее второе.
Ну а во-вторых, ТС согласился с моим посылом, и из его поста в теме ясно, что он имел в виду всё же настройку посредством GUI, а не настройки гуЯ, как и понял я и @hobbit, и большинство людей в теме.
Если ты не видишь кнопку «применить» - это не значит что настройки сохранились. Возможно, дизайнер данного интерфейса просто странный и спрятал кнопку сохранения куда-то где сразу не заметно - так что ищи. Или, может быть, программа заглючила и почему-то эту кнопку не прорисовала. И вот чтобы таких двусмысленных ситуаций не возникало, нужно обязательно в явном виде показывать юзеру статус сохранённости текущих настроек, причём после начала их изменения должен быть виден переход от сохранённых к несохранённым, а в какой-то момент - обратный.
Кстати, чисто в качестве пищи для размышлений: даже на ЛОРе (да, это не GUI-софт, а сайт в интернете, но всё же) есть оба варианта. Большинство настроек делаются через профиль и требуют подтверждения для применения. Но переключение светлой/тёмной темы для Tango делается нажатием иконки внизу страницы без какого-либо дополнительного подтверждения. Да, это не ползунок и тем более не поле ввода, а кликабельная кнопка, но тем не менее скорее попадает под вариант без подтверждения.
Я поразмышлял на эту тему. Есть настройки, которые применять сразу болей-лимений безопасно: громкость, размеры шрифтов, начертания шрифтов, цветовая тема и прочее.
Есть настройки, которые заведомо не нужно применять сразу, просто потому, что выбираются не из списка возможных/допустимых вариантов (как темы или шрифты), но, например, вводятся строкой, как, например, адрес proxy, логин или пароль. Такую настройку заведомо не стоит применять сразу.
И есть настройки, которые выбираются из списка допустимых вариантов, но всё же их изменение может быть достаточно опасным, потому нужна кнопка подтверждения. Например выбор языка интерфейса и настроек локали. Согласитесь, если вы случайно ткнули в оформление на иврите, и сразу не только поменялись все надписи, но и направление ввода сменилось на справа-налево, и интерфейс весь от этого поменялся на незнакомо-непонятный, то это плоховатенько.
Лично я за немедленное применение за исключением случаев, когда это небезопасно, например при изменении настроек экрана. В обычных ситуациях нажатие дополнительных кнопок для применения — это, на мой взгляд, лишние действия в стиле «Вы точно уверены?».
А помимо опасности есть ещё, например, такая штука как «связанность» настроек. Я почему привёл в качестве примера прокси: для него вот есть IP, есть порт, есть логин и пароль. Если я хочу сменить один прокси на другой, мне надо поменять значения во всех четырёх полях. Если изменить только IP, например, и настройка применится сразу, то прога начнёт стучаться по новому IP, но по старому порту (и ещё и с неправильным логином и паролем) — это как бы вроде и не опасно, но глупо. Эти поля имеют смысл только вместе, и применять их надо только когда пользователь понял, что заполнил все эти поля, а не какое-то одно, что и достигается исключительно отдельным подтверждением. Естественно, это не обязательно может быть именно прокси, и не обязательно даже только текстовые поля — может быть и два ползунка, которые как-то «связаны» между собой, например, размер чанка информации и частота отправки этих чанков, ну и много чего ещё.
Блин, я из бокового меню на главной тоже подумал что это касается именно настройки GUI, и тыкнул в ответе на
Настройки применяются сразу - нажал на флажок или радио-кнопку и настройка применена
При настройке гуя удобнее сразу видеть результат. А оказывается что вы тут все про другие настройки… Тогда, конечно, лучше с отдельной применительной кнопкой.
Для этого лучше организовать Preview, а не мгновенное применение настроек. А то так случайно сделал фон такой же как текст (или очень близкой в плане контрастности), и… всё, ничего не видно, куда дальше тыкать.
Либо не применяется до нажатия кнопки подтверждения, либо с предпросмотром и откатом на предыдущее состояние по нажатию «Отмена».
По второй тактике обычно настройку отображения текста делают. Сразу видишь изменения в зоне предпросмотра и при этом не ломаешь интерфейс.
Применение без дополнительного подтверждения обычно уместно про изменении настроек через меню: скрытие/показ элементов интерфейса, изменение сортировки и всё такое прочее.
Я когда-то в программе размер шрифта излишне увеличил и строка настроек с размером шрифта улетела за экран. Пришлось искать файл, куда она настройки писала, и удалять.
А ещё в Гноме раздражало, что при изменении шрифтов/dpi всё вокруг перерисовывается, а при изменении обратно не встаёт куда было.
Для ГИП лучше всего Применить с таймером. В смысле по Применить выскакивает окошко с подтверждением. Если пользователь за 15 секунд в нём не нажал ОК, возвращается обратно (чтобы если настройки настолько плохи, что невозможно работать с настройками, не искать файл).
Вообще-то, и для TUI актуально. Например, в Midnight Commander сразу видны изменения при выборе темы оформления из списка.
Так что выбрал «Смотря, что за настройки».
Универсальный вариант (например, в Гимпе таких диалогов много): кнопки «ОК», «Применить», «Отмена» и чекбокс «Применять автоматически». Хотя иногда это избыточно, а иногда не хватает кнопки «Undo».