Pull to refresh

Comments 41

А что неудобного во втором варианте? Вы же храните все в сессии, зарегистрирован пользователь или нет. Поясните, если я чего-то не понимаю.

А вот в плане юзабилити, второй вариант это очень большой плюс. Очень приятно, знаете ли, когда пользователь чувствует, что разработчик позаботился и о нем, анониме (пока что). Создается очень хорошее впечатление о сайте и о разработчиках в частности. И случайно попавший к вам человек становится потенциальным юзером вашего сервиса.
При таком варианте требуется предусмотреть достаточно много «сюжетных линий»:

1. Я открыл сайт с домашнего компьютера, создалась новая сессия, начался сбор интересов пользователя для этой сессии. Я зарегистрировался — сессия привязалась к моему аккаунту.

2. Я регистрируюсь с компьютера друга, должны ли скопироваться его интересы в мой новый профиль, либо надо создавать пустой набор предпочтений.

3. Я открыл сайт на работе, должны ли накопленные предпочтения добавиться в мой профиль, когда я захочу написать комментарий и авторизуюсь.

4. Что, если я зашел из интернет-кафе, где до меня несколько неавторизованных юзеров смотрели абсолютно разные разделы, а я авторизуюсь и получу к себе непонятный набор интересов. (как вариант ставить галочку — «чужой компьютер»)

возможно есть и другие варианты…
все описанное сводится имено к checkboxу чужой комьютер
а если несколько неавторизованных пользователей за компом это не проблемма разработчика, все предусмотреть нельзя
тем более что «супербан» для привязки не предусматривает ссессию или пользователя
кстати чем привязку делать будете решили? и собственно формат хранения предпочтений?
это поинтереснее будет!
формат предпочтений пока в разработке, хотим сделать достаточно интеллектуальную систему.
Думаю стоит аккуратненько и ненавязчиво спросить у пользователя, хочет ли он импортировать собранные предпочтения. Так у друга вы выберете нет, на работе да, а в кафе либо нет, либо галочка.
А если пользователь ничего не ответит, то положить все в «долгий ящик», для дальнейшего рассмотрения, и когда у пользователя будет свободная минутка, он сам выберет, что сохранить, а что удалить.
UFO just landed and posted this here
UFO just landed and posted this here
по-моему сессии вообще хранятся до закрытия браузера, смысла хранить больше — не вижу.
UFO just landed and posted this here
подождите, что я узнаю? session_start(); в пхп работает до закрытия браузера.
UFO just landed and posted this here
зачем хранить сессию в куках????? это вы для того что типа случайны пользователь зайдет на сайт, походит там, потом закроет его, потом через неделю вспомнить про ваш сайт, зайдет еще раз и ему уже нужная инфа предложиться????

