Jun 15, 2007

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

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

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

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

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 и там много вкусных фич – 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. Больше ничего не слышал :)

  • [...] Больше информации о инструментах вы можете получить из статей: Максима Гулевича «Обзор инструментов для UI-дизайнера и Информационного архитектора», Александра Сергеева (HumanoIT) о использовании Axure Pro, Влада Головача (Usetics) о прототипировании интерфейсов в InDesign, Юрия Ветрова (Artics) о wirefram’ах выполненных в Visio и даже динамике web 2.0 в них [...]

  • [...] Больше информации о инструментах вы можете получить из статей: Максима Гулевича «Обзор инструментов для UI-дизайнера и Информационного архитектора», Александра Сергеева (HumanoIT) о использовании Axure Pro, Влада Головача (Usetics) о прототипировании интерфейсов в InDesign, Юрия Ветрова (Artics) о wirefram’ах выполненных в Visio и даже динамике web 2.0 в них [...]

  • [...] Юрия Ветрова (Artics) о wirefram’ах выполненных в Visio и даже динамике web 2.0 в них. Заслуживают внимания две презентации Александра [...]

  • [...] Юрия Ветрова (Artics) о wirefram’ах выполненных в Visio и даже динамике web 2.0 в них. Заслуживают внимания две презентации Александра [...]

Leave a comment

Руководитель отдела проектирования и дизайна интерфейсов Mail.Ru. Работаю над коммуникационными и мобильными сервисами компании, а также общепортальными задачами.

Вакансии в интерфейсной команде Mail.Ru

  • Дизайнер Почты Mail.Ru
    Приоритетное направление со множеством интересных и сложных задач. Пользователи Почты Mail.Ru — это десятки миллионов людей.
  • Дизайнер мобильных сайтов и приложений
    iOS, Android, Windows Phone, Symbian, J2ME, Bada.
  • Дизайнер для Futubra, нового продукта
    Создавать совершенно новый проект. Такой дизайнер сделает 665 концепций и будет полон сил для 666-й. Он делает работу быстро, просто, эффектно. В его голове полно идей, он постоянно ими делится, но знает, что цена идеи самой по себе стремится к нулю и ни за одну не держится на смерть. У него есть в кармане пачка решений необычных задач. А если и нет, он знает, где такие решения найти.
  • Дизайнер стратегических продуктов
    Работа над Почтой, главной страницей и другими продуктами.