Михаил Елфимов об интерфейсах

zayarny как-то высказал хорошую мысль о злых сервисах (и, соответственно, добрых сервисах). Я перескажу это несколько своими словами.
Идея в том, что есть сайты, которые делают интернет лучше. А есть сайты, которые сделаны для того, чтобы приносить прибыль своим владельцам. Иногда это совпадает, чаще — нет.

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

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

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

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

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

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

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

Примеров может быть очень много: одноклассники, мамба, тут и многочисленные клоны Facebook и LinkedIn. Когда создатели этих сервисов говорят, что они не просто скопировали оригинал, но адаптировали его к российскому рынку — они не имеют в виду, что сделали сайт удобнее для российских пользователей. В их понятии адаптация означает перестройку под популярные в рунете способы перегона посетителей в деньги. Это злые сайты, бесполезные сервисы и плохой веб.

Всегда будут люди, которые будут делать бизнес на грязном SEO, спаме и злых сервисах. Они делают веб плохим. Вопрос лишь в том, хотим ли мы участвовать в этом. Я думаю, каждый IT-специалист должен отдавать себе отчет в том, делает ли он веб лучше или хуже. И принимать осознанное решение о том, какие сайты он увидит в интернете завтра.

Артем Горбунов о слове «юзабилити»@artgorbunov.ru

Читаю что там написал Горбунов, читаю что написал Копылов, и не понимаю обоих. Вероятно, это означает что я далек от понимания юзабилити у обоих авторов.

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

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

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

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

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

Если нужен визуально богатый сайт, совершающий прорыв в своей области — надо обращаться к гениальным дизайнерам. Если нужен средний сайт, соответствующий представлениям пользователей — надо обращаться к юзабилити-специалистам. И те и другие — специалисты в своей области.

P.S. Я не знаю, насколько тут можно проводить сравнение, но давайте посмотрим на Яндекс.Почту и Gmail. Внешне все выглядит следующим образом. Яндекс.Почту делал Воронежский — гениальный дизайнер. Gmail делали юзабилити-специалисты.

Яндекс.Почта — традиционный почтовый сервис, над интерфейсом которого долго думали и вылизывали. Там красивые картинки, правильного размера кнопки и красиво сделаны фильтры «непрочтенные», «с файлами» и т.д. Красиво, но ничего особенного.

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

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

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

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

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

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

The Limitations of Server Log Files for Usability Analysis @boxesandarrows.com

Конечно, автор статьи прав насчет обычных логов. Они не точны. Люди, занимающиеся баннерной рекламой, скажут вам что расхождение в статистике, измеренной различными способами, может быть до 40% посещений. И тем не менее, логи — практически единственный способ быть в курсе реально происходящего.

Что можно сделать, чтобы повысить точность статистики?
— Использовать механизм сессий, чтобы отслеживать перемещения пользователя по сайту. Этим исключаются меняющиеся IP-адреса, анонимайзеры и прокси-серверы. Минусом является то, что некоторые браузеры могут блокировать cookie-файлы, через которые работают сессии;
— Хранить связь сессии и профайла пользователя, что позволяет получить некоторые демографические данные (если, конечно, они есть в профайле пользователя);
— Включать в одинаковые ссылки, находящиеся на одной странице, дополнительную информацию (если ссылка находится в меню — дописывать &from=menu, если ссылка находится в блоке навигации внизу страницы — дописывать &from=bottom, и т.д.), чтобы можно было определить, из какой части страницы перешел пользователь;
— Использовать механизмы асинхронных HTTP-запросов через Javascript (XmlHttpRequest), чтобы отслеживать перемещения пользователя по сайту. Этим исключается влияние кэширования на статистику, но увеличивает нагрузку на сеть и сервер.

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

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

С сайта pda-reader.ru

Хорошее замечание написал synchro (автор briefly.ru):
При проектировании интерфейс рассматривают не с точки зрения логики и простоты, а понятности для тупорылого пользователя. Эх, консерваторы… Так ещё долго интерфейсы не станут лёгкими и прозрачными.

И еще:
Проектируя интерфейс, надо думать в первую очередь не о простоте выполнения пользователем сценариев, но о правильности оных.

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

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

Как реагировать на такие тестовые задания?

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

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

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

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

HTC Touch (T-Mobile MDA Touch) @mobilegazette.com
Обзор GSM-коммуникатора HTC Touch (Elf) @mobile-review.com

Первый смартфон на Windows Mobile, который выглядит пригодным для тыканья в экран пальцем. Не буду говорить о том, что это одно из первых устройств, в которых сенсорный экран вообще приспособлен для пальцев, а не для стилуса. До этого были, как минимум, Nokia N800 (интернет-планшет), LG Prada, ну и предстоящий Apple iPhone. Как ни парадоксально, это всё.