Фильтры на страницах товарных каталогов

Идея фильтровать список товаров по признакам на странице сайта стара как мир. Но тем не менее в реализации существуют свои тонкости. Из личного опыта могу поделиться следующим:
1. Изначально необходимо указывать, сколько представлено товаров на странице. При наложении фильтра надо указать, сколько получилось в выборке, и опять же, сколько было изначально, т.е. например “57 товаров из 95”. Так пользователь чувствует себя увереннее. Цифры дают ему чувство контроля ситуации.
2. Фильтр здорово делать на асинхронной технологии (AJAX), чтобы при его запуске перегружался только товарный список, а не вся страница. Ведь мы же движемся от веб-сайтов к веб-приложениям!
3. Несмотря на п.2 пользователю нужно дать возможность оперировать прямой ссылкой на страницу с отфильтрованными товарами (например, отправить по ICQ, почте или сохранить в закладки). Следовательно рядом с формой фильтра необходимо разместить окошко с прямым адресом, в котором текущее состояние фильтра зашито в параметры GET.
Впервые я эту функциональность увидел на сайтах карт. Можно сколько угодно елозить по местности, а потом получить прямую ссылку на нужный фрагмент.
4. По возможности надо избегать заставлять пользователя вводить что-либо вручную с клавиатуры. Мышки должно быть достаточно для всего. Сейчас возможности JavaScript позволяют очень элегантно, при помощи различных ползунков (удачная параллель с офлайновой жизнью) решать эту задачу.
5. Отчасти перекликаясь с п.4.. При наличии непрерывного параметра (где как раз полезны ползунки :) ), изменяющегося в некоем диапазоне, всегда полезно дать пользователю понять границы этого диапазона. Например, Цена - от 100 до 300 руб, Длина - от 100 до 500 мм.  Знание минимума и максимума также дает пользователю больше чувства контроля над ситуацией.
6. При наличии дискретного списка значений параметров, особенно если он длиннее 5-6 пунктов, полезно упорядочить этот список по понятному пользователю правилу. Например, по алфавиту.
7. Когда выбор по некоторым товарным признакам уже сделан, полезно (опять же пользуясь AJAX’ом) в блоках остальных признаков деактивировать (и закрасить, например, серым цветом) те опции, выбор которых обеспечил бы пустую выборку, т.е. не имеет смысла.
К примеру у нас ассортимент состоит из грузовиков и малолитражек. Если пользователь уже выбрал объем двигателя менее 1 литра, то очевидно опцию “грузовик” в блоке фильтра “Тип автомобиля” можно деактивировать.
8. Аналогичное замечание верно для диапазонных параметров. В процессе заполнения фильтра следует сужать изначальный диапазон до тех границ, которые еще имеют смысл.
9. “Логическая” тонкость. Если по параметру не отмечена ни одна опция, то фильтрация по нему не производится. Стало быть, это равнозначно ситуации, когда отмечены ВСЕ опции, т.е. включаем в выборку все разновидности по данному параметру.

Рецензия на книгу "Тотальная видимость" Питера Морвиля

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

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

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

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

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

Чем эта книга полезна для бизнеса? Якоб Нильсен, главный по юзабилити на нашей планете, считает, что "Маркетинг, ориентированный на поисковые механизмы, заслуженно считается самым актуальным вопросом в интернет-бизнесе. [...] Эта книга позволит вам развивать бизнес в интернете в условиях, когда клиентам найти вас не так-то просто."

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

Книга "Тотальная видимость" на сайте издательства Символ-Плюс

Автоматизация сбора отзывов о товарах от покупателей

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

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

Работать все это будет далеко не в 100% случаев. Большинство покупателей, к сожалению игнорирует такие просьбы. Но, как показывает практика, около 10% откликаются и пишут рецензии, что уже очень неплохо! :)

Решение задачи более компактного представления товаров в каталоге на интернет-сайте

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

Пример: Кронштейны (для полки) разной длины и цвета. Если варианты по длинам: 100 мм, 200 мм, 300 мм, по цветам: белый и синий. Признак “материал” у всех одинаковый - сталь.

Решение: вводим понятие Типа товаров. Тип - это объединение нескольких товаров, схожих во всем, за исключением одного или нескольких признаков. При создании типа указываем, на основе какого признака (признаков) в него будут объединяться товары. Далее такие признаки будем называть вариативными. Остальные признаки для всех товаров внутри типа должны совпадать, их будем называть статическими.

