Pull to refresh

Comments 119

Замечательная статья! Будучи сама разработчиком, я постоянно опасаюсь перегрузить приложение настройками и запугать пользователя.
А как вы относитесь к разделению настроек на advanced и typical?
UFO just landed and posted this here
UFO just landed and posted this here
>Да и в расширенные настройки имеет смысл лезть только в том случае, когда ты понимаешь чего хочешь добиться.

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

те кто тычут в «продвинутые» бездумно будут спокойны — настроек немного и все элементарные. а те кто действительно знают чего хотят рано или поздно найдут где и как это можно настроить (на крайняк ман почитают если сами не нашли)
UFO just landed and posted this here
UFO just landed and posted this here
UFO just landed and posted this here
откуда такая статистика? «typical» потому и назвывают «typical» а не «for beginners». и делают её, выбранным по умолчанию, чекбоксом. такчто юзер скорее всего тупо жмет «next» не задумываясь ни о чем
UFO just landed and posted this here
В xine-ui было очень удачное разделение настроек на 5 категорий. Я спокойно останавливался на 3-4, потому что в пятой я нифига не понимал, да и зачем мне эта экзотика нужна?..
Че за хрень?! Я, например, себя не считаю нубом/ламмером. Но если я разбираюсь с новым программным продуктом, и мне надо заставить его заработать, я сделаю это в упрощенном варианте, а расширенные настройки буду копать, если останется время, ну или в том случае, если и они не представляют для меня ничего сложного.

*голосом урка*: Статистику обоснуй или ответишь.
UFO just landed and posted this here
А надо не advanced называть а extended. «Расширенные» не бьют по самолюбию как «продвинутые». А так да, психология в интерфейсах — это очень большая тема.
Обычно, если есть две группы пользователей (advanced и typical), то недостаточно поделить только настройки, делить нужно весь интерфейс. Т.е. лучше всего делать две разных программы для разных уровней потребностей пользователей (как pixelmator и photoshop, picasa и lightroom).

