Дизайн пользовательских интерфейсов и юзабилити: Интерактивные прототипы. Действующая модель пользовательского интерфейса, часть 3. Особенности процесса
Я уже писал про классификацию и два основных пути создания интерактивных прототипов. В большинстве случаев мы делаем как раз цветной прототип. По сути, это обычная верстка HTML-шаблонов страниц на основе визуального дизайна, включающая в себя JavaScript-взаимодействия. Разница в том, что эти шаблоны еще много раз поменяются и дополнятся.
Автоматические средства создания прототипов на основе схем страниц — те же Axure RP Pro и Intuitect — я стараюсь не использовать. Они и сами по себе заточены под типовые задачи, так что когда нужно делать что-то нестандартное, все их преимущества теряются. Зато добавляется сложности варки каши из топора. Поэтому мы стараемся делать прототипы вручную, с помощью обычных программ для HTML-верстки.
Процесс достаточно прост. На вход верстальщику поступает набор дизайн-макетов, на выходе — набор HTML-файлов. Расписывать тут особо нечего, лучше обратиться к любой статье по HTML-верстке. Но есть пара моментов, которые важны при создании прототипов:
Продуманные названия файлов. Перечень файлов интерактивного прототипа и их названий лучше расписать перед началом работы. Я стараюсь следовать принципу хлебных крошек — например, “catalog.html”, “catalog-category.html” и “catalog-category-item.html”. Так и в списке файлов ориентироваться проще — часто нужно показать конкретную страницу прототипа. И связность интерфейса лишний раз помогает проверить.Линковка страниц по ходу верстки. Прототип должен быть связан между собой для удобства юзабилити-тестирования и просто работы с ним. Если страница сверстана и на нее ведут ссылки, в них должен быть URL страницы. Банально, но если этим не заниматься сразу, придется потратить тонну времени на это после окончания верстки. Хотя сам прототип обычно делает верстальщик, связыванием страниц лучше заниматься проектировщику — он знает о взаимодействиях интерфейса гораздо лучше.Актуальный контент. Для лучшего восприятия прототипа и заказчиком, и пользователями, лучше использовать не lorem ipsum и заменители картинок, а тестовые данные. В последнее время я стараюсь готовить их даже до начала проектирования. Это помогает лучше понять контекст использования системы, отдельные ее особенности. Да и воспринимается гораздо лучше. Плюс по характеру тех же названий новостей проще понять суть проекта и команде разработки, и самому проектировщику.Не слишком увлекаться валидностью и красотой кода. Прототип будет меняться часто и быстро, так что тратить время на кристально чистый код не нужно — это только тормозит процесс. Лучше переверстать HTML начисто как только закончатся активные эксперименты с прототипом.Использование прототипа
После того как прототип готов, начинается его обсуждение и юзабилити-тестирование. А значит пачками приходят изменения. Причем далеко не всегда понятно, как именно нужно подправить какой-нибудь элемент интерфейса. Даже после долгих обсуждений и серии набросков есть как минимум пара альтернативных решений. Лучше всего реализовать все спорные альтернативы — подготовить несколько версий тех страниц прототипа, где находятся элементы для обсуждения.
Тут есть вариант увлечься. По-хорошему, конечно, при всех изменениях нужно обновлять весь пакет документации — схемы страниц (wireframes), макеты дизайна, HTML-шаблоны, сценарии юзабилити-тестирования. Но если прогонять для каждой правки весь цикл проектирование -> дизайн -> верстка -> юзабилити-тестирование, можно потратить уйму времени. Которого потом не хватит на проработку более важных решений. Так что если это не многолетний проект и нет армии проектировщиков и дизайнеров, нужно рисковать целостностью документации в пользу более качественного интерфейса. Где-то этапы цикла упрощать, где-то — выкидывать. Точнее, оставлять на следующие циклы. Главное хотя бы вести журнал изменений — чтобы после окончания экспериментов внести их в документацию.
Про сам процесс юзабилити-тестирования лучше расписать в отдельной статье. А еще лучше — обратиться к отличному пособию Влада Головача. Отмечу только, что по ходу работ удобнее показывать промежуточные результаты коллегам или просто знакомым. Есть, например, хорошие практики экспертных оценок. А вот тестирование проводить уже в конце или на нескольких важных промежуточных точках.
Еще один важный момент — поддержка прототипа. Если его использование планируется в качестве одного из источников документации, как это описано в первой части, нужно чтобы он всегда отражал последнюю версию интерфейса. Разработчики часто обращаются к нему как к последней инстанции. И если там что-то устарело — очень вероятно что будет устаревшим и в уже работающей версии. Значит к прототипу должен быть приписан постоянный верстальщик, фиксирующий все изменения.
Нужно определиться в самом начале, что в проекте является эталоном интерфейса — схемы страниц (wireframes), макеты дизайна или интерактивный прототип. Поддерживать все три слоя дороговато, да и менеджеру не хватит времени на достойный контроль качества всех трех процессов. Правда, по итогу часто все равно получается «шапку и футер смотрите в прототипе, тело страницы — в wireframes». Это во многом решается постоянным присутствием проектировщика, который расскажет, где правильно.
Главное не забывать, для чего и для кого делается интерактивный прототип. Тогда он будет не дороговатой игрушкой для кого-то из участников процесса, а здорово поможет на многих этапах работы над проектом. Да и продать идею инвестору или партнеру, имея на руках осязаемую вещь вместо просто набора обещаний на бумаге, намного проще.
Читайте первую часть материала с классификацией интерактивных прототипов и вторую, с описанием подходов к процессу их создания.
- Библиотеки ВУЗов оцифруют за 145 миллионов К концу 2007 года 15 российских вузов, среди которых всего 2 московских будут объеденены в одну сеть на основе каталога учебно-методической литературы, — сообщают “Единые системы”. На новый грандиозный проект Министерство образования было готово выделить 160 млн. рублей, но с компанией, выигравшей тендер на разработку каталога, сошлись на 145 миллонах. Ею стала недавно поглотившая “Борлас” компания IBS.Польза проекта очевидна: уже в начале 2008 года 13 федеральных вузов и два столичных, получат
- Web-разработка: Как JavaScript тормозит Веб (и что с этим делать)? Примечание: ниже перевод статьи "How JavaScript is Slowing Down the Web (And What To Do About It)", посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то
- sunnybear: Как JavaScript тормозит Веб (и что с этим делать)? Примечание: ниже перевод статьи "How JavaScript is Slowing Down the Web (And What To Do About It)", посвященной, в основном, работе с виджетами: характерные проблемы и методы их решения.Одна строка JavаScript является основой большинства текущих технологий, которые используют авторы блогов. Виджеты, средства (фото-/видео-)обмена, отслеживание посетителей, рекламные объявления. Во многих случаях единственная строка JavaScript — это все, что нужно автору, чтобы добавить в своей блог что-то
- pashka_r: 6 принципов вёрстки Эти рассуждения были навеяны постом akella про оценку качества вёрстки. Прочитав этот пост и немалое количество комментариев к нему, решил составить список (аля "10 правил чего-то там" — говоряттакие заголовки — это очень хорошо и помогают блогу "раскрутиться") критериев, которыми руководствуюсь я при вёрстке страниц. Стоит также заметить, что HTML+CSS, также как и программирование под веб, для меня является чем-то вроде хобби — т.е. "мега" проектов я (пока?) не реализовывал. Мо
- Web-разработка: Email это не место для дизайна Примечание: ниже перевод статьи Jeffrey Zeldman "E-mail is not a platform for design". В ней рассматривается текущая поддержка со стороны email-клиентов HTML-разметки писем. Статья во многом спорная и неоднозначная.После стольких лет процветания интернета HTML-письма по-прежнему вызывают сильное отвращение (still sucks). Вы можете подумать, что я имею в виду «HTML-письма не отображатся корректно в некоторых email-клиентах» Однако, это лишь часть истины. Компании тратят сотни часов простых верст
- Каскадные Таблицы Стилей: IE7 { css2: auto; } IE7 - библиотека JavaScript, заставляющая эксплорер работать по стандартам. Устраняет множество проблем с css, делает правильной обработку полупрозрачных PNG под IE5 и IE6.IE7 загружает и парсит таблицы стилей в формат, понятный эксплореру. После этого появляется возможность использовать функции CSS2/CSS3 без css-хаков. Облегченная версия скрипта включается в ваш HTML/XML документ. Никакого изменения разметки или css стилей не нужно. IE7 предоставляет Microsoft Internet Explorer поддержку W3C
- Веб-стандарты: 55 причин использовать XHTML-CSS при создании сайтов Перевод статьи «55 Reasons to Design in XHTML-CSS».В случайном порядке здесь представлены мои 55 причин создавать только бестабличные сайты, используя валидный XHTML для разметки, CSS для форматирования и Flash только в качестве уместной вставки. Под бестабличностью я понимаю избегание форматирования контента таблицами (или «супом» из заменяющих таблицы div-ов) и нацеленность на как можно более семантичную разметку. Некоторый из перечисленных причин объясняют, «почему не использовать простой
- Web-разработка: Первый взгляд на HTML 5 PreambleВ статье рассматриваются новые интересные возможности, которые предоставит пятая версия стандарта HTML. Приводится несколько примеров кода с применением новых тегов, а так же поясняются понятия HTML- и XML-сериализации с описанием преимуществ применения каждой из них. Вводная «лирическая» часть текста сокращена, т.к. она во многом пересекается с ранее опубликованным обзорным постом об HTML 5, в котором был приведен фрагмент интервью того же автора.Автор: Лахлан Хант, http://lachy.id.auО
- Web-разработка: Факторы, влияющие на html вёрстку (Часть 2: Работа PM и Рабочий процесс) Продолжение...Эта статья является продолжением Части1: Работа HTML кодера.Работа PM1. Однозначное толкование требований, пожеланий и воли клиента.Худший вариант: Пожелания клиента передаются PM’ом кодеру как есть (расплывчато, невнятно)Требование или задача формулируются, например, так: «Сделайте это более зелёным», «увеличьте шрифт», «отодвиньте этот блок влево», «оформите эту страницу в общем стиле».Хорошая практика: PM, на сколько это возможно, выясняет требования и пожелания клиента и перед
- Уроки французского: 3 лекарства для Ослика У великого (по доле рынка) творения Microsoft — браузера Internet Explorer раньше 7 версии имеется множество недостатков, среди которых современных веб-дизайнеров и разработчиков наиболее напрягают:плохая поддержка селекторов CSS2 (в частности, слабая поддержка псевдокласса :hover)плохая поддержка PNG с градациями прозрачности.Эти проблемы должны решиться, если все пользователи IE перейдут на седьмую версию. Для тех, кто не хочет ждать, я представляю три лучших лекарства от этих недомоган