Comments 160
Очевидный подвох — ожидание кода подтверждения, мыло конечно быстро приходит, но бывают и исключения
Правда, но та же фигня с ссылкой активации.
Собственно, именно это ожидание меня больше всего и волнует: пока ждёшь письма переключаешься на что-то другое и забываешь что хотел сделать. Так хоть страничка открыта остаётся
Собственно, именно это ожидание меня больше всего и волнует: пока ждёшь письма переключаешься на что-то другое и забываешь что хотел сделать. Так хоть страничка открыта остаётся
Можно в БД хранить не только код, но и ссылку на товар/страницу с которой перешел человек на регистрацию.
И сразу же после активации перенаправлять его туда, к просмотру товара.
И сразу же после активации перенаправлять его туда, к просмотру товара.
В своих проектах я так и делаю, только храню не в БД, а в сессии.
в БД все же лучше. если пользователь перешел на регистрацию с какой-то страницы, зарегался, письмо не пришло в первые n минут… пользователь забил и ушел. через пару часов ему на почту таки пришло письмо… он перешел по ссылке, аккаунт активировался и о чудо, его средиректили туда откуда он пришел. и тут сессии не помогут)
Вы не поняли, я в сессии храню ссылку откуда пользователь перешел на регистрацию. А затем при формировании письма выдергиваю из сессий URL, немножко его переделываю для активации и отправляю пользователю. Никаких редиректов он переходит на нужную страницу и профиль автоматически активируется.
Проблема в том, что через n минут сессия завершится, а вместе с ней погибнет и ваша ссылка.
Какая принципиальная разница в базе или в сессии?
Вообще-то я не говорил ни о каких принципиальных разницах.
Ну просто из этого предложения
я сделал вывод, что Вы упираете именно на хранение в сессии. Иначе зачем бы вообще об этом было упоминать, если принципиальной разницы нет?
Ну если это просто ремарка — прошу прощения за вмешательство.
Хотя при использовании сессии, на мой взгляд, остаётся описанная выше проблема
В случае, если пользователь «завис и задумался» в процессе регистрации, сессия может закончиться где-то на этом этапе. И отсылать на емейл будет, извините, нечего.
Случай, конечно, далёк от нормы, однако совсем отметать его возможность нельзя?
В своих проектах я так и делаю, только храню не в БД, а в сессии.
я сделал вывод, что Вы упираете именно на хранение в сессии. Иначе зачем бы вообще об этом было упоминать, если принципиальной разницы нет?
Ну если это просто ремарка — прошу прощения за вмешательство.
Хотя при использовании сессии, на мой взгляд, остаётся описанная выше проблема
RegisISVir В этот момент ссылка будет уже на e-mail'e пользователя.
Проблема в том, что через n минут сессия завершится, а вместе с ней погибнет и ваша ссылка.
В случае, если пользователь «завис и задумался» в процессе регистрации, сессия может закончиться где-то на этом этапе. И отсылать на емейл будет, извините, нечего.
Случай, конечно, далёк от нормы, однако совсем отметать его возможность нельзя?
Вы правы — нельзя. Но и хранить «левые» данные в базе не особо хочется. Да и обращаться к ней в лишний раз, тоже особого желания не возникает.
У меня вот на сайтах, кстати, вдруг участились случаи «потери сессии» прямо во время оформления заказа. Причём время жизни сессии у нас исчисляется не минутами, а часами. И всё равно — бывают прецеденты.
Какие же они «левые»? Самые что ни на есть актуальные данные. Опять повторю свой вопрос: чем в данном случае сессия отличается от базы данных принципиально? Почему вы предпочитаете хранить «левые» данные в сессии, которая может «погибнуть», вместо хранения их в постоянной базе данных, которая не подвержена случайным обрывам связи у клиента, случайным и специальным очисткам кук и т.п.?
Ведь, при необходимости, можно строго дифферинцировать «временные» данные, которые из базы данных можно регулярно вычищать.
Вы считаете, хранение всей информации в памяти (сессии) даёт большой и хороший выигрыш? Если речь о производительности, то, имхо, при достаточно большом объёме этой информации памяти будет немножко не хватать. И, как результат, часть будет храниться на диске? Кто Вам гарантирует, что работа с данными сессии в этом случае будет быстрее и эффективнее, чем работа с базой данных?
Или я мыслю категориями прошлого века?
Или у Вас есть какие-то другие резоны отмахиваться от базы данных в этом конкретном случае?
PS: сразу оговорюсь: я не считаю, что база данных в данном случае априори лучше — но всё же хотелось бы услышать более понятные аргументы в пользу сделанного выбора.
Вы правы — нельзя. Но и хранить «левые» данные в базе не особо хочется.
Какие же они «левые»? Самые что ни на есть актуальные данные. Опять повторю свой вопрос: чем в данном случае сессия отличается от базы данных принципиально? Почему вы предпочитаете хранить «левые» данные в сессии, которая может «погибнуть», вместо хранения их в постоянной базе данных, которая не подвержена случайным обрывам связи у клиента, случайным и специальным очисткам кук и т.п.?
Ведь, при необходимости, можно строго дифферинцировать «временные» данные, которые из базы данных можно регулярно вычищать.
Да и обращаться к ней в лишний раз, тоже особого желания не возникает.
Вы считаете, хранение всей информации в памяти (сессии) даёт большой и хороший выигрыш? Если речь о производительности, то, имхо, при достаточно большом объёме этой информации памяти будет немножко не хватать. И, как результат, часть будет храниться на диске? Кто Вам гарантирует, что работа с данными сессии в этом случае будет быстрее и эффективнее, чем работа с базой данных?
Или я мыслю категориями прошлого века?
Или у Вас есть какие-то другие резоны отмахиваться от базы данных в этом конкретном случае?
PS: сразу оговорюсь: я не считаю, что база данных в данном случае априори лучше — но всё же хотелось бы услышать более понятные аргументы в пользу сделанного выбора.
Скажем так — я рассуждал гораздо приземленней. Передо мной стоит задача — сохранить на некоторое время URL с которого пользователь перешел в модуль регистрации. Рассмотрим случай с сессией — что мы делаем? Одно движение сохраняем данные в сессию и все… и пользуемся ими при необходимости. Что же если рассмотреть случай с БД? В случае с БД, надо сначала установить связь с оной, записать данные в таблицу, затем когда мы захотим ими воспользоваться нужно будет достать данные из таблицы, и в конце концов, когда эти данные уже не понадобятся — нужно их удалить. Слишком много действий, но гарантированная надеждность (и то не всегда, вы согласны? Ведь из базой тоже что-то может случиться).
И так я прихожу к выводу, что во первых мне гораздо проще и быстрее сохранить в сессию, а так же на моих серверах сессию никуда почему-то не происходит потерь.
Сейчас мое мышление несколько сумбурно, вымотался на работе. Но мой итог таков:
Работа с сессией проходит гораздо проще, быстрее, и эффективней в плане производительности.
И так я прихожу к выводу, что во первых мне гораздо проще и быстрее сохранить в сессию, а так же на моих серверах сессию никуда почему-то не происходит потерь.
Сейчас мое мышление несколько сумбурно, вымотался на работе. Но мой итог таков:
Работа с сессией проходит гораздо проще, быстрее, и эффективней в плане производительности.
Можно сохранять URL страницы, с которой пришёл пользователь, прямо в форме регистрации… И не надо ни сессии ни БД…
Вот это, пожалуй, и есть оптимальное решение с учётом негарантированного времени доставки сообщений по электронной почте.
Отличный вариант.
UFO just landed and posted this here
Вот я так и сделал у себя год назад ишо.
Считаю что перед тем как делать регистрацию, где либо надо обратится к проблеме того, что она есть для владельца и для пользователя, т.е. я хочу сказать, что выше приведенный вариант регистрации может подходить лишь к малой доле веб проектов (это мое мнение). И может прежде чем что то разрабатывать, а в нашем примере заботиться юзабилити. Нужно сначала определить в какой степени нужна та или иная базовая функциональность (принятая на большинстве порталов за идеал) именно в нашем проекте. Подталкиваю к тому что прежде надо по пункту определить 1 2 3 и т.д. что есть что, кому что необходимо и возле каждого вариант реализации. Глядишь многие пункты окажутся ненужными, да и клиентам вашим понравится… ()
P.S. Прихожу каждый раз ко мнению, что если бы многие порталы вообще отказались от регистрации, то это им только пошло бы на пользу. (делайте то что необходимо. а не то что принято!, и многие проблемы юзабилити уйдут сами собой)
P.S. Прихожу каждый раз ко мнению, что если бы многие порталы вообще отказались от регистрации, то это им только пошло бы на пользу. (делайте то что необходимо. а не то что принято!, и многие проблемы юзабилити уйдут сами собой)
Почитав комментарии к этому посту и немного помедетировав, я всё больше склоняюсь к тому, что регистрация нужна лишь тогда, когда пользователь создаёт контент.
Надо ли это в интернет-магазине, думаю, зависит от конкретного случая.
Единственное, пожалуй, что может оправдывать ненужную регистрацию это «число зарегистрированных пользователей», которое, почему-то очень любят инвесторы/покупатели.
Надо ли это в интернет-магазине, думаю, зависит от конкретного случая.
Единственное, пожалуй, что может оправдывать ненужную регистрацию это «число зарегистрированных пользователей», которое, почему-то очень любят инвесторы/покупатели.
На данный момент видел почти идеальный вариант регистрации который заключался в следующем: Для пользователя при клике на кнопку или ссылку под которой фунциональность обеспечена только зарегистрированным пользователям выпрыгивает popup окно с просьбой ввести свой никнейм и еще одно поле в которое можно вести любые контактные данные по желанию. Далее пользователь делает сабмит формы появляется прогрес бар (мол… выполняется вход). В это время у пользователя появляет значок в трее с иконкой портала и tooltip'ом в котором написано селующее «Вы (логин) подтверждаете свою регистрацию там та и там та?» Варианты «Да» и «Нет». После клика на «да» пользователь остается на своей странице на которой уже при помощи аякса подгрузился его логин к примеру…
Понятно, спасибо. Подход очень интересный, однако, как и поход, предложенный в посте, страдает завязкой на скрипты. Но звучит здорово :)
И мне очень понравился подход. что же касается скриптов — так а почему бы не делать проверку на наличие включенного javascript и, в зависимости от этого, переключаться на нужный сценарий регистрации (с использованием ajax либо «по старинке» с активацией через email).
Для тех же кто считает, что легче помнить например свой uin в мессенджере сделать селект-бокс с вариантами подтверждения на выбор (хотя это уже малость замысловато будет).
Это я вобщем рассуждаю, а не конкретно о регистрации в интернет-магазинах.
Для тех же кто считает, что легче помнить например свой uin в мессенджере сделать селект-бокс с вариантами подтверждения на выбор (хотя это уже малость замысловато будет).
Это я вобщем рассуждаю, а не конкретно о регистрации в интернет-магазинах.
А мыло в любом случае ждать придется. Даже если используется традиционный метод регистрации — все равно нужно ждать письма со ссылкой активации, а в этом методя хотя бы не нужно никуда уходить(перезагружать) с начальной страницы
UFO just landed and posted this here
Люди, вы о чем???
Если человек хочет что-то у вас купить (скачать, послушать, прочитать), зачем требовать от него активации? Активация — это процесс валидации адреса e-mail, и не более того… А валидация e-mail нужна чаще всего как защита от повторных (читай — повальных) регистраций.
На мой взгляд, в данном случае активация аккаунта как этап регистрации — не нужна.
Если человек хочет что-то у вас купить (скачать, послушать, прочитать), зачем требовать от него активации? Активация — это процесс валидации адреса e-mail, и не более того… А валидация e-mail нужна чаще всего как защита от повторных (читай — повальных) регистраций.
На мой взгляд, в данном случае активация аккаунта как этап регистрации — не нужна.
Удобно.
Спасибо!
Но меня волнует, почему никто так не делает. С СМС регистрациями — да, но вот по электропочте код активации никогда не видел
Но меня волнует, почему никто так не делает. С СМС регистрациями — да, но вот по электропочте код активации никогда не видел
Имхо, код присылаемый по почте, это какой-то особый вид идиотии. От спама и «шутников» не спасает, зато обычный пользователям мешает.
А как тогда удостоверится, что это действительно e-mail пользователя?
А зачем удостовериться что это почта пользователя? в реальности активация ничего не дает, то есть абсолютно ничего.
Пустить набить корзину, оформить заказ, участвовать в жизни сайта, для всего этого не нужно «валидировать» пользователя. Запросить проверку стоит перед началом денежных отношений, когда цель уже есть (заказ лежит в группе неоплаченное), и когда после проверки пользователь придет не созирцать красоты, а с четкой целью оплатить уже любовно выбранное и заказанное. Да и то, а нужна ли, в действительности, эта проверка.
К тому же, ваще прикрастное решение будет требовать исполнение каких-нибудь скриптов, что не есть хорошо.
Пустить набить корзину, оформить заказ, участвовать в жизни сайта, для всего этого не нужно «валидировать» пользователя. Запросить проверку стоит перед началом денежных отношений, когда цель уже есть (заказ лежит в группе неоплаченное), и когда после проверки пользователь придет не созирцать красоты, а с четкой целью оплатить уже любовно выбранное и заказанное. Да и то, а нужна ли, в действительности, эта проверка.
К тому же, ваще прикрастное решение будет требовать исполнение каких-нибудь скриптов, что не есть хорошо.
Я бы сохранял контекст в ссылке активации. Например:
Магазин суперкотят
Вы зарегистрировались в нашем магазине для покупки товара «Супер котята!».
Пройдите по ссылке, чтобы продолжить оформление заказа: super-kittens.ru/goods/123/buy?activation_key=51hkjl45g6kj
Можно к ссылке регистрации на всех страницах цеплять &returnto=<текущий url>, и после успешного подтверждения активации перенаправлять пользователя на страницу с товаром. Так будет работать даже без JavaScript.
Знаешь, apple_fan… Вот это всплывающее окошко, а под ним ожидает действие или найденный item… Для пользователя исключён процесс «думать», сведены к минимуму перемещения по сайту… Молодец!
Хозяйке на заметку) В копилку однозначно. Спасибо.
Хозяйке на заметку) В копилку однозначно. Спасибо.
Самый простой и логичный способ — попросить пользователя, если он не зарегистрирован, ввести только e-mail, после этого выслать ему такое письмо:
— Поздравляем,…
Скачать кота вы можете по ссылке…
Если вы планируете и дальше пользоваться услугами нашего сайта — вот вам пароль…
— Ссылка есть активация, логин и скачивание одновременно.
Очень часто люди приходят ради одного файла или одной покупки.
— Поздравляем,…
Скачать кота вы можете по ссылке…
Если вы планируете и дальше пользоваться услугами нашего сайта — вот вам пароль…
— Ссылка есть активация, логин и скачивание одновременно.
Очень часто люди приходят ради одного файла или одной покупки.
А без регистрации вообще покупать нельзя? что за маразм?
Этот пост ни в коей мере не спорил с этим тезисом. Он лишь описывал как можно сделать регистрацию удобнее, когда это неизбежно.
Покупка в данном случае — не более чем пример возможного применения концепции.
Покупка в данном случае — не более чем пример возможного применения концепции.
Кажется регистрация обязательна для электронных магазинов. С точки зрения действующего законодательства. Поправьте, если я не прав.
Обязательная регистрация (особенно в интернет-магазинах) — редкостный идиотизм.
Продвинутые пользователи в таких случаях на ссылку регистрации нажимают колесом или Ctrl-кликом :)
Ваше решение несколько сгладит впечатление, но лучшим решением было бы отсутствие обязательной регистрации.
Продвинутые пользователи в таких случаях на ссылку регистрации нажимают колесом или Ctrl-кликом :)
Ваше решение несколько сгладит впечатление, но лучшим решением было бы отсутствие обязательной регистрации.
Вы, безусловно, правы. Отсутствие регистрации это действительно лучший вариант.
Этот пост ни в коей мере не спорил с этим тезисом. Он лишь описывал как можно сделать регистрацию удобнее, когда это неизбежно.
Этот пост ни в коей мере не спорил с этим тезисом. Он лишь описывал как можно сделать регистрацию удобнее, когда это неизбежно.
Регистрация неизбежна, если предполагается, что пользователь будет генерировать контент (комментарии в блоге, посты в форуме и т.п.) Если же пользователь собирается что-то скачать — в крайнем случае, ссылка должна прийти ему на почту (выше была такая мысль). Если пользователь пришёл в магазин — он покупатель. Не мучайте его. Дайте ему купить. Что важнее, база юзеров или продажи?
Возможно, дело в том, что вы неверно выбрали пример, но, в случае с магазином, регистрация должна быть лишь возможным вариантом. Вас же в ближайшем магазине не отфутболивают получать «карточку постоянного покупателя», когда вы пришли за хлебом?
Возможно, дело в том, что вы неверно выбрали пример, но, в случае с магазином, регистрация должна быть лишь возможным вариантом. Вас же в ближайшем магазине не отфутболивают получать «карточку постоянного покупателя», когда вы пришли за хлебом?
Эх, надо было брать примером форум :)
Тогда лучшим решением (как и в случае с комментариями в блоге) было бы форму регистрации совместить с формой быстрого ответа (обычно на форумах совмещают с нею форму входа, но почему только её?) — в этом случае сообщение отправляется, но показывается на сайте после подтверждения емейла (о чём пользователю предварительно сообщается).
удобнее сделать регистрацию совмещенной с оформлением заказа, если это так уж неизбежно.
Подскажите мне пример магазина (не будем говорить о партнёрских центрах закупок), когда регистрация действительно неизбежна.
Любой магазин, хранящий историю заказов/ имеющий накопительные скидки и тд и тп.
Я как раз и говорю — что желательно обойтись без регистрации, если вы не поняли.
Я как раз и говорю — что желательно обойтись без регистрации, если вы не поняли.
В этом случае лучше бы написать, что «можно зарегистрироваться и получать бонусы и скидки, но если не хочется — можно перейти к оформлению заказа прямо сейчас». Но не заставлять.
Чтобы что-нибудь купить, всё равно ведь надо вводить какие-то свои реальные, физические/юридические данные? Вот и добавить к форме ввода этих данных пару _необязательных_ полей с комментарием: «А если вы хотите (сохранить эти данные и использовать при следующих покупках)/(хранить историю заказов)/(иметь накопительные скидки)/(чтобы волосы были мягкими и шелковистыми) — можете ввести сюда имэйл и пароль, и будет вам счастье.»
я конечно могу быть неправ, но:
1) Лишний копи-паст, на мой взгляд, не слишком удобное решение.
2) Так же, подобное это лишний раз задуматься о том, какую вкладку надо или не надо закрыть.
Возможно, как вариант решения, это создание временной корзины, которая может перерасти после регистрации в обычную.
Т.е. пользователь набирает корзину, которой присваивается какой-нибудь номер.
Если переход на регистрацию с ссылки определенного товара, то в корзину он добавляется сам.
В почтовой ссылке номер корзины может участвовать в составе кода на активацию или отдельным параметром.
1) Лишний копи-паст, на мой взгляд, не слишком удобное решение.
2) Так же, подобное это лишний раз задуматься о том, какую вкладку надо или не надо закрыть.
Возможно, как вариант решения, это создание временной корзины, которая может перерасти после регистрации в обычную.
Т.е. пользователь набирает корзину, которой присваивается какой-нибудь номер.
Если переход на регистрацию с ссылки определенного товара, то в корзину он добавляется сам.
В почтовой ссылке номер корзины может участвовать в составе кода на активацию или отдельным параметром.
запомнить урл с которого человек перешел на регистрацию, регистрируемся, приходит письмо с активационным урлом, заходим, нас редиректит в то место откуда мы начали попытки купить котят… ничего сложного
у всплывающего окошка с заказом есть недостаток — его невозможно закрыть. Пользователь лишается выбора, что ему делать. Система сказала «регистрируйся», а посетитель даже отказаться не может от столь заманчивого предложения )
Может я еще похожу по сайту и подумаю, стоит ли мне регистрироваться и что-то заказывать вообще
Может я еще похожу по сайту и подумаю, стоит ли мне регистрироваться и что-то заказывать вообще
посмотрите как сделано на stackoverflow.com
там немного по другому, но тоже интересно
там немного по другому, но тоже интересно
Ещё рез большое спасибо.
Технология OpenID — это очень подходящая штука для проекта, целевая аудитория которого — «продвинутые» пользователи. Я напрасно забыл о ней!
Технология OpenID — это очень подходящая штука для проекта, целевая аудитория которого — «продвинутые» пользователи. Я напрасно забыл о ней!
UFO just landed and posted this here
Обычно после отправки письма я перехожу на почтовик(т.е. переключаюсь на другой таб, а у меня это около 6~10), ввожу тамошны пароль(хотя вру есть оочень полезный мастер паролей), увижу другие новые более важные письма естественно контекст теряется а потом вапще забываю про покупку :(. Я предлагаю использовать месенжер(название не самое удачное) т.е. обычного пользователя(GTalk, Magent, ICQ etc) и просто отправить код активации через сообщением.
Мне кажется, что аська — это мегаофигенно! Не знаю, сработает ли в жизни, но теоретически — супер!
Слово «Зарегистрировать» очень часто пугает пользователя. Предлагаю альтернативу не использовать его.
1. Пользователь выбирает товар
2. Пользователь подтверждает свое желание
3. Пользователь получает, письмо «Здравствуйте, вы заказали у нас товар „Книга Иванова“, перейдите по ссылке...»
1. Пользователь выбирает товар
2. Пользователь подтверждает свое желание
3. Пользователь получает, письмо «Здравствуйте, вы заказали у нас товар „Книга Иванова“, перейдите по ссылке...»
Пример:
Хорошая идея, большое спасибо!
Надо только ясно намекнуть, что если товар не подтвердить — ничего не случится
Надо только ясно намекнуть, что если товар не подтвердить — ничего не случится
Насколько я помню, мой вариант решения подобных заморочек заключался в том, что:
1) любой анонимный юзер при посещении получает sessionID
2) при оформлении заказа новый юзер вбивает на несколько полей больше (имя, телефон, имыл, адрес доставки)
3) сразу после оформления анонимная сессия перестаёт быть анонимной и контекст юзера не теряется
4) конечное подтверждение заказа происходит только после подтверждения регистрации через клик на ссылку в почте
В описанном способе:
1) товары можно класть в корзину всегда
2) нет завязки на открытые окна браузера, пока не пришло письмо активации
1) любой анонимный юзер при посещении получает sessionID
2) при оформлении заказа новый юзер вбивает на несколько полей больше (имя, телефон, имыл, адрес доставки)
3) сразу после оформления анонимная сессия перестаёт быть анонимной и контекст юзера не теряется
4) конечное подтверждение заказа происходит только после подтверждения регистрации через клик на ссылку в почте
В описанном способе:
1) товары можно класть в корзину всегда
2) нет завязки на открытые окна браузера, пока не пришло письмо активации
А как пользователь может вернуться, посмотреть что он купил/написал/закачал?
В e-mail указывается логин/пароль?
В e-mail указывается логин/пароль?
В п.2 в скобочках я перечислил «несколько полей», которые различаются в зависимости от направленности сайта (кому на форуме нужен адрес доставки?). Да, поля «пароль» и «пароль ещё раз» тоже надо вводить и письмо про авто-регистрацию тоже придёт. Отдельно, чтобы не потерялось. А по ссылке активации юзера автоматически логинит как надо, не надо ничего вводить заново.
Я бы смысловые единицы «акт регистрации» и «акт заказа» всё таки разделил.
Когда пользователя заставляют вбить кучу полей он пугается.
Ему нужно дать выбрать товар, положить его в корзину по вашей системе, потом быстро его регнуть (пример снизу). Все теперь он ваш.
И после этого просить заполнять большую форму с адресом доставки.
В этом случаи у вас уже будет его email, и если он потеряется перед видом большой формы, вы всегда сможете ему послать напоминание о том что он может продолжить оформление покупки
Ему нужно дать выбрать товар, положить его в корзину по вашей системе, потом быстро его регнуть (пример снизу). Все теперь он ваш.
И после этого просить заполнять большую форму с адресом доставки.
В этом случаи у вас уже будет его email, и если он потеряется перед видом большой формы, вы всегда сможете ему послать напоминание о том что он может продолжить оформление покупки
Проще на почту прислать ссылку для продолжения заказа…
p.s электропочта… тёмадрочерство.
p.s электропочта… тёмадрочерство.
Да ладно вам, просто забавное слово. К тому же, по-моему, гораздо более русское, чем любые другие варианты. Если бы его не в Студии Лебедева придумали и чуть пораньше, могло бы и прижиться вполне. А так — народ терзается противоречиями.
Разница между Электронным и Электро совсем разная… как бы… Электрической почты не бывает…
и он нисколько не более русское… оно не логично.
и он нисколько не более русское… оно не логично.
Электронная почта — слишком длинно, емейл — слишком не по-русски… Что предлагаете?
Я предлогаю писать правильно и логично, если вы из-за 4х буков и пробела решаете писать не грамотно… то извините
Приятно видеть в подобных комментах по две орфографические ошибки… Именно из-за разницы значений слов «электронный» и «электрический» в слове «электропочта» присутствует некоторый фан…
Сработало… значит когда специально пишешь с явными ошибками вы замечаете, а глупость слова — электропочта не замечаете…
Глупость — это постоянно писать «не» раздельно с прилагательными и наречиями, а потом говорить, что в данном конкретном случае сделал это специально.
Слово «электропочта», вообще говоря, неправильное, я согласен, но это не отменяет его права на жизнь. Я считаю, что слово забавное, и его вполне можно использовать в правильном контексте. На айтишном сайте добавить долю стёба вполне можно.
Вы часто используете словосочетание «электронная почта»? Или предпочитаете чем-то заменять?
Слово «электропочта», вообще говоря, неправильное, я согласен, но это не отменяет его права на жизнь. Я считаю, что слово забавное, и его вполне можно использовать в правильном контексте. На айтишном сайте добавить долю стёба вполне можно.
Вы часто используете словосочетание «электронная почта»? Или предпочитаете чем-то заменять?
Конечно, xml решает.
Я не могу понять, почему при всех регистрациях всё крутится вокруг е-мейла? Это что, не такой же аккаунт на другом сайте? Он как-то влияет на безопасность? Зачем его сразу же подтверждать? Какие-то лишние действия. Мыло нужно просить у пользователя для оповещений, если пользователь этого хочет. При этом вполне можно вместо мыла предлагать ему воспользоваться аськой, телефоном, да хоть голубиной почтой. А возможно, что пользователю вообще не хочется, чтобы оповещения приходили, тогда вся эта волокита становится ненужной.
Наверное, основная проблема не в оповещении, а в запоминании: хочется запомнить пользователя на ресурсе. Он либо может придумать свой логин, либо ввести e-mail/icq/doveMail. E-mail/icq/doveMail несколько более generic.
Думаю, для сайтов масштаба MySpace или Вконтакте такой подход имеет смысл, а вот для небольших магазинов придумать логин проблемы вообще нет. Да и что мешает использовать ФИО в качестве логина? Вероятность совпадения паролей у тёзок-однофамильцев не выше, чем шанс успешного взлома. А ФИО клиент в любом случае будет заполнять.
Кликанье на линк в почте в какой-то степени гарантирует, что у того, кто оформил заказ и указал имейл, есть доступ к данному почтовому ящику. Т.е. подтверждается не столько валидность имейла, сколько валидность юзера :)
Я это прекрасно понимаю. Но зачем это делать до того, как потребуется реальное общение с пользователем через почту? И зачем привязываться к почте?
Я, наверное, знаю ответ. Электропочта — это то, что пользователь помнит хорошо и гарантировано не забудет. Я имею в виду не столько продвинутого пользователя, сколько свою соседку, которая вообще-то работает в банке, а в интернете пишет внукам письма и иногда что-то по мелочи покупает.
В случае с обслуживанием интернет-магазина менеджеру хочется быть уверенным, что его портянка заказов состоит из реальных заказов. Списываться/обзванивать всё равно придётся, но повысится эффективность — если имейл не подтверждён, ещё не факт, что юзер не ошибся при указании имейла. И ещё подтверждение через имейл увеличивает гарантию того, что юзер точно решил что-то покупать. Тот, кто обломался сходить в почту и подтвердить имейл, скорее всего и от заказа откажется. Отказы — это ведь отдельная история, верно?
Я чуть выше описывал механизм удобной, на мой взгляд, регистрации. Так вот в случае, если юзер не получил почту, он волен повторить оформление заказа и указать другие данные.
Я чуть выше описывал механизм удобной, на мой взгляд, регистрации. Так вот в случае, если юзер не получил почту, он волен повторить оформление заказа и указать другие данные.
Всё правильно пишете и вариант регистрации неплохой предлагаете. Я говорю не о том, нужно ли подтверждение (безусловно, нужно), меня интересует сам вопрос необходимости указания электронной почты. Например, я бы предпочёл, чтобы время доставки пиццы или каких-нибудь роллов со мной согласовывали по телефону, а не через емэйл.
Понял. Могу сказать, что сам пиццу заказываю только по телефону ;) И у них там в базе имейла моего нет, идентификатором выступает как раз телефон.
Полагаю, что вот в таких достаточно специальных случаях можно сделать выпадающее меню «предпочтительный способ связи» и если там телефон — не требовать подтверждения имейла. Другой вопрос, что это может быть геморно с точки зрения реализации, но это уже совсем другая тема :)
Полагаю, что вот в таких достаточно специальных случаях можно сделать выпадающее меню «предпочтительный способ связи» и если там телефон — не требовать подтверждения имейла. Другой вопрос, что это может быть геморно с точки зрения реализации, но это уже совсем другая тема :)
Проблема в том, что обычно для регистрации нужно указывать мыло, даже если убираешь галочку с «Присылать уведомления о новых сообщениях на почту» или ему подобных. И это считается нормой. Так что я не уверен насчёт такой уж «специальности» указанного случая. В предложенном вами выпадающем списке не помешал бы пункт «не хочу я с вами связываться» :)
Йопрст, это уже больше похоже на опцию «не хочу доставку, просто так заказал» :)
Прикольно бы было, если бы на хабре нотификации об ответах приходили в виде смс-ок, если вместо имейла указан мобильник или бы девушка из контакт-центра звонила и зачитывала :)))))
Да, имейл — это норма на текущий день. В принципе, не считаю это трагедией, честно.
Прикольно бы было, если бы на хабре нотификации об ответах приходили в виде смс-ок, если вместо имейла указан мобильник или бы девушка из контакт-центра звонила и зачитывала :)))))
Да, имейл — это норма на текущий день. В принципе, не считаю это трагедией, честно.
Есть дикое количество сайтов, где нужна регистрация для доступа к контенту, но с которых нет никакого желания получать какие-то сообщения и уведомления.
Смс и телефон хороши для городских инет-магазинов. Мыло — для социальных сервисов. Те же уведомления на Хабре мне были бы совершенно неинтересны, если бы они более удобным образом дублировались на сайте. Всё равно мне постоянно приходится чистить от них почту. Грамотный веб-интерфейс поудобнее будет, чем примитивные средства электронного письма.
Смс и телефон хороши для городских инет-магазинов. Мыло — для социальных сервисов. Те же уведомления на Хабре мне были бы совершенно неинтересны, если бы они более удобным образом дублировались на сайте. Всё равно мне постоянно приходится чистить от них почту. Грамотный веб-интерфейс поудобнее будет, чем примитивные средства электронного письма.
Необязательно сразу же заставлять пользователя активировать e-mail. В вашем случае «далее» заменяется на «зарегистрироваться»; после регистрации выводим сообщение, что всё хорошо, не заставляя пользователя прямо сейчас активировать аккаунт по e-mail. Пользователь продолжает работу с сайтом минимально теряя контекст. Активацию же мы попросим только в самом крайнем случае, когда нам на самом деле нужен e-mail: для магазина при оформлении заказа; для форума — после написания сообщения (когда оно в черновиках, пока аккаунт не активирован) и т.д.
А во время активации пользователь получает письмо с ссылкой и переходит по ней?
Пользователь сразу получает письмо с ссылкой. Просто мы не заставляем на неё щёлкать/вводить код активации, пока нам реально не понадобится его e-mail.
Понятно, спасибо!
Есть риск что потом пользователь потеряет письмо с кодом/ссылкой активации!
Слово «потом» тут не уместно. Любая активация это действие которое говорит «нужно сделать сейчас».
Если рассматривать случаий что пользователь отвлекся, мы всегда может ему послать напоминание через X часов.
Если рассматривать случаий что пользователь отвлекся, мы всегда может ему послать напоминание через X часов.
Пока пользователь не активировал аккаунт, в профиле/в меню пользователя всегда должна быть ссылка вида «выслать письмо для активации повторно».
Слегка оффтоп. Для интернет-магазинов регистрация — злое зло, как уже верно отметили выше. Она может присутствовать в виде опции, для просмотра истории покупок, написания отзывов итп, но сам процесс покупки должен быть максимально простым и ненапряжным, пришел на сайт с поисковика — увидел — кликнул «Заказать» — заполнил телефон и адрес доставки — checkout.
Для форумов и блогов такая идея в общем случае мало чем отличается от существующей реализации, т.к. время доставки письма — велична случайная, пользователь не будет сидеть и ждать, уйдет со страницы и потеряет контекст, но это уже недостадок емэйла, как системы доставки активационного кода\линка, а не не самой идеи. Сама идея вполне здравая и, честно говоря, непонятно почему до сих пор не реализованная.
Для форумов и блогов такая идея в общем случае мало чем отличается от существующей реализации, т.к. время доставки письма — велична случайная, пользователь не будет сидеть и ждать, уйдет со страницы и потеряет контекст, но это уже недостадок емэйла, как системы доставки активационного кода\линка, а не не самой идеи. Сама идея вполне здравая и, честно говоря, непонятно почему до сих пор не реализованная.
В моём магазине незарегистрированный пользователь добавляет всё в корзину. Потом ему предлагают зарегистрироваться.
Когда он проходит ухтивацию и всё такое, в корзине остаётся от, что он туда и понапихал.
Когда он проходит ухтивацию и всё такое, в корзине остаётся от, что он туда и понапихал.
а зачем вообще какой то код на почту ??
можно (например здесь, на шаге 2 из 2) выводить капчу и просить ее ввести в поле «код подтверждения». Бота от человека мы уже отделили. Если отправка кода на мыло имеет цель проверки существования адреса почты, то это целиком забота пользователя — ввести правильный адрес. Т.к. он заинтересован в получении товара.
можно (например здесь, на шаге 2 из 2) выводить капчу и просить ее ввести в поле «код подтверждения». Бота от человека мы уже отделили. Если отправка кода на мыло имеет цель проверки существования адреса почты, то это целиком забота пользователя — ввести правильный адрес. Т.к. он заинтересован в получении товара.
Хороший вариант.
Ну а если же все-таки добивать вариант без регистрации то сервис(http://www.maxmind.com/app/telephone_overview) предоставляемый maxmind, думаю, самое(|более приемлимое) логичное. Т.е. не нужно регистрироваться, ведется корзина при оформлении заказа робот звонит на телефон заказчика и говорит 4х значное число(на вышеуказанном сервисе есть поддержка 6и языков, за что респект и уважуха им :)) вводишь и ждешь курьера(или в зависимости от бизнес процесса). А цена, считаю, терпимая 0.29 американских рублей даже для Казахстана 0.36$(все познается в сравнении). Канешна как то глупо/непривычно без регистрации создается ощущение как будто покупаешь на улице. И возникает тупая идея оставить рег для юр лиц а для физ без! :)
Для интернет-магазина вообще-то можно придумать схему без регестрации. А можно ли придумать такое же, допустим, для форума или социальной сети?
Ничего светлого на ум, к сожалению, не приходит, кроме как OpenId :)
немного офтопа, я вапще думаю почему, например, парни из phpbb, не сделают общую авторизацию, т.е. захожу на форум при авторизации просто выбираю сервер(форум) авторизации. Надоедает каждый раз выдумывать, называлка ломается, так как не хочеться один и тот же логин/пароль для всех мало ли что.
немного офтопа, я вапще думаю почему, например, парни из phpbb, не сделают общую авторизацию, т.е. захожу на форум при авторизации просто выбираю сервер(форум) авторизации. Надоедает каждый раз выдумывать, называлка ломается, так как не хочеться один и тот же логин/пароль для всех мало ли что.
Два варианта реализации:
1) регистрация по номеру сотового, а не по мылу. Если не хотите тратить деньги на защиту от спам ботов (что непростительно интернет-магазинам), то высылается на номер активация. Если не хотите тратить деньги и на это, то еще и на е-мэйл. Практика показывает, что номер сотового не забывают, а вот номер помойной почты — часто.
2) регистрация через капчу.
Короче, отсылать на е-мейл активацию это уже очень пошло, поскольку фантастически бесит. Я зашел на сайт и хочу купить, а не демонстрировать свою человеческую сущность. Деньги — время и все такое. Так что с ботами боритесь «человеческими» средствами, а не садистскими.
Пользователь страдать не должен.
1) регистрация по номеру сотового, а не по мылу. Если не хотите тратить деньги на защиту от спам ботов (что непростительно интернет-магазинам), то высылается на номер активация. Если не хотите тратить деньги и на это, то еще и на е-мэйл. Практика показывает, что номер сотового не забывают, а вот номер помойной почты — часто.
2) регистрация через капчу.
Короче, отсылать на е-мейл активацию это уже очень пошло, поскольку фантастически бесит. Я зашел на сайт и хочу купить, а не демонстрировать свою человеческую сущность. Деньги — время и все такое. Так что с ботами боритесь «человеческими» средствами, а не садистскими.
Пользователь страдать не должен.
Спасибо за критику.
С сотовым есть две проблемы:
1. человек не всегда готов доверить свой номер не очень большому ресурсу
2. не во всех странах входящие СМС бесплатно. Платить 15 центов не за что не очень приятно
С капчей проблем я не вижу. Пожалуй, для форума или социальной сети это оптимальный вариант. Для интернет-магазина, похоже, можно и без регистрации, поскольку транзакция одноразова.
С сотовым есть две проблемы:
1. человек не всегда готов доверить свой номер не очень большому ресурсу
2. не во всех странах входящие СМС бесплатно. Платить 15 центов не за что не очень приятно
С капчей проблем я не вижу. Пожалуй, для форума или социальной сети это оптимальный вариант. Для интернет-магазина, похоже, можно и без регистрации, поскольку транзакция одноразова.
Для чего нужна регистрация?
Можно же сделать проще. Пользователь заходит в карточку товара и сразу же заказывает нужный ему товар без какой-либо нудной регистрации.
Попробуйте — это удобно. www.k-1.ru
Можно же сделать проще. Пользователь заходит в карточку товара и сразу же заказывает нужный ему товар без какой-либо нудной регистрации.
Попробуйте — это удобно. www.k-1.ru
Сайтик удобный!
Вообще требовать от пользователя регу или не требовать это завист от магазина.
Правильнее конечно сделать аналогично и посадить менеджера который будет тут же делать отзвон клиенты по заявка и дальше уже обрабатывать их.
Рега нужна в тех случаях когда надо автоматизировать процесс и в
тот момент она должна быть просто и разбита на две части а) быстрая рега, путем запроса только мыла и пароля + б) дорега: путем просьбы ввести дополнительную инфу для отправки заказа.
Вообще требовать от пользователя регу или не требовать это завист от магазина.
Правильнее конечно сделать аналогично и посадить менеджера который будет тут же делать отзвон клиенты по заявка и дальше уже обрабатывать их.
Рега нужна в тех случаях когда надо автоматизировать процесс и в
тот момент она должна быть просто и разбита на две части а) быстрая рега, путем запроса только мыла и пароля + б) дорега: путем просьбы ввести дополнительную инфу для отправки заказа.
Недостаток у к-1 такой, что звездочки на обязательные поля не видно.
После того как я жмахнул на юр лицо, и мне выпал список полей… стало страшно и лень чтото вводить
Все эти поля надо сделать по цвету более тусклыми и написать словами что они не обязательные, и желательно 1 большую форму в место нескольких мелких.
Мне как клиенту удобнее достать реквизиты из текстового файла, и кинуть им в 1 большую форму… а не заполнять поля по отдельности.
После того как я жмахнул на юр лицо, и мне выпал список полей… стало страшно и лень чтото вводить
Все эти поля надо сделать по цвету более тусклыми и написать словами что они не обязательные, и желательно 1 большую форму в место нескольких мелких.
Мне как клиенту удобнее достать реквизиты из текстового файла, и кинуть им в 1 большую форму… а не заполнять поля по отдельности.
Спасибо, попробовал. Мне кажется, сделано очень изящно. Я большой фанат progressive disclosure :)
Однако, если пользователь возвращается на сайт магазина, каким образом сказать ему: «Вы купили А, Б и В. У нас есть офигенные Г и Д которые все покупают к А»?
Однако, если пользователь возвращается на сайт магазина, каким образом сказать ему: «Вы купили А, Б и В. У нас есть офигенные Г и Д которые все покупают к А»?
«Электропочта» звучит круто ))))
а зачем вообще регистрироваться?
1. пользователь заходит на сайт
2. находит то что надо и берёт по-пути указывая адрес электропочты
всё
1. пользователь заходит на сайт
2. находит то что надо и берёт по-пути указывая адрес электропочты
всё
А вы не задумывались зачем указывать именно электронную почту?
Я к примеру редко читаю почту, раз в сутки (да-да завидуйте мне :) ).
Сейчас же есть куча других способов связаться с пользователем. Например, можно использовать сервисы мгновенных сообщений.
Если я к примеру постоянно пользуюсь джабером, то почему бы мне при регистрации не указать именно его, а не свою почту? И тогда я получу код активации в свой джабер, причём это будет быстрее и удобнее, чем через почту.
А что мешает использовать для отправки кода активации SMS? (На мобильный телефон нужно будет отправлять какой-то достаточно простой код, например только цифры, т.к. с экрана телефона нельзя скопировать код в буфер обмена)
Или, да ладно уж там, показать код активации прям на сайте, в том же окне регистрации! И нечего боятся спамеров, у матёрых спамеров есть куча электронных адресов. Можно код показать в виде картинки (типа тест на человека разумного). А можно и дальше пойти — прямо текстом и указать. {Тут уже на сколько фантазии фватит}
А уже потом в процесе, если email так важен для ресурса, как-то ненавязчиво спросить его у уже зарегистрированного пользователя.
Я к примеру редко читаю почту, раз в сутки (да-да завидуйте мне :) ).
Сейчас же есть куча других способов связаться с пользователем. Например, можно использовать сервисы мгновенных сообщений.
Если я к примеру постоянно пользуюсь джабером, то почему бы мне при регистрации не указать именно его, а не свою почту? И тогда я получу код активации в свой джабер, причём это будет быстрее и удобнее, чем через почту.
А что мешает использовать для отправки кода активации SMS? (На мобильный телефон нужно будет отправлять какой-то достаточно простой код, например только цифры, т.к. с экрана телефона нельзя скопировать код в буфер обмена)
Или, да ладно уж там, показать код активации прям на сайте, в том же окне регистрации! И нечего боятся спамеров, у матёрых спамеров есть куча электронных адресов. Можно код показать в виде картинки (типа тест на человека разумного). А можно и дальше пойти — прямо текстом и указать. {Тут уже на сколько фантазии фватит}
А уже потом в процесе, если email так важен для ресурса, как-то ненавязчиво спросить его у уже зарегистрированного пользователя.
UFO just landed and posted this here
Я при выборе товара и покладывании его в корзинку — id корзинки сохраняю в кукисе (мягко выражаясь). И посетитель ничего не потеряет.
проблема стара
activation_key=51hkjl45g6kj
вот когда вы передаете это вы где-то это храните, почему вам бы не храить там же и $_SERVER['REQUEST_URI']
activation_key=51hkjl45g6kj
вот когда вы передаете это вы где-то это храните, почему вам бы не храить там же и $_SERVER['REQUEST_URI']
а чего минусуем? может поясним хотя б?
по моему очень просто вы там где храните когд апрува там же и храните адрес с котого прошла регистрация и отправляете пользователся потом туда.
по моему очень просто вы там где храните когд апрува там же и храните адрес с котого прошла регистрация и отправляете пользователся потом туда.
Предположим, человек набабахал себе полную виртуальную корзину продуктов :)
REQUEST_URI выгладит типа "/cart.dhtml"
При переходе туда получаем нужную страницу, но без единого продукта.
Это так, как первый попавшийся в голову пример.
REQUEST_URI выгладит типа "/cart.dhtml"
При переходе туда получаем нужную страницу, но без единого продукта.
Это так, как первый попавшийся в голову пример.
вообще для хранения в карзине не знаю как вы, но я использую ссесию. тоесть ничего непропадет
«Хранение корзины» и «хранение адреса, с которого пошла регистрация» — всё же разные вещи, согласитесь? Так вот без сохранения корзины хранение только адреса регистрации может привести к неприятным результатам. Ваш ответ был просто совсем не полон.
ЗЫ: кстати, с корзиной — это лишь один из вариантов. Самый распространённый, но, боюсь, не единственный. И суть проблемы состоит в том, что надо хранить всю сопутствующую информацию, а не только REQUEST_URI
ЗЫ: кстати, с корзиной — это лишь один из вариантов. Самый распространённый, но, боюсь, не единственный. И суть проблемы состоит в том, что надо хранить всю сопутствующую информацию, а не только REQUEST_URI
Так что скорее всего ваш способ надо объединять с предложенным выше камрадом ganzer:
Я при выборе товара и покладывании его в корзинку — id корзинки сохраняю в кукисе (мягко выражаясь). И посетитель ничего не потеряет.
представляю как женщина приколнных лет сидит и минут 20 пялится в аутлук, а мэил ру в это время гоняет мыль по фильтрам )))
имхо в таких случаях надо пользователя сразу логинить, а подтверждает пусть позже.
остался вопрос — как узнать, что это не робот. а для этого JS в руки и мозг в голову, комрадэ =)
имхо в таких случаях надо пользователя сразу логинить, а подтверждает пусть позже.
остался вопрос — как узнать, что это не робот. а для этого JS в руки и мозг в голову, комрадэ =)
UFO just landed and posted this here
А как Вам такой вариант: Есть на сайте какие то функции, доступные только зарегистрированным пользователям… При попытке активации такой функции незарегистрированным пользователем всплывает тул тип, в котором пользователь указывает минимально необходимые данные для регистрации (мыло, пароль) и система позволяет пользователю авансом пользоваться этой функцией(сразу после указания минимально необходимых данных), но при условии, что в течение суток(например) будет подтверждение регистрации от пользователя… Если же по истечении суток подтверждения нет, то все действия пользователя считаются недействительными и теряют свою значимость на сайте, а аккаунт автоматически удаляется. Интересно Ваше мнение, спасибо.
Спасибо за идею.
В общем, звучит очень здорово: пользователю не надо сразу лезть в почту, не надо уходить со страницы. Действие получается неразрывно.
Однако, я вижу следующие возможные проблемы:
1. сложно донести до пользователя, что зарегестрироваться необходимо. Это сделать довольно непросто, так как закладываться на то, что пользователь прочитает какой-либо текст нельзя.
Как вариант можно высылать письмо с темой «ААА!!1! зАрегся или ВСЁ пропало!!! адын!!».
Это вполне приемлемо для чего-нибудь крупного (банка, магазина, службы доставки и т.п. ).
2. пользователь может забыть зарегиться по-настоящему: после того, как он сделал то, что он хотел сделать на сайте, он, скорее всего, «выгрузит» контекст сайта из головы. А потом очень удивиться, увидев, что все, что он сделал пропало.
Можно решить письмом из пункта 1.
3. несколько сложен случай, если в указанном мыле была допущена ошибка: по-идее, тогда информация пропадёт. Простого способа её восстановить я не вижу.
4. (не очень существенно) мы закладываемся на то, что у пользователя работают скрипты и корректно рендерится CSS
Думаю, что эти проблемы решаемы (отображать все «авансовые» изменения другим цветом, вешать везде див со словами «Всё может пропасть», слать письмо-напоминание). Вариант очень интересный.
Положил в копилку UI-идей :)
В общем, звучит очень здорово: пользователю не надо сразу лезть в почту, не надо уходить со страницы. Действие получается неразрывно.
Однако, я вижу следующие возможные проблемы:
1. сложно донести до пользователя, что зарегестрироваться необходимо. Это сделать довольно непросто, так как закладываться на то, что пользователь прочитает какой-либо текст нельзя.
Как вариант можно высылать письмо с темой «ААА!!1! зАрегся или ВСЁ пропало!!! адын!!».
Это вполне приемлемо для чего-нибудь крупного (банка, магазина, службы доставки и т.п. ).
2. пользователь может забыть зарегиться по-настоящему: после того, как он сделал то, что он хотел сделать на сайте, он, скорее всего, «выгрузит» контекст сайта из головы. А потом очень удивиться, увидев, что все, что он сделал пропало.
Можно решить письмом из пункта 1.
3. несколько сложен случай, если в указанном мыле была допущена ошибка: по-идее, тогда информация пропадёт. Простого способа её восстановить я не вижу.
4. (не очень существенно) мы закладываемся на то, что у пользователя работают скрипты и корректно рендерится CSS
Думаю, что эти проблемы решаемы (отображать все «авансовые» изменения другим цветом, вешать везде див со словами «Всё может пропасть», слать письмо-напоминание). Вариант очень интересный.
Положил в копилку UI-идей :)
Пожалуйста.
1,2. А что если удалять информацию с сайта, но сохранять в базе… После удаления с сайта писать письмо пользователю о том что все его добро удалено и у него есть последний шанс восстановить это добро втечение недели например переидти по ссылке…
3. Может стоит сделать 2 поля для мыла по аналогии как пароль…
4. Не являюсь разработчиком… Вы имеете ввиду всплывающий тултип?
Вам спасибо!
1,2. А что если удалять информацию с сайта, но сохранять в базе… После удаления с сайта писать письмо пользователю о том что все его добро удалено и у него есть последний шанс восстановить это добро втечение недели например переидти по ссылке…
3. Может стоит сделать 2 поля для мыла по аналогии как пароль…
4. Не являюсь разработчиком… Вы имеете ввиду всплывающий тултип?
Вам спасибо!
1,2. Можно — лишь бы не спугнуть пользователся. Когда что-то где-то удалено обычно человек пугается
3. Тоже снизит вероятность ошибки. Отмечу, что два поля для мыла — это не то же, что два поля для пароля: в парольных полях нельзя делать Ctrl+C, Ctrl+V, так что пользователь вынужден ввести пароль дважды руками (что понижает вероятность ошибки). Однако в открытых полях буфер обмена работает, так что пользователь вполне может ввести мыло и Ctrl+A, Ctrl+C, Tab, Ctrl+V.
4. Ага. Тултип имеет две проблемы: а) его надо всплывать джаваскриптом б) его надо делать невидимым с помощью CSS. И то, и другое не везде одинаково поддерживается.
3. Тоже снизит вероятность ошибки. Отмечу, что два поля для мыла — это не то же, что два поля для пароля: в парольных полях нельзя делать Ctrl+C, Ctrl+V, так что пользователь вынужден ввести пароль дважды руками (что понижает вероятность ошибки). Однако в открытых полях буфер обмена работает, так что пользователь вполне может ввести мыло и Ctrl+A, Ctrl+C, Tab, Ctrl+V.
4. Ага. Тултип имеет две проблемы: а) его надо всплывать джаваскриптом б) его надо делать невидимым с помощью CSS. И то, и другое не везде одинаково поддерживается.
Sign up to leave a comment.
Концепция процесса регистрации