Ах, эти интерфейсы

Жираф большой — это не сразу поймешь!

2012-01-30T19:02:00.007+04:00

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

Не так давно мы с моим двухлетним сыном посетили Ленинградский зоопарк. Большинство зверей сын прекрасно знал по фотографиям и рисункам, и, естественно, он хорошо представлял себе жирафа. Однако, увидев жирафа (довольно таки издалека), ребенок испугался и начал плакать. Оказалось, что жираф БОЛЬШОЙ. Мой сын знал, как он выглядит, знал что он милый и красивый, но он не ожидал, что он такой большой — книги не дали ему всей полноты картины, ее смог дать только личный опыт.

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

Дай телефончик подержать

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

Юзабилист, помни, ты — ты не посетитель зоопарка, ты работаешь в нем смотрителем!

Если вы хотите проектировать интерфейсы под iOS, Android, Phone7, Win, Mac, Linux (нужно подчеркнуть), вам просто необходимо попользоваться данным устройством «для личных целей» как минимум 1–2 недели. Этот совет я получил от коллег проектировщиков, последовал ему и ни раз убеждался в его ценности.

Люди мы небогатые

«Но где мне взять все эти дорогие девайсы», — вскричит читатель, — «я беден, денег едва хватает на поездку в Египет на новогодние каникулы». Думаю универсального совета тут не существует.

Когда мы учились делать приложения для iOS и Android, я настоял, чтобы закупили по паре устройств каждой платформы, аргументируя это тем, что все равно для тестирования они понадобятся через пару месяцев.

А какие идеи есть у вас?

Мое выступление на РИФ+КИБ 2011

2011-05-20T15:54:00.004+04:00

Вот видео РИФовского круглого стола по теме «Зачем компании создают usability-отделы?». Мое выступление — первое, со 2-й по 15-ю минуты. Также рекомендую посмотреть следующие за мной 2 доклада. Список выступающих и их презентации (которые на видео не рассмотреть) доступны на сайте организатора.

Проектирование интерфейса (для начинающих)

2011-05-06T12:35:00.006+04:00

Выкладываю видео с теоретической частью мастер-класса ~~«Электроника для собак»~~ «Проектирование пользовательского интерфейса (для начинающих)».

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

Делайте интерфейсы под пальцы

2011-03-22T15:36:00.008+03:00

Тачскрины и интерфейсы «под пальцы» сейчас повсюду. Это хорошо, но возникает проблема нехватки адаптированных интерфейсов.

Сегодня, получая деньги в банкомате, я встретил вот такой интерфейс:

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

ОК, это понятно. В переходный период с обычных экранов на тачскрины такое будет встречаться повсеместно. Я просто решил поделиться с вами одной идеей:

Все веб-интерфейсы, которые вы делаете, адаптируйте для работы пальцами на тачскрине. По сути я советую все веб-интерфейсы делать под планшеты (iPad и т.п.).

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

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

Быстрая обратная связь очень важна для сайтов, продающих товары или услуги

2010-12-23T11:57:00.008+03:00

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

Что я имею ввиду под словосочетанием «быстрая обратная связь»? Это когда ты зашел на какой-то сайт и появляется окошко, в котором можно пообщаться с менеджером, отвечающим на твои вопросы. Ну вы поняли. Кстати, как это по научному называется?

Есть две основных причины, почему такая быстрая связь посредством встроенного чата важна:

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

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

Общаясь с клиентом прямо на сайте можно повысить вероятность успешной покупки.

Кому это будет полезным

Каким сайтам будет толк от системы он-лайн общения? Мне кажется всем, кто продает что-то со множеством опций или что-то дорогое и штучное.

Несколько примеров навскидку:

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

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

Подойдет ли решение сайтам с большим трафиком, например, крупным интернет-магазинам? Честно говоря, не знаю. Нужно смотреть на соотношение расход/доход. Кто знает, может быть телефонные барышни должны уступить место барышням клавиатурным, хотя бы частично?

Некоторые нюансы

Вот некоторые моменты, которые мне кажутся важными:

