В последнее время проектируем все больше веб2.0-проектов и веб-приложений. В придачу к “социализации” сервисов, это добавляет им технологичности. В основном это касается динамического взаимодействия и других AJAX-овых штучек. Хорошо, если это просто пара всплывающих слоев или появляющаяся по клику форма комментирования. Но иногда нужно сделать что-то вроде NetVibes, в котором, по сути, всего одна страница в классическом понимании и огромное количество динамических реакций.
Я описываю динамические взаимодействия в специально отведенной правой колонке wireframe. Делается сноска с интерактивного элемента, а в ней словами описывается реакция системы на действие пользователя и показывается состояние системы после этого. Обычно это касается конкретного блока, так что места вполне хватает на пару-тройку комментариев с иллюстрацией. К тому же, все взаимодействия в любом случае будут описаны в сценариях взаимодействия и спецификации. Поэтому очевидные вещи вроде ссылок и кнопок комментариев не требуют. Так что места в правой колонке чаще всего хватает.
Реже нужно отрисовать элемент, имеющий много состояний. Простейший пример — форма, в которой поля проверяются на валидность по мере ввода, а не после отправки. Вот тут начинаются сложности. Хорошо еще, если проверяемых полей не так много и их поведение одинаково. И не менее хорошо, если кроме этой формы динамических элементов на странице нет. Но с этим везет не всегда. Выхода два. В первом случае я делаю копию страницы, куда попадают не вместившиеся на первую комментарии. Не самый красивый способ, зато простой и понятный. Во втором стоит просто поискать, на каких еще страницах есть такие же динамические элементы и описать их уже там.
Самая непростая ситуация — это приведенный выше пример онлайнового рабочего стола NetVibes. В таких системах речь часто идет об изменении даже не конкретного блока, а всего состояния страницы. При том что сама страница остается той же — здесь правая колонка wireframe мало чем поможет. Но решение все равно есть. В одном из недавних проектов было отрисовано около 10 состояний одной страницы веб2.0-портала. Все они попали в отдельный Visio-документ, где каждая страница описывала одно, кое-где два-три состояния.
По мере вебдванольного движения к увеличению динамических взаимодействий есть смысл внимательнее смотреть за теми, кто проектирует обычные десктопные приложения. Там подобные проблемы решают уже давно и этот опыт поможет сэкономить тонну времени. Ну и, ясное дело, сделать документацию качественнее и понятнее.
15 comments
Рекомендую попробовать Axure для проектирования более-менее динамичного прототипа. Сам пользуюсь около года и вполне доволен.
Мы обычно описываем логику взаимодействия в отдельном документе, и, если того требует проект, выносим в прототип небольшие примечания, благо Axure позволяет делать это за пару кликов.
В Axure я пытался сделать несколько проектов, но мне не понравилось — по сравнению с Visio возможности ограничены, а достойный презентации прототип в любом случае в ней не сделаешь.
Больше всего мне в Axure идеология не понравилась — как раз совмещение спецификации и реализации. Поскольку многие моменты уже реализованы, их описывать вроде как не нужно. Но при этом они теряются и забываются — о многих взаимодействиях знает только автор, а для того чтобы об этом узнали все заинтересованные лица, нужно их описать.
Все, конечно, зависит от процесса, который принят у вас. Но в моем случае мы сперва делаем черновик интерфейса, затем дизайн, затем прототип. И для того чтобы все было учтено в дизайне, нужно иметь полный перечень ключевых элементов, чтобы не забыть их отрисовать. И для этого как раз нужно полное описание в wireframes.
Так что в этом плане я за то, чтобы прототип делать вручную, без автоматизированных средств — только так он получится действительно хорошим.
Привет!
Я уже сделал несколько проектов на Axure – и очень доволен. В Visio теперь только sitemap делаю.
После минимализма Axure (причем – всего хватает), MS Vision 2007 – ужасно навороченный. Кривая обучения уж очень у него кривая 🙂
А что ты имел в виду?
“Поскольку многие моменты уже реализованы, их описывать вроде как не нужно. Но при этом они теряются и забываются — о многих взаимодействиях знает только автор, а для того чтобы об этом узнали все заинтересованные лица, нужно их описать.”
Привет, Саш!
Все зависит от того, какие проекты делаются и как выстроен процесс внутри — каждому будет удобнее и эффективнее свой вариант 🙂 Мне не хватало мощности даже на простых проектах, так что на крупных я даже не стал пробовать — неудобно и не вписывается в процесс.
В той фразе имел в виду то, что, допустим, есть у тебя всплывающий слой, появляющийся при наведении на ссылку. В Visio я даю сноску о всех подобных штуках и глядя на wireframe страницы ты сразу видишь, что на ней должно взаимодействовать и как. А в прототипе пока не совершил взаимодействие, ты о нем не узнаешь. Если, конечно, не прокликать все элементы. Но это ненадежный метод 🙂 Или я что-то не знаю об Axure? Поделись, Саш, хорошим примером 🙂
А 2007й Visio я попробовал, но быстро снес обратно в пользу 2003го 🙂 Во-первых, ничего полезного для проектирования не добавилось, да и вообще в целом там изменений мизерное количество. А во-вторых, сыроват и тормознут.
Юра, я сейчас заканчиваю один проект делать на Axure с элементами web2.0 (примитивными в принципе – окошки на слое aka всплывающие слов, закладки, ну и collapse/expand) – до этого я юзал Axure только для создания прототипов, а спеки писал по старинке – скриншот и описалово. Возможно потом будет что рассказать по поводу веб2.0 и Axure, а пока – только предположения 🙂
Например, я предполагаю, что программерам будет удобнее получать in-place справку для контролов. А там, где нужно описать взаимосвязь двух-трех-N контролов или поведение страницы – в Axure есть Page Notes. Но минус Page Notes – там только текст может быть.
Кстати, вышел Axure Pro 4.6 Beta и там много вкусных фич – http://axure.com/CS/blogs/axure/archive/2007/05/04/Introduction-to-Version-4.6-Features-_2D00_-Part-1.aspx.
Надо бы посмотреть.
Ну и интерактивность в Axure Pro – побогаче будет, чем в Visio с его переходами по кликам!
Это как раз то, что я хотел в статье донести — трудности начинаются, когда нужно описать изменение всего состояния страницы, а не только конкретного элемента. Этим мне Axure и не нравится — тратишь время не на проектирование, а еще и на реализацию 🙂
Программистам в любом случае достанется прототип — wireframes в Visio его не исключают. Но у них будет два способа изучить концепт интерфейса — по статичной документации и интерактивному прототипу. Первый способ нужен для обзора функциональности, второй — для детального понимания.
Про свежую версию слышал, но я подожду 5й части — там, думаю, они добавят что-то значимое.
А насчет интерактивности — Visio ведь не предполагает, что в нем будет интерактивность 🙂 Visio предполагает, что в нем будут нарисованы концептуальные схемы страниц, с которыми будет работать дизайнер и которые можно будет вставить в спецификацию (в твоем комментарии этот процесс описан как делание скриншотов с Axure, что по сути то же самое). Делать в нем интерактивность запарно, да и выходит она ограниченной.
Да, могу сказать что и меня в Axure не устраивают средства документирования требований ко всей странице (или к группе страниц или к процедуре). Ну и sequence-диаграмм в Axure не хватает (хотя там есть Flow-виджеты). Но все равно процесс описания ускорился 🙂 До процесса внесения изменений я еще не дошел, но думаю что он также ускорится. Раньше бывало изменишь спеку, забудешь прототип, изменишь прототип – забудешь спеку 🙂
Я рисую детальные прототипы в Axure, которые идут и дизайнеру и программистам. То есть делаю все окна, даже окна подтверждения совершения операции в стиле Азы Раскина 🙂 (то есть показать слой по месту выполнения операции – в Axure это можно сделать при помощи динамической панели, в Визио – ХЗ). Вот именно за интерактивность – 5 баллов Axure – прототип получается high-fidelity и прогать не надо (а помню раньше прогал на php, чтобы интерактив был :).
Хотелось бы еще: языка скриптового, sequence-диаграмм, sitemap-диаграмм, page notes с картинками и чтобы генерилось не 1000 файлов (Axure бъет, например, таблицы на png-картинки), а один html под каждую страницу (реальная проблема выкладывать для заказчика обновление в Интернет – и windiff/rsync не спасает – файлы все время с разными именами генеряться).
Юра, поставь плиз плагин для вордпресса, который нотификации шлет участникам дискуссии 🙂
Спасибо 🙂
Что знаешь об Adobe Edgy?
Кай,
Знаю, что есть одноименная рассылка про UI-технологии от Adobe. Больше ничего не слышал 🙂