1000
1
Произошла курьезная и очень болезненная ситуация одновременно.
У нас много зарегистрированных клиентов и много из них тех, кто ни разу не входил в систему.
Писать клиентам по таким вопросами бесполезно — мало кто из обиженных клиентов ответит почему он обиделся.
Поэтому мы не поленились и начали тупо всем звонить и спрашивать, почему, мол, так и не зашли?
Ответ был почти у всех одинаковый:
-Мы не смогли ввести логин пароль.
Результат расследования отправил всех в глубоких шок.
Чтобы понять причину этого, мы нашли лояльных клиентов из числа тех, кто ни разу не смог войти, и до последних мельчайших деталей воспроизвели всю последовательность событий.
Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.
Логин и пароль на доступ в систему приходил электронным письмом. Люди копипастили логин из письма и вместе с ним копировался лишний пробел на конце!
Т.е. если в поле логина есть пробел, система не выпускает фокус и
в итоге люди не могли даже начать вводить пароль.
Проблеме этой было примерно 3-4 месяца. На вскидку, из-за того что примерно 120-150 человек из тех кто хотел платить деньги за сервис просто не смогли зайти и жестко обиделись, этот пробел нам стоил примерно 500 т.р. Плюс минус 90 т.р.
Проблемы было две:
1. в шаблоне почтового уведомления после логина стоял лишний пробел:
<td align="right"> Логин для входа: </td> <td class="value">%3$s </td>
Проблемное место вот здесь"%3$s "
Решили просто правкой шаблона. Теперь лишних пробелов при копипасте нет.
2. В форме авторизации не было обработки на ввод строки с некорректными символом
Тут для решения проблемы решили сделать так: Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать. К моменту проверки корректности самого логина(а в качестве логина используется e-mail) мы имеем полностью очищенную строку. А задача валидартора уже дать оценку похоже это на email и есть ли он в нашей базе.
Т.е получается так что сначала строка нормализуется а только потом валидируется. Этот подход решено было внедрить везде. Валидаторы всех форм и полей ввода были снабжены функциями предварительной нормализации, в зависимости от типа данных конечно.
Все члены команды разработки на mm24.com занимаются вебом не менее 10 лет. И тем глупее мы выглядели в своих же глазах.
Ситуация никогда не проявилась бы, если в шаблоне уведомления не было лишнего пробела. Или в форме авторизации было предусмотрено более информативное сообщение, которое точно показывало на причину сообщения об ошибке.
Возможно наш печальный пример кому-то окажется полезным.
У нас много зарегистрированных клиентов и много из них тех, кто ни разу не входил в систему.
Писать клиентам по таким вопросами бесполезно — мало кто из обиженных клиентов ответит почему он обиделся.
Поэтому мы не поленились и начали тупо всем звонить и спрашивать, почему, мол, так и не зашли?
Ответ был почти у всех одинаковый:
-Мы не смогли ввести логин пароль.
Результат расследования отправил всех в глубоких шок.
Чтобы понять причину этого, мы нашли лояльных клиентов из числа тех, кто ни разу не смог войти, и до последних мельчайших деталей воспроизвели всю последовательность событий.
Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.
Логин и пароль на доступ в систему приходил электронным письмом. Люди копипастили логин из письма и вместе с ним копировался лишний пробел на конце!
Т.е. если в поле логина есть пробел, система не выпускает фокус и
в итоге люди не могли даже начать вводить пароль.
Проблеме этой было примерно 3-4 месяца. На вскидку, из-за того что примерно 120-150 человек из тех кто хотел платить деньги за сервис просто не смогли зайти и жестко обиделись, этот пробел нам стоил примерно 500 т.р. Плюс минус 90 т.р.
Проблемы было две:
1. в шаблоне почтового уведомления после логина стоял лишний пробел:
<td align="right"> Логин для входа: </td> <td class="value">%3$s </td>
Проблемное место вот здесь"%3$s "
Решили просто правкой шаблона. Теперь лишних пробелов при копипасте нет.
2. В форме авторизации не было обработки на ввод строки с некорректными символом
Тут для решения проблемы решили сделать так: Перед валидацией, сначала делаем trim, потом регуляркой вычищаем все что может помешать. К моменту проверки корректности самого логина(а в качестве логина используется e-mail) мы имеем полностью очищенную строку. А задача валидартора уже дать оценку похоже это на email и есть ли он в нашей базе.
Т.е получается так что сначала строка нормализуется а только потом валидируется. Этот подход решено было внедрить везде. Валидаторы всех форм и полей ввода были снабжены функциями предварительной нормализации, в зависимости от типа данных конечно.
Все члены команды разработки на mm24.com занимаются вебом не менее 10 лет. И тем глупее мы выглядели в своих же глазах.
Ситуация никогда не проявилась бы, если в шаблоне уведомления не было лишнего пробела. Или в форме авторизации было предусмотрено более информативное сообщение, которое точно показывало на причину сообщения об ошибке.
Возможно наш печальный пример кому-то окажется полезным.
реклама
Готов был отдать от 3333 до 4166 рублей.
Что за Х??
а так - тупо рекламный вброс...
Криворучка менеджер. Принял работу не проверив её хотя бы раз.
Опишу почему сделали именно так а не сделали обработчик стандартно на сабмит формы:
Механизм валидации един в системе.Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.
Чтобы не допускать этого решили мягко намекать пользователю что здесь и сейчас у тебя некорректно написано. Но и это, как мы видим оказалось не самым лучшим решением.
Поэтому сейчас «плохие» убираются на момент появления. Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.