В этой статье рассказано о новой модели взаимодействия проектировщиков взаимодействия пользовательского интерфейсов, дизайнеров и разработчиков, предложенной Microsoft . Эта модель реализуется благодаря совместной работе специалистов по дизайну и пользовательским интерфейсам в пакете Microsoft Expression Studio и разработчиков в Visual Studio 2008.

Введение

Технология XAML/Blend обещает дать нам, проектировщикам взаимодействия более высокий контроль над результатом их работы. Это здорово, потому что позволяет нам добиваться того, чтобы конечный продукт имел интерфейс, максимально приближенный к задуманному. Однако данная технология меняет привычный для проектировщиков способ работы, и требует от них новых навыков.  

У любого опытного проектировщика неизбежно возникнут вопросы: что действительно дает новый подход; стоят ли нововведения смены привычек; легко ли изменять пользовательский интерфейс; можно ли нескольким специалистам вести совместную работу над одним проектом; позволяет ли Microsoft Blend разрабатывать действительно сложные интерфейсы?

Рассмотрим эти вопросы подробнее.

Классический подход

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

• На основе собранных пользовательских и иных требований проектировщики создают макеты будущего интерфейса в виде так называемых прототипов. С определенным уровнем абстракции прототип графически представляет внешний вид интерфейса. Неотъемлемой частью прототипа является описание поведения интерфейса, возникающее в процессе взаимодействияпользователя с продуктом. Обычно для этого применяется либо текстовое описание, либо сам прототип эмулирует поведение продукта - в этом случае можно говорить об интерактивном прототипе.  
• На основе такой спецификации дизайнеры создают графический стиль продукта, аразработчики его реализуют.У каждого участника разработки имеется собственная зона ответственности и компетенции.    

Обмен информацией обеспечивается с помощью результатов труда каждого специалиста и происходит следующим образом:

• Проектировщики создают прототип в удобной для них форме (например, в );
• На основе этих прототипов дизайнеры создают графические файлы с оформлением, которые затем передают разработчикам.
• Разработчики получают прототипы и файлы с оформлением и затем реализуют пользовательский интерфейс с помощью подходящей среды программирования.

У каждого участника разработки имеется собственная зона ответственности

Естественно, реальная схема взаимодействия сложнее, но основные потоки взаимодействия именно таковы (см. рисунок 1).

Рисунок 1. Разделение зон ответственности

Данный подход отлично работает для обычных веб-приложений, в силу ограниченности выразительных средств. Это работает неплохо и для классических настольных (GUI) приложений, где давно устоялись свои модели взаимодействия, построенные на основе фиксированного набора элементов управления (полей ввода, раскрывающихся списков, радиокнопок и так далее).

Однако данный подход плохо работает для современных Ajax приложений и особенно для RIA ("richinternetapplications", дословно "интерактивно богатые интернет приложения"). Для того чтобы передать сложное поведение таких приложений проектировщику необходимо написать массу документации, воспринимать которую готов далеко не всякий разработчик. Кроме того, объемные тексты сложно и дорого сопровождать. Если проектировщик упустит некий нюанс поведения программы, то разработчик вероятнее всего реализует оптимальным с точки зрения реализации образом, но не обязательно оптимальным с точки зрения пользователя. В данном случае верна простая истина - лучше один раз увидеть, чем 10 раз услышать.

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

Вот бы сделать так, чтобы проектировщики сами реализовывали взаимодействие? - эта мысль приходила и приходит многим специалистам в области ИТ. Как бы с программистов снять часть ответственности за создание пользовательского интерфейса?

Новая парадигма

В настоящий момент происходит стремительное слияние настольных (GUI) и веб-приложений. Пользователи успели привыкнуть к уникальным с точки зрения оформления и поведения интерфейсам, которые приняты в мире веб-сайтов и веб-приложений. "Сделайте приложение с уникальным оформлением" стало привычным требованием со стороны маркетологов.

В связи с появлением идеологии Ajax появилась возможность делать гибкие и, самое главное, быстрые веб-приложения. Приложения построенные на базе платформ MS .NET или AdobeFlex с точки зрения пользователя ничем не отличаются от "родных". Совершенно естественным образомвозникло решениепозволяющее отделить внешний вид пользовательского интерфейса, сколь бы сложным оно не было, от бизнес-логики программы. Решение основано на специальных языках описания интерфейса - XAML от Microsoft , MXML от Adobe, ZUL от Mozilla и так далее. В этих текстовых языках описывается внешний вид элементов (в векторном формате) так, что интерфейс можно создавать в любом редакторе.     

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

