24
12 лет назад · 1 фото · 1000 просмотров · 13 комментариев
Сколько может стоить один лишний пробел?
Метки: #HTML #вебразработка #вебформы
Произошла курьезная и очень болезненная ситуация одновременно.
У нас много зарегистрированных клиентов и много из них тех, кто ни разу не входил в систему.
Писать клиентам по таким вопросами бесполезно — мало кто из обиженных клиентов ответит почему он обиделся.
Поэтому мы не поленились и начали тупо всем звонить и спрашивать, почему, мол, так и не зашли?
Ответ был почти у всех одинаковый:
-Мы не смогли ввести логин пароль.
Результат расследования отправил всех в глубоких шок.
Чтобы понять причину этого, мы нашли лояльных клиентов из числа тех, кто ни разу не смог войти, и до последних мельчайших деталей воспроизвели всю последовательность событий.
Форма авторизации настроена так, что если пользователь вводит неправильный символ в поле «логин», система выдает об этом сообщение и не дает пользователю покинуть это поле пока не будет исправлена ошибка. По этой логике пользователь всегда понимает какой именно символ был введен неправильно.
Логин и пароль на доступ в систему приходил электронным письмом. Люди копипастили логин из письма и вместе с ним копировался лишний пробел на конце!
Т.е. если в поле логина есть пробел, система не выпускает фокус и
в итоге люди не могли даже начать вводить пароль.
Проблеме этой было примерно 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 лет. И тем глупее мы выглядели в своих же глазах.
Ситуация никогда не проявилась бы, если в шаблоне уведомления не было лишнего пробела. Или в форме авторизации было предусмотрено более информативное сообщение, которое точно показывало на причину сообщения об ошибке.
Возможно наш печальный пример кому-то окажется полезным.
Метки: #HTML #вебразработка #вебформы
Попробовал зайти на мм24.ком.
Готов был отдать от 3333 до 4166 рублей.
Что за Х??
если бы не упоминание названия организации... было бы просто неинтересно.
а так - тупо рекламный вброс...
Криворучка программист. Не проверил себя и сдал работу.
Криворучка менеджер. Принял работу не проверив её хотя бы раз.
Я налетал на такие пробелы, начинаешь проверять почему копи паст не работает, пробел закрался.
будь проще и люди к тебе потянутся! ;)
Конечно, с фокусом вы намудрили, но неужели никто не заметил, что копирует лишний символ?
Вариант копипаста из письма не тестировался. Фокус группа состоящая из 10 клиентов, получала реквизиты доступа иным способом.
Группа тестеров, состоящая из 3х человек, которая проводила полное тестирование всего цикла подключения клиента, также не копипастила логин. И тут все еще интереснее.
В системе всегда используются одни и те же тестовые логины и у тестеров они просто запомнились в форме механизмом автозаполнения.
Вот такая получилась череда событий.
Ну тупость юзеров недооценивать нельзя. НО КТО ДОГАДАЛСЯ ФОКУС НЕ ВЫПУСКАТЬ?????
Согласен, не всегда это это оправдано. Как я писал выше, если пользователь вводит посимвольно, то при вводе неправильного символа система матерится и нагло принуждает пользователя исправить ошибку. И такой подход совсем не работает когда ввод идет строки целиком.
Опишу почему сделали именно так а не сделали обработчик стандартно на сабмит формы:
Механизм валидации един в системе.Некоторые формы содержат порядка 40 полей ввода. И когда пользователь допускал ошибки хотя бы в 10(а это сплошь и рядом), он видел целый веер хинтов с предупреждениями. Это его пугало.
Чтобы не допускать этого решили мягко намекать пользователю что здесь и сейчас у тебя некорректно написано. Но и это, как мы видим оказалось не самым лучшим решением.
Поэтому сейчас «плохие» убираются на момент появления. Допустим если в поле для емейла пишем символы! и № они сразу убираются и пользователю показывается ая-яй.
С точки зрения юзабилити ничего убирать не надо, а при ошибочном вводе все данные оставляем в форме, затирая только пароли.
Согласен, перемудрили
А никто и не проверял )))