Общение должно происходить в том же окне (табе), что и сайт. Никаких новых окон!
Общение не должно требовать авторизации и тем более регистрации.
Окно с предложением помочь должно появляться само, без действия пользователя. Хотя вызов чата по клику может стать решением для сайтов с большим количеством покупателей.
Окно с чатом не должно быть навязчивым и уж тем более модальным.
Окно не должно появляться на всех страницах сайта. Важно найти точки, в которых его появление будет уместным.
Окно чата должно содержать имя и фотографию менеджера (консультанта), с которым общается пользователь. Имя и фотография должны быть настоящими. Если это по каким-то причинам не возможно, то пусть будет виртуальный персонаж. Не пытайтесь обмануть пользователя фотографией девушки из клипарта, которая якобы работает 24×7. Сделайте рисованный аватар и имя, из которого понятно, что это псевдоним.
Если при сообщении издается звук, проследите, чтобы он не был громким.
После завершения разговора, клиент должен иметь возможность получить его запись по почте вместе с телефоном и именем специалиста, с которым он общался.

Успешных вам продаж!

Браузерам нужен новый логотип

2010-11-25T22:57:00.010+03:00

В самых популярных операционных системах панель задач (не важно как она называется) состоит из крупных значков приложений. Вот как выглядят сегодня браузеры на ней:

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

Видео с конференции UX Russia 2010

2010-10-20T17:58:00.012+04:00

Организаторы выложили видео с конференции. Притом вмонтировали в видео и презентацию. Мелковато, но зато в контексте.

Мой доклад «Методы быстрой авторизации» вызвал резонанс, многим понравилось. А я сейчас посмотрел на себя со стороны и мне не нравится — болтал много лишнего, говорил путано. Но, буду меняться. Смотрите, если интересно (переход на другую страницу):

Если что, то есть презентация в pdf.

К чести организаторов они выложили ВИДЕО ВСЕХ ДОКЛАДОВ конференции! Это очень и очень круто, они молодцы, что не зажмотились.

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

Сколько я смогу заработать на юзабилити?

2010-10-17T19:48:00.013+04:00

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

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

Немного истории

Генри Форд был гениальным инженером и бизнесменом. На его заводах производился первый по-настоящему массовый и народный автомобиль Ford T. За 19 лет было произведено более 15 миллионов (!) автомобилей. Этот автомобиль был дешев, прост и очень надежен, на сохранившихся до наших дней экземплярах все еще рабочая подвеска.

Был ли этот автомобиль ориентирован на удобство пользователя? Однозначно нет! У него были плохие неудобные тормоза, его примитивная подвеска не была устойчива в поворотах, из-за отсутствия бензонасоса он глох на горках, он был травмоопасен, скрипуч, а комфорт в нем отсутствовал как класс. Но таковы были все автомобили того времени. Форд опережал их по технологичности, надежности и цене. Конкурентов у него долго не было.

Здесь важно понимать, что это были времена начала отрасли автомобилестроения. Хотя Форд и сделал автомобиль массовым, он очень поздно понял то, что давно поняли его отстающие конкуренты — получив средство передвижения, люди начинают хотеть большего: комфорта, престижа, индивидуальности (именно в таком порядке).

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

Повторение истории в веб-индустрии

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

Заботились ли все эти люди об удобстве пользователя? Естественно, нет! Потому что нужно было удовлетворить базовые потребности — надежность системы, скорость и цену разработки и поддержки, кросс-платформенность и т.д.

А что же с проектированием, ориентированным на пользователя? Как и в автомобильной индустрии, первыми сделали ставку на это маленькие и средние компании. Им нужно было какое-то конкурентное преимущество, а пользователю нужна была любовь, тепло и забота. Постепенно на западе, а затем и в России юзабилити стало приносить деньги не только дизайнерам, но и бизнесменам.

Так насколько это прибыльно?

И вот теперь бизнес чаще и чаще задает вопрос «сколько мне принесет дополнительных денег это ваше юзабилити».

Я хочу ответить на этот вопрос.

Если вы спрашиваете это, значит вы точно не в первом эшелоне. Значит вы уже в роли догоняющих. А если вы все еще лидер своей отрасли, то значит вы повторяете судьбу Генри Форда и конкуренты, которые кажутся швалью, могут скоро откусить вам хвост.

