Итак, после почти двухмесячного перерыва мы продолжаем нашу дискуссию.

Русскоязычную аудиторию я поздравляю с праздником Защитника Отечества.

За этот период я успел отметить свой день рождения. В честь этого Ozon.ru предложил мне свою акцию сделать заказ с 5% скидкой и бесплатной доставкой. Этим я и поспешил воспользоваться, чтобы заказать книги Алана Купера "Психбольница в руках пациентов" и "Об интерфейсах", которые уже давно хотел прочесть.

Итак, из первой книги мы узнали, что психбольница -- это мир, в котором всё большую роль начинает играть программное обеспечение, а пациенты -- это разработчики этого ПО. Именно от них в конечном счёте зависит насколько удобно нам будет пользоваться этими продуктами. Часто программисты пишут так как удобно им, и для людей таких как они. Из этого делается логичный вывод, что программисты ни в коем случае не должны заниматься проектированием взаимодействия. Проектировщики взаимодействия должны начать работу до написания кода. Разумеется, из любого правила есть исключения, следует помнить, что сам Алан Купер -- в прошлом программист. А потому я таки всё ещё верю, что моя попытка совместить в себе и программиста, и проектировщика для этого проекта может быть не безуспешной.

Самое главное, что я вынес из обоих книг -- это метод целеориентированного проектирования взаимодействия основанный на создании персонажей. Персонажи -- это вымышленные пользователи вашей системы, которые в конечном счёте помогают ориентироваться на их конкретные цели и избежать проблемы так называемого "резинового пользователя".  Пользователь становится резиновым, когда рассуждая о необходимых функциях ПО мы говорим, что-то вроде "пользователю может понадобиться командная строка" (может понадобиться, а может и нет). Персонажи помогают избавиться от этой досадной не однозначности в чётких размышлениях, вроде "Вася будет пользоваться командной строкой, а вот Маше она точно не нужна. Но наш продукт больше нацелен на Машу...".

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

Что касается второй книги, то ровно половину её составляет подробный пересказ технических деталей методик описанных в первой книге. Здесь уже нет тех прекрасных примеров проектирования и вообще весь процесс в деталях кажется уже не столь романтичным :-) Начинаешь хорошо осознавать, что работа проектировщика -- это тяжелый труд.

От второй половины книги "Об Интерфейсе" я ожидал гораздо большего, чем просто перечисления всех существующих элементов взаимодействия и в действительности несколько разочаровался.

Тем не менее расскажу о наиболее интересных мыслях возникших по мере чтения. Во-первых, читая о системе отмен, я вдруг понял, что типичная операция удаления текста -- это тоже отмена, отмена ввода текста. Теоретически можно реализовать отмену, так чтобы BackSpace стал именно не просто удалением, а именно отменой в выделенном контексте. При этом с первым нажатием он может отменять в выделенном фрагменте форматирование текста, а уже вторым -- ввод различных фрагментов этого текста. Повтор же (скажем в виде клавиши Insert) будет строго отвечать за повторный ввод ранее удалённого текста и повторное его форматирование.

Такая идиома может при хорошей проработке стать отличным ходом в совершенствовании системы отмен.

Другая мысль, которую чётко изложил Алан Купер на страницах своей книги -- это положительная обратная связь в виде звукового сопровождения. Это означает, что озвучивать надо не отрицательные события ошибок, а обратно положительные события системы (успешное выполнения задания и т.д.). Алан Купер утверждает, что звуки в компьютерах обычно раздражают не потому, что они противны, а потому что они сопровождают всегда отрицательные события. Отрицательные же события должны сопровождаться тишиной. В действительности я и раньше задумывался о том, что в играх звуковое сопровождение во многом помогает управлению персонажами, в отличие от работы. В том числе голосовые подсказки вроде "Ваш форт атакован" или "Не достаточно денег" оказываются весьма полезными. Но почему в рабочем окружении всё оказывается не так радужно я не понимал.

Если говорить о сравнении идей Джефа Раскина и Алана Купера, то важно отметить, что Джеф Раскин -- во многом проектировщик целых компьютеров и операционных систем, а Алан Купер специализируется на конкретных решениях обычно для ОС Windows. Часто они исходя из разных предпосылок приходят к одним выводам. Скажем Джеф Раскин говорит "нет" диалоговым окнам с одной кнопкой "ОК" на основе их нулевого объема информации сообщаемой системе и из-за создания лишнего режима. Алан Купер же аргументирует свою позицию тем, что таким образом разработчик либо обвиняет пользователя в ошибках программы, либо программа хвалится своими достижениями (здесь я подумал, что в диалоговом окне вроде "файл успешно сохранён" не хватает кнопок "Молодец" и "Возьми с полки пирожок"), ну и, конечно же, такое сообщение способно нарушить поток сознания пользователя.

В тоже время Джеф Раскин где-то писал, что полосы прокрутки являются явно не интуитивной составляющей интерфейса. Я бы, конечно, не поверил Джефу, если бы сам не видел как человек далёкий от компьютеров, имея в виду, что документ нужно пролистать ниже (дальше), показывал руками вверх (имея ввиду движение именно документа, а не "камеры"). Алан Купер же считает это хорошей идиомой современных интерфейсов, хотя и не рекомендует использовать горизонтальную прокрутку для текстовых данных.

Джеф Раскин описывает Zoom-интерфейс как прекрасную идиому взаимодействия. Алан Купер говорит, что Zoom обычно понятен только IT-специалистам, а логический Zoom вовсе понятен только разработчикам.

Джеф Раскин пишет о том, что сама идея приложений не очень хороша, и что пользователю нужна большая интеграция, а Алан Купер -- ни о чём подобном нигде не упоминает.

В связи с этим можно прийти к выводу, что иметь своё мнение всегда полезно и нельзя во всём полагаться на мэтров проектирования взаимодействия.

Возвращаясь к Blender 3D, скажу, что прочитав книги Алана Купера, я вдруг понял, что его мощный интерфейс, в котором невозможно разобраться без подробной документации, является следствием плохого (отсутствующего) проектирования. По сути во многом это просто нагромождение функций. Впрочем нельзя также забывать, что изначально он проектировался для использования в узком кругу дизайнеров, для которых он был профессиональным инструментом. Изначально в нём многие функции вообще были доступны только горячими клавишами. Конечно, это частично оправдывает такой дизайн, тем не менее нельзя забывать, что улучшая свой продукт для среднего пользователя вы во многом делаете лучше и профессионалу.

На изображениях статьи вы можете видеть всю мощь процедурных текстур: это морской пейзаж, горный ночной пейзаж, ковёр. Апофеозом этих возможностей является модель глаза. Она примечательна не только тем, что полностью состоит из процедурных текстур, но также обладает эффектом красного глаза, когда источник света светит в зрачок прямо. Вены на глазу видны только с краёв, даже если мы попытаемся посмотреть на него сбоку. Наконец легко сделать так, чтобы расширение зрачка регулировалось одним единственным числом (от 0,0 для максимально расширенного зрачка до 1,0 для максимально суженного). На рисунках вы можете видеть кошачий глаз с расширением 0,44 и 1,0.

К великому сожалению все чудеса процедурных текстур не доступны при рендеринге в реальном времени в режиме игрового движка (все текстуры в нём остаются просто серыми). Все эффекты, которые можно видеть на этих изображениях достигаются путём долгого и мучительного просчитывания процессором без участия графического ускорителя. Естественно для целей этого проекта такое положение дел никуда не годится. Мне ещё предстоит узнать каким образом нужно использовать текстуры, чтобы они были видимыми в игровом движке.

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