Юрий Ветров об интерфейсах
  • Главная
  • Статьи
  • Дайджест
  • Конференции
  • Дизайн-менеджмент
  • Дизайн-системы
  • Заметки
  • О блоге
Юрий Ветров об интерфейсах
Юрий Ветров об интерфейсах
  • Главная
  • Статьи
  • Дайджест
  • Конференции
  • Дизайн-менеджмент
  • Дизайн-системы
  • Заметки
  • О блоге

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

  • 15 июня 2007

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

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

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

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

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

Юрий Ветров

Директор по бренду и дизайну (ex-Muse Group (Ultimate Guitar, MuseScore, Audacity и другие), Райффайзен Банк и Mail.ru Group). Я руковожу командами, которые отвечают за дизайн, исследования и редактуру бренда и интерфейсов, а также дизайн-систему в коде. Автор книги и курса «Паттерны дизайн-менеджмента» и «Дайджеста продуктового дизайна». Со-организовывал Fintech Design Conf, Mail Design Conf и московский Dribbble Meetup, а также Russian Design Cup. Читал лекции в Британке, курировал курс Future London Academy в Лондоне. Мои публикации есть на Smashing Magazine, UXmatters и UX Collective. Подробнее обо мне.

Другие статьи по теме
View Post
  • Дизайн-системы

Тёмная тема оформления

  • Юрий Ветров
  • 17 мая 2020
View Post
  • Дизайн-менеджмент
  • Статьи
  • Тренды

DesignOps, стремительно ворвавшийся в тренд

  • Юрий Ветров
  • 23 июля 2018
View Post
  • Дизайн-системы
  • Рецензии

Книги о дизайн-системах

  • Юрий Ветров
  • 26 апреля 2018
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия. Часть 6 — Внедрение

  • Юрий Ветров
  • 30 мая 2017
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия. Часть 5 — Дизайн с выхлопом

  • Юрий Ветров
  • 12 апреля 2017
View Post
  • Статьи
  • Тренды

Куда идёт UX в 2016 году

  • Юрий Ветров
  • 14 сентября 2016
View Post
  • Дизайн-менеджмент
  • Статьи

UX-стратегия на практике. Часть 4 —
От дизайн-команды к дизайн-культуре

  • Юрий Ветров
  • 12 сентября 2016
View Post
  • Методы и практики
  • Статьи
  • Тренды

Алгоритмический дизайн

  • Юрий Ветров
  • 27 июня 2016
15 comments
  1. SergeyCreadone:
    16 июня 2007 в 20:19

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

    Ответить
  2. Juras Vetrau:
    18 июня 2007 в 12:41

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

    Ответить
  3. Александр Сергеев:
    18 июня 2007 в 14:54

    Привет!
    Я уже сделал несколько проектов на Axure – и очень доволен. В Visio теперь только sitemap делаю.
    После минимализма Axure (причем – всего хватает), MS Vision 2007 – ужасно навороченный. Кривая обучения уж очень у него кривая 🙂
    А что ты имел в виду?
    “Поскольку многие моменты уже реализованы, их описывать вроде как не нужно. Но при этом они теряются и забываются — о многих взаимодействиях знает только автор, а для того чтобы об этом узнали все заинтересованные лица, нужно их описать.”

    Ответить
  4. Juras Vetrau:
    18 июня 2007 в 15:11

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

    Ответить
  5. Александр Сергеев:
    18 июня 2007 в 16:40

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

    Ответить
  6. Juras Vetrau:
    21 июня 2007 в 17:52

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

    Ответить
  7. Александр Сергеев:
    23 июня 2007 в 2:28

    Да, могу сказать что и меня в Axure не устраивают средства документирования требований ко всей странице (или к группе страниц или к процедуре). Ну и sequence-диаграмм в Axure не хватает (хотя там есть Flow-виджеты). Но все равно процесс описания ускорился 🙂 До процесса внесения изменений я еще не дошел, но думаю что он также ускорится. Раньше бывало изменишь спеку, забудешь прототип, изменишь прототип – забудешь спеку 🙂
    Я рисую детальные прототипы в Axure, которые идут и дизайнеру и программистам. То есть делаю все окна, даже окна подтверждения совершения операции в стиле Азы Раскина 🙂 (то есть показать слой по месту выполнения операции – в Axure это можно сделать при помощи динамической панели, в Визио – ХЗ). Вот именно за интерактивность – 5 баллов Axure – прототип получается high-fidelity и прогать не надо (а помню раньше прогал на php, чтобы интерактив был :).
    Хотелось бы еще: языка скриптового, sequence-диаграмм, sitemap-диаграмм, page notes с картинками и чтобы генерилось не 1000 файлов (Axure бъет, например, таблицы на png-картинки), а один html под каждую страницу (реальная проблема выкладывать для заказчика обновление в Интернет – и windiff/rsync не спасает – файлы все время с разными именами генеряться).

    Ответить
  8. Александр Сергеев:
    23 июня 2007 в 2:30

    Юра, поставь плиз плагин для вордпресса, который нотификации шлет участникам дискуссии 🙂

    Ответить
  9. Александр Сергеев:
    28 июня 2007 в 2:58

    Спасибо 🙂

    Ответить
  10. Кай:
    27 декабря 2007 в 13:39

    Что знаешь об Adobe Edgy?

    Ответить
  11. Juras Vetrau:
    27 декабря 2007 в 13:56

    Кай,
    Знаю, что есть одноименная рассылка про UI-технологии от Adobe. Больше ничего не слышал 🙂

    Ответить
  12. Уведомление: GUI.RU - Хроники Юзабилити » Архив блога » Прототипирование web-сайтов. СобиÑ
  13. Уведомление: GUI.RU - Хроники Юзабилити » Архив блога » Прототипирование web-сайтов. СобиÑ
  14. Уведомление: Прототипирование сайтов. Собирая воедино. Проектирование пользоватÐ
  15. Уведомление: Прототипирование сайтов. Собирая воедино. Проектирование пользоватÐ

Добавить комментарий Отменить ответ

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Юрий Ветров об интерфейсах
Дизайн-менеджмент цифровых продуктов, © 2007-2018

Input your search keywords and press Enter.