Поэтому нужно ставить вопрос совсем иначе: «сколько я потеряю в ближайшие 5 лет, если сегодня не начну вкладывать деньги в юзабилити».

User Experience Russia 2010: впечатления

2010-10-09T10:14:00.009+04:00

Конференция User Experience Russia образца 2010 года прошла очень хорошо. Хочу поделиться впечатлениями буквально в двух словах.

Доклады были интересными, как у хэдлайнеров в первый день, так и у простых смертных во второй.

В первый день понравился больше всех Билл Бакстон из Майкрософт, который открыл мне глаза на то, что нужно оглядываться назад на технологии и девайся 20-летней давности. Теперь я понимаю, зачем Студии Артемия Лебедева нужен музей старья.
Очень вствил доклад Андрея Себранта из Яндекса, который оформил мои смутные ощущения о мониторинге проекта в графики и формулы.

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

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

Вроде бы все доклады будут не только выложены в виде презентаций, но и в видео формате. Это радует, т.к. как известно информация должна быть открытой.

Я поищу видео с моим выступлением и выложу его в блоге.

Радуйтесь, когда вас ненавидят

2010-08-13T21:24:00.006+04:00

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

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

И тут я неожиданно понял, что когда тебя ненавидят пользователи — это круто!

Если ты не слышишь ругани от пользователей, это значит только одно — твоей системой мало кто пользуется. А если ругани нет после трех дней простоя — значит пора сворачивать проект.

Прав был Влад Головач в своей книге, утверждая, что любой интерфейс плох (в смысле, что любой интерфейс есть куда улучшать). А если плох, значит его будут ругать. Жестко и часто нецензурно.

Вот такая своеобразная любовь пользователей. Читайте фидбэк, дружите с саппортом и будет вам счастье!

Что случается, когда маркетологи пишут код

2010-07-12T16:07:00.028+04:00

Что бы там ни говорили проектировщики интерфейсов и другие «друзья пользователей», но работают они прежде всего для заказчика. Заказчиком же обычно являются маркетологи и/или коммерсанты. К сожалению эти замечательные люди порою бывают слишком уж замечательными и начинают сами «писать код» веб-приложения. Но проектировать интерфейсы они не умеют, программировать тоже, зато хорошо умеют писать длинные тексты — их то они и вставляют в обилии везде, где только можно, это и есть их «код». Результат получается как в том письме, что писал Дядя Фёдор из Простоквашино, когда все написали по чуть-чуть, а ~~пользователь~~ получатель этого письма хватался за сердце и падал в обморок.

Я приведу пару примеров из жизни, но намеренно не буду приводить скриншотов и называть имена и явки. Просто я ~~боюсь мести~~ не хочу переходить на личности. В конце (для терпеливых и неумеющих быстро прокручивать страницы) я скажу секрет, как нужно поступать, чтобы все были счастливы.

С точностью до запятой

Делали мы как-то веб-сервис, на котором была очень длинная форма. Заказчик был ну очень щепетилен в плане юридической составляющей. И они по сути нарисовали форму сами и...

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

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

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

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

Объявление: объявление находится ниже

В другом проекте заказчик попросил разместить НАД формой авторизации инструкцию как пользоватья веб-сервисом. Не как авторизовываться, а именно весь цикл, что произойдет после авторизации.

В результате поля с логином и паролем существенно съехали вниз и... были не видны не многих мониторах, особенно на лэптопах.

Сроки поджимали, спорить было затруднительно и проект вышел с такой фичей. И только позже я узнал причину, почему заказчик решил так поступить. Дело в том, что пользователю на телефон в виде SMS высылалась ссылка на эту страницу. А высылалась она под видом «узнай поподробнее».

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

Вот мы и подошли к нашему секретному выводу.

Большой секрет

Заказчик должен ставить перед разработчиком общую задачу, а не углубляться в частности. Разработчик на то и подряжен, что он лучше знает КАК сделать, а заказчик на то и заказчик, что лучше знает ЧТО сделать.

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

Грустно, но эту прописную истину, которая описана в куче книг, не понимают очень многие.

Краткая шпаргалка для заказчика, что такое «хорошо», а что такое «плохо»:

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