Для редактирования XAML лучше всего применять специальный пакет, Microsoft Expression Blend или просто Blend. Редактирование внутри него происходит в наглядной, визуальной форме, то есть проектировщик может создавать элементы, перемещать их по экрану и описывать поведение. Вроде бы все отлично! Проектировщики проектируют интерфейс, дизайнеры его доводят до товарного вида, а разработчики реализуют. Но давайте более пристально взглянем на Blend.

Взаимодействие между членами команды теперь происходит следующим образом:

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

На рисунке 2 изображена новая схема взаимодействия.

Рисунок 2. Пространство XAML

Все достаточно красиво с первого взгляда, но со второго начинаются вопросы:

Должен ли сценарии трансформаций (фактически анимацию) создавать именно проектировщик, а не дизайнер? Для того, чтобы перемещения объектов были естественными для человеческого восприятия необходимо следовать определенным принципам, например, двенадцати принципам Уолта Диснея ( http://www.multikov.net/master.php?article=3 ). Однако, если дать анимацию на откуп дизайнерам, то имеется шанс, что не все трансформации будут реализованы должным образом - только проектировщик знает в деталях поведение будущего продукта.

Пространство имен объектов, которое удобно для проектировщика, может оказаться неудобным для разработчика, и наоборот. То есть проектировщик может получить обратно от разработчика такой XAML, в котором ему заново придется разбираться.

Как отслеживать изменения, которые происходят с XAML? Не все изменения наглядны, следовательно, у всех участников будет уходить много времени на документирование этих изменений во внешней коммуникационной среде (например, по e-mail).

Каким образом осуществлять глубинные изменения экранных объектов (или рефакторинг, если говорить по-программистки)? При итеративной разработке постоянно возникает необходимость в изменении внешнего вида и поведения экранных объектов. Все объекты внутри XAML выстраиваются в жесткую иерархию (вследствие XML синтаксиса), и любой перенос объекта приводит к необходимости контролировать вручную результат переноса. Проще говоря, Blend не содержит удобных средств для оперативных изменений объектов.

Подобных вопросов возникает большое количество.

Новые требования к проектировщикам

Часть проблем возникает от того, что изменились зоны ответственности специалистов (см. рисунок выше), и так как теперь специалисты действуют в единой XAML-среде, то средства редактирования обязаны поддерживать это разделение.

Но сначала разберемся с новыми требованиями к проектировщикам взаимодействия.

Итак, проектировщику необходимо:

• В совершенстве владеть и . Не все возможности реализованы в , так что язык знать необходимо.
• Понимать и применять основные принципы анимации. Это знание пригодится,даже если все трансформации будут делать дизайнеры.  
• Уметь организовывать взаимодействие с разработчиками и дизайнерами - так как вся работа происходит в единой среде, то все члены команды оказывается в одной лодке, которую очень легко раскачать. Можно легко свалить вину за неудачу на другого члена команды, следовательно, пока не поддерживает взаимодействие между членами команды, требуются внешние способы контроля вносимых изменений и регламенты взаимодействия.

Теперь специалисты действуют в единой XAML -среде.

Как видим, переобучения проектировщиков не избежать.

Нереализованные требования в Blend

Также сам Blend должен поддерживать новый подход в должной мере, а именно:

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

Выводы

Blend - это не средство прототипирования в классическом виде. Нет смысла проектировать интерфейс внутри Blend для иных платформ, нежели для MicrosoftSilverlight (с) и .NET (с).Однако для данных платформ проектировщики взаимодействия получили возможность максимально контролировать конечный результат. К сожалению, существующая версия Blend не поддерживает в должной мере изменившуюся парадигму создания пользовательского интерфейса. Этот недостаток мало сказывается на небольших проектах с числом участников до 3-4, но на средних и больших проектах разработка интерфейса может потребовать слишком больших усилий.  

Blend не поддерживает в должной мере изменившуюся парадигму создания пользовательского интерфейса.

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