По сути же это просто разделение экрана на два, причем по не очень ясному критерию (как пользователю определить, advanced он или нет?), т.е. поиск нужной настройки осложняется тем, что искать придется в двух местах вместо одного.
UFO just landed and posted this here
Аналогично делал несколько лет назад. А сейчас получилось сделать довольно сложное приложение вообще без настроек. Они либо определяются автоматически, либо преподаются в виде небольшого мастера, который человеческим языком объясняет, что, как и куда)
UFO just landed and posted this here
Это скорее тупо лишние настройки — вы их почитайте (даже те, что на скриншоте в статье), неужели пользователю есть дело до того, позволять или нет restricted protocols for active content (???), показывать mixed content (????), не спрашивать выбора сертификата когда что-то там… (????? чтоооо??). Никому, 0,000% пользователям, ни разу в жизни не понадобится менять эти настройки. Нужно просто разработчикам было самим сделать выбор, чтобы по умолчанию нормально и безопасно было. Разработчики, кстати, такой выбор намного лучше пользователя сделают. А настройки эти выкинуть.
Зачем выкидывать. Спрятать. Примерно как это сделано в фф через about:config.
Они могут регулироваться внутри приложения, хоть при сборке константами, но признайте, что из пользователей никому никогда не понадобится их менять. Для пользователя они не имеют смысла, и из интерфейса их надо просто выкинуть.
UFO just landed and posted this here
я сразу обратил внимание на то, что вместо трех строчек «названия опции», «вкл» и «выкл» можно было одно название с чекбоксом сделать)
Сколько людей — столько мнений, сколько программистов — столько программ, сколько дизайнеров — столько и дизайнов — можно перечислять до бесконечности… Такова людская натура и я считаю это правильным — держаться каких-то правил и держаться шаблонов не всегда правильно. Кого настройки радуют, кого-то огорчают — люди все разные и с этим ничего не поделаешь.
Покажите мне человека, которого радует настройка Allow webpages to use restricted protocols for active content: Disable/Enable/Prompt.
Есть и обратный пример. Netbeans. Отличная IDE. Но, Боже, почему в ней почти ничего нельзя настроить? размер и цвет шрифта не в счет. Ну дайте хотя бы конфиг-файл, но чтобы табы можно в два ряда выставить. Или настроить отображение непечатных символов (отличать пробел о таба, но не мозолить глаза символами конца строки).
P.S. Это уникальный комментарий ;)
в ультраэдитах чем дальше тем хуже с настройками. их и раньше было не мало, но их было проще найти. теперь же приходится лазить по «деревьям» и не всегда нужный рубильник оказывается там где ты его ищешь :(

а вот в IDEA не смотря на «деревья» все гораздо лучше — там есть поиск :D
согласен, поиск по настройкам (названию и описанию) — мегаудобная вещь
Но я так и не нашёл, как там отключить автоматическое форматирование кода для javascript.
Поиск — это уже мертвому припарка, когда настроек становится чересчур много. Это, конечно, лучше, чем его отсутствие.
Я слышал, что там до какой-то версии шрифт чуть ли не правкой в jar-файле менялся. Это тот случай, когда под задачу пользователя (настраивать цвета/шрифты в IDE — однозначно важная задача пользователя) не предусмотрели настройки. Видимо, пользователи их доконали, теперь добавили. Может, и ваши когда-нибудь добавят, хотя они узкоспецифичные довольно.
Голосовать не могу, но за статью спасибо!
Но на практике возникает другой вопрос — как лучше поставить процесс разработки UI чтобы удержаться на лезвии ножа «добавили лишнее — не добавили нужного». Для себя пока остановился на необходимости детального прототипирования софта в balsamiq mockups и отыгрывания на прототипе «рабочих» ситуаций, благо там можно кликать по кнопкам с переходами на другой экран.

А еще есть проблема с пониманием важности вопроса клиентом — он-то думает «да ну вас, еще тут время тратить играться с интерфейсами — кодить надо!». Не у всех получается противостоять давлению.
Когда-то нам руководство категорически запрещало делать вообще какие-либо настройки в довольно сложной программе. К слову, у конкурентов таких настроек были десятки. Ничего, жили, работали, пользователи довольны были. Прошло время, и теперь на предложение вынести что-то в настройки уже сами разработчики дают отпор. Даже настройки proxy полностью автоматические 9читай-отсутствуют) И это нормально. Иногда это экономит кучу времени разработчиков и тестеров, иногда- наоборот. Зато пользователи явно в выигрыше. В настройках оказывается или то, без чего программа совсем не может работать, или то, без чего возникнут разные нехорошие вопросы (вроде галочек «хранить пароль»)
Из опыта могу сказать, что обычно программа обрастает настройками и может быть, что большинства из них не было в оригинальном дизайне.

Поменяв что то раза три четыре по пожеланиям пользователей, обычно добавляется опция на этот случай. Сначала для себя — чтоб сэкономить время и деньги, а при наплыве однотипных изменений опция выходит в свет. Опять таки это может заметно разгрузить обслуживание и тех.поддержку.

Название обычно выбирается из переписки с первыми пользователями — то есть то как они определяли проблему. Например: «а как мне эту штучку сделать больше» превращается в опцию «увеличение штучки». Потом, правда, бывает проблема с пользователями которые хотели «эту штучку сделать меньше» и, конечно, не догадываются, что в опциях «увеличение штучки» ползунок можно потянуть и в другую сторону. Просто потому, что в эту опцию они не заглядывают — в названии не фигурирует то, что они ожидают увидеть. Появляется дублирующая настройка «уменьшение штучки», а из «увеличения» убирается возможность отрицательных значений. Хорошо, когда опцию можно легко переименовать объединив смысл, попустим «масштабирование штучки». Но часто, не смотря на техническую реализацию, описание проблемы являет собой «взаимоисключающие» требования.