Только самое нужное

2010-05-08T17:36:00.010+04:00

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

Рассмотрим принцип «сообщать только самое нужное» на примере сайта «Мобильный перевод» компании МОБИ.Деньги, который я проектировал и внедрял. Суть этого сервиса — позволить владельцам телефонов Билайн обналичивать средства с их мобильного счёта.

С места — в карьер

Главная страница сайта выглядит так:

Что тут есть (необходимое):

Два коротких вводных предложения, отражающие суть услуги.
Форма перевода, которая одновременно является поясняющей иллюстрацией.
Ссылки на доп. информацию: где получить перевод, размер комиссии, текст публичной оферты, помощь.

Чего тут нет (лишнее):

Длинных маркетинговых текстов.
Предложения зарегистрироваться.
Мусорной графики.

Подпишитесь под договорчиком, пожалуйста

Когда пользователь заполнил первую форму, он перейдет на страницу подтверждения платежа. Т.к. телефон является источника перевода, то одноразовый пароль мы автоматически высылаем через смс (регистрация отсутствует как класс):

Что тут есть:

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

Чего тут нет:

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

Собственно, всё!

Всё, перевод совершен:

Что тут есть:

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

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

Чего тут нет:

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

Каков итог?

С момента первого посещения сайта до совершения успешного перевода прошло около минуты. Сравните это со временем, которое вам потребуется, чтобы совершить такой же перевод на другом сайте или в офф-лайне.

Советы напоследок:

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

Ограничивать нельзя позволить

2010-03-05T19:03:00.007+03:00

Хочу прочитать некоторый ликбез по построению полей на форме ввода, а также рассмотреть некоторые ошибки.

Ликбез (повторяем пройденное в детском саду)

Сверху — пример простой формы (фрагмент). Она хорошо отражает два главных принципа:

Поле должно быть достаточной длины, чтобы поместился контент — это самое важно, аксиома. Недостаток длины полей ведет к ошибкам ввода. Но это и так все знают.
Поле должно по возможности быть не длиннее, чем нужно. Если поле содержит точно определенное количество символов, то логично сделать его именно такой длины (не забыть про разные шрифты, браузеры и некоторый запас). Это не обязательное требование, но желательное. Конечно, бывает некрасиво, когда длина полей скачет или просто не хочется заморачиваться. Но уж точно 1-2 символа не должны вводиться в длиннющее поле. Хороший вариант — завести css-классы для длинного, короткого и среднего полей.

Переходим в старшие классы или горе от ума

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

Оба этих требования ошибочны, что я и объяснил заказчику. Хотел также поделиться доводами с вами.

Ни цента больше

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

Понаехали тут

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

Посмотрите на форму сверху. В первом поле хоть мы и рекомендуем вводить 10 цифр телефона слитно, но прощаем и пробелы и дефисы и даже лишнюю восьмерку в начале. А почему нет? Что нам сложно отбросить лишние символы что ли!

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

Дата вылета на форме бронирования билетов

2010-03-02T19:16:00.006+03:00

Подбирал сейчас авиабилеты на модном сайте Агент.ру, выбрал параметры и главное заполнил поле «Дата вылета». Мне выдало сообщение «выберите другую дату — возможно, на указанную дату нет рейсов по заданному направлению».

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

Решить проблему можно по-разному — сделать диапазон даты вылета или чекбокс «Показать рейсы на этой неделе». Но это все усложняет форму.

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

Маленький пук для программиста и у вас появилась дополнительные заказы.

Вывод

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

Победа безопасности над разумом

2010-02-28T23:29:00.004+03:00

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

Хостинг, на котором находится мой сайт, имеет панель администрирования, защищенную паролем. Этот пароль я сразу поменял на удобный мне, это разрешено. Из этой панели можно поменять пароли для ftp и ssh, но... только на автоматически сгенерированные, на свои нельзя. Как мне объяснили, это для безопасности. Почему при этом можно придумать себе любой мастер-пароль — загадка. В результате этого маразма постоянно борюсь с желанием сохранить пароль к ssh в текстовый файл на рабочем столе.

Мой пароль протух и пахнет

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

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

А у вас какой длины?

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

