Идеальная авторизация
Автор: Ярослав Бирзул \ Опубликовано 19 сентября 2008 года в категории Идеалы
Не знаю почему, но удобству формы для входа на сайт уделяется уж слишком мало внимания со стороны дизайнеров. Большинство считает этот блок слишком простым, чтобы уделять ему много времени. Что совершенно зря.
Казалось бы – что тут может быть сложного: два поля, кнопка, пару ссылок и, возможно, чекбокс. Но всё не так просто как кажется на первый взгляд.
Существуют довольно жесткие рамки отображения формы входа, а также некоторые моменты, которые просто стоит учитывать, рисуя эту форму. Постараюсь их описать как можно подробнее:
1. Форма входа должна быть видна на первом экране браузера. Т.е. сразу при открытии сайта, без использования полосы прокрутки. При этом нужно учитывать минимальную высоту разрешения мониторов пользователей на момент создания дизайна, а также то, что браузер забирает на себя от 10 до 30% пространства.

2. Нежелательно выводить поля в линию. При выводе полей в столбец пользователь заполняет их практически на автомате – сказывается привычка. Если же выводить поля в линию – психологический паттерн не столь силен.

3. «Размер не имеет значения». Фраза, которая никак не относится к кнопке входа. Она не должна быть расчитана на снайперов. Учитывайте, что сейчас всё большее распространение приобретают мониторы с довольно большим разрешением, на которых маленькие кнопочки выглядят сущим мучением. Но в то, же время не переусердствуйте с размерами.

4. Зачастую кнопка входа лучше всего смотрится, если её ширина совпадает с шириной полей. Хотя это уже зависит напрямую от дизайнера, который и занимается проектировкой формы входа. Данный момент точно не является правилом. Скорее личным предпочтением автора.

5. Поля логина и пароля должны быть одного размера. Установлено, что при поиске формы входа пользователь «сканирует» глазами страницу в поисках двух одинаковых полей, которые находятся в непосредственной близости друг от друга. Поэтому крайне нежелательно располагать также какие-то другие поля ввода.

6. Если вы ограничены в месте – можно перенести надписи «Логин», «Пароль» внутри полей, которые исчезают при клике на них. У этого решения 2 минуса – иногда люди нажимают на поле, а потом отвлекаются. Поэтому пользователи могут быть сбиты с толку. Вторым минусом является то, что не у всех включен Javascript с помощью которого и достигается подобный эффект. Поэтому надписи лучше выводить отдельно от полей.

7. Размеры полей должны быть удобными как для ввода, так и для чтения. Стоит также учитывать отступы от краев поля до текста внутри него. Причем с запасом прочности – не все браузеры одинаково выводят текст внутри поля. Любимый верстателями Internet Explorer вообще любит отступы на завтрак кушать.

8. Ссылки на регистрацию и на восстановление пароля лучше всего выводить напротив каждого из полей соответственно. Т.е. «зарегистрировать» (или «новый») выводим напротив поля логина. А ссылку «забыли пароль?» напротив поля пароля. Всё просто, не так ли?

9. Форма авторизации не должна быть графически пресыщенной в целом. Градиенты внутри поля добавляют мороки не только верстателям, но и пользователям.
10. Выводить форму входа можно на любом месте сайта. Будь-то сверху, справа, слева. В результате тестирования оказалось, что пользователям абсолютно удобен вывод формы авторизации в любом месте на сайте с учетом пунктов 1 и 2 этого списка.
11. На кнопке входа может быть написано всё что угодно. Вплоть до «выход» т.к. пользователи очень редко обращают внимание на надпись. Поэтому и закцикливаться на этом не стоит.
12. Если вход на сайт производится без перезагрузки страницы (AJAX) обязательно нужно показывать то, что информация отправляется и обрабатывается. Лучше всего это достигается с помощью так называемого лоадера. Какой-нибудь зацикленной вертящейся, или бегающей фентифлюшкой. Это повелось уже с наших любимых операционных систем, поэтому не стоит изменять привычке.
13. После входа на сайт информацию о пользователе, ссылки на настройки и прочую информацию из личного профиля лучше всего выводить на месте формы входа т.к. пользователь будет искать её именно там. Особенно если она построена через AJAX.
Не забывайте также и общие положения о пустом пространстве между полями и кнопкой, отступы внутри полей, и снаружи.
PS: Друзья, настоятельно рекомендую тем, кто еще не читал небольшую информацию к прочтению обязательно её прочитать.
PPS: У вас есть твиттер? Тогда вы можете меня читать там же.
Тем временем
1. Миша Квакин пишет о жёлтеньких (именно таких) страницах интернета.
2. Егор Чернев обозревает видео плеер Panda.
3. Guicci ищут программиста в Минске.
4. Сергей Чаботько рассказывает о конкуренции в сфере контекстной рекламы.


