Comments 57
Повторный ввод пароля при регистрации
— Если я ошибся, скажи сразу. А не заставляй делать всё заново.
И как я скажу, что пользователь ошибся? Как я пойму?
Особенно это критично на мобильных устройствах, где вероятность ошибки выше
Так может не так уж и бессмысленно? Пользователь дважды вводит пароль и вероятность, что он ошибся дважды на несколько порядков ниже, чем вероятность ошибиться один раз.
Мне кажется, важна причина в целом - использования пароля, как входа.
Это либо авторизация по почте, либо по нику. Что делает аккаунт менее "безопасным".
Если говорим про безопасность, по исследованиям - 2 из 3 человеков выбирают биометрию, как способ авторизации. Проще и воспринимается безопаснее.
Отсюда, танцы с бубнами при создания пароля будто немного изживают себя. Но все же, если он требуется - используют живой валидатор, который сразу сообщает в моменте требования пароля. Увидела недавно, что условия начали упрощать для этого способа (не знаки+символы+латиница+цифры+названия заграничной страны, а связка символов+цифр).
Я бы тоже спросил, как система может сказать что пользователь ошибся, когда он вводит новую пароль, которую только что придумал?
del
Вот так, бро
Ну, я считаю что сама практика показывать пароли явным текстом, очень плохая по определению. Сколько из пользователей проверяют свои пароли после первого введения? Да и оно может быть полезно когда вводим пароль для входа в систему, а не при выборе нового пароля.
Кроме того, введение требований к пароли, вне зависимости от того какие они, на самом деле абсолютно бесполезно и только уменьшает пространство паролей никак не повышая их силу. «Password!1» – это словарный пароль, несмотря что полностью соответствует требованиям.
Это лишь твои домыслы и гипотезы, которые ничем не подтверждены. А пример выше - это база, которую должен знать любой Джун.
Дам тебе непрошеный совет: проверяй информацию прежде, чем утверждать что-то
Учитывая ваш второй абзац, вы сами говорите, что паролю - доверия нет. И проблема не в подсказках к полю/удобства ввода проверочного пароля. А в самой логике его использования, как основного способа последущего входа при регистрации.
Смысл тогда разбирать подфоу/кейс?
В формате хороших практик, отметила, где есть хорошие примеры решения этого флоу. Но опять же, крупные продукты, которые владеют огромной базой данных о пользователях, делают упор на другие способы авторизации.
Ну, почему? Надо просто не ограничивать пользователя в выборе пароля. И метод с повторным вводом на самом деле вполне надежный и проверенный временем – не надо придумывать варианты, просто чтобы что-то обновить. Точно так же как и не надо принуждать пользователя к безопасности – он все эти требования обойдет легко и с удовольствием. Надо сделать так, чтобы выбирая слабый пароль и если что случится, страдал только этот пользователь и не страдали остальные пользователи.
Расскажи эту теорию безопасникам)
Ну, безопасники – они разные. Корпоративные очень любят чтобы выглядело безопасно и официальные политики соблюдались. Является ли система безопасной на самом деле им совершенно безразлично.
Логичный филовсовский вопрос, а кому по вашему мнению тогда не безразлична безопасность пользователей? Стартапам?
Но, я понимаю, что мнение сформировано (скорее всего) из-за огромного количества слитых данных пользователей крупных сервисов.
И опять же это не повод - не стараться делать безопасные интерфейсы и придумывать новые механики тем же корпорациям.
а кому по вашему мнению тогда не безразлична безопасность пользователей?
Ну, например мне не безразлична безопасность моих же ресурсов в сети. А кстати, хорошая притча:
Однажды Сисадмин пожаловался Учителю:
– Мы выдали всем нашим пользователям индивидуальные пароли, а они не желают хранить их в тайне. Записывают на листочках и приклеивают к мониторам. Что нам делать? Как заставить их?
Инь Фу Во спросил:
– Сначала скажи, почему они это делают.
Сисадмин подумал и ответил:
– Может быть, они не считают пароль ценным?
– А разве пароль сам по себе ценный?
– Не сам по себе. Ценна информация, которая под паролем.
– Для кого она ценна?
– Для нашего предприятия.
– А для пользователей?
– Для пользователей, видимо, нет.
– Так и есть, – сказал Учитель. – Под паролем нет ничего ценного для наших работников. Надо, чтоб было.
– Что для них ценно? – спросил Сисадмин.
– Догадайся с трёх раз, – рассмеялся Учитель.
Сисадмин ушёл просветлённый и сделал на корпоративном портале персональные странички для всех работников. И на тех страничках был указан размер зарплаты. Узнав об этом, все пользователи забеспокоились о своих паролях. На другой день в курилке обсуждали размер зарплаты Главбуха. На третий день ни у кого не было видно листочков с паролями.
Можно сделать систему полностью опасной. Полностью безопасной ее сделать в принципе нельзя. К тому же, надо внимательно анализировать какие меры увеличивают безопасность и какие просто создают «видимость безопасности». Такая видимость намного, намного опаснее, чем не делать ничего. Вот я продемонстрировал, что требования к содержанию пароли никак не уменьшает возможность для пользователя придумать словарные пароли. И он наоборот – начнет их придумывать намного чаще, просто потому что запоминать реально сложного пароля очень трудно. Тем более, если эти пароли его вынуждают менять каждые 2..3 месяца. Наоборот – если настаивать чтобы пользователи использовали рандомные пароли + менеджер паролей, это запросто увеличит безопасность. Даже если советовать пользователей записывать пароли на листке, но чтобы хранили эту бумажку в бумажник , это тоже увеличит безопасность системы. Но оно выглядит «опасным» и поэтому такое никогда не примут.
Вы изначально говорили про безопасников корпораций) потому мой вопрос в полном виде звучал бы - каким конкретно безопасникам тогда не все равно на данные пользователей? Или таких безопасников нет?
Демонстрация притчи - это базовые байки по поводу безопасности данных защищенных паролем, которые имеют место быть. Но пароли - это не единственный способ авторизации на момент 2025 года. Их основных только 14 (а так их более 30), и их используют в разных комбинациях, чтобы защитить данные пользователя. И/или делать вход в сервисы комфортным.
Корпоративным работникам «не все равно» только в рамках «если что, я не виноват». Если он, в случае инцидента, может доказать, что он сделал все необходимое для безопасности, соблюдал официальные политики компании и лучшие практики, то ему это будет совершенно достаточно. Даже если у человека безопасность является хобби, то он вряд ли начнет экспериментировать с корпоративными ресурсами. А то очень быстро закончит свою карьеру, а то и обвинят и посадят.
Откуда теория про безразличие? Это ваш личный опыт?
Все решения с ориентацией на мобилы вместо нормальных платформ хуже любого из "устаревших". Ненавижу телефонистов.
Поддерживаю тебя
Да уж. Приучили их тыкать сосисками. Так они и по нужде когда ходят, тыкать не перестают. Какой уж тут UI..
Что именно ты имеешь ввиду под "нормальной платформой"?
PC разумеется.
Подразумевается не то, что мобильные платформы неполноценные (речь не об этом сейчас), а то, что если PC UX на мобилках плох (правда), то почему считается нормальным обратный путь - UX мобилок тащить на PC. Вот это необъяснимо.
Очень даже объяснимо: есть практика Mobile First. Она оптимизирует скорость и проста в масштабировании на десктопы.
Исторически сайты делали сначала для десктопа, а потом пытались адаптировать под мобильные. Это часто приводило к перегруженным интерфейсам на маленьких экранах.
Mobile First меняет приоритет: сначала создается версия для мобильного устройства (минимум контента и элементов), а затем интерфейс расширяется для больших экранов
Очень хорошо обосновано, почему перенос десктопных практик на мобилы плох. Но, ничего не сказано о том, что мобильный интерфейс на десктопе не менее убог, и о том, почему вдруг решили, что так делать можно. Судя по всему, никакого "а затем" после "сначала" в большинстве случаев не бывает.
Хочется пруфов. Хотябы два примера, где мобилку плохо перенесли на десктоп
Навскидку, например, сайт baucenter. Теперь на странице помещается где-то на 50% меньше информации. Шрифты, отступы и тд сделаны "по-мобильному", что на десктопе выглядит как полный хаос. Там еще креативные дизайнеры поработали. Возможно, часть хаоса не из-за мобиле-ферст, а из-за них. Не самый красноречивый пример, но первый вспомнившийся.
Интересный пример, прочекала)
Я бы поспорила про мобайл-фёрст, ибо часть решений выглядит совсем не мобильно, а откровенно плохо. Например карточки товара, которые адаптировали плохо именно с веба, а не наоборот (это можно судить по отступам, иерархии шрифтов). Думаю, проблема в ресурсах выделенных на дизайн и разработку.
НО! Давно не видела приятной плашки сверху про переход на старый дизайн сайта) К слову, в старом дизайне мобильная версия намного юзабельнее)
НО! Давно не видела приятной плашки сверху про переход на старый дизайн сайта)
Святы люди! надеюсь, это не отмазка ,которая через полгода пропадет (не признавать же, что бюджет ушел в никуда.
Да, дизайн плох сам по себе, но такой его вид уже однозначно вызывает ассоциации "mobile first" (разреженные шрифты, поля ввода с мусором, размеры плашек излишне большие для десктопа, в целом меньше информации на единицу площади и тд).
Простите, я кроме откровенно плохой верстки фронта и попытки дизайнера задействовать френдли-тренды не увидела) Мобайл-ферст, банально от названия, говорит о том, что на мобиле должно быть удобно в первую очередь. Не удобно. И также не читаемо)
Косвенные признаки - всё должно быть большое с большими промежутками, чтобы удобно тыкать пальцами. Вот оно такое в примере и есть - большое с большими промежутками.
Вы можете рассказывать, что это не имеет отношения к мобильному дизайну, всё равно никто не поверит
Выше скрин с карточками товара в мобильной адаптации) элемент дизайн-системы, с которым должны хотеть/чаще всего взаимодействуют в е-комерце.
И он как раз отсекает ваши косвенные признаки, потому что нет ни больших промежутков, нет удобства тыкать пальцами. Некорректные цветовые акценты, не читаемые заголовки, (например - невозможно (хотя по цвету должно) тапнуть на отзывы). Ненужная в рамках мобилы кнопка добавления в список по соседству с корзиной (если я правильно считала иконку), это решают уже давно иначе в мобайле.
я не смотрю мобильную адаптацию, я смотрю десктопную версию. Да, нечитаемые заголовки и пр. Но, к этому - конские размеры. Всё большое, зачем это на десктопе? Просто сделали для мобилы, а то, что теперь даже два ряда карточек перестали помещаться на экране, кого волнует? На мобиле норм. Старая версия - цена навскидку тем же шрифтом, но выделенная жирным. Для чего делать цифры 8мм в высоту? для мобилы. Для чего увеличивать поля ввода и увеличивать в них шрифт? для мобилы. Для чего увеличивать расстояния между элементами списка слева? Так для мобилы же!
Вы можете не соглашаться, это просто словесное описание ужаса человека, увидевшего это. Ведь за новый дизайн заплачены деньги, делали профи. Значит в этом ужасе есть какой-то смысл? Какой? Так для мобил же делали.
Как-то так.
У получателя 10 счетов в разных филиалах или в одном. Как по инн получить нужный?
получатель указывает ИНН нужного банка, вместо названия банка, ИНН, БИК, корсчета и что там еще.
получатель указывает ИНН нужного банка
Что есть глупо. Если все равно какой-то набор цифр вводить - то надо вводить сразу все нужные в одном поле, а не размазывать по нескольким Смотри мое сообщение ниже про IBAN. Но банки почему-то его использование для внутренних платежей не внедряют.
Зачем вводить все нужные? Зачем их вообще знать?
Зачем вводить все нужные? Зачем их вообще знать?
У меня, скорее, вопрос, зачем знать какие-то ИНН что банка, что получателя?
На но платежке (любого вида) должен же быть условный адрес назначения, куда деньги должны попасть? Ну вот и копипастим этот IBAN, не разбираясь с его структурой.
Одна непрерывная строка тут удобна тем, что ее можно в баркод закодировать и быстро прочитать в форму почти чем угодно.
С другой стороны, есть еще ГОСТ Р 56042-2014 который про тот QR, что обычно на платежках ЖКХ стоит, но никто не запрещает использовать его еще много где -- это, по сути, данные для той стандартной формы банковского перевода. И приложения банков его могут более-менее читать. А вот предоставлять все реквизиты в таком виде мало кто догадывается.
А руками вводить неудобно что так что так.
> зачем знать какие-то ИНН что банка, что получателя?
Мне всё равно, как называется эта строка. Главное, чтобы она была одна. Сейчас при вводе ИНН (относительно короткой строки) все остальные поля заполняются автоматом, что для меня сущее облегчение.
PS: могли бы уточнить, что IBAN включает все банковские реквизиты, включая сам счет. Было бы понятнее. Я говорил только о реквизитах банка.
Так-то да. Одна строка для полного описания назначения
могли бы уточнить, что IBAN включает все банковские реквизиты, включая сам счет.
Смысл в том, что это несущественно - знать, что там у него внутри. Существенно, что достаточно одной этой строки, без дополнительного ввода. чтобы деньги попали туда, куда надо.
Правда, часто надо еще разные номер лицевого счета указывать, что там не предусмотрено, и их нужно отдельно вводить. Тут совсем одной строки не предусмотрено и QR по ГОСТ Р 56042-2014 будет удобней, хоть он и здоровый.
Смысл в том, что это несущественно - знать, что там у него внутри.
Ну вот вы второй фразой себя же опровергаете
Правда, часто надо еще разные номер лицевого счета указывать
Мне реально неважно, что означает тот номер, который я ввожу. Мне должно его хватать для всего. И я не должен думать, нужно ли в данном случае еще что-то довводить, или нет.
PS: я понятия не имею, что такое "лицевой счет" и чем он от других счетов, которыми меня пытают банки в своих платежках, отличается. Оплата по платежкам - боль.
Те, кто предлагает "оплату по QR" такие же недалёкие создания, как и те, кто требует все двадцать реквизитов банка -
Каким образом мне оплатить по QR с квитанции, прошедшей через средний офисный ксерокс или сделать то же самое с десктопа, они не думают.
: я понятия не имею, что такое "лицевой счет" и чем он от других счетов, которыми меня пытают банки в своих платежках, отличается.
А это проблема уже не столько UI-я, сколько всей системы оплат, увы.
Потому что банк не может за организацию учитывать, за что там ей деньги пришли.
Те, кто предлагает "оплату по QR"
Больше никуда нужные данные просто физически не влазят. Даже если изобрести индивидуальный идентификатор на прлатежку, который включает все-все-все - это будет слишком длинная последовательность цифр.
Каким образом мне оплатить по QR с квитанции
Печать QR покрупнее, чтобы выживал при копировании. Починить ксерокс. Если он не выполняет свою функцию - сохранять содержание документа, то он явно не пригоден к эксплуатации.
сделать то же самое с десктопа, они не думают.
Если набирать руками - удобно не будет никак. Ни на десктопе, ни на телефоне. А у большинства людей есть таки сенсоры (в телефонах, да), чтобы руками не набирать. И, увы, сейчас "без смартфона жизни нет". Тот, кто сейчас настаивает, что смартфоном пользоваться не намерен - это уже сознательный выбор неудобного способа.
Но есть альтернативы, да.
(1) когда плательщик сообщает, откуда брать деньги (например, вбив номер банковской карты). И набирать надо мало. Но там свои проблемы, как мы знаем.
(2) получатель платежа посылает куда-то платежку, чтобы банк ее увидел и предложил оплатить. Вопрос, только, куда и как.
вот IBAN - полумера какая-то. Почему не сделать формат, при котором вся информация о платеже в одном поле, не понимаю. Пусть думают, чего уж там.
А у большинства людей есть таки сенсоры (в телефонах, да), чтобы руками не набирать.
А некоторые люди принципиально мобилками не платят, и вообще не платят, пока не поймут на 100% что это за платеж и куда. А они говорят "платите по QR" и показывают его на экране десктопа. Показать рядом копируемую строку? Да ну, глупость какая.
Почему не сделать формат, при котором вся информация о платеже в одном поле, не понимаю
Который не пойдет тем, которые "вообще не платят, пока не поймут на 100% что это за платеж и куда" - оно же нечитабельное.
Вот как раз для тех, кто хочет знать - вся эта форма с кучей полей и сделана.
Показать рядом копируемую строку?
Показываемая картинка с QR-ом отлично скармливается банковскому приложению на том же десктопе в через тот виджет, что на телефоне говорит 'сканировать QR'. Просто перетаскиванием.
Вот как раз для тех, кто хочет знать - вся эта форма с кучей полей и сделана.
Вот мы и вернулись к ИНН (после ввода которого остальные поля заполняются автоматом) и номеру непосредственно счета, чего хватает для платежа.
Который не пойдет тем, которые "вообще не платят, пока не поймут на 100% что это за платеж и куда" - оно же нечитабельное.
пусть у меня в приложении оно развернется в читабельное. Тоже мне проблема.
отлично скармливается банковскому приложению на том же десктопе в том же виджете
не уверен, что у меня такое есть. не уверен, что вообще такое есть. проверю на всякий случай.
не уверен, что у меня такое есть. не уверен, что вообще такое есть. проверю на всякий случай
Если нет - шаг добавится. Придется картинку на диск сохранить и прочитать картинку с диска. Но если не позволяет перекидыванием - это косяк UI-я банка, а не самого способа представления платежки.
Вот, скажем, у Сбербанка выходит, если кнопку 'QR сканер'на десктопе кликнуть.
Сканирование из файла
.
Вообще, с поразительной лёгкостью вы заменяете шаги "скопировать реквизит, ввести в поле" на "сохранить (варианты - заскриншотить, вырезать, сохранить на диск), загрузить с диска картинку (не забыть удалить, мало ли)". Типа "это же одно и то же".
Разницы - пара секунд. Не существенно. Набирать длинные последовательности строк все равно не надо.
Разницы - пара секунд. Не существенно.
эмм.... действительно нечего сказать.
эмм....
Ну как...
Ноткей клиппера, выделяем область, картинка сразу улетает в Screenshots. - раз секунда. (Ну да, это не стандартный клиппер, там чуть дольше, но если человек не хочет мобильным телефоном пользоваться - он настроит рабочее место для таких операций)
Потом в банк-клиенте выбор картинки в 'недавних файлах' - два секунда.
Удалять - в рамках общей регулярной чистки компа и этого самого Screenshots.
В тот самый банк клиент логониться значительно дольше обычно. Не постоянно же его открытым держать?
Мне говорят "вот все реквизиты в этой строке под названием ABC", я "ок, копирую в приложение в поле ABC". На этом всё.
Или мне говорят - "как-нибудь загони эту картинку в свое приложение". А написано ли рядом, что это вообще можно делать? А написано ли что это можно сделать в моём приложении? А каким образом это можно делать? И тд.
Вместо стандартной операции предлагается какой-то мэджик с использованием стороннего инструмента, предположением, что у меня есть какие-то "недавние файлы", убеждением меня, что я должен что-то там регулярно чистить.
И между этими вариантами без стеснения ставится знак равенства.
скажите, что это стёб и я успокоюсь.
А написано ли что это можно сделать в моём приложении?
...
Вместо стандартной операции
Предлагается сделать стандартную операцию "Просканируйте этот QR вашим платежным приложением"
Для подавляющей части народа это означает телефоном. А тот, кто телефоном не пользоваться не хочет - он сам решил и научился делать эту стандартную операцию другим способом прямо на десктопе. И да, это написано - в этом самом приложении банка. И иконкой показано, что можно QR тут ему скормить. Кто же виноват, что пользователь возможность игнорирует.
И между этими вариантами без стеснения ставится знак равенства.
Равенства не ставится. Идет сравнение с процедурой набивания каких-то ИНН-ов и прочих циферок руками в какой-то форме.
я вас понял. или это стёб или настолько другой ход мыслей, что разговаривать бесполезно.
я вас понял. или это стёб или настолько другой ход мыслей
Другой ход. Как, кстати и желание платить именно с десктопа. Если человек хочет (по современным меркам) странного - то ему придется использовать немного странными способами. Тем более, как я на примере Сбербанка показал - все вполне нормально и так, если банк в своем десктопном клиенте не халтурит с возможностями.
Большинство российских банков до сих пор предлагают форму для перевода, в которой пользователь должен вручную указать БИК, корреспондентский счёт, ИНН и КПП
И поэтому ЦБ уже давно (хотя нужно было сильно раньше) одобрил использование IBAN.
Ну да, длинный, но поле ввода одно, не надо задумываться что есть что.
Да уж, одна из самых неудобных вещей - типичные phpшные формы регистрации на всяческих сайтах/форумах. Мало того, что скопипастить пароль во второе поле ввода часто не предоставляется возможным (мешает отсутствие значка показать пароль, при <input type="password">).
А при неверном вводе сбрасываются ВСЕ поля формы, что сильно раздражает. Особенно при наличии дополнительной капчи или наличия большого количества полей. Хотя вполне можно было реализовать автосохранение введённых данных на время регистрации через LocalStorage.
Правильный UX - это
вот :)
много лет учимся, потом - много десятилетий используем без изменений. :)
UX-рудименты, часть 2: дизайн, который остался жить в 2012-м