С одной стороны, одно слово – эпохальная вещь! Все-таки Купер это гуру юзабилити и UX-дизайна. Чего только стоят его принципы проектирования взаимодействия. Как обычно: всё гениальное просто. Вот только некоторые из них, особо импонирующие:
- Считайте пользователей людьми очень умными, но очень занятыми и Пользователи не понимают булевы алгебру. В точку: когда я убрал булеву формальность в фильтрах Aml Pages, все вопросы пользователей исчезли. Пофиг, что с формальной точки зрения раздел документа не подпадает под условия фильтра (считай, запроса) – раз пользователю надо увидеть раздел, значит надо! Ни к чему заставлять отменять или изменять фильтр. Юзеру точно виднее, что ему нужно.
- Избегайте чистого листа. Как только в Aml Pages появились категории страниц по умолчанию, все вопросы по их использованию тут же улетучились сами собой. Редактор категорий есть, да и раньше был. Но как только появились умолчательные примеры категорий – вопросы по ним отпали в принципе.
- Прячьте рычаги катапультирования. И не уговаривайте меня, нет и не будет в Aml Pages команды “удалить все”.
- Пользователи готовы прикладывать усилия соразмерно результату. Действительно готовы. Но только вот не стоит их заставлять достигать результата сразу. Лучше оставлять пользователю возможности для принятия решения, для “маневру” до последнего момента.
- Компьютер работает, а пользователь думает. Вот-вот, робяты! Это по закону Мура производительность процессоров удваивается каждые два года. А производительность пользователя нет! Ну так хотя бы не мешайте ему. Пусть думает, пусть размышляет – этого никакой софт за него не сделает никогда.
- Никогда не подгоняйте интерфейс под метафору. Сколько не прикручивал пружинный, стилизованный под бумажные аналоги, разделитель панелей в Aml Pages – все равно он торчал как в одном месте заноза. Снёс!
- Удаляйте элементы, пока продукт не сломается, а затем верните последний удаленный элемент на место. В яблочко! “Совершенство, это когда не нечего добавить. Совершенство, это когда нечего убрать” (© Антуан де Сент-Экзюпери). Много раз сталкивался с тем, что из продукта что-то пора и выкинуть. Итеративный такой процесс получается. Сначала фичи накапливаются, потом переосмысливаются, а со временем некоторые и канут в воду. Резать, однозначно резать – причем не дожидаясь перитонита.
- В ошибках может и не быть вашей вины, но вы несете за них ответственность. Да здрям автоматический бекап и автосохранение. Сколько нервов они сберегли моим пользователям, а мне времени, потраченного на поддержку.
- Диалоговое окно – это еще одна комната, не ходите в комнату без веской причины. Без разговоров! Все что имеет смысл делать не модальным, просто необходимо так и делать. Модальные диалоги нужны только для группировки сходных функций.
- Не создавайте многострочные вкладки. Вот дернул меня черт за руку, сделать в Aml Pages режим многострочных вкладок, славу богу хоть не по умолчанию. Теперь вот теперь
кручу попойизворачиваюсь в общении с пользователями, как бы это убожество в новой версии незаметно убрать. (этот блог читают и пользователи: я ж не спроста хочу убрать. Убрать надо для другого, значительно более удобного решения…).
В общем, что сказать… Книга действительно серьезная, must have однозначно. Но вот с другой стороны, ну такое количество в ней воды, что таки пару раз она мне обеспечила здоровый и быстро наступивший сон. Очень много про то, как “не надо”. А вот изложения как у Дженифер Тидвелл, “как надо” все-таки маловато. Примеры есть, но они не разобраны методично. По стилю изложения About Face немного напоминает легендарную “Психбольницу в руках пациента”. Но! Для такого в стиле “манифеста” 700 страниц имхо все-таки многовато – либо уж кратче, либо методичнее. Хотелось бы больше конкретики, причем с разбором, а не просто примеров из жизни – 700 страниц примеров все-таки требуют хоть какой-то каталогизации.
Но все равно не жалею о времени, потраченном на эту книгу. Чувствуется перо мастера – там такая концовка, такое послесловие, что отрицательные эмоции сильно поутихли. Das ist, проще говоря.
PS: все ссылки как-то сами собой получились именно на фичи моей Aml Pages, а не Aml Maple. Но Aml Pages приложение значительно более богатое фичами, чем “Мапля”. Более того, оно как раз и есть то самое “монопольное приложение”, в отличие от Мапли. На тему разницы между монопольными и временными приложениями у Купера тоже весьма толково и аргументировано расписано.
Спасибо. Хорошие тезисы. Закину себе в корзину, в следующий заказ куплю, наверное. Хотя после прочтения последнего абзаца я засомневался, стоит ли это делать, если там действительно много воды... подустал я уже от такого стиля изложения.
ОтветитьУдалитьКстати, рекомендую по теме книгу Джэфа Раскина.
Отличный пост, молодца :)
ОтветитьУдалитьРасскажи заодно как убираешь старые фичи. Я бы с удовольствием тоже кое-что выкинул сейчас из ранее навороченного, но я точно знаю что какой-то маленькой, но все-таки, процент пользователей эти фичи используют - как им сказать "все, в новой версии не судьба?"
2Lamer:
ОтветитьУдалитьНу как сказать насчет "много воды"... Вроде как и душевно, но больно много такой философского-в-курилкиного-трепа стиля изложения почитал последнее время. Вроде всё "да", совсем согласен - но все это тезисно, все это очень манифестативно так изложено. Конечно, примеры "как не надо делать" нужны, но не в таком количестве. Более того считаю обязательным такой пример разбирать более подробно, и тут же приводить примеры "как надо делать".
В общем, если не читали "Психбольницу в руках пациента", то нормально. Если читать после нее, много мыслей повторяется. Хотя концовка с краткими тезисами - вполне так тянет на разумную кулинарную книгу под рукой.
2Begemot:
ОтветитьУдалитьСпасибы за комплименты :)
Ну, по разному по большому счету удаляю фичи. Я ж в основном ссылался на Aml Pages, а там фич - мама не горюй. Если что удалить, и не убудет.
Обычно, если фича совсем спорная, то устраиваю какой-нить опрос с обсуждением в форуме. Причем скорее именно обсуждение, нужно слышать аргументы, понимать кто высказывается за ту или иную позицию (чтобы понимать почему), выуживать из пользователей в рамках каких более объемных задач им нужна та или иная фича.
Потом все это дело запускается в бета-версии, которые активно на сайте "пиарятся", обсуждаются пробуются. Ну, и в финале фича режется окончательно.
Технически: в бета-версиях так прям с ходу не рублю как правило. Просто код полностью закоментируется. Что-то вроде как удаляем ключевую по фиче переменную или функцию, все остальное что на нее завязано компилятор сам найдет, ну а мое дело закомментировать.
Но главная суть которую я вынес не так чтобы недавно, но явно не с молодости и зари разработки: "В ЗВЕЗДУ ДЕМОКРАТИЮ!". Это не мое высказывание, а одного маститого девелопера. Потому при сильно спорных фичах, кто-то должен принять на себя волевое решение. Решение - это всегда ответственность. Ну, а пользователи в принципе не могут нести ответственности, поэтому окончательное решение за разработчиком.
Есть две формы правления: "анархия и монархия, анархию мы уже пробовали..." :) Причем подобная монархия это все-таки ни в коем случае не тирания. Все равно есть общение, обсуждения, пробы. Частенько пользователи сами с друг другом прообщаются, и кто-то в чем-то кого-то из них переубедит.
Ну, и конечно правило семеро одного не ждут (правда, наверное с другим соотношением). Если почти всем не нужно, а одному-единственному "нада", то тут уж решение за мной - у разработчика тоже ведь есть веские причины убрать фичу. Писать для одного это тупик: "извините, но за 100 долларов Вы заказную версию НЕ получите" ((C) Джоэл Сполски).
А вообще, конечно вопрос принятия решения, обсуждения с народом, это тонко все. Имхо, нет тут общего решения.
А вот как фичу резать в техническом плане, вопрос любопытный. Как и на елку влезть, и ее родимую не ободрать. Как сделать шаг вперед, не боясь что не получится вернуться обратно.
PS: ну есессна всегда есть некоторое количество особо любимых пользователей, активных участников - к ним отношение другое, ну и вес их мнения тоже другой.
PPS: а вообще есть такое клевое наблюдение: коли фичу можно сделать так, а можно эдак, а можно вообще не делать, то тут ВАЖНЫЙ момент не в том, какой выбор сделать. А в том, что он вообще появился!?! С фигов ли? Если делаешь всё верно, то как правило русло решения не будет так дробиться, как-то оно будет стабильно двигаться в нужном направлении. Я об этом сам много размышлял, много раз на такую ситуацию напарывался, да и читал у маститых наших коллег (ссылку позже, где-то в сети об этом видал точно, хотя буквально сейчас перелистываю уже бумажный вариант).
Что-то не могу я найти ссылку на пост с мыслей про выбор и сам факт возникновения выбора, так что взял из бумажного варианта:
ОтветитьУдалить"Вместо того чтобы выбирать между вариантами А и Б, он (архитектор) должен подумать над другим вопросом "Как спроектировать решение, чтобы снизить важность выбора между А и Б?". В этой ситуации интересен выбор не между А и Б, а сам факт существования этого выбора (а также то, что правильный выбор необязательно очевиден или неизменен)"
Точно не помню, где я видел эту мысль, но почему-то мне настройчиво кажется что в блоге AVL`а тут http://avl.livejournal.com