Pull to refresh

Comments 12

Изначально все это доступно у меня на сайте hardclient.com (в частности, в разделе по e-commerce).

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

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

Рад, что оказалось полезно! Всего в таком формате по e-commerce у меня пока что 22 статьи, постепенно переношу их на Habr: все где-то через неделю будут доступны в моем профиле.

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

Пожалуйста, если уж ограничиваете ввод по количеству цифр, будьте на 142% уверены, что учли все варианты во всех странах.

Выбор кода страны в виде списка (еще и с флагами, красота - можно подучить как выглядят флаги всех стран) - сортирует его кто как вздумает, и по коду (а там разное количество цифр и идет +3, +4, ... +33, +5) и в алфавитном порядке названия страны (а че, удобно ж, но это пока не вводишь номер Великобритании/Англии/Соединенного (или даже Объединенного!) Королевства :] ), а то и вовсе названия стран на русском, а сортировка по ISO2 кодам где-то внутри.

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

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

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

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

Форматирование при вводе – в принципе хорошая практика: реально становится легче проверить, воспринять информацию, но вы правильно упомянули, что есть куча нюансов: 

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

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

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

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

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

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

в) нередко встречался с тем, то отделение кода страны от номера телефона приводит к тому, что вставка номера обрабатывается некорректно – и это приводит к ошибочному вводу. 

Про код в начале SMS – очень хорошее замечание, добавлю! Плюс хорошо было бы маркировать сами поля соответственно, чтобы можно было вставить из авто-подсказки в 1 касание, без необходимости отвлекаться и уходить из браузера / приложения.

Про сроки неактивности согласен, иногда компании перегибают палку в этом плане. Может, на безопасность это и влияет, но еще сильнее [негативно] влияет на UX.

Поле ввода номера телефона не должно по своему поведению отличаться от обычного текстового, ну ладно, числового, поля. Ведь нет (пока) общепринятого поведения и мои ожидания сильно отличаются от фантазий разработчика. Глядя на поле (с пробелами, дефисами) я хочу точно знать сколько раз нажать backspace, чтобы стереть часть номера. А поле нажимает его за меня. Еще бесит, когда ошибся в одной цифре посередине, тыкаешь мышкой, backspace и... номер быстренько переформатируется по загадочному алгоритму, потому, что он стал без этой цифры похож на номер Тувалу и разработчик услужливо переключил и страну и номер отформатировал. Или возьмем Великобританию. Внутри страны принято номера указывать с нулём вначале, а "снаружи" с +44. Как вы помните, номер я копирую. Для этих целей у меня в Контактах для себя указано 3 варианта одного номера - с кодом страны, с нулем и... без нуля, когда код страны в виде выпадающего списка флагов. Про такую роскошь как автозаполнение в браузере я давно забыл - там можно ввести только один вариант телефон (ну у человека ж не может быть второго номера, да?)

статью я писал только под РФ

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

Про ошибки в форматировании при попытке изменить одну из цифр полностью согласен. 

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

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

Про жесткое +7 – наверное, здесь стоит рассматривать конкретные случаи. Предположу, что иногда это делается из-за географии доставки: если доставка только по РФ, то и номера ограничивают только РФ. Согласен, что в данном случае часть пользователей может ущемляться. Но, вероятно, если так делают, эта доля незначительна.

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

Да, это печальный момент. Иногда продумать все наперед сложно – какая бы крупная компания ни была, какие бы бюджеты не выделялись на research и тестирование, всегда будет вероятность проколов.

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

Но это уже другая большая история. Как раз сейчас готовлю материал по этой теме.

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

Да, печаль. Но, стоит заметить, будет уже хорошо, если, как минимум, вашему фидбэку удалось добраться через поддержку / отдел контроля качества до нужного продакта 😊 Иногда и этого не происходит.

Sign up to leave a comment.

Articles