Вот так не хитро получается, что на мэйл.ру куча настроек и адресс надо вводить 3 раза…
Всё так и есть, спасибо за доходчивое изложение. Но это не значит, что так и должно быть. Проектирование интерфейса не должно заканчиваться с выпуском первой версии продукта.
UFO just landed and posted this here
опечатка в тему — иногда без «настойки» не разобраться.
исправил
UFO just landed and posted this here
Однако не стоит скатываться в крайности, и убирать вообще все настройки (как это делает GNOME, превращаясь в desktop environment для полных олигофренов). Нужно уметь выбирать правильный баланс.

А оптимально, имхо, оставлять на видном месте только самые нужные настройки, а остальное прятать где-то под кнопкой Advanced.
Как-то прятать настройки — это странно. Это мешать будет скорее, чем помогать? Vista/7 хорошо вот настройки прячут, постоянно блуждаю в пачках экранов, перелинкованных друг с другом. Фиг что настроишь. Я думаю, что если настройка нужна, то делать её. Если без нее можно обойтись — не делать (в Mac OS X вон вообще только цвет выделения настраивается и чернобелость шариков в DE, и ничего, никто не страдает от нехватки настроек. Видимо, не сильно нужно). И ничего не прятать.

Кстати, я писал, что один продукт для всех сразу не сделать. Наверное, GNOME не для вас просто? Переориентируются, убирая настройки, они часть старых пользователей потеряют, зато новых приобретут. А метят на тех, кому как раз убранные настройки и не нужны, видимо.
А я вот люблю когда настроить можно как можно больше.
С условием, что все настройки названы верно (имя правильно отображает на, что влияет та или иная настройка) и в случае наличия совсем уж специфичных вещей, что бы было нормальное описание в мануале.
Скорее устранять нужно настройки, не относящиеся к целям и задачам пользователя. С этим всецело согласен. И многим программам есть что улучшать в этом плане — перестановка кнопок в Word, да, не имела отношения к задачам и была лишней, они, кстати, осознали и решили эту проблему в 2007-м. Не согласен с тем, что пользовательские настройки нужно всегда устранять. Например, скины в винампе были очень хорошей настройкой, потому что соответствовали цели пользователя выразить свою индивидуальность через необычный скин.
UFO just landed and posted this here
Не люблю, когда настроек мало или нет совсем. Иногда приходится брать в руки IDA и менять «вручную» то, что программисты могли бы сделать.
А еще очень сильно действует на нервы то, что в некотрых программах очевидные настройки доступны только в про-версии, а базовая сделана так, что кажется, что специально сделали, чтобы не было удобно. Чертов маркетинг!
Чтобы разобраться, давайте задумаемся, откуда берутся настойки?

Даа, без «настойки», выходит, не разобраться? :))

Шучу, спасибо за статью!
:)
поправил, спасибо
До открытия хабраката возникла мысль: в комментариях процитировать Getting Real. Открыл — а там уже ссылка на него :)
Кстати, о багтрекерах — у Launchpad очень удобный.
ix.io/Yl — лучшая реализация настроек из всего, что мне встречалось. Я серьёзно.
dwm. В awesome конфиг на lua, здесь конфиг — только Cшный header.
И почему в веб-интерфейсах нет более-менее текстовых конфигов?
Насчёт того, что наличие галочки заставляет программистов писать больше кода — поспорю. Обычно, если для какого-то параметр не получается тривиальным образом выбрать одно из значений, то отказ от галочки в настройках означает написание довольно сложного и интеллектуального автомата, который должен в каждом случает принимать решение какой из вариантов выбора использовать, а не просто примитивный выбор одного из вариантов. В моей практике было несколько случаев, когда код, который должен был принять решение, какой из вариантов алгоритма запустить, был сложнее самих алгоритмов. Это, в частности, является объяснением того, почему так мало встречается хороших приложений с минималистическими настройками, и обычно это приложения крупных компаний, имеющих возможности тратить на разработку значительные суммы.
Да, согласен, так тоже бывает. Но иногда не нужно выбирать во время исполнения, достаточно просто использовать всегда один из вариантов. Например, настройка — это перетаскиваемые панели, то приходится писать код, реализующий перетаскивание. А можно просто определить оптимальное место и перетаскивания не делать. Если настройка — выбор цвета кнопок, то приходится думать о том, чтобы на всех экранах был доступен конфиг для получения цвета (грубо). Потом еще тестировать, что везде применилось.
1. Mental model — ментальная модель, или модель пользователя, всего-то.