Пример: Вводим тип “Кронштейн”. Объединяем в него все наши кронштейны. Вариативными параметрами будут “длина” и “цвет”. А “материал” будет статическим - он для всех товаров в типе одинаков.

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

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

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

Пример: Поскольку у нашего типа “Кронштейн” набор признаков ортогональный, то проектируя интерфейс интернет-магазина, мы можем дать пользователю независимый выбор длины кронштейна и его цвета (можно использовать radio-button отдельно по цвету и по длине). Если же набор не ортогонален, то необходимо реализовывать общий выбор по всем парам (тройкам и т.д.) значений (белый, 100 мм), (белый, 200 мм)... и т.д.

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

Стоимость оптимизации в системах веб-аналитики

Эх, досадно, что Google Analytics и Яндекс.Метрика не позволяют вбивать и учитывать стоимость продвижения по ключевым словам.
А то ведь как было бы удобно! Вбил по слову стоимость продвижения за месяц, дальше трафик - конверсия - заказы - деньги. То же самое смотрим по контексту на это же слово. И вот она, заветная информация на блюдечке. :) Сразу понятно, что лучше работает, контекст или оптимизация.

Метрика для юзабилити

В связи с появлением Веб-визора возникла идея о еще одной метрике юзабилити - пробег мышки (может уже кто-то считает?).
Можно посчитать итого за сессию (по всем и с достижением цели). Можно посчитать в среднем на страницу (хотя менее информативно).
Ход мыслей таков. Принято минимизировать число кликов на пути пользователя к цели. Но на мой взгляд скролл и елозанье мышью гораздо утомительнее, чем клики. Особенно если стол завален барахлом, что бывает нередко :), и мышке разбежаться негде.
Поэтому лучше добавить в интерфейс 2-3 клика, но уменьшить при этом мышиный пробег.
Кстати скролл тоже надо считать как пробег мыши. Только мышка стоит, а “земля” под ней бежит :).

“Зеленые” прайс-листы

Бывает, что необходимо предупредить партнеров и клиентов о повышении цен или изменениях ассортимента заранее, скажем, за неделю. Старые цены должны еще висеть на сайте и в прайсе. Но новый прайс-лист с датой выпуска через неделю и новыми ценами должен быть разослан уже сейчас.
Еще ситуация - ввод новых товаров, которые поступят на склад через некоторое время. Но надо предварительно о них оповестить.
Для решения вводим понятие “зеленого” прайс-листа, в котором изменения цен и новые позиции подсвечиваются зеленым цветом. Он предназначен, как правило, для внутренней рассылки и сообщает о будущих нововведениях.
Хитрость создания “зеленого” прайс-листа заключается в том, что существующему товару, которые претерпевает изменения, мы ставим в специальное поле знак “Update”. Аналогично совсем новой позиции ставим знак “Insert”.
Делается это для того, чтобы при наступлении указанной даты запуска изменений мы нажатием всего лишь одной кнопки переносим “зеленые” цены в обычные, а новые позиции разрешаем опубликовать на сайте.
Также автоматически генерируется новый “боевой” прайс-лист и цепляется на соответствующую страницу сайта для скачивания.

Сопутствующая информация в форме обратной связи

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

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

“Связанные” изделия

Когда мы презентуем товарный каталог на сайте, бывает трудно выстроить строгую логическую иерархию в виде дерева. Один и тот же товар часть пользователей ищет в одной подгруппе, другая часть - в другой. Можно конечно пенять им на “отсутствие логики”. Но они, не найдя нужного, сами будут нам пенять на то же самое. Чтобы такой конфликт не сказался на продажах, предлагается подстроиться под пользователя и ввести механизм “связанных” изделий.
Заключается он в следующем.
Товар сидит как “родной” только в одной подгруппе. Но в качестве “гостя” может быть привязан к любой другой подгруппе. Пользователь видит его там наравне с “родными” товарами.
В чужую подгруппу товар переносит все свои свойства за исключением сортировки, которую в чужой подгруппе необходимо назначить товару отдельно.
Почему требуется изначально строгое дерево и принадлежность товара к одной подгруппе, как “родного”? Для внутренних нужд поддержки и редактирования товарной базы. Администратор всегда должен знать, где что у него хранится, и куда залезть, чтобы поправить. Если редактировать базу через табличный экспорт-импорт, то для работы с конкретным товаром требуется выгрузка именно его “родной” подгруппы.
В противном случае, если мы имеем независимую привязку на множестве товаров к множеству подгрупп, придется лопатить всю товарную базу для поиска нужной позиции.