Проектирование интерфейсов с AJAX. Как отразить веб2.0-динамику в wireframes

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

Я описываю динамические взаимодействия в специально отведенной правой колонке wireframe. Делается сноска с интерактивного элемента, а в ней словами описывается реакция системы на действие пользователя и показывается состояние системы после этого. Обычно это касается конкретного блока, так что места вполне хватает на пару-тройку комментариев с иллюстрацией. К тому же, все взаимодействия в любом случае будут описаны в сценариях взаимодействия и спецификации. Поэтому очевидные вещи вроде ссылок и кнопок комментариев не требуют. Так что места в правой колонке чаще всего хватает.

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

Самая непростая ситуация — это приведенный выше пример онлайнового рабочего стола NetVibes. В таких системах речь часто идет об изменении даже не конкретного блока, а всего состояния страницы. При том что сама страница остается той же — здесь правая колонка wireframe мало чем поможет. Но решение все равно есть. В одном из недавних проектов было отрисовано около 10 состояний одной страницы веб2.0-портала. Все они попали в отдельный Visio-документ, где каждая страница описывала одно, кое-где два-три состояния.

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