Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 82
Спасибо за статью.
а еще можно показывать подсказки только когда человек вводит что-то плохо (это больше к валидации ввода относится)
ибо если под каждым полем написано "сюда бувы", а "сюда телефон в таком формате", а "сюда не меньше 8 символов" то в глазах начинает рябить имхо
ибо если под каждым полем написано "сюда бувы", а "сюда телефон в таком формате", а "сюда не меньше 8 символов" то в глазах начинает рябить имхо
Как по мне, так самый удобный вариант предложил Ярослав Бирзул:
Выводить подсказку по конкретному полю в тот момент, когда пользователь его заполняет.
Выводить подсказку по конкретному полю в тот момент, когда пользователь его заполняет.
Спасибо. Хорошая статья.
Мне как пользователю особенно близка проблема с этими самыми «неуверенными ошибками».
Мне как пользователю особенно близка проблема с этими самыми «неуверенными ошибками».
Прекрасная статья!
В примере с неуверенными ошибками не во всём с вами согласен: на мой взгляд, система авторизации не должна давать пользователю знать, логин ли неправильный или пароль. Это даёт возможность неавторизованным пользователям перебирать логины.
В примере с неуверенными ошибками не во всём с вами согласен: на мой взгляд, система авторизации не должна давать пользователю знать, логин ли неправильный или пароль. Это даёт возможность неавторизованным пользователям перебирать логины.
Правильное замечание насчёт авторизации.
Система аутентификации :)
По сабжу согласен, не удобно, но так делают именно для безопастности.
По сабжу согласен, не удобно, но так делают именно для безопастности.
а что можно сделать знав только логин? в чем опасность?
Выше вероятность (ниже сложность) подбора допустимой комбинации "логин-пароль", т.к. одна часть этой комбинации уже известна.
Это не что-то, что заведомо "можно сделать", это просто вопрос трудоемкости подбора, повышая удобство мы снижаем безопасность.
Поэтому, обычно в операционные системы в таких ситуациях пишут именно "неверная комбинация логина и пароля" или "логин, либо пароль не верен" и т.п.
Это зафиксировано в каких-то стандартах по уровням защищенности компьютерных систем, но где именно я не помню...
Это не что-то, что заведомо "можно сделать", это просто вопрос трудоемкости подбора, повышая удобство мы снижаем безопасность.
Поэтому, обычно в операционные системы в таких ситуациях пишут именно "неверная комбинация логина и пароля" или "логин, либо пароль не верен" и т.п.
Это зафиксировано в каких-то стандартах по уровням защищенности компьютерных систем, но где именно я не помню...
в принципе ясно, но в любом случае имхо это не такая уж "дыра", чтобы жертвовать удобностью интерфейса.
Это дыра просто зияющая, и любой аудитор за неё даст рейтинг F. Сайту, который позволяет перебирать логины таким образом, я бы ни за что денег (е-трейдер?) не доверил.
Но а если не давать пользователям иметь пароль менее 6-ти символов, то в любом случае подбирать пароль будет долго.
Очень многие сайты имеют открытые списки пользователей, большинство отображают логины рядом с сообщениями (Вы ведь в поле логина вводите «bubuq», не так ли?:)). В первом случае так пропарсить список пользователей куда проще, чем перебирать. В чём опасность знания, что в системе есть такой логин (разумеется, нельзя показывать сообщение, что пароль найден, а логин неверен, речь не об этом)?
Я вообще ужасное скажу — в поле логина я ввожу bubuq, и в поле пароля ввожу пароль, несмотря на HTTP-соединение без шифрования! А если бы это предложил сделать банк, я бы в лучшем случае бежал бы подальше, а в худшем проинформировал бы Государственную Инспекцию Данных, и Банк Латвии.
Есть некоторая разница между социальным порталом, и финансовой институцией. Во втором случае риск выражается в деньгах, возможно в сотнях тысяч и миллионах денег. Кроме того, банки и брокерские конторы подвержены всевозможным государственным регуляциям, которые насаждают им стандарты безопасности, так что в общем случае, это и не их выбор, выдавать ли логин.
Есть некоторая разница между социальным порталом, и финансовой институцией. Во втором случае риск выражается в деньгах, возможно в сотнях тысяч и миллионах денег. Кроме того, банки и брокерские конторы подвержены всевозможным государственным регуляциям, которые насаждают им стандарты безопасности, так что в общем случае, это и не их выбор, выдавать ли логин.
На таких сайтах ценность кражи логина очень мала, обычно это форумы. А вот в других случаях — нет. И подобрав логин, можно продолжать подбирать пароли по словарю, например.
Это, кстати, тоже не правильно. Логин не должен быть ником в общем случае. Также, как он не должен быть адресом e-mail, но где-то на это закрывают глаза... все ради удобства.
И в плане производительности БД кстати тоже удобней так :)
тоже полностью согласен с тем, что нехорошо сообщать что именно неверно — логин или пароль, а вот не стирать поле логина вполне логично.
Логины многих сайтов можно собрать и без формы авторизации. Я считаю, что лучше подсказать пользователю, что логин вводится с ошибкой, а не заставлять его лихорадочно перебирать пароли. ;) От перебора лучше защищаться задержками.
Хы, если в логине ошибка надо написать: "У вас неправильно набран логин, а пароль правильный" )
Почему бы просто не ограничить количество неправильных вводов пароля/логина на правильный логин/пароль?.. Хотя бы на время, например — сутки. Подбирать в таких темпах долго надо будет.
Те, кто подбирают, обычно имеют ботнеты в тысячи, десятки тысяч машин. Они временные задержки и не заметят.
Вопрос идет о соотношении удобство/безопасность. И неизвстно что более оптимально
- данные о неверном логине и пароле + мягкой политикой в отношении таймаутов на перебор
или
- отдельная инфа по ненайденному логину + жесткие ограничения на неудачные попытки авторизации.
- данные о неверном логине и пароле + мягкой политикой в отношении таймаутов на перебор
или
- отдельная инфа по ненайденному логину + жесткие ограничения на неудачные попытки авторизации.
Еще лучше, когда ник не является логином. То есть при регистрации пользователь вводит логин и ник, который отображается на сайте. Можно заставить его сделать, чтобы не совпадали между собой.
Типографика! ;)
Путеводитель Часть 1.
Вступление — Часть 2.
Языковой барьер — Часть 3.
Ошибки в формах — Часть 4.
Ошибки на сервере — Часть 5.
Рука помощи
А статья интересная и полезная, спасибо.
Не согласен с примером "неуверенные ошибки".
Дело в том, что ты несколько неправильно понимаешь процесс аутентификации.
С точки зрения компьютера, нет такого понятия, как пара "правильный логин"-"пароль с опечаткой". Для него ничего не значит логин сам по себе, даже если он и есть в системе.
Только верная пара логин-пароль является ключом входа, и никак иначе. Все остальные сочетания - это попытка взлома системы. Именно поэтому и существует такая формулировка: "неправильный логин или пароль", чтобы не дать злоумышленнику дополнительную информацию о системе защиты.
Пускай неизвестный хакер и дальше перебирает логины с паролями, по реакции системы он никак не должен узнать, насколько он близок к цели, подобрал ли он правильный логин.
Если же система будет отдавать: правильный логин, вот только пароль какой-то не такой, то злоумышленнику останется только перебрать брутфорсом все пароли и получить доступ к системе.
Не согласен с примером "неуверенные ошибки".
Дело в том, что ты несколько неправильно понимаешь процесс аутентификации.
С точки зрения компьютера, нет такого понятия, как пара "правильный логин"-"пароль с опечаткой". Для него ничего не значит логин сам по себе, даже если он и есть в системе.
Только верная пара логин-пароль является ключом входа, и никак иначе. Все остальные сочетания - это попытка взлома системы. Именно поэтому и существует такая формулировка: "неправильный логин или пароль", чтобы не дать злоумышленнику дополнительную информацию о системе защиты.
Пускай неизвестный хакер и дальше перебирает логины с паролями, по реакции системы он никак не должен узнать, насколько он близок к цели, подобрал ли он правильный логин.
Если же система будет отдавать: правильный логин, вот только пароль какой-то не такой, то злоумышленнику останется только перебрать брутфорсом все пароли и получить доступ к системе.
Ничто не мешает сохранять в поле логина даже неверный логин.
спасибо за инфу. не подумал:-)
С точки зрения Хабра и многих других сайтов, логин — общедоступная информация.
С точки зрения http://etrade.com/ , показанного в примере, нет.
Мы ведь именно о примере говорим, нет?
Мы ведь именно о примере говорим, нет?
Вообще-то, вы начали с того, что автор топика несколько не правильно понимает процесс аутентификации, потом перешли на объяснение этого процесса с точки зрения компьютера. Но мы об авторизации на сайтах говорим, а не в ОС. А сайты бывают разные. На Хабрахабре логин — общедоступная информация.
Хорошо.
Тогда подведем итог:
После ввода пользователем неверной комбинации "логин/пароль" необходимо очистить поле пароля и оставить поле логина то содержимое, что ввел пользователь.
При этом, если логин является общедоступной информацией, надо вывести ошибку "неправильный пароль", а в случае, когда сайт не распространяет логины своих пользователей, выводить "неправильный логин или пароль".
Замечу, что сайтов, где логин виден всем и используется в авторизации, много, но много и тех сайтов, что выводят ту информацию, что указал пользователей - имя/фамилию или псевдоним, логин же используется именно для того, для чего и предназначен - для аутентификации.
Кроме того, многие сайты предлагают аутентифицироваться по паре "e-mail/пароль", а выводят псевдоним пользователя.
Во всех этих случаях надо использовать соответствующий текст ошибки, который не указывает, в каком из полей произошла ошибка.
Тогда подведем итог:
После ввода пользователем неверной комбинации "логин/пароль" необходимо очистить поле пароля и оставить поле логина то содержимое, что ввел пользователь.
При этом, если логин является общедоступной информацией, надо вывести ошибку "неправильный пароль", а в случае, когда сайт не распространяет логины своих пользователей, выводить "неправильный логин или пароль".
Замечу, что сайтов, где логин виден всем и используется в авторизации, много, но много и тех сайтов, что выводят ту информацию, что указал пользователей - имя/фамилию или псевдоним, логин же используется именно для того, для чего и предназначен - для аутентификации.
Кроме того, многие сайты предлагают аутентифицироваться по паре "e-mail/пароль", а выводят псевдоним пользователя.
Во всех этих случаях надо использовать соответствующий текст ошибки, который не указывает, в каком из полей произошла ошибка.
Согласен с вами.
Все аргументы уже перечислили, добавлю от себя пару:
— логин такая штука, что у всех набирается на очень большом автомате с клавиатуры, большинство пользователей, даже если и будет ошибка, выделят весь текст в поле и напишут его мгновенно заново. Поэтому исправление ошибки займет больше времени, цем написание заново. Чем тут можно помочь, так это чтобы фокус при загрузке сразу был на поле логина.
— второй случай. В системе есть пользователи Gray и Grey. Gray пробует войти на сайт, но сделал опечатку и ввел в поле Grey. Естественно аутентификация не прошла, но пользователю система уверенно говорит, что с логином все ОК, а вот пароль ты ввел неверный. Если пользователь уставший будет или будет спешить, то он может набирать "свой" пароль пока его не забанят по IP за брутфорс.
Короче это фича а не баг, в таком серьезном цикле, как планируется, это нужно понимать, и рассматривать со всех сторон, а не только с той, что "это безопасности не сильно угрожает". Написал первое что пришло в голову по недостаткам именно юзабилити.
PS. Жду от автора следующих статей.
Все аргументы уже перечислили, добавлю от себя пару:
— логин такая штука, что у всех набирается на очень большом автомате с клавиатуры, большинство пользователей, даже если и будет ошибка, выделят весь текст в поле и напишут его мгновенно заново. Поэтому исправление ошибки займет больше времени, цем написание заново. Чем тут можно помочь, так это чтобы фокус при загрузке сразу был на поле логина.
— второй случай. В системе есть пользователи Gray и Grey. Gray пробует войти на сайт, но сделал опечатку и ввел в поле Grey. Естественно аутентификация не прошла, но пользователю система уверенно говорит, что с логином все ОК, а вот пароль ты ввел неверный. Если пользователь уставший будет или будет спешить, то он может набирать "свой" пароль пока его не забанят по IP за брутфорс.
Короче это фича а не баг, в таком серьезном цикле, как планируется, это нужно понимать, и рассматривать со всех сторон, а не только с той, что "это безопасности не сильно угрожает". Написал первое что пришло в голову по недостаткам именно юзабилити.
PS. Жду от автора следующих статей.
Все верно. Позволю себе добавить на счет алертов: на мой взгляд, алерты лучше вообще не использовать, а делать кнопку submit неактивной, пока пользователь не заполнит все поля.
Хотя бы в Word'e орфографию проверили.
Тут уж не до пунктуации.
Тут уж не до пунктуации.
Понравилось, интересная статья. Жду продолжения! ;)
Ляп на первой картинке. В "программистских" шрифтах перечёркивается ноль, а не буква "о". Причём обычно перечёркивается в другую сторону. Много примеров: http://www.lowing.org/fonts/
В ASP.Net есть прекрасный инструмент - валидаторы текстовых полей. Позволяют проводить валидацию как на сервере, так и на клиенте с помощью JavaScript. Кроме того, в майкрософтовском аяксе есть ValidatorCalloutExtender, который позволяет показать ошибку в окошке рядом с неправильным полем (отличное решение для пятого примера, когда теснота не позволяет показывать статический текст).
Пример можно посмотреть на сайте ASP.net.
Пример можно посмотреть на сайте ASP.net.
Главное при при ошибке странице регистрации не скидывать данные из формочек, даже пароль, зачем самим отгонять новых пользователей от шага регистрации. На безопасность это не повлияет.
Хы, а я вот абсолютно не вижу ни проблемы ни повода для истерии - reloaded лишили и лишают ubisoft большого куска прибыли, поэтому вполне нормально, что Юби использует наработки reloaded в своих целях. Если в двух словах, то Юби +1.
Вы меня простите, я никогда в жизни никому не указывал на стилистические и грамматические ошибки, но эту статью просто трудно прочесть: «По моему, очевидно, что если ошибка имело место быть...».
В первом примере «Ошибки надо показывать» ошибка заключается в том, что пользователю система вобще позволила нажать на кнопку при незаполненном поле.
В первом примере «Ошибки надо показывать» ошибка заключается в том, что пользователю система вобще позволила нажать на кнопку при незаполненном поле.
В оглавлении на текущую главу не стоило ставить ссылку. Если бы Вы выделили её полужирным начертанием, было бы лучше. А так, кажется, что ссылка - это предыдущая статья. Не то чтобы это уж очень плохо, но и не хорошо.
Извините, но статья показалась мне вялой и "неуверенной", написанная как бы нехотя. Приведены довольно грубые примеры без достаточной аргументации, почему и как можно делать. И, по моему скромному мнению, статья учит "не тому", в связи с чем и пишу небольшую рецензию.
Вступление
Допущено несколько ошибок в коротком тексте ("скрипт должен показаться её" - правильно "скрипт должен показывать её", "комментариями да бы читатели" - правильно "пояснять, дабы читатели", а ещё лучше "чтобы", без пафоса), надо бы повнимательнее быть, хотя такая погода... бывает.
В этом вводном тексте рассказывается, что ошибки бывают, и их надо показывать. Вывод кстати необязательный, потому что можно стараться не допускать "ошибок", ведь не все они таковыми являются (часто системные сообщения выдаются "под соусом" ошибки, например, "Поиск не дал результатов" - это не ошибка, а сообщение, поскольку несёт вполне ценную информацию, "Отдел нельзя удалить, потому что в нём содержатся сотрудники" - это тоже сообщение, хотя и выдающееся после неудачной попытки удалить отдел, но по сути оно сообщает пользователю следующее: "Я ленивый или уставший программист, у меня не было времени писать для тебя проверки, встроенные в интерфейс, чтобы не показывать тебе кнопку "удалить", вот я и решил тебя поучить: ты нажмёшь на кнопку, а я тебе объясню, почему этого не стоило делать"). Вообще, надо было начать с того, что считать ошибкой и какая она бывает (по степени важности, по происхождению, кому адресована и т.д.), от всего этого будет зависеть, как ошибку обрабатывать.
Ошибки в программе чем-то напоминают FAQ на сайте, это те дыры, которые лучше было бы залатать, а не демонстрировать.
Во вступлении есть такая фраза: "ошибка имело место быть, причём не важно с чьей стороны". Я придерживаюсь того же мнения, что и Владислав Головач, если в программе и бывают ошибки, то виновата в этом всегда программа, а не пользователь (подробнее об этом можно почитать в его небезызвестной книге "Дизайн пользовательских интерфейсов"). Конечно, разрабатывать полноценные программы, не нашпигованные сообщениями об ошибках, - дело дорогостоящее, и приходится искать золотую середину, но знать, что пользователь не виноват в нашем нерадении о нём, пожалуй, надо.
"Итак, поехали". Поехали.
"Ошибки надо показывать". В качестве иллюстрации показан пример с иностранным сайтом, который чем-то аналогичен нашему Яндекс.Адреса. В форме два поля "Что" и "Где", соответственно, программа призвана искать что-то, находящееся где-то, но на сайте нигде не сказано, что оба поля обязательны для заполнения, об этом почему-то пользователю сообщается задним числом.
Если эти два поля, с точки зрения раработчиков сервиса, действительно должны быть заполнены, то надо было: а) чётко написать о том, что необходимо заполнить оба поля, б) не допускать нажатия кнопки "Find" скриптом, проверяющим содержимое полей до тех пор, пока оба не окажутся заполненными.
Решение проблемы на Яндекс.Адресах мне видится более изящным. Там нет обязательных полей. Если мы ищем "зоомагазин", то получим все зоомагазины, независимо от их местонахождения, если мы ищем "Кузнецкий мост", то получим все заведения, расположенные поблизости, если мы ищем "зоомагазин" и указываем расположение "Кузнецкий мост", получим, как и ожидается, все зоомагазины около Кузнецкого моста. Можно даже ничего не вводить и нажать кнопку "Найти", сервис покажет нам в ответ каталог, чтобы мы могли определиться, что же нам нужно.
Извините, но статья показалась мне вялой и "неуверенной", написанная как бы нехотя. Приведены довольно грубые примеры без достаточной аргументации, почему и как можно делать. И, по моему скромному мнению, статья учит "не тому", в связи с чем и пишу небольшую рецензию.
Вступление
Допущено несколько ошибок в коротком тексте ("скрипт должен показаться её" - правильно "скрипт должен показывать её", "комментариями да бы читатели" - правильно "пояснять, дабы читатели", а ещё лучше "чтобы", без пафоса), надо бы повнимательнее быть, хотя такая погода... бывает.
В этом вводном тексте рассказывается, что ошибки бывают, и их надо показывать. Вывод кстати необязательный, потому что можно стараться не допускать "ошибок", ведь не все они таковыми являются (часто системные сообщения выдаются "под соусом" ошибки, например, "Поиск не дал результатов" - это не ошибка, а сообщение, поскольку несёт вполне ценную информацию, "Отдел нельзя удалить, потому что в нём содержатся сотрудники" - это тоже сообщение, хотя и выдающееся после неудачной попытки удалить отдел, но по сути оно сообщает пользователю следующее: "Я ленивый или уставший программист, у меня не было времени писать для тебя проверки, встроенные в интерфейс, чтобы не показывать тебе кнопку "удалить", вот я и решил тебя поучить: ты нажмёшь на кнопку, а я тебе объясню, почему этого не стоило делать"). Вообще, надо было начать с того, что считать ошибкой и какая она бывает (по степени важности, по происхождению, кому адресована и т.д.), от всего этого будет зависеть, как ошибку обрабатывать.
Ошибки в программе чем-то напоминают FAQ на сайте, это те дыры, которые лучше было бы залатать, а не демонстрировать.
Во вступлении есть такая фраза: "ошибка имело место быть, причём не важно с чьей стороны". Я придерживаюсь того же мнения, что и Владислав Головач, если в программе и бывают ошибки, то виновата в этом всегда программа, а не пользователь (подробнее об этом можно почитать в его небезызвестной книге "Дизайн пользовательских интерфейсов"). Конечно, разрабатывать полноценные программы, не нашпигованные сообщениями об ошибках, - дело дорогостоящее, и приходится искать золотую середину, но знать, что пользователь не виноват в нашем нерадении о нём, пожалуй, надо.
"Итак, поехали". Поехали.
"Ошибки надо показывать". В качестве иллюстрации показан пример с иностранным сайтом, который чем-то аналогичен нашему Яндекс.Адреса. В форме два поля "Что" и "Где", соответственно, программа призвана искать что-то, находящееся где-то, но на сайте нигде не сказано, что оба поля обязательны для заполнения, об этом почему-то пользователю сообщается задним числом.
Если эти два поля, с точки зрения раработчиков сервиса, действительно должны быть заполнены, то надо было: а) чётко написать о том, что необходимо заполнить оба поля, б) не допускать нажатия кнопки "Find" скриптом, проверяющим содержимое полей до тех пор, пока оба не окажутся заполненными.
Решение проблемы на Яндекс.Адресах мне видится более изящным. Там нет обязательных полей. Если мы ищем "зоомагазин", то получим все зоомагазины, независимо от их местонахождения, если мы ищем "Кузнецкий мост", то получим все заведения, расположенные поблизости, если мы ищем "зоомагазин" и указываем расположение "Кузнецкий мост", получим, как и ожидается, все зоомагазины около Кузнецкого моста. Можно даже ничего не вводить и нажать кнопку "Найти", сервис покажет нам в ответ каталог, чтобы мы могли определиться, что же нам нужно.
Дальше идёт пример с авторизацией на каком-то сайте. Непонятно, почему одна часть истории находится в разделе "Действие без пояснения или Ошибки надо показывать 2", а другая - в "Ошибка в виде системного диалогового окна", но первый раздел, действительно, не снабжён никакими пояснениями, поэтому и комментировать его я не буду.
По поводу использования средств браузера, в данном случае показа алерта, читаем: "Использовать элементы интерфейса других программ, мягко говоря — плохой тон (за исключением радиобаттанов, полей текста и чекбоксов; выпадающие списки — в отдельных случаях)". Мягко говоря, это чушь. Браузер - это программа для просмотра сайтов, соответственно это уже не "другая программа", при этом как браузер может работать с сайтом (навигация, поиск по тексту, добавление в закладки, подписка на RSS-канал, сохранение изображения через контекстное меню), так и сайт может производить какие-то действия посредством браузера (показ названия страницы в заголовке окна, выдача справочной информации через всплывающие подсказки и панель статуса) и т.д. Для меня так и осталось загадкой, в каких таких отдельных случаях использование стандартных выпадающих списков - это нормально, а в каких - ненормально (может быть, Вы спутали выпадающий список, являющийся элементом формы, с выпадающим меню, являющимся элементом навигации?)
Вообще, речь вроде шла об алерте, который показан средствами браузера. В чём же его особенность? Алерт - это модальное окно для сообщения об ошибке с единственной кнопкой "ОК". Модальное окно - это такое окно, которое не позволяет работать с системой, пока не будет закрыто (т.е. такое окно переводит систему в особый режим, англ. mode). Алерт модален не случайно, а для того, чтобы пользователь обязательно прочитал сообщение об ошибке прежде, чем продолжит работать с системой (из расчёта, что он может сделать что-то непоправимое). Алерт браузера - это сообщение об ошибке именно браузера, это первая причина, по которой его не стоит использовать. Вторая причина заключается в том, что алерт браузера считает системой не одну какую-то вкладку, а всю программу в целом, переводя её в режим сообщения об ошибке. Таким образом, когда открывается алерт браузера, пользователь уже не может ничего сделать, пока не закроет его, он не может ни навигироваться, ни переключиться на другую вкладку, браузер оказывается временно заблокирован. Ну, а третья причина психологическая. Эстетически алерт браузера выглядит агрессивно (алерт не предназначен для вывода информационных сообщений и не настраивается; как видно из названия alert, это предупреждение об опасности, грозящей пользователю), и выбивается из оформления сайта, что не может не шокировать пользователя, поскольку такой алерт призывает его ко всей возможной сосредоточенности, на которую тот способен (не будем забывать, что алерт браузера также сопровождается неожиданным звуком "бдзыньк!").
Если уж сайту необходимо вывести алерт (в каких случаях его нужно выводить - это отдельная песня), то лучше делать его средствами самого сайта, с помощью JavaScript, тогда можно и настроить его внешний вид, и сделать немодальным.
По поводу использования средств браузера, в данном случае показа алерта, читаем: "Использовать элементы интерфейса других программ, мягко говоря — плохой тон (за исключением радиобаттанов, полей текста и чекбоксов; выпадающие списки — в отдельных случаях)". Мягко говоря, это чушь. Браузер - это программа для просмотра сайтов, соответственно это уже не "другая программа", при этом как браузер может работать с сайтом (навигация, поиск по тексту, добавление в закладки, подписка на RSS-канал, сохранение изображения через контекстное меню), так и сайт может производить какие-то действия посредством браузера (показ названия страницы в заголовке окна, выдача справочной информации через всплывающие подсказки и панель статуса) и т.д. Для меня так и осталось загадкой, в каких таких отдельных случаях использование стандартных выпадающих списков - это нормально, а в каких - ненормально (может быть, Вы спутали выпадающий список, являющийся элементом формы, с выпадающим меню, являющимся элементом навигации?)
Вообще, речь вроде шла об алерте, который показан средствами браузера. В чём же его особенность? Алерт - это модальное окно для сообщения об ошибке с единственной кнопкой "ОК". Модальное окно - это такое окно, которое не позволяет работать с системой, пока не будет закрыто (т.е. такое окно переводит систему в особый режим, англ. mode). Алерт модален не случайно, а для того, чтобы пользователь обязательно прочитал сообщение об ошибке прежде, чем продолжит работать с системой (из расчёта, что он может сделать что-то непоправимое). Алерт браузера - это сообщение об ошибке именно браузера, это первая причина, по которой его не стоит использовать. Вторая причина заключается в том, что алерт браузера считает системой не одну какую-то вкладку, а всю программу в целом, переводя её в режим сообщения об ошибке. Таким образом, когда открывается алерт браузера, пользователь уже не может ничего сделать, пока не закроет его, он не может ни навигироваться, ни переключиться на другую вкладку, браузер оказывается временно заблокирован. Ну, а третья причина психологическая. Эстетически алерт браузера выглядит агрессивно (алерт не предназначен для вывода информационных сообщений и не настраивается; как видно из названия alert, это предупреждение об опасности, грозящей пользователю), и выбивается из оформления сайта, что не может не шокировать пользователя, поскольку такой алерт призывает его ко всей возможной сосредоточенности, на которую тот способен (не будем забывать, что алерт браузера также сопровождается неожиданным звуком "бдзыньк!").
Если уж сайту необходимо вывести алерт (в каких случаях его нужно выводить - это отдельная песня), то лучше делать его средствами самого сайта, с помощью JavaScript, тогда можно и настроить его внешний вид, и сделать немодальным.
Привязанность ошибки к её причине. "Неверно" пишется слитно, если нет противопоставления, а что такое "корректные ошибки" я не понимаю. Но думаю, что Вы хотели сказать, что ошибки правильно показывать как можно ближе к контексту их возникновения, тогда они легче читаются. Например, раньше было принято выводить ошибки заполнения формы длинным списком в верхней части страницы, теперь же, когда программировать формы стало проще, ошибки выводят напротив полей, в которых они возникли, и пользователю не нужно уже искать поле "Индекс" по всей странице.
От себя добавлю, что полезно также снабжать сообщения об ошибке в форме тегом label, чтобы по нажатию на него пользователь мог перевести фокус на поле, значение которого надо исправить.
Привязанность в тесноте. Здесь приведён пример того самого, о чём я писал чуть выше, когда сообщения об ошибках показываются одним списком, отдельно от полей. Редкий, кстати, пример, потому что здесь блок сообщений находится не над формой, а сбоку от неё, засчёт этого используется меньше полезного пространства и не нужно пользоваться скроллингом, чтобы найти соответствия между ошибкой и полем, где она возникла. Но сказать, что это хорошее решение, я бы не стал, будем считать, что дизайнеры нашли причину сделать форму такой сжатой.
Кстати, блок сообщений об ошибках можно сделать фиксированным, а форму - прокручиваемой, тогда все ошибки всегда будут навиду, независимо от того, в какой части формы мы находимся. Важно только не забыть снабдить сообщения об ошибках соответствующими привязками к полям, чтобы форма при нажатии на сообщение, прокручивалась до искомого места.
Неуверенность ошибки. Тема выбрана важная, только пример подобран неудачный. Я часто сталкивался с тем, когда программист ленитя разделять ошибки и делает так, что система выдаёт какое-нибудь отвлечённое изречение, из которого невозможно одноначно понять, чем же вызван сбой в работе. Это может быть "Неверно заполнена форма" (вместо "Укажите идентификатор") или "Неверные критерии поиска" (вместо "Для осуществления поиска необходимо ввести хотя бы два символа"), "Ошибка в дате" (вместо "Дата начала не может превышать дату окончания" или "Ошибка в формате даты. Правильный формат: ДД.ММ.ГГГГ"), а иногда и просто "Ошибка!" Только это не "неуверенность", а "неполнота" сообщения. При составлении сообщения об ошибке необходимо помнить, что такое сообщение выполняет две основные функции: 1) сообщает о причине неудачной операции, 2) сообщает, что нужно исправить, чтобы операция прошла успешно.
Предотвращение ошибок. У Вас сказано, что предотвращать ошибки надо пояснениями и предостережениями. Но далеко не всегда пользователь может всё внимательно прочитать, всё понять и "не делать глупостей". Более радикальным способом борьбы с ошибками является предотвращение самой возможности их допустить.
Если нельзя отправлять форму до того, как будут введены фамилия и имя отправителя, то попросту не надо позволять форму отправить.
Если дата введена неправильно, лучше показать сообщение об этом до того, как пользователь перейдёт к отправке формы.
Если нет прав на редактирование записи, то надо заблокировать саму возможность её редактировать.
Если нет прав на просмотр страницы, по возможности надо не давать ему ссылки на эту страницу.
Чтобы пользователь понимал, от какого действия его ограждают, необходимо (там, где это необходимо) показывать неактивный элемент управления, отвечающий за действие: дактивированную кнопку или закладку, бледный текст вместо ссылки и т.п. Это похоже на текстовый квест: игрок не может пройти через дверь, но ему не пишут: "Дверь заперта, прохода нет", вместо этого его интригуют: "Дверь заперта, прохода нет. Если у вас есть ключ, воспользуйтесь им", таким образом, даже тот игрок, у которого нет ключа, знает, что дверь при определённых условиях можно открыть.
Какой способ предотвращения ошибки выбрать - предупреждение, блокировка или сочетание того и другого - дело такта разработчика и особенностей использования системы.
От себя добавлю, что полезно также снабжать сообщения об ошибке в форме тегом label, чтобы по нажатию на него пользователь мог перевести фокус на поле, значение которого надо исправить.
Привязанность в тесноте. Здесь приведён пример того самого, о чём я писал чуть выше, когда сообщения об ошибках показываются одним списком, отдельно от полей. Редкий, кстати, пример, потому что здесь блок сообщений находится не над формой, а сбоку от неё, засчёт этого используется меньше полезного пространства и не нужно пользоваться скроллингом, чтобы найти соответствия между ошибкой и полем, где она возникла. Но сказать, что это хорошее решение, я бы не стал, будем считать, что дизайнеры нашли причину сделать форму такой сжатой.
Кстати, блок сообщений об ошибках можно сделать фиксированным, а форму - прокручиваемой, тогда все ошибки всегда будут навиду, независимо от того, в какой части формы мы находимся. Важно только не забыть снабдить сообщения об ошибках соответствующими привязками к полям, чтобы форма при нажатии на сообщение, прокручивалась до искомого места.
Неуверенность ошибки. Тема выбрана важная, только пример подобран неудачный. Я часто сталкивался с тем, когда программист ленитя разделять ошибки и делает так, что система выдаёт какое-нибудь отвлечённое изречение, из которого невозможно одноначно понять, чем же вызван сбой в работе. Это может быть "Неверно заполнена форма" (вместо "Укажите идентификатор") или "Неверные критерии поиска" (вместо "Для осуществления поиска необходимо ввести хотя бы два символа"), "Ошибка в дате" (вместо "Дата начала не может превышать дату окончания" или "Ошибка в формате даты. Правильный формат: ДД.ММ.ГГГГ"), а иногда и просто "Ошибка!" Только это не "неуверенность", а "неполнота" сообщения. При составлении сообщения об ошибке необходимо помнить, что такое сообщение выполняет две основные функции: 1) сообщает о причине неудачной операции, 2) сообщает, что нужно исправить, чтобы операция прошла успешно.
Предотвращение ошибок. У Вас сказано, что предотвращать ошибки надо пояснениями и предостережениями. Но далеко не всегда пользователь может всё внимательно прочитать, всё понять и "не делать глупостей". Более радикальным способом борьбы с ошибками является предотвращение самой возможности их допустить.
Если нельзя отправлять форму до того, как будут введены фамилия и имя отправителя, то попросту не надо позволять форму отправить.
Если дата введена неправильно, лучше показать сообщение об этом до того, как пользователь перейдёт к отправке формы.
Если нет прав на редактирование записи, то надо заблокировать саму возможность её редактировать.
Если нет прав на просмотр страницы, по возможности надо не давать ему ссылки на эту страницу.
Чтобы пользователь понимал, от какого действия его ограждают, необходимо (там, где это необходимо) показывать неактивный элемент управления, отвечающий за действие: дактивированную кнопку или закладку, бледный текст вместо ссылки и т.п. Это похоже на текстовый квест: игрок не может пройти через дверь, но ему не пишут: "Дверь заперта, прохода нет", вместо этого его интригуют: "Дверь заперта, прохода нет. Если у вас есть ключ, воспользуйтесь им", таким образом, даже тот игрок, у которого нет ключа, знает, что дверь при определённых условиях можно открыть.
Какой способ предотвращения ошибки выбрать - предупреждение, блокировка или сочетание того и другого - дело такта разработчика и особенностей использования системы.
Во-вторых, она очистила поля User ID и Password и теперь я буду вынужден вводить их зановоК сведению: пароль должен очищаться всегда, а точнее НЕ присутствовать ни в HTML, ни в адресной строке.
Добавил бы еще пункт "Акцентируйте внимание", бывает что форма не самое основное, и может быть где-то ниже первого скрина. Плюс ошибка всего одна. Тогда, после сабмита, юзер может не заметить ошибки (предположим что js валидация прошла или ее не было) и подумать что всё ок. В таком случае уместен алерт "У вас ошибка, проверьте все и повторите еще". Хоть он и выглядит избыточным. Кстати, такой алерт уместен даже при валидации яваскриптовой: представьте что его нет, юзер случайно нажал на энтер и система вывела ошибку (card checksum error), причем так что он незаметил изменений (не смотрел на экран). После этого он сабмитит, а ошибка не исчезает, новой не появляется, форма не сабмитится - можно подумать что форма просто не работает. Алерт в таком случае означал бы что всё ок со скриптом, но по прежнему не всё ок с данными формы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Подача ошибок. Часть 1. Вступление.