Archive for the 'Проектирование ПИ' Category

Встраивание звукового файла в страницу

Михаил Елфимов on Ноя 15th 2007

Встраивание звукового файла в страницу очень симпатично сделано на computerra.ru (например, в конце статьи).

Вот так выглядит плеер в неактивном виде:

А так выглядит плеер во время воспроизведения:

Ну, из недостатков — мне все-таки хотелось бы знать сколько времени всего длится семпл, и сколько трафика я потрачу на прослушивание (это я хотел бы знать до прослушивания).

Filed in Практика, Проектирование ПИ, Ссылки | No responses yet

Проектирование социальных сетей (вторая часть доклада «Юзабилити социальных сетей»)

Михаил Елфимов on Ноя 13th 2007

Это вторая часть доклада «Юзабилити социальных сетей», прочитанного на конференции User Experience 2007. Первую часть доклада готовил Владимир Климентьев, она выложена в формате статьи на вебпланете (Социальные сети: от реальности к веб-сервису@webplanet.ru).

Сначала о названии. Вы можете спросить «где же тут обещанное юзабилити?». У монеты есть две стороны: проектирование пользовательских интерфейсов и юзабилити-тестирование. И то и другое отталкивается от анализа задач пользователя. Выдвигаются гипотезы о том, как пользователь будет взаимодействовать с системой. В соответствии с гипотезами проектируется интерфейс, затем эти гипотезы проверяются во время юзабилити-тестирования. Поэтому эти два вида деятельности тесно связаны. Без задач пользователя невозможно проектирование интерфейса: например, «поделиться новостью с друзьями» — вполне себе задача пользователя, и понятно как для неё проектировать. В то время как «запостить текст в сообщество» — такой задачи пользователя быть не может, и как для этого проектировать — совершенно непонятно. Должен ли у поста быть заголовок? Нужны ли теги? Будет ли указываться настроение? Из задачи пользователя это не ясно.

Были вопросы о моем опыте проектирования социальных сетей. Скажу сразу — я не гуру. Все, что изложено в докладе, можно узнать в интернете и нескольких книгах, если у вас есть две-три недели времени. Это обобщение чужого опыта под руководством здравого смысла.

Само понятие социальной сети — дело тонкое, поэтому я буду считать социальной сетью то, что назвал социальной сетью. Подробнее об определении — в статье Владимира Климентьева.

Определимся с тем, какие компоненты необходимы для функционирования социальной сети. Итак, Социальная сеть =
Самоидентификация пользователей + Связи между пользователями + Межличностные коммуникации + Предметная область + Рейтинги?

Самоидентификация пользователей. Это может быть профайл (анкета), список интересов, список тегов, друзья, краткое жизнеописание. Это может быть блог, как очень эффективное средство самоидентификации. Пользователи в сети лишены процедуры знакомства, и необходим какой-то механизм представления. Самоидентификация связана с накопления авторитета и доверием между членами сообщества. Полноценное общение невозможно без доверия между людьми.

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

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

Предметная область. Это собственно то, вокруг чего построен конкретный сервис социальной сети. Могут быть блоги, вакансии/резюме, фотографии, музыка — да что угодно. Предметная область имеет особое значение в досоциальный период развития сети, когда пользователей на сайте еще немного и предметная область остается единственным привлекающим фактором.

Рейтинги. Рейтинги всегда есть. Люди всегда заинтересованы в том, чтобы померяться разного рода рейтингами, это естественная потребность, которую можно использовать для построения авторитета пользователя и повышения доверия между пользователями. Даже если вы сами не спроектировали рейтинг как часть своего сервиса — это сделают другие люди, как, например, Яндекс для Livejournal и прочих блогохостингов.

Проектирование социальной сети принципиально отличается от проектирования обычных сайтов тем, что на первый план выходит взаимодействие типа человек-человек, вместо человек-компьютер. Перед тем как рисовать экраны и именовать разделы, надо определиться с тем, как люди будут взаимодействовать между собой на вашем сервисе. Из проектирования интерфейсов в этом, кажется, может быть полезна т.н. диаграмма Swim Lane@en.wikipedia.org — на ней отображаются все процессы и все роли, и то как действие переходит между различными ролями пользователей. Всегда, проектируя интерфейс сайта, где есть социальное взаимодействие, надо видеть второго человека, сидящего по другую сторону интернета.

Рассмотрим стадии развития социальной сети.

Предсоциальный период. У любого сервиса (если только он не построен на основе другого, уже работающего сайта) есть такой этап развития, начальный, когда социального взаимодействия еще нет, поскольку пользователей слишком мало. 10 человек — явно мало, чтобы считаться социальной сетью. 100 человек — может быть. 1000 человек — наверное, уже достаточно. Вот до преодоления этого барьера на первый план выходит предметная область, функциональность, вокруг которой построен сервис. В Livejournal можно просто вести блог. В flickr можно закачивать фотографии и давать ссылки на них. В LinkedIn можно заполнить визитную карточку и использовать как резюме. Это помогает накопить первоначальную базу пользователей.

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

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