Сергей Чаботько
Миша Квакин
Футуриус
Точка с запятой;
Guicci
Просто Tyomma
Юрий Дибров
WebMolot
Чернев
Юрий Ветров
Владимир Долженко пишет нам 19 сентября, 2008 в 11:30
отличный пост!
назревал вопрос решения данной проблемы, а тут такой пост как нельзя кстати
ps. кстати, форма для комментариев в блоге показывает плохой стиль по п.6 данного поста :)
Ярослав Бирзул пишет нам 19 сентября, 2008 в 11:34
По поводу формы комментариев - тогда тут бы нарушилась симметрия.
BDSoft пишет нам 19 сентября, 2008 в 11:48
А как на счёт формы входа в всплывающем окошке как на хабре например?
Егорка пишет нам 19 сентября, 2008 в 11:48
Спасибо Ярослав! Как раз делаю форму авторизации на своем проекте, обязательно учту все эти замечания.
Ярослав Бирзул пишет нам 19 сентября, 2008 в 11:50
BDSoft, не вижу в ней ничего плохого, но все эти пункты желательно соблюдать и в этом случае.
Ярослав Бирзул пишет нам 19 сентября, 2008 в 11:51
Егор, на здоровье :)
Егорка пишет нам 19 сентября, 2008 в 11:52
Кстати, что-то не то с 12 пунктом.
Егорка пишет нам 19 сентября, 2008 в 11:55
Хотя нет, перечетал еще два раза и понял в чом соль.
Ярослав Бирзул пишет нам 19 сентября, 2008 в 11:56
Егор, а что с ним не так? Процесс загрузки - обязательно нужно показывать, т.к. не в каждом браузере отображается процесс подзагрузки без перезагрузки.
Егорка пишет нам 19 сентября, 2008 в 12:31
Да я прочитал всё наоборот. Удаляй мои комменты (-:
Роман Настенко пишет нам 19 сентября, 2008 в 12:57
C пунктами 6 и 8 можно поспорить.
В пункте 6 следует учесть, что выключен javascript у нескольких процентов пользователей всего, и даже если он выключен — надписи всего лишь не будут исчезать.
Для некоторых сайтов это можно считать критичным, но, в принципе, это не такой уже четкий критерий. Пример: не для сайтов типа
Пункт 8 тоже вряд ли стабилен. Регистрация может находиться рядом с формой, отдельным заметным блоком — в таком случае дублировать ее зачем? Кроме восстановления пароля может быть опция “запоминания”. В общем, приведенное размещение совсем не “идеальное”. Пример… да хоть http://www.perfectomania.com/wp-login.php
Еще я бы добавил две вещи:
1) Наличие правильного порядка переключение полей клавишей Tab.
2) Перемещение курсора сразу в поле логина, если форма — все что есть на странице.
Роман Настенко пишет нам 19 сентября, 2008 в 12:58
Примером один был Яндекс, если что :)
Ярослав Бирзул пишет нам 19 сентября, 2008 в 7:48
Роман, по порядку.
> В пункте 6 следует учесть, что выключен javascript у нескольких процентов пользователей всего, и даже если он выключен — надписи всего лишь не будут исчезать.
Вот именно. И это самый раздражающий момент, кода при клике стандартная надпись внутри поля не пропадает. А кому нужен раздраженный посетитель?
> Регистрация может находиться рядом с формой, отдельным заметным блоком — в таком случае дублировать ее зачем?
Вообще-то речь шла о главной странице, на которой НЕ БУДЕТ блока регистрации.
> Кроме восстановления пароля может быть опция “запоминания”
Это не проблема.
> В общем, приведенное размещение совсем не “идеальное”
Пока аргументов недостаточно, чтобы так решить.
> Наличие правильного порядка переключение полей клавишей Tab.
Согласен.
Роман Настенко пишет нам 19 сентября, 2008 в 10:03
// Вообще-то речь шла о главной странице, на которой НЕ БУДЕТ блока регистрации. //
Я имел ввиду заметную ссылку, например в виде кнопки, или просто заметную. ВНЕ ФОРМЫ. Обычно такая есть. В таком случае В ФОРМЕ она не нужна.
// Вот именно. И это самый раздражающий момент, кода при клике стандартная надпись внутри поля не пропадает. А кому нужен раздраженный посетитель? //
В случае, если, допустим, без Javascript не будет работать основной функционал сайта — этим можно пренебречь.
// Пока аргументов недостаточно, чтобы так решить. //
Я не имел ввиду, что такое решение — особо ужасное. Просто говорю, что, в зависимости от ситуации, применить какую-то другую модель будет ничем не хуже.
http://www.picamatic.com/show/2008/09/19/11/41/1038834_500×265.jpg не такая уж и идеальная с точки зрения привлекательности и практичности (широкая очень) структура.
Кстати, еще одно вспомнил. Поле логина, чтобы работало автозаполнение нормально, должно называться login.
Роман Настенко пишет нам 19 сентября, 2008 в 10:16
Кстати, вот пример довольно оригинальной формы авторизации: http://www.free-lance.ru/ ;)
Ярослав Бирзул пишет нам 19 сентября, 2008 в 10:29
> Я имел ввиду заметную ссылку, например в виде кнопки, или просто заметную. ВНЕ ФОРМЫ. Обычно такая есть. В таком случае В ФОРМЕ она не нужна.
Обычно такая есть? В каких волшебных странах есть такое “обычно”?
> В случае, если, допустим, без Javascript не будет работать основной функционал сайта — этим можно пренебречь
Основной функционал ДОЛЖЕН работать при отключенных JS, картинках и флеше. Если он не работает - то тут уже не до авторизации.
> http://www.picamatic.com/show/2008/09/19/11/41/1038834_500×265.jpg не такая уж и идеальная с точки зрения привлекательности и практичности (широкая очень) структура.
Неужто не ясно, что тут всё гипертрофировано? В обычной отрисовке она должна быть явно уже.
> Кстати, вот пример довольно оригинальной формы авторизации: http://www.free-lance.ru/
А что оригинального в их авторизации? Противоречит п.2
Евгений пишет нам 19 сентября, 2008 в 10:36
6-й пункт можно реализовать так что никаких проблем при отключенном JS не будет, не исчезающий текст это не обязательный недостаток, а убогость конкретных реализаций.
Вот пример такой формы, при отключенном JS подписи становятся перед полями (можно сделать и сверху)
http://designformasters.info/stuff/compact-accessible-forms/example-complete.html
А вот отвлечься пользователь действительно может и потом будет гадать, что за поле он заполняет, в чем я каждый раз убеждаюсь заполняя три поля в форме комментариев этого блога.
А еще (мне кажется, даже чаще) пользователь может переключиться табом на поле даже не посмотрев, что в нем написано, при нестандартном расположении полей это приводит к тому, что он теряется.
Мне кажется именно проблемы с идентификацией пола, а не с отключенным JS, делают расположение подписей к полям внутри них (мягко говоря) не очень удобным для пользователя.
8-й пункт мне кажется очень спорным. Почему «Зарегистрироваться» напротив логина? пароль к регистрации не относиться? связь с полем не очень четкая.
Лучше поставить эти ссылки ниже кнопки чтобы они не маячили в основной рабочей зоне, все таки используются они на порядок меньше.
По 4-му могу сказать только за себя, кнопки размером с текстовое поле смотрятся страшно, красненький пример там гораздо симпатичнее. Наиболее подходящий размер кнопки связан с количеством текста в ней и гармоничными полями вокруг него, здоровенная кнопка с пятью буквами в центре выглядит нехорошо.
PS: заметил, что на Яндексе как раз такая форма как я привел в примере, при отключенном JS там просто подписи над полями.
Роман Настенко пишет нам 19 сентября, 2008 в 10:40
// А что оригинального в их авторизации? Противоречит п.2 //
Интересная реализация просто. Не такая уж она и ужасная, хотя да, противоречит.
Ярослав Бирзул пишет нам 19 сентября, 2008 в 10:41
> А вот отвлечься пользователь действительно может и потом будет гадать, что за поле он заполняет, в чем я каждый раз убеждаюсь заполняя три поля в форме комментариев этого блога.
Вообще-то заполнить можно всего-лишь один раз, затем поля не показываются.
> Почему «Зарегистрироваться» напротив логина? пароль к регистрации не относиться? связь с полем не очень четкая.
Регистрируется обычно именно логин, или e-mail, а не пароль. Т.к. пароль может быть не уникальным, а логин и e-mail - обязан. Всё просто - паттерн: Логин - Зарегистрировать \ Новый
Ярослав Бирзул пишет нам 19 сентября, 2008 в 10:42
> Интересная реализация просто. Не такая уж она и ужасная, хотя да, противоречит.
Я и не говорил, что она ужасная. Просто интересно чем она оригинальна?
Роман Настенко пишет нам 19 сентября, 2008 в 10:44
// Просто интересно чем она оригинальна? //
А где еще так сделано?
Ярослав Бирзул пишет нам 19 сентября, 2008 в 10:49
> А где еще так сделано?
Почти на всех форумах и ЖЖ.
А также на некоторых Drupal-сайтах
Роман Настенко пишет нам 19 сентября, 2008 в 10:52
// Почти на всех форумах и ЖЖ.
А также на некоторых Drupal-сайтах //
На http://www.free-lance.ru/, ИМХО, такой прием лучше всего реализован.
Ярослав Патрикеев пишет нам 19 сентября, 2008 в 11:32
Да, я тоже выскажусь :)
Постулаты хорошие, я считаю, их можно принять. Оспаривать не хочу, не буду, потому что не за чем.
От себя скажу, что можно добавлять разнообразия в текстовое описание формы. Но в меру и вдумчиво. Как мне кажется, можно пробовать строить предложения с местами для заполнения («Привет, меня зовут [логин], мое кодовое слово — [пароль] и я пришел в нашу секретную службу», подойдет для сайта ФСБ ;) или вопросы к пользователю. Все это хорошо в сочетании с вольным стилем текста на неофициальных сайтах.
Тексты вообще интереснее, когда они интересные ;)
Толкователь пишет нам 21 сентября, 2008 в 4:53
В дизайне каждой детале нужно уделять внимание, и поля для авторизации не исключение. Все верно…
Мои пять Да и пять Нет | AlexNote пишет нам 23 сентября, 2008 в 1:21
[...] Идеальная авторизация Казалось бы – что тут может быть сложного: два поля, кнопка, пару ссылок и, возможно, чекбокс. Но всё не так просто как кажется на первый взгляд. Существуют довольно жесткие рамки отображения формы входа, а также некоторые моменты, которые просто стоит учитывать, рисуя эту форму. Постараюсь их описать как можно подробнее… [...]
DjoniLee пишет нам 27 сентября, 2008 в 11:46
Вообще для авторизации надо использовать OpenID вот и все будет вам идеальная авторизация!
Ярослав Бирзул пишет нам 27 сентября, 2008 в 11:57
DjoniLee, мы тут говорим не о технической реализации, а визуальной.
DjoniLee пишет нам 27 сентября, 2008 в 6:50
Так визуально надо сделать форму под OpenId!
Ярослав Бирзул пишет нам 27 сентября, 2008 в 6:52
Что значит “надо”?
1. Кому надо?
2. Зачем надо?
3. Почему надо?
http://www.birzool.com/info/ - ознакомьтесь, пожалуйста, с пунктом 6.
lena пишет нам 28 сентября, 2008 в 8:28
обычная авторизация как и у многих блогов все окей
Ярослав Бирзул пишет нам 28 сентября, 2008 в 8:37
lena, к чему вы это написали?
Евгений пишет нам 28 сентября, 2008 в 1:15
Ни к чему, это спамер, как и Толкователь и DjoniLee, ручной спам сейчас процветает.
Ярослав, просто смотри, что у людей по ссылке, а то я заметил, что спамеры тут слишком свободно себя чувствуют.
Ярослав Бирзул пишет нам 28 сентября, 2008 в 1:18
Жень, спасибо за наводку.
Robin пишет нам 30 сентября, 2008 в 7:32
Очень классно, обязательно буду использовать в своих работах!
плк пишет нам 2 октября, 2008 в 9:14
спасибо за полезные советы, кстати некоторые из них я сразу применял, вот. А вообще, главное чтобы все эти прелести и красивости не помешали основному функционалу сайта и не отвлекали внимание от контента сайта.
Кстати очень полезный у Вас сайт афтор, я даже на RSS подписался.
Интересное для веб-мастеров (03.10.2008) » Как создать сайт бесплатно? Как сделать сайт? Журнал для веб-мастеров и блогеров от школы создания с пишет нам 3 октября, 2008 в 6:51
[...] Идеальная авторизация Не знаю почему, но удобству формы для входа на сайт уделяется уж слишком мало внимания со стороны дизайнеров. Большинство считает этот блок слишком простым, чтобы уделять ему много времени. Что совершенно зря… [...]
Это типа логин тут пишет нам 22 октября, 2008 в 2:23
Юзабилити… юзабилити…
А вот нафига вообще поле “логин”, кто нибудь может вразумительно сказать?
Ну, вообще, и с точки зрения юзабилити….
Ярослав Бирзул пишет нам 22 октября, 2008 в 2:57
Это типа логин тут, к примеру, для того, чтобы люди не обращались к человеку “Это типа логин тут”.
Это типа логин тут пишет нам 22 октября, 2008 в 4:09
Угу… “плк” или “Robin”, видимо, гораздо информативнее по-вашему.
Имя нужно вводить при регистрации, а не при входе на сайт.
Для входа пароля более чем достаточно.
Не согласны?
Ярослав Бирзул пишет нам 22 октября, 2008 в 4:15
Это типа логин, нет конечно.
Логин при регистрации - должен быть уникален.
Пароль - нет.
Ярослав Бирзул пишет нам 22 октября, 2008 в 4:17
Примерно у половины зарегистрированных людей будет пароль: 123456
Если вы его введете - как сайт должен знать в какой логин входить?
Еще учтите то, что логин это не всегда ник. Это может быть e-mail, фио.
Это типа логин тут пишет нам 22 октября, 2008 в 4:24
Кстати, (не обращали внимания?) например, в социальных сетях
есть поле E-mail, а не Login, что тоже излишне, но хотя бы объяснимо…
Оно не отображается всем желающим, но полезно, например,
для восстановления пароля.
А логин… Ну это же пережиток юникс-систем. Все просто копируют бездумно.
С логином одни неудобства.
Некоторые сайты не дают ввести пробел, некоторые - подчерк,
где-то Alex и aLeX - разные логины, где-то одинаковые.
Популярные логины (Например Alex, Michael_K, Ivan Sidorov) часто заняты.
Из-за этого приходится на разных сайтах пользоваться разными логинами
не трудно и забыть или запутаться (и других запутать).
В общем, я бы сказал, что поле Логин - это сплошной геморрой.
Раз уж речь зашла о Юзабилити, то лишнее поле - первый кандидат на удаление,
а вовсе не то, куда его поставить и в какой цвет покрасить.
Ширше надо мыслить… Я бы даже сказал ширее…
Это типа логин тут пишет нам 22 октября, 2008 в 4:27
Хм… Капча всплыла…
Обратил внимание, что вы идентифицируете меня по е-мэйлу…
(виден в запросе GET)… Ну и зачем логин?
Ярослав Бирзул пишет нам 22 октября, 2008 в 4:29
А вы где-то логин конкретно в этом блоге видели?
Капчи тут тоже нет.
Это типа логин тут пишет нам 22 октября, 2008 в 4:31
> Логин при регистрации - должен быть уникален.
> Пароль - нет.
Так сделайте наоборот, какие проблемы.
В конце концов, если слепить их в одно слово в одно поле - это будет не то же самое?
Ярослав Бирзул пишет нам 22 октября, 2008 в 4:43
1. Логин или(!) e-mail является идентификатором: http://ru.wikipedia.org/wiki/%D0%98%D0%B4%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%82%D0%BE%D1%80
Никто не просит вас вводить при входе на сайт и то и другое.
2. Логин, это уникальная сущность, а пароль нет: http://ru.wikipedia.org/wiki/%D0%A3%D1%87%D1%91%D1%82%D0%BD%D0%B0%D1%8F_%D0%B7%D0%B0%D0%BF%D0%B8%D1%81%D1%8C
Пароль не может быть уникальным. Если в сайт будет встроена проверка незанятости пароля - это дает средство подбора пароля злоумышленникам.
3. Логин впервые стал использоваться в банковской системе для удобства вкладчиков средств. Но никак не “пережиток unix систем”: http://ru.wikipedia.org/wiki/%D0%91%D0%B0%D0%BD%D0%BA%D0%BE%D0%B2%D1%81%D0%BA%D0%B0%D1%8F_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0
4. Слить логин и пароль, это тоже самое, что слить Имя и идентификационный код платы налогов. Т.е. редчайшая глупость.
5. Имя пользователя (не равно) логин. Вы когда заполняете какие-то документы пишете вместо ФИО логин?
Прошу вас, не позорьтесь пытаясь доказать мне откровенную глупость с умным видом.
> Так сделайте наоборот, какие проблемы.
В конце концов, если слепить их в одно слово в одно поле - это будет не то же самое?
Если вам очень хочется использовать одно поле при входе - можно создать систему генерирования уникального кода пользователя.
Но в ней сразу всплывают минусы:
1. Пользователей интернетом уже 2 миллиарда и увеличивается в геометрической прогрессии. Т.е. генерировать нужно код (на вырост хотя-бы до тысячи миллиардов). Т.е. XXXX XXX XXX XXX
А для того, чтобы избежать фишинга уникального кода - его нужно увеличить еще по меньшей мере на 4 знака. А лучше на 7-10.
Т.е. уже вот такой вот: XXXX XXX XXX XXX XXX XXX XXX
Вы осилите запомнить вот такой вот уникальный код (к примеру): 4719817816917471917713
Нет конечно. За этим сразу следует второй минус.
2. Т.к. вы запомнить такой код объективно не сможете, его придется где-то хранить. На e-mail к примеру.
а) Это не безопасно.
б) Чтобы войти в e-mail вам придется использовать… “Логин + пароль”. Тогда к чему всё это делать?
Выводы:
1. Это сложно.
2. Небезопасно.
3. Ничего концептуально не меняет.
Вывод из выводов:
связка логин + пароль на сегодняшний день самый удобный способ идентификации пользователя.
Это типа логин тут пишет нам 22 октября, 2008 в 5:43
Зря вы так…
Следуя вашей логике, если использовать уникальные логины,
то они (логины) должны приобретать вид 4719817816917471917713
(ведь пользователей интернета из двух миллиардов скоро станет тысяча, (что они кушать, пардон, будут интересно :) )
Однако таких уникальных логинов (равно и уникальных е-мэйлов) я что-то не встречал.
И причина очень проста - никто не пользуется только десятиричными цифрами ни в емайлах,
ни в логинах, ни в паролях.
Кроме того, пользователей даже у больших порталов много меньше, чем пользователей интернета вообще.
По поводу “небезопасности”… Брутфорсу на самом деле глубоко начихать
одно там уникальное поле длиной в 20 символов или два по десять.
Но учитывая, что в традиционных системах логин часто виден, а пароль
“у половины юзеров 123456″ - она более подвержена такому типу атак.
Выдумать и запомнить длинный уникальный код совсем не сложно:
Мнемонику может придумать каждый для себя.
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX - достаточно символов?
и он легко может быть одинаковым в нескольких местах сети
(если вы, конечно, доверяете владельцем серверов и безопасности самих серверов).
А вообще, безопасность - эта тема совсем другого разговора
и не касается впрямую удобства пользователя.
И еще, я не пытаюсь ничего навязать.
Я лишь предлагаю более критично относиться к шаблонам мышления.
Ярослав Бирзул пишет нам 22 октября, 2008 в 5:55
> Следуя вашей логике, если использовать уникальные логины,
то они (логины) должны приобретать вид 4719817816917471917713
(ведь пользователей интернета из двух миллиардов скоро станет тысяча, (что они кушать, пардон, будут интересно :) )
Никита, вы вообще читаете, что я пишу? Прирост сделан чтобы избежать перебора уникальных идентификаторов вручную.
> Однако таких уникальных логинов (равно и уникальных е-мэйлов) я что-то не встречал.
И причина очень проста - никто не пользуется только десятиричными цифрами ни в емайлах,
Достаточно посмотреть на мой логин: DezmASter. Если где-то он встречается - значит это я. Простой? Да. Уникальный? Да. Но его может ввести любой, если он не будет застрахован с помощью пароля.
> Кроме того, пользователей даже у больших порталов много меньше, чем пользователей интернета вообще.
Глупости. FaceBook вам как пример.
> По поводу “небезопасности”… Брутфорсу на самом деле глубоко начихать
Разве я где-то хоть словом обмолвился о брутфорсе? Я сказал “перебор паролей”.
> достаточно символов?
Вполне. А теперь воспроизведите его заново.
> и он легко может быть одинаковым в нескольких местах сети
Именно поэтому мнемоника пасует перед набором цифр.
> и не касается впрямую удобства пользователя.
Ошибаетесь.
> И еще, я не пытаюсь ничего навязать.
Неужто?
> Я лишь предлагаю более критично относиться к шаблонам мышления.
Я тоже предлагаю вам более критично относится к СВОИМ шаблонам мышления, и подтверждать своё мнение аргументацией из авторитетных источников, а не “должно быть так, потому что я так сказал!”.
Внимательно прочитайте эту страницу: http://www.birzool.com/info/
На будущее, чтобы избежать подобных ситуаций, Никита, вам стоит аргументировать свои мысли как это делаю я.
Это типа логин тут пишет нам 22 октября, 2008 в 6:04
> Никита, вы вообще читаете, что я пишу?
Я - не Никита. Да читаю.
Ярослав Бирзул пишет нам 22 октября, 2008 в 6:07
> Я - не Никита. Да читаю.
Тогда тут вы оставили заведомо ложную информацию:
http://my.mail.ru/mail/klokov16/
Ярослав Бирзул пишет нам 20 ноября, 2008 в 7:07
Snowcore, как ни странно: главное в форме авторизации - последовательность переключения полей и ссылок с помощью клавиши Tab
:)
PS: из личных наблюдений.
kvint пишет нам 27 ноября, 2008 в 4:14
В самом деле, интересная статья. Очень кстати. Интересует такой вопрос:
В основном при регистрации и логинизации фигурируют два поля (login/email и пароль). В форме восстановления пароля – одно (email). Так вот, целесообразно ли будет объединить все три формы в одну? То есть кнопка входа будет выполнять собой три функции – войти, зарегистрироваться или выслать пароль.
Такой вариант: пользователь вводит email и пароль, жмет «войти / зарегистрироваться». Если он зарегистрирован – логиним его, если нет – регистрируем, если логин такой есть, но пароль неверный – предлагаем ему напомнить пароль, скрывая поле пароля и превращая кнопку «войти / зарегистрироваться» в кнопку «выслать пароль».
Что вы скажете на это ?
Ярослав Бирзул пишет нам 27 ноября, 2008 в 11:20
kvint, скажу, что это может стать новым трендом при должной реализации. Но описанный вариант уж очень неинтуитивен на данный момент.
Николай Громов (nicothin) пишет нам 14 декабря, 2008 в 1:20
вызвало интерес расположение ссылки, регистрирующей пользователя.
логично ввести имя и желаемый пароль и нажать «зарегистрироваться» — при этом хорошо бы, чтоб под полем пароля появлялось поле для ввода электронного адреса и кнопка «вход» менялась на «зарегистрировать» (ну и проверка заполнения полей, конечно).
Ярослав Бирзул пишет нам 14 декабря, 2008 в 6:01
Николай, о регистрации ведь речь не идет. Тут целиком упор на удобный вход на сайт уже зарегистрированного пользователя.
Николай Громов (nicothin) пишет нам 14 декабря, 2008 в 6:45
Ярослав: да просто ссылка упоминается в финальном варианте формы, вот и подумалось о функционале.
поскольку мне лично не встречались движки не требующие хирургического лечения для приобретения подобного функционала, я остаюсь риверженщем ссылки на регистрацию и напоминание пароля под кнопкой входа.
Ярослав Бирзул пишет нам 14 декабря, 2008 в 6:48
А зачем тут хирургическое лечение движка? Достаточно в верстке перенести ссылки из под кнопки к полям − и вуаля.
Николай Громов (nicothin) пишет нам 14 декабря, 2008 в 3:08
я про описанный мной функционал говорил.
не умею я думать о веб-дизайне вне мыслей о том, как придуманное будет работать.