По-моему это бред все-таки хранить сессию в куках да еще и заморачиваться над определением закрыл юзвер бразуер или нет. Не обижайтесь, но это мое мнение )
UFO just landed and posted this here
под сессией в данной теме понимается не банальный session_start(), а кука с идентификатором группы параметров на сервере
вот шел сюда сказать то же самое один в один) вообще ничего неудобного нету. серверу придется намного больше данных ворочать — единственный минус.
задумка правильная… реализация имхо не существенна...(хотя второй вариант совсем не плох)
мне вот не понравилось отсутствие привязки предпочтений у яндекса с авторизованным пользователями почты…
настроил ты yandex.ru/setup/ — сохранились настройки в печеньках, но с настройками почтового аккаунта связи никакой!
немного непривычно, если сравнивать с google.ru/ig
UFO just landed and posted this here
Благодарные пользователи оценят ваши шаги им навстречу. Голосую за вариант №2.
UFO just landed and posted this here
UFO just landed and posted this here
Хороший вопрос про поисковики, интересно будет посмотреть, что окажется в интересах гугла или яндекса)) Скорее всего они получат сборную солянку из того, что проиндексируют, а при повторной индексации получат похожий контент. По идее ничего страшного произойти не должно.
я думаю поисковые боты не умеют работать с куками )
При хранении данных об активности незарегистрированного пользователя стоит ИМХО:
а) отразить этот факт в «Соглашении о конфиденциальности и сборе данных» или аналогичном документе, чтобы пользователи потом не возмущались, что их данные коллекционируются (многие еще думают, что после закрытия браузера следов об их деятельности не остается)
б) Много думать, какие данные собирать и (особенно) как их потом показывать/использовать. Иначе может получиться, что зайдя в поисковик один человек увидит историю поиска другого человека (с этого же компьютера), а там может быть что-то «не для посторонних глаз» и т.п.
ИМХО: Сохранение предпочтений незарегистрированных юзеров, если в проекте предусмотрена регистрация — ненужное занятие, ибо у юзера теряется грань между пользованием ресурсом в анонимном режиме и пользованием в зарегистророванном режиме. Настройки юзера(незарегистрированного) могут потеряться, и ему это явно не понравится, что приведет к ухудшению мнения о ресурсе.
а разве нельзя по печенькам сохранять?
Во-первых, пользователи — существа ленивые, и так называемый «first time user» может быть весьма полезен.
Во-вторых, зачастую подобные удобства для пользователей могут стать большими неудобствами для разработчиков, но поскольку система делается для пользователей, то я голосую за второй вариант.
надо пользователя как-то заинтересовать в регистрации ) Типа смотри как я умею выводить тебе что ты хочешь без регистрации, а с регистрации ты вообще офигеешь, ну вот как-то так…
пользовательский профиль + все user-related фичи такие как постинг, комментирование, голосование и тд.
То что удобнее для пользователя чаще всего оказывается менее удобно в реализации…

Пока пользователь не зарегистрировался, хранить настройки было бы лучше, привязываясь не к временной сессии, а к куке с уникальным значением, которая вешается на каждого нового пользователя. Тогда настройки будут сохранятся между сеансами, что опять же хорошо в плане юзабилити.
Стоит.

Регистрация — зло.

А реализация Вашего второго варианта до боли тупа.

3 ООП класса —

abstract Visitor

UnregistredVisitor: Visitor
— Intrerests
— Session

RegistredVisitor: UnregistredVisitor
— Login
— Password

Все в базе хранится, а в сессии только ID UnregistredVisitor`а.

Периодически база чистится и сносятся UnregistredVisitor`ы сроком более X дней/месяцев/лет (хотя в современных условиях можно это и не делать вообще — место дешево).
Если вам не интересно собирать статистику, то храните в куках или в сессии. Или там, откуда оно будет чиститься, если не востребовано в течении определенного срока.
Я принципиально не понимаю разницы между зарегистрированным и незарегистрированном пользователях, наверное, это придумали программисты для разделения пользователей на классы (негры и белые). Второму варианту конечно же быть. Меня больше удивляет нелюбовь к незарегистрированным пользователям, которые так же как и обычные гоняют по твоему сайту трафик.
UFO just landed and posted this here
Спасибо за разъяснение, но я в курсе проблемы. Мой комментарий должен был сказать что меня удивляют вопросы по типу этого топика, а не «почему придумали регистрацию».
Да, в ASP.NET тоже довольно легко реализуется второй метод: там Profile Provider хранит сессии анонимного пользователя и позволяет их учесть при регистрации.
Сделайте вместо регистрации авторизацю по OpenID и используйте первый вариант.

OpenID почти не напрягает пользователей, по сравнению с обычной регистрацией, где нужно заполнять кучу бессмысленных полей.
UFO just landed and posted this here
Зато не приходится заполнять никакие текстовые поля (как-минимум login, e-mail, password; в худшем случае — подтверждение по e-mail). Это напрягает гораздо больше, чем пара лишних кликов мышкой.

Похоже, что вы не разделяете идеи OpenID.
Предлагаю автору самые умные мысли и замечания переносить в статью. Дабы она не оставалась вопросом без ответов. А людям потом не надо будет просматривать все комментарии.
у меня едет крыша, или коменты стали отображаться снизу-вверх?! О__о
гмм, сейчас нормально, ну и чудеса…
Sign up to leave a comment.

Articles