Интересная статья. Но стоит уточнить, что эффекта Даннинга — Крюгера не существует. Это пример автокорреляции, которого не замечали до 2016 года. Если измерить эффект статистически достоверным способом, он исчезнет. Здесь можно почитать тезисно и есть ссылка на подробную статью на русском (и её оригинал на английском).
Но рекомендации в этом параграфе всё равно полезны: не вестись на манипулятивный, эмоциональный, экспертно-уверенный стиль высказываний.
Хорошая статья, но не хватает информации об авторе, даже фамилии в профиле нет. На примере какой компании собрана статистика и получен опыт работы с кандидатами? Это реальный опыт автора или сочинение на тему?
В самом первом примере эмоциональный вариант вводит в заблуждение. Ошибка 403 обычно отображается, когда у пользователя нет прав для просмотра страницы. В эмоциональном же варианте написано, как будто это какой-то сбой, над устранением которого разработчики уже работают
Забавно, что недавно вышла статья на похожую тему, но я её не видел ранее. Моя статья вдохновлена именно случаем на работе, о котором я написал в самом начале.
Если человек действительно размечает так почту, то с его точки зрения ничего не изменится (пока он не захочет завести ещё один аккаунт). Нормализация нужна только для того, чтобы сверить регистрируемый имейл с уже зарегистрированными в системе и не дать завести аккаунт с почтой anton+habr@gmail.com, когда там уже есть anton+habrahabr@gmail.com.
Требование от безопасников или комплаенса касалось именно того, можем ли мы сообщать, что указанный адрес электронной почты уже зарегистрирован в нашей системе. То есть можем ли мы сказать "пользователь с таким адресом уже зарегистрирован" или должны говорить менее конкретное и понятное пользователю (или злоумышленнику, который проверяет, есть ли пользователи таких-то имейлов среди наших пользователей) "с таким адресом зарегистрироваться нельзя".
В некоторых компаниях это могут быть требования безопасников. В некоторых компаниях, деятельность которых регулируется, это может быть требованиям регулятора или закона, и тогда об этом дизайнерам должен сообщить комплаенс.
Случай, когда разные почты после плюса достанутся разным пользователям, крайне маловероятен. Его я упоминаю в статье. Если такое может произойти в каких-то почтовых сервисах, это не станет проблемой безопасности, так как в базу данных следует сохранять не нормализованный адрес, а полный, с плюсом и тем, что после него. Нормализация нужна именно для сравнения с уже существующими имейлами при регистрации новых аккаунтов.
А если говорить об ошибках, можно придумать разные примеры. Например, пользователь сначала зарегистрировался на Хабре с тегом anton+habrahabr@gmail.com, а потом, подзабыв об уже сделанной регистрации и выбранном для этого ресурса теге, регистрируется с тегом anton+habr@gmail.com. То есть это ошибка не на уровне опечатки, а не уровне оговорки или работы памяти.
Я бы здесь уточнил, что, несмотря на gmail.com в примерах, Гмейлу свойственно именно игнорирование точек. А остальные штуки с регистром, доменными алиасами и субадресацией свойственны всем основным почтовикам
Я в выводе об этом и написал. Вся эта дополнительная логика — это дополнительная работа. И надо думать в каждом конкретном случае, стоит ли она того, чтобы снизить вероятность определённой ошибки. Приведённые в пример сервисы вроде ChatGPT, Notion, Amazon отслеживают только регистр. А для тестировщиков не сложно сделать исключение по корпоративному домену
Возможно, я недостаточно акцентировал на этом моменте внимание. "Убрать плюс" — это речь о нормализации имейла. При этом в базу сохраняется и исходный, и нормализованный имейл. И письма отправляться должны на исходный
Я не предлагаю отрезать «+» и всё после него. Наоборот, в базу должен сохраняться такой имейл, который пользователь указал при первичной регистрации, чтобы работала борьба со спамом. Но вот уже дальнейшие регистрации с этим же ящиком — не позволять
Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.
«Вмешиваемся, только если произошел срыв сценария, чтобы помочь респонденту и посмотреть оставшийся участок флоу (при технической возможности).» — а как это учитывается в столбце «Прошёл этапов»? Записывается количество этапов, пройденных до срыва?
Для 12-го пункта не хватает какого-то примера. Слишком абстрактно. Тезис: «Иногда надо переделать базовое, фундаментальное решение». Ну да, такое бывает, но что считается базовым решением в проектировании интерфейсов, какие новые вводные или совершённые в проектировании ошибки могут привести к изменению базового решения, как избежать таких ситуаций? Может быть, пример из твоей практики сделал бы тезис понятнее. Иначе кажется, что это лишний пункт для статьи с таким заголовком.
Если оставить чекбокс «Мало соуса», будет не вполне ясно, что будет, если он выключен. Обычная порция соуса, много соуса, совсем без соуса? Лучше заменить на радиогруппу с конкретными вариантами добавления соуса
Интересная статья. Но стоит уточнить, что эффекта Даннинга — Крюгера не существует. Это пример автокорреляции, которого не замечали до 2016 года. Если измерить эффект статистически достоверным способом, он исчезнет. Здесь можно почитать тезисно и есть ссылка на подробную статью на русском (и её оригинал на английском).
Но рекомендации в этом параграфе всё равно полезны: не вестись на манипулятивный, эмоциональный, экспертно-уверенный стиль высказываний.
Хорошая статья, но не хватает информации об авторе, даже фамилии в профиле нет. На примере какой компании собрана статистика и получен опыт работы с кандидатами? Это реальный опыт автора или сочинение на тему?
В самом первом примере эмоциональный вариант вводит в заблуждение. Ошибка 403 обычно отображается, когда у пользователя нет прав для просмотра страницы. В эмоциональном же варианте написано, как будто это какой-то сбой, над устранением которого разработчики уже работают
Просто для справки: сейчас акции Фигмы стоят около 70 долларов за штуку
На Gmail разные люди не могут завести адреса vasya.b@gmail.com и vasyab@gmail.com. Если вы уже получили в Gmail адрес vasya.b@gmail.com, и какой-то Вася Б. решит завести себе там адрес vasyab@gmail.com, то Gmail скажет, что этот адрес уже занят
Да, это то, что идёт до @. В стандарте так и называется "local part"
Забавно, что недавно вышла статья на похожую тему, но я её не видел ранее. Моя статья вдохновлена именно случаем на работе, о котором я написал в самом начале.
Если человек действительно размечает так почту, то с его точки зрения ничего не изменится (пока он не захочет завести ещё один аккаунт). Нормализация нужна только для того, чтобы сверить регистрируемый имейл с уже зарегистрированными в системе и не дать завести аккаунт с почтой anton+habr@gmail.com, когда там уже есть anton+habrahabr@gmail.com.
Требование от безопасников или комплаенса касалось именно того, можем ли мы сообщать, что указанный адрес электронной почты уже зарегистрирован в нашей системе. То есть можем ли мы сказать "пользователь с таким адресом уже зарегистрирован" или должны говорить менее конкретное и понятное пользователю (или злоумышленнику, который проверяет, есть ли пользователи таких-то имейлов среди наших пользователей) "с таким адресом зарегистрироваться нельзя".
В некоторых компаниях это могут быть требования безопасников. В некоторых компаниях, деятельность которых регулируется, это может быть требованиям регулятора или закона, и тогда об этом дизайнерам должен сообщить комплаенс.
Случай, когда разные почты после плюса достанутся разным пользователям, крайне маловероятен. Его я упоминаю в статье. Если такое может произойти в каких-то почтовых сервисах, это не станет проблемой безопасности, так как в базу данных следует сохранять не нормализованный адрес, а полный, с плюсом и тем, что после него. Нормализация нужна именно для сравнения с уже существующими имейлами при регистрации новых аккаунтов.
А если говорить об ошибках, можно придумать разные примеры. Например, пользователь сначала зарегистрировался на Хабре с тегом anton+habrahabr@gmail.com, а потом, подзабыв об уже сделанной регистрации и выбранном для этого ресурса теге, регистрируется с тегом anton+habr@gmail.com. То есть это ошибка не на уровне опечатки, а не уровне оговорки или работы памяти.
Я бы здесь уточнил, что, несмотря на gmail.com в примерах, Гмейлу свойственно именно игнорирование точек. А остальные штуки с регистром, доменными алиасами и субадресацией свойственны всем основным почтовикам
Я в выводе об этом и написал. Вся эта дополнительная логика — это дополнительная работа. И надо думать в каждом конкретном случае, стоит ли она того, чтобы снизить вероятность определённой ошибки. Приведённые в пример сервисы вроде ChatGPT, Notion, Amazon отслеживают только регистр. А для тестировщиков не сложно сделать исключение по корпоративному домену
Возможно, я недостаточно акцентировал на этом моменте внимание. "Убрать плюс" — это речь о нормализации имейла. При этом в базу сохраняется и исходный, и нормализованный имейл. И письма отправляться должны на исходный
Я не предлагаю отрезать «+» и всё после него. Наоборот, в базу должен сохраняться такой имейл, который пользователь указал при первичной регистрации, чтобы работала борьба со спамом. Но вот уже дальнейшие регистрации с этим же ящиком — не позволять
Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.
«Вмешиваемся, только если произошел срыв сценария, чтобы помочь респонденту и посмотреть оставшийся участок флоу (при технической возможности).» — а как это учитывается в столбце «Прошёл этапов»? Записывается количество этапов, пройденных до срыва?
«Ну сделал и сделал»
Для 12-го пункта не хватает какого-то примера. Слишком абстрактно. Тезис: «Иногда надо переделать базовое, фундаментальное решение». Ну да, такое бывает, но что считается базовым решением в проектировании интерфейсов, какие новые вводные или совершённые в проектировании ошибки могут привести к изменению базового решения, как избежать таких ситуаций? Может быть, пример из твоей практики сделал бы тезис понятнее. Иначе кажется, что это лишний пункт для статьи с таким заголовком.
Если оставить чекбокс «Мало соуса», будет не вполне ясно, что будет, если он выключен. Обычная порция соуса, много соуса, совсем без соуса? Лучше заменить на радиогруппу с конкретными вариантами добавления соуса
А есть в паблике эти хелперы, может быть, в виде файла в Фигма-комьюнити?
"Итого 12 токенов — View, Navigation, Background, Border, Overlay, Primary, Secondary, Accent, Danger, Success, Warning, OnAccent, Disabled."
Я посчитал, получается 13 токенов…