Почему некоторые сайты ограничивают длину пароля 10 символами и запрещают вводить знаки типа @#$%^& — для меня загадка. Ну не на размере же базы данных они экономят! Вот и попробуйте в Альфа банке придумывать раз в месяц новый пароль не меньше 8 и не больше 10 символов.

Они все равно сделают по-своему

Не ограничивайте пользователей и не считайте их за малых детей (даже если они такими являются). Это все равно бесполезно. Они запишут ваш супер пароль на бумажку и наклеят на монитор.

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

Можно спорить и отстаивать мнение, что от жены тоже могут быть тайны, но я не об этом. Дело в том, что имеется возможность загружать компьютер без ввода пароля вообще и эта возможность штатная. А переключаться между пользователями мы стали с помощью горячих клавиш, которые работают без настройки — пользователи в Убунте висят на разных консолях, так что Ctrl+Alt+F9 вам в помощь. Я же говорю, что пользователи все равно сделают все по-своему.

Что делать?

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

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

Снежные интерфейсы простого народа

2010-02-01T22:31:00.020+03:00

Если вы не хотите, чтобы пользователи что-то делали в вашем интерфейсе, а запретить это вам лень или нету сил, тогда вы пишите объявление типа: «Матерные комменты не писать, ну пожалуйста» или «За нарушение правил форума — бан, смерть и вечное проклятие».

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

Чтобы оценить масштабы бедствия:

Хорошая идея — завершенная идея

2010-01-05T00:17:00.013+03:00

Мало создать интерфейс, нужно довести его до состояния, когда им возможно будет пользоваться, а вот это уже на порядок сложнее.

Есть такая компания Макдоналдз. Она американская, а Америка — это такая страна, где уважают инвалидов и считают (на практике, а не в теории) их обычными гражданами, достойными без посторонней помощи сходить на спортивный матч, в магазин или в столовку.

Именно поэтому все русские Макдоналдзы имеют отдельный туалет для инвалидов. А вот сделать крыльцо, ведущее в этот ~~туалет~~ ресторан, доступным для инвалидов — до этого уже руки не дошли. Короче, типичный пример тупого следования заокеанским гайдлайнами, лицемерия и русской экономии:

Назвался груздем — полезай в стандарты

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

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

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

В заключение хочу показать пример ~~семантической верстки~~ как нужно делать общественные места доступными для инвалидов: версия НТВ, версия РТР.

Дублируй, не дублируй — толку мало!

2010-01-02T19:58:00.010+03:00

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

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

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

Тварь я в очереди стоящая или карту имею?

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

О том, что эти кассы особенные (только карты) покупателям сообщается вербально и визуально (желтые большие щиты с черными жирными буквами), причем не один и даже не два раза. Давайте посчитаем:

объявление по громкой связи;
большой плакат на подходе к этим кассам;
надпись на уровне касс;
надпись на самой кассе;
где-то еще, если я не ошибаюсь;
и наконец (!) кассир спрашивает «вы по карте?».

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

Расплачиваясь, я поинтересовался у кассира, как много покупателей не видят надписи с предупреждениями и разворачиваются возмущенно после его вопроса о карте. Его ответ меня поразил:

— Процентов 60%, ну, может поменьше, — ответил кассир. — А ведь столько предупреждений, везде надписи, а они не читают!