2. По поводу Купера — у вас фраза «проектировать с учетом целей и задач пользователя». Так целей или задача? Goal-centred design или Task-centred user interface design? Какой подход то? Не разобрались вы, честно.

3. Настройки — это «скрытый» налог пользователя на использован интерфейса. Все зависит от некоторых факторов: от того как часто пользователь обращается к настройкам, достаточно ли ему единожды к ним обратиться, и обращается ли к настройкам именно пользователь, а не обслуживающий персонал например.

4. Про закон Хика тоже вопрос. Вот, как вы считаете, он работает всегда безусловно, или например закон Хика применим к первому использованию интерфейса или нескольким первым?

5. >>Штука в том, что это представление не обязано соответствовать (и не соответствует) тому, >>как программа на самом деле работает (модель реализации).
То как должна работать программа — ментальная модель, небольшая у вас путаница. Как раз модель реализации это взгляд разработчиков, а не то взгляд пользователей, которые как раз знают, как должна работать программа.
1. Ок, просто не хочу разводить зоопарк с терминами, не зная, как в официальном переводе это называется.
2. В Goal-centered design задачи (tasks) все равно рассматриваются, хоть и вытекают из целей (goals) пользователя. Настройки — это уже детальный уровень, на нем, как правило, и цели, и задачи определены, и их надо учитывать. Это я имел в виду. Хотя, разное бывает, конечно. Можно и на уровне целей, наверное, настройки определить какие-то.
4. Наверное, когда пользователь делает выбор. Если у него до автоматизма переключение настройки отработано, то с интерфейсом что-то не так выбора не происходит, скорее всего.
5. Да, я написал то же самое, наверное, мы друг друга не поняли.
Задания рассматриваются, но они мало-критичны в этой модели. Хотя опять же, для меня например модель goal-centred не очень объективна. Уж немного это специфичный метод, т.к. для того чтобы его использовать нужен опыт и навык хороший работы именно с этим методом, чтобы получать результаты.
Тот же TCUID значительно быстрее может дать результат, но лучше или хуже — зависит от

С Хиком мне видется, что давно пора кому-то из гуру сделать пару экспериментов из области когнитивной психологии, чтобы прояснить, поле деятельности закона = )

Ну здравствуйте, малокритичны. Задания точно так же рассматриваются, только их определением занимается уже сам проектировщик, исходя из целей (кстати, более корректный перевод — мотивов) пользователя, а в task-centered они считаются даными свыше.
Я имею в виду исходно, конечно же, малокритичны. Вытекают они из целей. Поэтому мне этим модель и не нравится данная. Лишняя зависимость, которую приходится разрешать проектировщику.

Очень показателен пример с Гуглом. И волки сыты, и овцы… могут нажать одну кнопку и не мучаться выбором.
Пардон, а как насчет Advanced Search в Google?

Вариант 1:


Вариант 2:
Прочитать и понять 3 страницы Tips & tricks.