Для более активного наращивания базы пользователей можно предпринимать следующие шаги:

  • Упрощение миграции из других сервисов. Например, копирование своего резюме с другого сайта простым указанием URL анкеты, формирование списка контактов путем импорта электронных адресов из адресной книги.
  • Стимулирование пользователей к регулярной генерации контента. Например, наличие постоянной анкеты, которую надо обновлять и поддерживать в актуальном состоянии, вместо одноразовых резюме.
  • Накопление авторитетности. К пользователю могут быть привязаны рекомендации других пользователей, ссылки, некоторый накопленный именно на этом сервисе авторитет, который не так просто перенести на другой сервис, в другое сообщество. Это стимулирует человек оставаться на этом сервисе, затрудняя миграцию.

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

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

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

В рекомендациях по формированию сообществ можно выделить ряд паттернов, best practices.

Делай как я. Людям проще копировать чью-то деятельность, а не размышлять над правилами и вникать в суть. Поэтому большое значение имеет с самого начала задавать тон общения, показывая людям чего от них ожидают, устанавливать формат сообщества. Основатели сообщества должны продемонстрировать на своем примере какое общение и какой контент они хотят видеть на сайте. Это эффективнее чем формировать свод правил, хотя и отменяет такой необходимости. Однако, если в правилах прописано одно, а сами основатели их не придерживаются — будет очень сложно следить за соблюдением правил и духа сообщества.

Ведущий сообщества. Он же менеджер сообщества, а также хранитель и модератор. В любом сообществе существуют ядро — те люди, которые вносят наибольший вклад. Они могут быть незаметны, их может быть немного (один человек, может быть 3-4 человека), но без них сообщество заполнится мусором или просто заглохнет. Необязательно это люди назначенные специально — это могут быть просто энтузиасты, регулярно добавляющие контент, поддерживающие общение и качество контента и общения. Если это люди, имеющие реальное имя и авторитет — сообщество благодаря им становится значительно более ценным.

Заполнение по запросу. Это сейчас начали реализовывать на moikrug.ru — вместо пустых блоков в профайле пользователя отображаются кнопки, с помощью которых другие пользователи могут попросить заполнить пробелы — указать место работы, интересы, школу, университет. Считается, что бездушные призывы сайта заполнить анкету еще на 5% не так стимулируют, как запросы от живых, реальных людей. Не знаю насколько это работает, привожу как есть.

Планирование активности. Чтобы у пользователя очень быстро не настал момент, когда он не знает что ему дальше делать на сайте, необходимо заранее планировать деятельность пользователя — сформировать основной сценарий, по которой он будет идти. Пользователь может пойти каким-то другим, альтернативным путем. Но основной сценарий необходимо продумать для того, чтобы правильно построить цепочку шагов по использованию сервиса и избежать досадных промахов в построении интерфейса.Пользователь зарегистрировался на сайте, что дальше? Поискал своих друзей. Что дальше? Заполнил место работы, поискал коллег, добавил в контакты. Что дальше? Начал переписку, написал несколько личных сообщений. Что дальше? Организовали пьянку. Что дальше? Выложили фотографии с пьянки, создали обсуждение. И т.д. Пользователей нужно вести, подсказывать дальнейшие действия, а не просто оставлять один на один с функциональностью сайта. Это может показаться навязчивым в реализации, но можно вести пользователя аккуратно, не подсказывать сто раз одно и то же, не давать неуместные в данном контексте советы, не быть назойливым. Это высший пилотаж проектирования взаимодействия — давать незаметные, но полезные подсказки в нужное время.

Напоследок, некоторые наблюдения о том, каким должен быть успешный сервис. Главное — не количество фич, не огромная всеохватывающая функциональность, а четкое позиционирование сервиса. Знакомиться — на mamba.ru, искать работу — на moikrug.ru, встречаться с одноклассниками — на odnoklassniki.ru, выкладывать фотографии — на flickr, и т.д. Человек должен с первого же взгляда на сервис понимать в чем этот сервис лучший. Если человек попал на сайт — пускай он имеет возможность воспользоваться им сразу же. Чем быстрее он увидит реальную пользу от сервиса — тем с большей вероятностью он к нему вернется.

