Недавно  мне довелось познакомиться с телефоном Samsung SGH-D780 Duos. Это телефон с двумя SIM-картами, впрочем речь не об этом. С момента первого издания книги Алана Купера "Психбольница в руках пациентов" упомянутой в прошлой статье прошло более 10 лет. Однако эта странная мысль вынесенная в заголовок до сих пор остаётся верной. По интерфейсу телефона можно сказать, что разные его части (музыкальный проигрыватель, обработка звонков, радио, диктофон и т.д.) писались разными слабо связанными командами разработчиков. Простой признак непродуманности интерфейса - работа с беспроводной гарнитурой. Так чтобы совершить через неё звонок - достаточно набрать номер при установленном аудио-соединении. Чтобы проиграть музыку из музыкального проигрывателя через наушники, независимо от установленного аудио-соединения, необходимо выбрать "воспроизвести через стереогарнитуру Bluetooth" и затем выбрать нужное устройство. Я, конечно, не против выбора, но ведь можно сделать чтобы по умолчанию предыдущий выбор срабатывал автоматически. А вот запись диктофона или мелодию в браузере файлов через Bluetooth гарнитуру прослушать нельзя вовсе.

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

Рассмотрим двух пользователей, которые хотят слушать музыку с помощью своего мобильного устройства везде, в том числе на улице или в транспорте. Их задача одна, но вот цели могут быть совершенно разными. Допустим первый пользователь хочет слушать музыку с максимальным качеством и чтобы посторонние звуки не мешали ему. Тогда ему подойдёт гарнитура с наушниками закрытого типа позволяющие закрыть уши от проникновения звуков со стороны. Этот человек будет выкручивать громкость музыки на полную мощность, если звукоизоляция наушников будет недостаточно сдерживать звуки извне.

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

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

Совершив столь длинное отступление подойдём к основной теме этой статьи: "Навигация". Не могу не отметить, что дизайн навигации в телефоне Samsung SGH-D780 выполнен хорошо. В большинстве меню указатель в нём по умолчанию устанавливается на пункт выбранный в прошлый раз. Это очень удобно при путешествии по вложенным меню и выполнении из раза в раз схожих операций. Такое поведение полностью соответствует основной идиоме навигации unDE.

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

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

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

В это время наше изучение Blender'а приблизилось к наиболее интересной части - создание анимации. Первая 3D-анимация созданная нами называется "кусочек льда падает в стакан воды". Вы можете просмотреть её либо на Youtube либо скачать в формате MP2. Время рендеринга этой анимации 2 дня на машине с 1,7 Гц процессором. Да и на само создание ушло в общей сложности около недели. Естественно второй раз можно создать тоже самое гораздо быстрее. Да и в целом если бы стакан был строгой кубической формы, и не хотелось бы создавать эффекта выплёскивания из стакана, то можно было бы обойтись куда меньшими потерями времени (в том числе процессорного). Вы легко можете найти другие работы с демонстрацией симуляции флюидов в Blender'е -- в одних при этом используется кубические формы сосудов, в других - не прозрачные жидкости и сосуды (например, молоко и керамическая миска). Знайте -- что такие анимации создать реалистичными в Blender гораздо проще.