Я знаю катастрофически мало пользователей Google, которые умеют пользоваться вторым вариантом и в том интерфейсе, который так расхваливается. Заслуга Google в выдаче релевантных результатов по введенной абракадабре так, чтобы пользователю никогда даже в голову не пришло нажать «Advanced Search»! :)
Не уверен, что правильно понял вопрос (вопрос?), но google advanced search — хороший пример адекватных настроек. Всё по делу.
Как какрикатура первая иллюстрация, может, и хороша, но упомянутую проблему она не иллюстрирует. В Google главное не интерфейс, а то что спрятано под ним. Не каждой небольшой компании под силу построить что-то подобное и самая большая сложность — не на разработка интерфейса.
Кстати, вот сколько живу, все больше склоняюсь к тому (это моя, исключительно субъективная, точка зрения), что программировать легко. Постановка задачи, выделение требований — это сложно. А когда с этим понятно, писать программу просто и приятно, компьютер — машина детерминированная. Хотя интересное, не спорю, самому нравится.
Я как бизнес/системный аналитик, пожалуй, соглашусь. :)
Мне вот всегда импонировала манера Гугла добиться максимальных результатов минимальными внешними эффектами. Например, новые фильтры слева от выдачи — действительно удачный компромисс между простотой и функциональностью.

Насчет Advanced Search. Увы, отношусь именно к тому большинству, который этим не пользуется. Но для Advanced — не так уж все запущено. ИМХО.
Извините, но такое количество настроек (и вообще понятие «настройки») начинают появляться в программном обеспечении по двум случаям:
1. Продукт нацелен на массы, большие массы. Я имею ввиду продукт уровня «операционная система» или «офисный пакет».
2. Продукт пишется разработчиком, который решает задачу не зная для кого / или не зная зачем / или не зная какую задачу. Например, «хочу написать прогу для выключения компа, чисто по приколу», в реальности нужно пару кнопок, но разработчик думает, что продукт нужен всем и начинает добавлять кучу лишних опций. После чего, кстати, вряд-ли сам юзает свой продукт.

P.S.: а вообще те, кто перешел с win на mac как раз очень хорошо понимают суть избыточных настроек. (ИМХО, не хочу разводить холивар).
UFO just landed and posted this here
Проблема освещена лишь с одной стороны.
Я, например, считаю, что (лично для меня) лучше излишество настроек, чем их недостаток. Люблю любой продукт настраивать под себя. Но при этом (1) должны быть грамотные дефолты (чтобы минимизировать изменения), и (2) однозначная классификация по категориям (чтобы легко отыскать).
И совсем хорошо, если настройки еще разделены по уровню advanced-ости. Например, как вкладка «Дополнительно» в µTorrent, или страничка «opera:config» в опере, или какая-то ручная правка XML/INI-файла с настройками. Я полезу туда только в том случае, если мне это действительно надо. Все остальное время полный список настроек будет скрыт от меня.

P.S. Кстати, довольно долго в качестве IM-клиента использую Miranda (где-то, с версии 0.3). Именно из-за ее исключительной гибкости в настройках. Зато я ответственно могу заявить, что она работает так, как я хочу.
Не очень понял, каким боком интерфейс поиска багзиллы относится к настройкам. Как инструмент поиска он исключительно удобен.
просто они фильтры джиры не видели (клик):