Лучшие сервисы моделируют те аспекты человеческой деятельности, которые существовали и прежде. Они помогают людям делать то, что люди и так делали. И делают это лучше других сервисов. Вместо того, чтобы заставить людей заниматься какой-то новой деятельностью, которой нет аналога, чем пытаться изменить способ взаимодействия людей — лучше моделировать его, и делать проще. Все самые популярные сервисы не делают ничего революционного. Они просто берут то, чем люди занимались и до них, и делают это лучше, проще и понятнее. Чем и привлекают к себе. Gmail функционирует как почтовый сервис, моделируя уже существующую деятельность, но организует процесс более естественным для человека образом. То же с Flickr, то же с Google. Livejournal создавался просто как средство поддерживать связь с друзьями, и это тоже работает.

Спасибо что дочитали до этого места. Хочу напомнить, что все вышесказанное — обобщение сетевого опыта с помощью здравого смысла. Необходимо учитывать контекст, свою особую ситуацию, а не следовать примерам слепо. Контекст — ключевое слово в юзабилити.

Источники:

  1. Common Pitfalls of Building Social Web Applications and How to Avoid Them @bokardo.com
  2. Community Building isn’t about Features @bokardo.com
  3. A Social Revolution by Modeling Human Behavior @bokardo.com
  4. It's Not Just Usability @joelonsoftware.com
  5. Социальные работники @sf-online.ru
  6. Деловые социальные сети и рекомендательные письма @nundesign.com
  7. Социальные сети и поведение на рынке труда @sj.obliq.ru
  8. «Социальная сеть»: от «френд-листа» к «рабочей группе» @internet.ru
  9. Social Networks And Group Formation @boxesandarrows.com
  10. «Умная толпа: Новая социальная революция», Говард Рейнгольд (@ozon.ru, @bolero.ru, @findbook.ru)
  11. «Design for Community: The Art of Connecting Real People in Virtual Places», Derek Powazek

Я буду рад услышать ваши комментарии и отзывы.

Filed in Исследования, Проектирование ПИ, Социальные сети, Статьи | 2 responses so far

Презентация «Проектирование социальных сетей»

Михаил Елфимов on Ноя 9th 2007

Презентация от моего доклада «Проектирование социальных сетей» на конференции User Experience 2007:
michael.elfimov.com/userexp/userexp-presentation.ppt (100 Кбайт)

Вроде всем понравилось. Завтра выложу в виде картинок с комментариями, сейчас уж очень спать хочется.

P.S. Выложил текстовую версию доклада.

Filed in Исследования, Проектирование ПИ, Социальные сети, Статьи | No responses yet

Цитата из «The Visual Display of Quantitative Information», 2nd edition (Edward R. Tufte)

Михаил Елфимов on Окт 18th 2007

Принципы отличной графики

Отличная графика — это хорошо спроектированное представление интересных данных; вопрос содержания, статистики и дизайна.

Отличная графика состоит из сложных идей, которые доносятся доходчиво, точно и эффективно.

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

Цитата из «The Visual Display of Quantitative Information», 2nd edition (Edward R. Tufte).
Перевод 2007, Михаил Елфимов.

Filed in Литература, Проектирование ПИ, Цитаты | No responses yet

Цитата из «The Visual Display of Quantitative Information», 2nd edition (Edward R. Tufte)

Михаил Елфимов on Окт 18th 2007

Контекст — основа графической честности

Чтобы быть правдивыми и разоблачающими, графики должны отвечать на вопрос, лежащий в самом сердце статистического мышления: «В сравнении с чем?» Истощенный, бедный данными дизайн всегда должен вызывать подозрения, поскольку графики часто лгут умалчивая, не включая данные, необходимые для сравнения. Принцип:

Графики не должны иллюстрировать данные, вырванные из контекста.

Цитата из «The Visual Display of Quantitative Information», 2nd edition (Edward R. Tufte).
Перевод 2007, Михаил Елфимов.

Filed in Литература, Проектирование ПИ, Цитаты | No responses yet

Тестовые задания технических дизайнеров

Михаил Елфимов on Окт 17th 2007

Результаты набора на вакансию технического дизайнера — 8 и задание на вакансию @artlebedev.ru

Интересные вариации над расписанием. Расписание, само по себе - вечная тема для инфодизайнеров.

Filed in Проектирование ПИ, Ссылки | No responses yet

Mac OS X с точки зрения проектировщика

Михаил Елфимов on Окт 12th 2007

Плюс:
- В браузере Сафари, при закрытии последней вкладки, она закрывается, и от программы остается только меню, которое не привязано к конкретному окну программы. Это поведение отличается, например, от Firefox для Windows, в котором при закрытии последней вкладки она заменяется на пустую. Это вынужденное поведение, поскольку невозможно закрыть окно и не закрыть программу, в Windows меню привязано к окну. Закрывать же программу по закрытию последней вкладки тоже как-то нелогично.
Mac OS X это решено более элегантно - программа может существовать с отображением только меню, без окон.

