Про ошибки в форматировании при попытке изменить одну из цифр полностью согласен.
Про стирание символов: кстати, как вариант, можно вовсе отказаться от символов (дефисы, скобки) в маске, разделяя все только отступами. Вероятно, это может частично сгладить недопонимание относительно того, сколько раз нужно жать backspace.
Про номер Великобритании: фактически обработку события вставки номера разработчик мог бы предусмотреть: вне зависимости от того, с чего начинается номер в буфере обмена – с нуля или с плюса – логика понимает, что это Великобритания. Загвоздка, конечно же, в том, что во многих странах своя конвенция для внутренних номеров, поэтому задача усложняется. Но все же не превращается в невыполнимую. Как вариант, можно пойти по правилу Парето и настроить обработчик подобных особенностей лишь по ключевым странам, из которых приходит подавляющее большинство пользователей.
Про жесткое +7 – наверное, здесь стоит рассматривать конкретные случаи. Предположу, что иногда это делается из-за географии доставки: если доставка только по РФ, то и номера ограничивают только РФ. Согласен, что в данном случае часть пользователей может ущемляться. Но, вероятно, если так делают, эта доля незначительна.
Да, печаль. Но, стоит заметить, будет уже хорошо, если, как минимум, вашему фидбэку удалось добраться через поддержку / отдел контроля качества до нужного продакта ? Иногда и этого не происходит.
Да, это печальный момент. Иногда продумать все наперед сложно – какая бы крупная компания ни была, какие бы бюджеты не выделялись на research и тестирование, всегда будет вероятность проколов.
И в этом случае важно, насколько компания гибка в плане управления обратной связью и внедрении улучшений. Насколько быстро ваше замечание, если оно валидное, может быть трансформировано в более удобный интерфейс.
Но это уже другая большая история. Как раз сейчас готовлю материал по этой теме.
Привет, спасибо за развернутый комментарий, много интересных мыслей! Да, тема эта важная, многое нужно учитывать. Попробую ответить по пунктам:
Форматирование при вводе – в принципе хорошая практика: реально становится легче проверить, воспринять информацию, но вы правильно упомянули, что есть куча нюансов:
а) общепринятое разбиение номеров в масках по частям в разных странах будет разным (статью я писал только под РФ, поэтому этого блока пока нет – но думаю, стоит расширить в будущем).
б) при корректировке номера юзер не должен стирать пробелы, дефисы, скобки маски вручную.
в) из какой бы среды номер ни копировался, важно обрабатывать то, какие символы вставляются из буфера обмена, чтобы на вход для форматирования шли только численные значения, а не символы форматирования извне.
К выбору кодов стран (с флагами, названиями и т.д.), если честно, у меня очень настороженное отношение:
а) если пользователь вводит номер вручную, скорее всего, он уж помнит код своей страны.
б) если поле промаркировано и пользователь вставляет сохраненное значение из подсказки, выбор кода в принципе не нужен.
в) нередко встречался с тем, то отделение кода страны от номера телефона приводит к тому, что вставка номера обрабатывается некорректно – и это приводит к ошибочному вводу.
Про код в начале SMS – очень хорошее замечание, добавлю! Плюс хорошо было бы маркировать сами поля соответственно, чтобы можно было вставить из авто-подсказки в 1 касание, без необходимости отвлекаться и уходить из браузера / приложения.
Про сроки неактивности согласен, иногда компании перегибают палку в этом плане. Может, на безопасность это и влияет, но еще сильнее [негативно] влияет на UX.
Рад, что оказалось полезно! Всего в таком формате по e-commerce у меня пока что 22 статьи, постепенно переношу их на Habr: все где-то через неделю будут доступны в моем профиле.
Изначально все это доступно у меня на сайте hardclient.com (в частности, в разделе по e-commerce).
Сам контент материалов я собираю для работы последние несколько лет. В апреле этого года дошли руки до того, чтобы оформить все в формате статей, сжато и с примерами. Сейчас в общей сложности по e-commerce готово 24 статьи.
Недавно пообщались командой отдела Habr по работе с пользователями, достигли понимания, что для читателей материалы были бы актуальны. Поэтому постепенно переношу их сюда. Процесс переноса не такой быстрый, как хотелось бы, но надеюсь, что материалы принесут пользу.
У одного магазина может быть тонна жалоб на неудобный интерфейс выбора временного интервала
У другого аналитика может показывать, что большая доля клиентов отваливается на выборе адреса с помощью карты
У третьего конверсия чекаута в мобильной версии сильно ниже, чем в версии для ПК
Соответственно и приоритеты в таких случаях могут быть разными. Какой-то единственно верной расстановки приоритетов нет. Здесь стоит опираться именно на имеющиеся данные систем аналитики и результаты клиентских исследований.
Этот материал лучше не воспринимать, как чек-лист, в котором нужно обязательно поставить все галочки:) Материал выполняет немного другую функцию:
Иногда при проектировании интерфейса дизайнеры/разработчики не обладают достаточной насмотренностью – зачастую просто потому, что не хватает времени на просмотр всех сайтов в индустрии в поисках конкретной фичи/интерфейса.
Из-за этого результат может получиться не оптимальным: интересное исполнение фичи у одного конкурента не заметили, а на грабли, на которые ранее наступил другой конкурент, наступили сами.
Эта и все остальные статьи по e-commerce (их сейчас 24) собраны на основе анализа топ-100 интернет-магазинов по версии DataInsight за последние годы. И их функция – экономить время, познакомить разработчика / дизайнера с разными идеями и решениями, сформировать насмотренность – без необходимости проходить 100+ сайтов в процессе разработке.
В каждом конкретном случае, разумеется, нужно смотреть на дизайн-решение и учитывать только те пункты, которые для него релевантны.
Понимаю. В этом вопросе, к сожалению, всем не угодишь.
Изначально многие просили именно спрятать материалы под спойлер, т.к. 1) «выглядело слишком пёстро» и текст было сложнее читать 2) с мобильного такой объем контента будет грузиться слишком долго.
Если читаете с ПК, могу предложить версию, в которой все открыто:
Рад, что оказалось полезно! Кстати, материалы «живые», я постоянно их дополняю. Поэтому если заметите, что чего-то не хватает, пожалуйста, дайте знать.
Вопрос не тупой, я сам разбирался:)
Для того, чтобы поставить лайк, нужна карма, которую пользователь зарабатывает, создавая контент и оставляя полезные комментарии.
Вот здесь эти механики описаны более подробно.
Для примера, я поставил лайк на ваш комментарий – у вас выросла карма. Насколько помню, когда карма будет больше 5, вы сможете ставить лайки.
Рад слышать! Да, пользовательский опыт – это часто про детали.
День добрый!
Скриншоты и видео скрыты специально – иначе статьи начинают слишком медленно загружаться (особенно на мобильных).
Для более удобного просмотра этой статьи с ПК (с открытыми скриншотами) можно прочитать ее на сайте: https://hardclient.com/ecommerce-search-bar
Все статьи из цикла по e-commerce также доступны по ссылке: https://hardclient.com/ecommerce
Про ошибки в форматировании при попытке изменить одну из цифр полностью согласен.
Про стирание символов: кстати, как вариант, можно вовсе отказаться от символов (дефисы, скобки) в маске, разделяя все только отступами. Вероятно, это может частично сгладить недопонимание относительно того, сколько раз нужно жать backspace.
Про номер Великобритании: фактически обработку события вставки номера разработчик мог бы предусмотреть: вне зависимости от того, с чего начинается номер в буфере обмена – с нуля или с плюса – логика понимает, что это Великобритания. Загвоздка, конечно же, в том, что во многих странах своя конвенция для внутренних номеров, поэтому задача усложняется. Но все же не превращается в невыполнимую. Как вариант, можно пойти по правилу Парето и настроить обработчик подобных особенностей лишь по ключевым странам, из которых приходит подавляющее большинство пользователей.
Про жесткое +7 – наверное, здесь стоит рассматривать конкретные случаи. Предположу, что иногда это делается из-за географии доставки: если доставка только по РФ, то и номера ограничивают только РФ. Согласен, что в данном случае часть пользователей может ущемляться. Но, вероятно, если так делают, эта доля незначительна.
Да, печаль. Но, стоит заметить, будет уже хорошо, если, как минимум, вашему фидбэку удалось добраться через поддержку / отдел контроля качества до нужного продакта ? Иногда и этого не происходит.
Да, это печальный момент. Иногда продумать все наперед сложно – какая бы крупная компания ни была, какие бы бюджеты не выделялись на research и тестирование, всегда будет вероятность проколов.
И в этом случае важно, насколько компания гибка в плане управления обратной связью и внедрении улучшений. Насколько быстро ваше замечание, если оно валидное, может быть трансформировано в более удобный интерфейс.
Но это уже другая большая история. Как раз сейчас готовлю материал по этой теме.
Привет, спасибо за развернутый комментарий, много интересных мыслей! Да, тема эта важная, многое нужно учитывать. Попробую ответить по пунктам:
Форматирование при вводе – в принципе хорошая практика: реально становится легче проверить, воспринять информацию, но вы правильно упомянули, что есть куча нюансов:
а) общепринятое разбиение номеров в масках по частям в разных странах будет разным (статью я писал только под РФ, поэтому этого блока пока нет – но думаю, стоит расширить в будущем).
б) при корректировке номера юзер не должен стирать пробелы, дефисы, скобки маски вручную.
в) из какой бы среды номер ни копировался, важно обрабатывать то, какие символы вставляются из буфера обмена, чтобы на вход для форматирования шли только численные значения, а не символы форматирования извне.
К выбору кодов стран (с флагами, названиями и т.д.), если честно, у меня очень настороженное отношение:
а) если пользователь вводит номер вручную, скорее всего, он уж помнит код своей страны.
б) если поле промаркировано и пользователь вставляет сохраненное значение из подсказки, выбор кода в принципе не нужен.
в) нередко встречался с тем, то отделение кода страны от номера телефона приводит к тому, что вставка номера обрабатывается некорректно – и это приводит к ошибочному вводу.
Про код в начале SMS – очень хорошее замечание, добавлю! Плюс хорошо было бы маркировать сами поля соответственно, чтобы можно было вставить из авто-подсказки в 1 касание, без необходимости отвлекаться и уходить из браузера / приложения.
Про сроки неактивности согласен, иногда компании перегибают палку в этом плане. Может, на безопасность это и влияет, но еще сильнее [негативно] влияет на UX.
Рад, что оказалось полезно! Всего в таком формате по e-commerce у меня пока что 22 статьи, постепенно переношу их на Habr: все где-то через неделю будут доступны в моем профиле.
Изначально все это доступно у меня на сайте hardclient.com (в частности, в разделе по e-commerce).
Сам контент материалов я собираю для работы последние несколько лет. В апреле этого года дошли руки до того, чтобы оформить все в формате статей, сжато и с примерами. Сейчас в общей сложности по e-commerce готово 24 статьи.
Недавно пообщались командой отдела Habr по работе с пользователями, достигли понимания, что для читателей материалы были бы актуальны. Поэтому постепенно переношу их сюда. Процесс переноса не такой быстрый, как хотелось бы, но надеюсь, что материалы принесут пользу.
Да, плюс во всех случаях, когда листинг отображается лишь частично, нам все равно необходимо будет обращаться к серверу, чтобы получить товары.
Ну, как минимум, важно, чтобы сам запрос к серверу обрабатывался эффективно.
Алена, привет! Рад, что полезно!
Каждый конкретный случай уникален:
У одного магазина может быть тонна жалоб на неудобный интерфейс выбора временного интервала
У другого аналитика может показывать, что большая доля клиентов отваливается на выборе адреса с помощью карты
У третьего конверсия чекаута в мобильной версии сильно ниже, чем в версии для ПК
Соответственно и приоритеты в таких случаях могут быть разными. Какой-то единственно верной расстановки приоритетов нет. Здесь стоит опираться именно на имеющиеся данные систем аналитики и результаты клиентских исследований.
Антон, день добрый! Рад, что оказалось полезно!
Этот материал лучше не воспринимать, как чек-лист, в котором нужно обязательно поставить все галочки:) Материал выполняет немного другую функцию:
Иногда при проектировании интерфейса дизайнеры/разработчики не обладают достаточной насмотренностью – зачастую просто потому, что не хватает времени на просмотр всех сайтов в индустрии в поисках конкретной фичи/интерфейса.
Из-за этого результат может получиться не оптимальным: интересное исполнение фичи у одного конкурента не заметили, а на грабли, на которые ранее наступил другой конкурент, наступили сами.
Эта и все остальные статьи по e-commerce (их сейчас 24) собраны на основе анализа топ-100 интернет-магазинов по версии DataInsight за последние годы. И их функция – экономить время, познакомить разработчика / дизайнера с разными идеями и решениями, сформировать насмотренность – без необходимости проходить 100+ сайтов в процессе разработке.
В каждом конкретном случае, разумеется, нужно смотреть на дизайн-решение и учитывать только те пункты, которые для него релевантны.
Понимаю. В этом вопросе, к сожалению, всем не угодишь.
Изначально многие просили именно спрятать материалы под спойлер, т.к. 1) «выглядело слишком пёстро» и текст было сложнее читать 2) с мобильного такой объем контента будет грузиться слишком долго.
Если читаете с ПК, могу предложить версию, в которой все открыто:
https://hardclient.com/ecommerce-checkout-address-and-time
Все 24 статьи по e-com'у без спойлеров доступны вот тут:
https://hardclient.com/ecommerce
Кстати, как считаете, есть какие-либо минусы у варианта, когда сортировка производится именно на фронте?
Спасибо за ценное дополнение! Добавил
Рад, что оказалось полезно! Кстати, материалы «живые», я постоянно их дополняю. Поэтому если заметите, что чего-то не хватает, пожалуйста, дайте знать.
Рад, что полезно!
Возможно, это у Яндекс.Маркета был один из тестов. Статью писал несколько месяцев назад, сейчас зашел посмотреть – функционал этот убрали.
Про допродажу на уровне чекаута обстоятельно пока еще не писал, но вкратце касался этой темы в статье по корзине.
Welcome!
Хорошая идея, спасибо, в следующих статьях буду включать + дополню эту статью, если найду моменты, которые не вписываются в текущую модель оценки.
Добавил, спасибо за предложение! Скорректирую и во всех остальных статьях.