<a/>
Жира вообще-то не для домохозяек. Любой айтишник в ней разберется без особых проблем. В итоге на этот экран попадаешь только несколько раз для настройки своих фильтров и все.
Да я что-то постоянно попадаю. Домохозяйка я, что ли? Правда, из этой кучи полей мне всего несколько нужно: проект, версия, assignee, статус, ну и текстовый поиск. Вот если бы они такой мини-фильтр сделали, вот это было бы круто. YouTrack видели, кстати? Вот там действительно для айтишников.
согласен, я уже два года джирой пользуюсь и самое сложное — найти нужный тикет(
ну не домохозяйки ей пользуются, но простым девочкам-менеждерам вполне приходится париться с ней. трекер то один на всю компанию.
а интерфейс поиска багзиллы не сложнее мантиса.
Для девочек менеджеров там создаются кастом фильтры, которые у них светятся на стартовой странице. А ля «Мои задачи», «Задачи которые я создал, но не закрыл после того как их сделали фиксед». И так далее.
дык кастом фильтры кто-то должен создать и девочкам показать. вот если б девочки, открыв поиск, сами все нашли, было бы круто)
Если девочки не полные дуры, то за пару дней вполне освоят. Проверено на опыте.
Имел счастье пользоваться жирой (а также редмайном, траком и прочими). Там везде примерно одинаковый кошмар. Но при регулярном использовании привыкаешь, да и невозможно это сделать проще, куда уж проще.
Ну там большая часть критериев (кроме дат) по сути — текстовые метки, и по меткам обычный текстовый поиск можно делать. Ввел название компонента — ищет по компоненту, ввел имя пользователя — ищет по assignee, ввел статус — ищет статус, версию — версию. Посмотрите YouTrack, они эту светлую идею воплотили в жизнь — одно поле поиска на все случаи жизни.
Если уж на то пошло, то лично мне было бы удобно пользоваться языком типа SQL для построения выборки. YouTrack посмотрел, впечатляет, да. Весьма близко к идеалу.
он удобен только при регулярном использовании, с точки зрения интерфейса он ужасен
Это как посмотреть. Приборная панель атомной электростанции с точки зрения дизайнера интерфейсов айфона тоже ужасна.

Хинт: интерфейс — это прежде всего удобство, а удобство вполне может достигаться ценой времени, потраченного на освоение. И уже после этого от такого вот «неудобного» интерфейса не оттащить.
имхо его можно сделать более дружественным к тем кто им не пользуется регулярно, сохранив при этом функциональность/удобство
Это очень дорого, а выхлопа чуть.
Кстати, про удобство далеко не всегда верно. Кнопка останова ядерного реактора не должна быть удобной. Она должна быть максимально неудобной, сложной и долгой в использовании.
Под удобством я имел в виду эргономичность. А это такое довольно многогранное понятие. Две кнопки для пуска пресса на расстоянии вытянутых рук — это из той же оперы.
Не совсем в тему, но хочу заметить, как разработчики в AutoCAD 2010 изящно решили давнюю борьбу тулбаров против ribbon. Они взяли, и сделали кнопку-переключатель для этих двух режимов, благодаря чему можно моментально либо вывалить все свои настроенные тулбары в традициях старого UI, либо увидеть вместо них более изящный ленточный интерфейс.
Тот случай, когда разработчик интерфейса не смог решить, что же лучше для пользователя, и добавили настройку. ИМХО, зря.
Они предоставили право решать пользователю. И настройку сделали не такую отвратительную как на карикатуре выше, а симпатичную кнопку вида «сделать мне приятно». По-моему наличие этой кнопки я выбрал в мастере, который открывается при первом запуске. Ко всему этому в AutoCAD есть еще и командный интерфейс, без которого AutoCAD не будет самим собой.
Бывают программы вообще без настроек.

rghost.ru/users/gts/releases/temperatura

Пример показывает, что совсем без них, пользователи уже чувствуют себя «неуютно». Уж очень привыкли видеть какие-нибудь меню с возможностью выбора.

четвертую ссылочку можно вместо баша читать)
А как насчёт решения мозиллы. Основные настройки доступны в меню, а остальные несколько сотен через редактор конфигурации.
Длинная простыня из не сортированных по функционалу настроек ужасна.
Там есть поиск… и они сортированы по имени, а значит в большенстве случаев, по функционалу. Что кстати отличает «это» от большенства конфиг-файлов
В случае настроек сортировка по имени не несёт никакой смысловой нагрузки. Как минимум потому что можно одно и то же назвать по-разному. Если вы программист, то наверняка знаете почему так сделано: просто потому что так проще. Дешевле.
Настройки есть, их надо где-то менять. Самое дешёвое — ввести в единый список и упорядочить по имени.

Вот только к удобству использования это решение не имеет никакого отношения.