Что ж, остается только надеяться, что к дорожным знакам водители относятся более внимательно. Впрочем, мой опыт автомобилиста говорит обратное :(

Каждому покупателю по персональному кассиру

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

В случаи с Икеей, кассир должен был отсеивать не более 5% покупателей, но никак не 50%.

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

Так что, пожалуй, кроме принципа «чем раньше, тем лучше», важен принцип: по возможности безболезненно.

--------------------------------------------------------------

P.S. Подумал тут, что проблема в баннерной слепоте. Люди не обращают внимание на яркие и заметные вывески, потому что обычно это реклама.

Модный и проигравший

2009-12-03T21:53:00.008+03:00

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

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

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

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

Интересно, что в этом бессмысленном (на мой взгляд) ребрендинге наверняка все действовали искренне. Маркетолог искренне решил, что старая бутылка — она старая во всех смыслах и нужно как-то отрабатывать свою большую зарплату. Дизайнер искренне сделал «современную упаковку», как его просили. Фокус-группы искренне сказали, что они предпочтут новую упаковку старой с вероятностью 23%. Искренне веря в рост продаж, директор оплатил расходы на этот балаган.

Погоня за модой в интерфейсах

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

Иконки рисуют одинковыми по форме и цвету — ничего, что найти нужную кнопку так в 2 раза дольше, зато стильно. Ну а сделать шрифт помельче (кстати, кто-нибудь знает зачем это делают?) и убрать подчеркивание у ссылок — ну куда же без этого!

А вы уже разместили главный функционал своего веб-сервиса внутри последнего флэш-плеера?

А какой календарик для блога сделал ты?

2009-11-26T18:13:00.012+03:00

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

1. Олдскул

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

Видимо бессмысленность подобного типа календаря поняли все и потому сегодня я с трудом нашел даже один для примера:

2. Гугел

В ЖЖ вообще перестали использовать календари (возможно, я ошибаюсь, но раньше они там были), пользователям вполне хватает ссылки [<< Previous 20].

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

Удобная штука — можно просмотреть сколько записей было в каждом месяце. Однако если бы я писал по 1-2 поста в день, то календарь превратился бы в кашу. Но Гугл не верит, что я на это способен, поэтому показывает в календаре не только названия месяцев, но и названия постов. Не верит и правильно делает :)

3. Сам себе дизайнер

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

Кроме того, я посчитал, что если в месяце нет записей, то его все равно нужно отображаться (сереньким и не линковать). Т.е. у меня в году всегда 12 месяцев и пользователь не гадает, почему после января сразу идет март:

4. Яндекс

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

5. Ойфанчег

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

Впрочем, для данного ресурса такое решение вполне оправдано:

Выводы

Идеальных календарей не существует. Для каждого случая необходимо искать свое решение.

Прототипирование на чистовую

2009-11-25T15:01:00.021+03:00

В среде профессиональных разработчиков интерфейсов часто обсуждается, какой инструмент прототипирования лучше, мощнее, дешевле, быстрее. Рискуя прослыть еретиком, скажу, что для некоторых веб-сервисов лучшее средство прототипирования — HTML.

Обычно веб-проект проходит следующие этапы:

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

Конечно, эти этапы — не закон. Всё зависит от политики разработчика, от сложности сервиса. Бывает, что один человек сел и сделал все этапы в один присест, например, Записочки именно так и сделаны Максимом Чечелем.

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

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

Я же хочу поделиться примером, как мы совместили сразу несколько этапов — прототипирование, дизайн, верстку, кликабельный прототип — при создании сервиса 3115.ru о котором я уже рассказывал.

Плюсы прототипирования на HTML

Создание этого сервиса уложилось всего в 3 этапа:

Набросок;
кликабельный HTML-прототип;
программирование;

Мы создали полный клон сервиса на статическом HTML + немного динамики на JS. На прототипе все нажималось, как на настоящем сайте (ну, почти все), а главное он выглядел, как готовый сайт.

Плюсы чистового прототипирования с помощью HTML:

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

Минусы прототипирования с помощью HTML:

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

Вывод: прототипирование веб-сервисов с помощью HTML может быть очень полезным, однако применять его нужно осторожно.

И помните, самое сложное объяснить инвестору, почему он видит работающий сайт, где всё нажимается, а с него требуют еще 3 месяца на программирование и кучу денег :)

Ах да, я же обещал в каждом посте картинку:

Делайте маленькие сервисы

2009-10-30T00:46:00.006+03:00

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

Я работаю в компании Моби.Деньги. У нас есть главный сайт, ~~во всех его возможностях сложно разобраться~~ он очень мощный по функционалу.

