Я хотел сказать, что созданный ИИ контент бывает плохим и хорошим. Так же как и человек может создавать плохой и хороший контент.
Проблема потребления контента в соцсетях заключается в том, что делаем мы это во многом по привычке, которая сформировалась тогда, когда обмен «социальным шумом» с близкими реально влиял на качество жизни.
А когда мы встречаем в соцсетях ИИ-контент, то бессмысленность этого занятия (потребления контента в современных социальных сетях с алгоритмическими лентами) становится видна очень отчётливо.
В приложении YouTube в горизонтальном фулскрине можно нажимать на любое место прогресс-бара (если правша, то скорее всего это будет правая часть прогресс-бара) и водить пальцем влево или вправо для перемотки видео назад или вперёд.
Да, это не самое очевидное действие, но я его уже много где встречал и уже в целом ожидаю, что проигрыватель поддерживает этот жест
Имхо, стоит задуматься о правилах, если их соблюдение мешает наносить пользу.
Почему дедлайн в среду вечером? Возможно, в предыдущих итерациях этого ритуала участникам требовалось время от последней записи до начала встречи, чтобы решить, посещать её или нет и спланировать день, как-то подготовиться, но со временем потребность в этом отпала. Но тогда стоит обновить правило.
Возможно, выбрали это время просто так. Тогда стоит выбрать какое-то рациональное время дедлайна, так как систематические исключения из правил расхолаживают коллектив.
В анонсе встречи указано, что записаться можно до обеда среды. Далее вы пишете, что кто-то запрыгивает в последний вагон в ночь со среды на четверг. Получается, описанное в аносне — скорее рекомендации, нежели правила проведения мероприятия?
Был неоплачиваемый месяц испытательного срока. Правильно ли я понимаю, что стажировка уже оплачивается? Сколько % примерно зарплата стажёра составляет от зарплаты джуниора?
И правильно ли я понимаю, что если это стажировка в команде PR, то это скорее маркетинговый дизайн, чем продуктовый?
Интересная статья. Но стоит уточнить, что эффекта Даннинга — Крюгера не существует. Это пример автокорреляции, которого не замечали до 2016 года. Если измерить эффект статистически достоверным способом, он исчезнет. Здесь можно почитать тезисно и есть ссылка на подробную статью на русском (и её оригинал на английском).
Но рекомендации в этом параграфе всё равно полезны: не вестись на манипулятивный, эмоциональный, экспертно-уверенный стиль высказываний.
Хорошая статья, но не хватает информации об авторе, даже фамилии в профиле нет. На примере какой компании собрана статистика и получен опыт работы с кандидатами? Это реальный опыт автора или сочинение на тему?
В самом первом примере эмоциональный вариант вводит в заблуждение. Ошибка 403 обычно отображается, когда у пользователя нет прав для просмотра страницы. В эмоциональном же варианте написано, как будто это какой-то сбой, над устранением которого разработчики уже работают
Забавно, что недавно вышла статья на похожую тему, но я её не видел ранее. Моя статья вдохновлена именно случаем на работе, о котором я написал в самом начале.
Если человек действительно размечает так почту, то с его точки зрения ничего не изменится (пока он не захочет завести ещё один аккаунт). Нормализация нужна только для того, чтобы сверить регистрируемый имейл с уже зарегистрированными в системе и не дать завести аккаунт с почтой anton+habr@gmail.com, когда там уже есть anton+habrahabr@gmail.com.
Требование от безопасников или комплаенса касалось именно того, можем ли мы сообщать, что указанный адрес электронной почты уже зарегистрирован в нашей системе. То есть можем ли мы сказать "пользователь с таким адресом уже зарегистрирован" или должны говорить менее конкретное и понятное пользователю (или злоумышленнику, который проверяет, есть ли пользователи таких-то имейлов среди наших пользователей) "с таким адресом зарегистрироваться нельзя".
В некоторых компаниях это могут быть требования безопасников. В некоторых компаниях, деятельность которых регулируется, это может быть требованиям регулятора или закона, и тогда об этом дизайнерам должен сообщить комплаенс.
Случай, когда разные почты после плюса достанутся разным пользователям, крайне маловероятен. Его я упоминаю в статье. Если такое может произойти в каких-то почтовых сервисах, это не станет проблемой безопасности, так как в базу данных следует сохранять не нормализованный адрес, а полный, с плюсом и тем, что после него. Нормализация нужна именно для сравнения с уже существующими имейлами при регистрации новых аккаунтов.
А если говорить об ошибках, можно придумать разные примеры. Например, пользователь сначала зарегистрировался на Хабре с тегом anton+habrahabr@gmail.com, а потом, подзабыв об уже сделанной регистрации и выбранном для этого ресурса теге, регистрируется с тегом anton+habr@gmail.com. То есть это ошибка не на уровне опечатки, а не уровне оговорки или работы памяти.
Я бы здесь уточнил, что, несмотря на gmail.com в примерах, Гмейлу свойственно именно игнорирование точек. А остальные штуки с регистром, доменными алиасами и субадресацией свойственны всем основным почтовикам
Я в выводе об этом и написал. Вся эта дополнительная логика — это дополнительная работа. И надо думать в каждом конкретном случае, стоит ли она того, чтобы снизить вероятность определённой ошибки. Приведённые в пример сервисы вроде ChatGPT, Notion, Amazon отслеживают только регистр. А для тестировщиков не сложно сделать исключение по корпоративному домену
Возможно, я недостаточно акцентировал на этом моменте внимание. "Убрать плюс" — это речь о нормализации имейла. При этом в базу сохраняется и исходный, и нормализованный имейл. И письма отправляться должны на исходный
Я не предлагаю отрезать «+» и всё после него. Наоборот, в базу должен сохраняться такой имейл, который пользователь указал при первичной регистрации, чтобы работала борьба со спамом. Но вот уже дальнейшие регистрации с этим же ящиком — не позволять
Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.
Я хотел сказать, что созданный ИИ контент бывает плохим и хорошим. Так же как и человек может создавать плохой и хороший контент.
Проблема потребления контента в соцсетях заключается в том, что делаем мы это во многом по привычке, которая сформировалась тогда, когда обмен «социальным шумом» с близкими реально влиял на качество жизни.
А когда мы встречаем в соцсетях ИИ-контент, то бессмысленность этого занятия (потребления контента в современных социальных сетях с алгоритмическими лентами) становится видна очень отчётливо.
В приложении YouTube в горизонтальном фулскрине можно нажимать на любое место прогресс-бара (если правша, то скорее всего это будет правая часть прогресс-бара) и водить пальцем влево или вправо для перемотки видео назад или вперёд.
Да, это не самое очевидное действие, но я его уже много где встречал и уже в целом ожидаю, что проигрыватель поддерживает этот жест
Эх, уже 26…
Имхо, стоит задуматься о правилах, если их соблюдение мешает наносить пользу.
Почему дедлайн в среду вечером? Возможно, в предыдущих итерациях этого ритуала участникам требовалось время от последней записи до начала встречи, чтобы решить, посещать её или нет и спланировать день, как-то подготовиться, но со временем потребность в этом отпала. Но тогда стоит обновить правило.
Возможно, выбрали это время просто так. Тогда стоит выбрать какое-то рациональное время дедлайна, так как систематические исключения из правил расхолаживают коллектив.
В анонсе встречи указано, что записаться можно до обеда среды. Далее вы пишете, что кто-то запрыгивает в последний вагон в ночь со среды на четверг. Получается, описанное в аносне — скорее рекомендации, нежели правила проведения мероприятия?
Был неоплачиваемый месяц испытательного срока. Правильно ли я понимаю, что стажировка уже оплачивается? Сколько % примерно зарплата стажёра составляет от зарплаты джуниора?
И правильно ли я понимаю, что если это стажировка в команде PR, то это скорее маркетинговый дизайн, чем продуктовый?
Интересная статья. Но стоит уточнить, что эффекта Даннинга — Крюгера не существует. Это пример автокорреляции, которого не замечали до 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 отслеживают только регистр. А для тестировщиков не сложно сделать исключение по корпоративному домену
Возможно, я недостаточно акцентировал на этом моменте внимание. "Убрать плюс" — это речь о нормализации имейла. При этом в базу сохраняется и исходный, и нормализованный имейл. И письма отправляться должны на исходный
Я не предлагаю отрезать «+» и всё после него. Наоборот, в базу должен сохраняться такой имейл, который пользователь указал при первичной регистрации, чтобы работала борьба со спамом. Но вот уже дальнейшие регистрации с этим же ящиком — не позволять
Согласен, универсальных правил нет. Но есть базовые рекомендации — такие решения, которые обычно хорошо работают в своей сфере (я бы разделил массовые и профессиональные интерфейсы). Эти базовые рекомендации можно применять по умолчанию, но не считать догмой. Стоит каждый раз задумываться, есть ли в конкретном случае факторы, из-за которых придётся от базового правила отступить.
Заголовок статьи, как мне кажется, как раз подсвечивает, что у базового решения есть свои недостатки, о которых полезно знать.
Это уже вопрос терминологии. В данном случае первое поле действительно может по факту оказаться необязательным. Но оно таковым оказывается только после того, как второе поле становится заполненным. То есть по умолчанию первое поле не необязательное, а «условно обязательное».
Если в форме два условно обязательных поля, дизайнер скорее всего поставит на первое место поле какое-то особое поле: либо то, которое бизнес хочет чаще видеть заполненным, либо то, которое по факту чаще заполняют пользователи.
Таким образом рекомендация помещать фокус в первое поле в форме кажется вполне разумной.
«Особенный конфуз может случиться, если первое поле не обязательное для заполнения. Или если форма структурирована таким образом, что пользователи привыкли заполнять её с конца» — это уже какие-то совсем экстремальные случаи. Если дизайнер сделал форму, в которой первое поле необязательное, вопрос к этому дизайнеру.