P.S. большинство
Да там бОльшая часть имен настроек — вменяемые названия на английском. А описаниея есть в гугле, причем там очень увесистые описания.
Это имхо лучше, чем лепить все возможные настройки программы во всякие менюшки.
Ну там настройки не чтоб лазить по ним, а чтоб менять то что уже знаешь зарание.
ИМХО это немногим отличается от варианта «Тупикал» — «Адвансед»
Ну это тот случай, когда добавленные разработчиком «на всякий случай» без разбору настройки иногда позволяют-таки воспользоваться продуктом.
tonsky, спасибо за статью!

В своих приложениях я борюсь за каждую галку в настройках. Думаю над тем, можно ли ее там вообще не делать. Приглашаю всех покритиковать настройки Телефона. Это бесплатный (и свободный) софтфон под Мак с открытым кодом. Буду рад любым отзывам и замечаниям. Если совместными усилиями получится сделать его настройки лучше — будет здорово. :)
Для меня важно, чтобы настроить можно было максимум. Но при этом важно, чтобы поиск настройки нужного был интуитивно понятен, и изначально все было настроено так, чтобы все работало, и чтобы это не менялось от версии к версии.
В принципе, я не против мастера настроек, где некоторые специфичные вещи достаточно подробно описаны.
Но ни в коем случае не делать обязательным прохождение всех его этапов.

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

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

Считаю настройки сетевых подключений в Windows самыми дурацкими. В Висте вообще капец, наплодили всяких центров того-сего.

Тут выше уже поминали Раскина, тоже процитирую:
… если мы являемся опытными разработчиками интерфейсов и можем в максимальной степени оптимизировать данный интерфейс, то пользовательские настройки могут только ухудшить работу этого интерфейса. Поэтому следует с осторожностью предоставлять пользователю возможности по установке личных настроек. Если пользователь может действительно улучшить работу интерфейса, внеся в него всего лишь несколько полезных изменений, — это значит, что, вероятно, мы плохо сделали свою работу.

Про Висту согласен, в XP еще как-то терпимо было. Больше всего люблю системные настройки в MacOS X — всё в одном приложении, простая иерархическая структура, максимум два уровня вложенности.
там все-таки больше обсуждается внешний вид интерфейса нежели настройки, их количество и расположение.
Соглашусь с Вами, но частично. Да, количество настроек надо уменьшать, но никогда не стоит забывать что эти настройки помогают пользователю сделать программу удобной себе. Если мы говорим о программке загрузки компьютера, то настроек можно сделать и поменьше, однако если говорить о программах ежедневного пользования, то тут «заточка» под себя просто необходима.
Во общем мое мнение не стоит бросаться в крайности.
загрузка компа тоже своего рода программа ежедневного использования… :)
Согласен с автором:
Форма настроек как бы говорят нам:
«Мы (разработчики) не смогли придумать правильный сценарий, поэтому придумайте его за нас.»
Чем разношерстней пользовательская аудитория тем больше будет в программе настроек (как минимум это будут пожелания по интерфейсу, сколько людей столько вкусов).
Если программа решает одну конкретную задачу, то сделать ее понятной, предсказуемой и удовлетворяющей потребностям большинства (по дефолту) задача вполне решаемая малым числом настроек или их отсутствием. Если же программа решает комплексы последовательных или параллельных задач то тут все сложнее, и чем больше этот комплекс тем больше настроек (т.к. это будет совокупность настроек и определить ее однозначно уже может оказаться невозможным).
Я думаю что:
  1. 1 Настройки должны быть понятными пользователю программы, если необходимо, то подробно документированными в терминах начинающего пользователя программы (настройки ui отдельно, функционал отдельно, дока по настройке доступна оттуда же где и настройка, только не надо подробное описание громоздить в интерфейс, в доке по настройке иногда полезно давать и справку по предметной области примеры использования и т.д.)
  2. 2 Настроек должно быть много. (в разумных пределах, в рамках задач программы)
  3. 3 Где возможно настройки должны определяться автоматически либо автоматически сужать выбор пользователя.
  4. 4 Чем чаще предполагается смена какой либо настройки (опции) в процессе работы тем доступнее она должна быть пользователю (в интерфейсе, настройки которые на данном этапе решения задачи пользователя не имеют смысла не должны присутствовать в интерфейсе). Настройки изменяемый один раз или редко (цвета и форматы вывода например) должны быть убраны в конфиги, адванседы и т.д.
  5. 5 Если нет возможности составить список настроек по умолчанию который удовлетворит большинство пользователей то использовать поддержку профилей настроек. Обязательно должен быть продуман вариант наиболее частого(ых) профиля(ей) настроек.