Любой владелец телефона Билайн может оплатить со счета телефона свой интеренет. А еще он может заплатить за квартиру. И за телефон может заплатить. И перевод другу сделать. А еще может подключить к телефону банковскую карту и платить с нее. Ну, подключил, а потом платишь также, только выбираешь другой способ вывода. Или не выбираешь, а платишь по старому со счета Билайн. А еще можно платить с помощью СМС, для этого нужно отправить аббревиатуру товара (что это!) и параметры (мама!!!), и сумму платежа на номер... так, какой номер, ах да, его можно найти в каталоге. Да, чуть не забыл, платить с карты может не только пользователь Билайн, но и других операторов. И самое главное — реальность, как следует из вышесказанного, рассматривается из ряда вон выходящий закон исключённого третьего, хотя в официозе принято обратное.

Поняли к чему я клоню? Да, мы приложили много усилий, чтобы пользоваться сервисом было легко, но слишком уж много там всего. Прямо Фотошоп какой-то! Но в Фотошопе люди работают годами, а на сайт заходят на пару минут сделать то, что им нужно. И если они не уложатся в пару мину, они пойдут искать другой сайт. Ведь так много нужно успеть — и Вконтакте посидеть и кино новое посмотреть.

Что делать с раздутым функционалом?

Проблема не в плохом юзабилити сайта, а в мощном функционале. А функционал — это же конкурентное приимущество, его не выбросишь на помойку!

Выход — делайте много маленьких сервисов вместо одного большого.

Поясню на нашем примере. У нас уже давно можно подключить банковскую карту к телефону и с этой карты пополнять баланс своего мобильного. Мы выделили эту возможность в отдельный сайт — 3115.ru. На нем можно подключить карту и заплатить с нее на телефон. И можно сделать это с помощью СМС — достаточно отправить сумму платежа (просто одну цифру) на номер 3115 (видите, он совпадает с именем домена).

Всё! Больше на этом сайте ничего делать нельзя. Фактически, можно на него зайти один раз в жизни на 2 минуты, чтобы подключить карту. А дальше — просто отправлять СМС, когда нужно.

Согласитесь, такой сервис пользователю гораздо проще понять и полюбить, а нам — рекламировать.

Ну не выбрасывать же!

А что будет с остальными возможностями нашей системы? Мы будем продолжать создавать маленькие сервисы, дробя наши возможности на составные части.

Пора заканчивать, так много текста никто не прочтет :)

Должно ли второе поле для загрузки файла появляться автоматически?

2009-10-01T13:53:00.015+04:00

Когда нужно загрузить файл, на сайтах обычно размещают поле с кнопочкой «Обзор». Этот элемент также известен под именем <input type="file"/>. Хочется обсудить, что делать, если файлов загрузить нужно несколько.

Вот как поступили разработчики Гугл почты:

Т.е. чтобы появилось поле для загрузки следующего файла, необходимо кликнуть по ссылке. И это, на мой взгляд, минус. Клик по ссылке + клик по кнопке и так несколько раз. Зачем?

А вот как поступают товарищи из Atlassian JIRA:

Как видите, следующее поле появляется автоматически после того, как загрузили предыдщее. И я считаю, что это большой плюс, по сравнению с Гугл почтой.

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

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

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

Пользователи плохо умеют считать проценты

2009-09-30T16:59:00.017+04:00

Если вы взимаете комиссию за услугу, необходимо внятно сообщить пользователю размер этой комиссии. Вопрос в том — в рублях или в процентах. В рублях, вроде бы логичнее, но если пользователь сам вводит сумму, то может быть, до момента ввода проще показать проценты? Я так считал. Оказалось, что пользователи считают иначе. Точнее, они вообще плохо считают.

В нашей платежной системе комиссия отображается в виде процентов:

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

Сегодня разговаривал со своим коллегой, работающим в одном крупном мобильном операторе. Он сказал, что они проводили исследования и оказалось, что вариант, применяемы у нас, отпугивает пользователей.

Как так? Почему? Оказывается, что пользователи плохо считают проценты. Плохо, в смысле неправильно. Например, при платеже на 1000 руб. и комиссии 2%, пользователь говорил: «Нет, 120 рублей комиссии — это слишком дорого».

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

Что ж, нужно исправляться и делать что-то в таком духе:

Впрочем, возможно, такое оформление для измененной логики не самое лучшее, нужно будет еще подумать и потестировать. Думаю, сделаем комиссию рядом с полем ввода суммы, например так: Сумма [500] руб. + комиссия 10 руб. (2%)

