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 рублей.
Что за Х??
а так - тупо рекламный вброс...
Криворучка менеджер. Принял работу не проверив её хотя бы раз.
Группа тестеров, состоящая из 3х человек, которая проводила полное тестирование всего цикла подключения клиента, также не копипастила логин. И тут все еще интереснее.
В системе всегда используются одни и те же тестовые логины и у тестеров они просто запомнились в форме механизмом автозаполнения.
Вот такая получилась череда событий.
Опишу почему сделали именно так а не сделали обработчик стандартно на сабмит формы:
Механизм валидации един в системе.Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.
Чтобы не допускать этого решили мягко намекать пользователю что здесь и сейчас у тебя некорректно написано. Но и это, как мы видим оказалось не самым лучшим решением.
Поэтому сейчас «плохие» убираются на момент появления. Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.