Минус:
- В том же браузере Сафари при клике по лейблу чекбокса состояние последнего не меняется. Много поколений HTML-верстальщиков впитывают с молоком матери, что лейбл чекбокса надо обязательно привязывать через атрибут FOR к ID чекбокса, ибо неправильно заставлять пользователя тыкать исключительно в сам чекбокс при наличии полезной ассоциированной площади. А тут это просто не работает. Так вот.

Filed in Практика, Проектирование ПИ | No responses yet

Излишняя услужливость

Михаил Елфимов on Окт 5th 2007

На сервисах типа mamba.ru, odnoklassniki.ru есть возможность посмотреть:

  • список людей, которые заходили к тебе в профайл;
  • дату, когда человек последний раз был на сайте (или индикация что он сейчас на сайте).

Меня это долго напрягало, и теперь я наконец понял что в этом неправильно.

В Gmail есть замечательная возможность сделать отмену любому своему действию (ну, кроме отправки письма). Даже удаление письма не влечет за собой ничего серьезного - письмо все равно можно восстановить. Т.е. человек может быть уверен, что а) система не сделает ничего без команды человека, б) что бы человек не сделал, он всегда может это исправить.

Это именно тот принцип, который нарушается на мамбе и одноклассниках. Человек, не нажимая никаких кнопок и не давая никаких команд, одним своим переходом по страницам вносит изменения в систему. И эти изменения он не может ни отменить, ни как-то исправить.

Filed in Проектирование ПИ, Юзабилити | One response so far

Интересное решение - теги для статьи

Михаил Елфимов on Авг 31st 2007

С сайта pda-reader.ru

Filed in Практика, Проектирование ПИ | No responses yet

«Правильное» проектирование

Михаил Елфимов on Авг 27th 2007

В использовании прототипов для проектирования есть правда и неправда.

Правда заключается в том, что прототипы удобны для согласования спроектированного с заказчиком (начальством). Собственно проектированию они тоже помогают. Но согласование — это ключевая фича.

Неправда заключается в том, что согласование с заказчиком — это не то же, что демонстрация юзеру. После согласования с заказчиком получается, например, что пункт «О проекте» — это очень важный пункт меню, который непременно должен быть на первом месте в меню и обязательно на главной странице. С точки зрения пользователя у меня этот момент вызывает сомнение. Поскольку как пользователь я совершенно уверен, что на странице «О проекте» будет какая-нибудь маркетинго-стимулирующая галиматья. Очень редко когда можно встретить грамотную страницу «О проекте», и то её содержание обычно на страницу никак не набирается — максимум пара предложений: зачем сайт/проект и чем он отличается от прочих.

Прототип, в котором на первом месте стоит ссылка «О проекте», начался неправильно — c контента, который заказчик хочет положить на сайт. Надо начинать с другого — что пользователь хочет видеть на сайте. Вместо задачи «распихать контент по разделам меню» и «красиво оформить расписание» появляется задача «понять, для чего люди приходят на сайт» и «дать им то, что им нужно». В этом варианте страница «О проекте» появиться никак не может. Заметьте, я не говорю что люди никак не учитываются при проектировании — они учитываются, но приоритет стоит на бизнесе, а не на людях.

Я немного утрирую — в этом конкретном проекте страница называется по-другому (нет, не «О нас»), и может быть даже я бы на неё и зашел, будь я реальным посетителем сайта. Однако, ничего полезного бы я там не увидел. Текст отвратителен. Разве что само наличие такой страницы и усилия маркетологов может повлиять на подсознательный выбор человека — значит старались создатели сайта, денег вот на тексты положили.

С третьей стороны, тут вступает в дело конфликт личных целей и целей корпоративных. Сайт этот не имеет целью быть самым совершенным сайтом во вселенной. Он выполняет возложенные на него цели, и удовлетворяет нужды заказчика в донесении информации до пользователя.Лично я поспорил бы с клиентом и настоял на своих решениях, потому что выступаю адвокатом своего взгляда на то, что удобно для пользователя. Они не идеальны, но исходят из желания сделать удобно, а не решить бизнес-цели. Если бизнес-цели диктуют необходимость сделать в расписании мероприятий вынести на первое место колонку «город» (дабы подчеркнуть геораспространенность), а удобство подсказывает, что правильнее было бы разместить колонку «дата», то я бы поставил первой колонку «дата», потому что бизнес-цель действует в течении первых пяти минут, а люди на эту страницу будут возвращаться, чтобы получать информацию, а не впитывать бизнес-цели.

Но я не уверен в окончательной правильности своего мнения, и думаю что предложение заказчика тоже имеет смысл. Твою мать, я в нерешительности. Несмотря на то, что решение уже принято и сайт уже делается, меня не оставляет мысль, что я прогнулся под мнение заказчика, вместо того чтобы отстоять удобство — напоминаю, гипотетическое! (ибо я проектировщик, а не пользователь)

Filed in Методы юзабилити, Проектирование ПИ, Статьи | No responses yet