В заключение скажу, что я не отловил эту проблему при юзабилити-тестировании. Дело в том, что пользователи при тестировании платили не свои деньги и не очень большие суммы. А раз так, то им хоть 90% комиссиии напиши — все ладно.

Так что порой получасовое общение с коллегой стоит многих часов исследований.

Активные и субактивные пункты меню

2009-09-24T09:51:00.033+04:00

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

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

В данной статье речь пойдет именно о меню. Т.е. об иерархичной структуре с единственным отношением (один пункт меню — одна страница). Множественные отношения — теги — под данное рассуждение не попадают.

Активный пункт меню

Предположим, что у вас есть сайт с меню из тех пунктов:

Новости Старости Странности

Активный пункт меню должен выделяться. Это поможет пользователю помнить (или понять, если он пришел по ссылке сразу на внутреннюю страницу), в каком именно месте сайта он находится. В нашем примере, когда пользователь щелкнет по пункту «Новости», то меню станет таким:

Новости Старости Странности

Активный пункт претерпел изменения:

Графически выделен — другой цвет фона и полужирное начертание шрифта;
Не залинкован — ссылка убрана, т.к. нет смысла давать ссылку на текущий URL.

Субактивный пункт меню

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

Состояние пункта меню в данном случае я называю субактивным:

Новости Старости Странности

Субактивный пункт сочетает в себе черты активного и пассивного пунктов:

Графически выделен другим цветом фона — это черта активного пункта;
Залинкован и не выделен полоужирным — это черты пассивного пункта.

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

Ошибки в построении меню

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

Но и в данном простом вопросе встречаются ошибки:

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

Где это НЕприменимо

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

Могу припомнить только две ситуации, где данный принцип неприменим:

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

Выводы и картинка

Разработчик, помни, выделение активного и субактивного пунктов меню улучшает навигацию, понижает артериальное давление и улучшает пищеварение!

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

Ах, эти интерфейсы

Жираф большой — это не сразу поймешь!

Дай телефончик подержать

Люди мы небогатые

Мое выступление на РИФ+КИБ 2011

Проектирование интерфейса (для начинающих)

Делайте интерфейсы под пальцы

Быстрая обратная связь очень важна для сайтов, продающих товары или услуги

Кому это будет полезным

Некоторые нюансы

Браузерам нужен новый логотип

Видео с конференции UX Russia 2010

Сколько я смогу заработать на юзабилити?

Немного истории

Повторение истории в веб-индустрии

Так насколько это прибыльно?

User Experience Russia 2010: впечатления

Радуйтесь, когда вас ненавидят

Что случается, когда маркетологи пишут код

С точностью до запятой

Объявление: объявление находится ниже

Большой секрет

Только самое нужное

С места — в карьер

Подпишитесь под договорчиком, пожалуйста

Собственно, всё!

Каков итог?

Ограничивать нельзя позволить

Ликбез (повторяем пройденное в детском саду)

Переходим в старшие классы или горе от ума

Ни цента больше

Понаехали тут

Рекомендации по обработке ошибок в полях формы

Дата вылета на форме бронирования билетов

Вывод

Победа безопасности над разумом

Мой пароль протух и пахнет

А у вас какой длины?

Они все равно сделают по-своему

Что делать?

Снежные интерфейсы простого народа

Хорошая идея — завершенная идея

Назвался груздем — полезай в стандарты

Дублируй, не дублируй — толку мало!

Тварь я в очереди стоящая или карту имею?

Каждому покупателю по персональному кассиру

Модный и проигравший

Погоня за модой в интерфейсах

А какой календарик для блога сделал ты?

1. Олдскул

2. Гугел

3. Сам себе дизайнер

4. Яндекс

5. Ойфанчег

Выводы

Прототипирование на чистовую

Плюсы прототипирования на HTML

Делайте маленькие сервисы

Что делать с раздутым функционалом?

Ну не выбрасывать же!

Должно ли второе поле для загрузки файла появляться автоматически?

Пользователи плохо умеют считать проценты

Активные и субактивные пункты меню

Активный пункт меню

Субактивный пункт меню

Ошибки в построении меню

Где это НЕприменимо

Выводы и картинка