Вещи очевидные, и фактически я повторил все что было сказано выше. В общем подробному анализу пользовательской аудитории быть!
Крайность на грани бреда: делать конфигуратор (интерфейса) настроек, и настройки автоматического определения настроек :)

Еще надо наверно разделить вкусы и потребности (форму и содержание). Вкусы у пользователя могут быть не предсказуемы, но задача ПО удовлетворять не вкусы, а потребности. У ПО есть определенный круг решаемых задач (проблем), что уже косвенно определяет потребности пользователя этого ПО. Поэтому «вкусовые» настройки уносятся с глаз долой, но должны быть, а «потребительские» распизиваются в нужные легко доступные места. (пункт 4)
Пример foobar2000, интерфейс аскетичный, но способный удовлетворить любой вкус. Конечно без копания и без некоторых навыков ничего не выйдет, но для человека у которого потребность удовлетворить свой вкус (которому важна форма) это гораздо лучше чем отсутствие такой возможности и «попсовый» интерфейс. Возможность сохранять «вид» создает условия для роста коллекции интерфейсов, что облегччает выбор (настройку) интерфеса тем кому вроде бы и пофиг но хотелось бы красивее :). Для тех кому важна форма есть поддержка плагинов и большая их коллекция. Для всех остальных же минимальный функционал и интерфейс.
опечатка: Для тех кому важна форма важен функционал есть поддержка плагинов и большая их коллекция.
Вспомнил еще Songbird — аудиоплеер-firefox
Про пример с foobar хотел бы добавить. Наверное я погорячился и создание интерфейса вряд ли можно отнести к конфигурированию (настройке).
Основные частые и понятные настройки + аналог about:config в браузерах с поиском и в добавок с консолью. Чтобы если по мелочи основное настроить — легко, а вот если что-то необычное — чтобы можно было.
Как пример можно взять CS 1.6: там и обычные настройки и консоль. Удобно. Некоторые только через консоль и шпилят, а я только обычными настройками и только connect в консоли:


А автору пожелание написать серию статей про проектирование интерфейсов с теорией и примерами. Будут очень признателен.
Самое главное в интерфейсе — стараться на него смотреть не с позиции того, что нужно разместить (позиция разработчика), а с позиции что потребуется пользователю (позиция простого пользователя). И чтобы куда ни тки, получал именно то, что ожидаешь — это база, о которой часто забывают.
Я обычно говорю так: «Где начинаются настройки, кончается User Experience». Но это, конечно, преувеличение.

На мой взгляд, серьёзная беда, если интерактивным продуктом нельзя пользоваться, пока не настроишь его. Если бы на всех сотовых телефонах MMS работали сразу, их было бы гораздо больше между абонентами.

К вопросу о том должно быть настроек много или мало: есть такие программы, и даже операционные системы, в которых можно настроить совсем всё. Они называются OpenSource и предназначены для людей, которые хотят и любят настраивать. Но как ни странно, даже в этом лагере есть чёткое стремление сделать стандартную конфигурацию годной к использованию сразу после установки.
О! Спасибо за отличный пример с ММС-ом!
Sign up to leave a comment.

Articles

Change theme settings