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

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

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

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

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

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

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

  1. SergeyCreadone

    Рекомендую попробовать Axure для проектирования более-менее динамичного прототипа. Сам пользуюсь около года и вполне доволен.

    Мы обычно описываем логику взаимодействия в отдельном документе, и, если того требует проект, выносим в прототип небольшие примечания, благо Axure позволяет делать это за пару кликов.

    Reply
  2. Juras Vetrau

    В Axure я пытался сделать несколько проектов, но мне не понравилось — по сравнению с Visio возможности ограничены, а достойный презентации прототип в любом случае в ней не сделаешь.

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

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

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

    Reply
  3. Александр Сергеев

    Привет!

    Я уже сделал несколько проектов на Axure – и очень доволен. В Visio теперь только sitemap делаю.

    После минимализма Axure (причем – всего хватает), MS Vision 2007 – ужасно навороченный. Кривая обучения уж очень у него кривая 🙂

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

    Reply
  4. Juras Vetrau

    Привет, Саш!

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

    В той фразе имел в виду то, что, допустим, есть у тебя всплывающий слой, появляющийся при наведении на ссылку. В Visio я даю сноску о всех подобных штуках и глядя на wireframe страницы ты сразу видишь, что на ней должно взаимодействовать и как. А в прототипе пока не совершил взаимодействие, ты о нем не узнаешь. Если, конечно, не прокликать все элементы. Но это ненадежный метод 🙂 Или я что-то не знаю об Axure? Поделись, Саш, хорошим примером 🙂

    А 2007й Visio я попробовал, но быстро снес обратно в пользу 2003го 🙂 Во-первых, ничего полезного для проектирования не добавилось, да и вообще в целом там изменений мизерное количество. А во-вторых, сыроват и тормознут.

    Reply
  5. Александр Сергеев

    Юра, я сейчас заканчиваю один проект делать на 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 с его переходами по кликам!

    Reply
  6. Juras Vetrau

    Это как раз то, что я хотел в статье донести — трудности начинаются, когда нужно описать изменение всего состояния страницы, а не только конкретного элемента. Этим мне Axure и не нравится — тратишь время не на проектирование, а еще и на реализацию 🙂

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

    Про свежую версию слышал, но я подожду 5й части — там, думаю, они добавят что-то значимое.

    А насчет интерактивности — Visio ведь не предполагает, что в нем будет интерактивность 🙂 Visio предполагает, что в нем будут нарисованы концептуальные схемы страниц, с которыми будет работать дизайнер и которые можно будет вставить в спецификацию (в твоем комментарии этот процесс описан как делание скриншотов с Axure, что по сути то же самое). Делать в нем интерактивность запарно, да и выходит она ограниченной.

    Reply
  7. Александр Сергеев

    Да, могу сказать что и меня в Axure не устраивают средства документирования требований ко всей странице (или к группе страниц или к процедуре). Ну и sequence-диаграмм в Axure не хватает (хотя там есть Flow-виджеты). Но все равно процесс описания ускорился 🙂 До процесса внесения изменений я еще не дошел, но думаю что он также ускорится. Раньше бывало изменишь спеку, забудешь прототип, изменишь прототип – забудешь спеку 🙂

    Я рисую детальные прототипы в Axure, которые идут и дизайнеру и программистам. То есть делаю все окна, даже окна подтверждения совершения операции в стиле Азы Раскина 🙂 (то есть показать слой по месту выполнения операции – в Axure это можно сделать при помощи динамической панели, в Визио – ХЗ). Вот именно за интерактивность – 5 баллов Axure – прототип получается high-fidelity и прогать не надо (а помню раньше прогал на php, чтобы интерактив был :).

    Хотелось бы еще: языка скриптового, sequence-диаграмм, sitemap-диаграмм, page notes с картинками и чтобы генерилось не 1000 файлов (Axure бъет, например, таблицы на png-картинки), а один html под каждую страницу (реальная проблема выкладывать для заказчика обновление в Интернет – и windiff/rsync не спасает – файлы все время с разными именами генеряться).

    Reply
  8. Pingback: GUI.RU - Хроники Юзабилити » Архив блога » Прототипирование web-сайтов. СобиÑ

  9. Pingback: GUI.RU - Хроники Юзабилити » Архив блога » Прототипирование web-сайтов. СобиÑ

  10. Pingback: Прототипирование сайтов. Собирая воедино. Проектирование пользоватÐ

  11. Pingback: Прототипирование сайтов. Собирая воедино. Проектирование пользоватÐ

Leave a Reply

Your email address will not be published. Required fields are marked *