Skip to:
Content

BuddyPress.org

Opened 12 years ago

Closed 6 years ago

#4132 closed enhancement (maybelater)

Account activation revamp

Reported by: sooskriszta's profile sooskriszta Owned by:
Milestone: Priority: normal
Severity: normal Version: 1.5
Component: Core Keywords: needs-patch, trac-tidy-2018
Cc: vivek@…

Description

In view of #4128 and #2741 I propose the following flow:
fill out registration -> activate account -> upload avatar -> login
Upload avatar step will not be mandatory.

The power and importance of avatars can't be overemphasized. This flow will likely lead to the vast mojority of users uploading avatars. Additionally, it is fairly standard for social networks.

Attachments (7)

1-register-form.png (8.8 KB) - added by sooskriszta 10 years ago.
2-register-form-submitted.png (7.3 KB) - added by sooskriszta 10 years ago.
3-activation-photo.png (19.3 KB) - added by sooskriszta 10 years ago.
4-activation-profile.png (15.2 KB) - added by sooskriszta 10 years ago.
5-activation-groups.png (16.1 KB) - added by sooskriszta 10 years ago.
6-activation-friend-search.png (13.9 KB) - added by sooskriszta 10 years ago.
7-activation-friend-search-results.png (29.5 KB) - added by sooskriszta 10 years ago.

Download all attachments as: .zip

Change History (67)

#1 @sooskriszta
12 years ago

When I say it's fairly standard for social networks, I mean uploading avatar immediately upon activation is fairly standard. Most social networks (and many other sites) automatically log the user in when she clicks on the activation link, so a separate manual login step is not required.

#2 @DJPaul
12 years ago

  • Keywords 2nd-opinion added

Users aren't logged in when the account is activated. I'm not sure it's safe to change that behaviour (e.g. someone else somehow using your registration token).

#3 @sooskriszta
12 years ago

Sorry, Paul, I didn't quite understand why it isn't safe to log the user in when he clicks on the activation link.

The majority of large sites I know actually have the user logged in at activation. From my experience with a site (non BuddyPress), 96% of users activate their account within 3 minutes of registration, 3% activate within 30 mts, and 90% of of those that don't activate within 30mts end up never activating.

The way one of the sites I know works is: When a user registers, he is logged in automatically. But since the account is not activated, he can't access any functionality. Upon clicking the activate link, the logged in user is taken to a basic profile info page, including uploading of profile image. If the user does not activate within 30mts, his connection/login is timed out. Then if he clicks on activation link after that, then he needs to log in after activating the account (theoretically, he can also log in before clicking on activate link...but such login still doesn't provide him access to functionality...and in practice few users who haven't activated within 30mts actually log in before clicking the activate link).

Another site I know distinguishes between first login and all other logins. After registering, user click on activate link. Then he has to log in. Upon login (first login) he is prompted to upload a profile photo, invite friends, etc.

I'm sure one of these workflow models could work for BuddyPress...

#4 @boonebgorges
12 years ago

The majority of large sites I know actually have the user logged in at activation.

Can you name some examples? I tend to agree with Paul that it's not secure to do this kind of auto-login. The issue is this: users activate their accounts with an activation key, which is sent in plaintext in an email. For the "96%" of users that activate within a few minutes, there is not much of a security issue (because the activation keys are deactivated after being used). But for those few users who never actually click the link, it means that there is an unused activation key sitting out there, waiting to be exploited at any point by whoever happens to stumble upon the email (or even manages to guess the proper URL).

If you want auto-login on activation, it's pretty easy to do with a plugin. (The hook you'll want to look for is 'bp_core_activated_user', and the WP function is wp_set_auth_cookie()) In this case, I would recommend that your plugin also set a short expiration date for activation keys, so that after (say) an hour or a day, a user will have to have a new key generated and emailed. That'll greatly reduce the likelihood of compromise.

#5 @sooskriszta
12 years ago

Facebook uses the "old BP" technique of uploading images on registration, before even sending out an activation link. If you click on activation link, you are already logged in.

hi5 has a similar method. When you click on activation link, you find that you are already logged in.

In Twitter, when you register, you are logged into your account (and you can add photos, edit profile, etc). Then an activation email is sent to you. If you click on activation email, you find yourself already logged in.

If you click on Activate link in Meetup, you find that you are already logged in.

etc.

But @boonebgorges, after your explanation, I understand your the security concerns a bit better. I think the 1st of the 2 workflows in my above message could be a good solution...

When I register for a BBPress site, I am logged in immediately (and my login times out in 30mts upon inactivity). But I don't have access to the major functions of the site. I receive an activation email. If I click on the activation email immediately, I find that I am already logged in, and am prompted to upload a profile picture.

If on the other hand, I am timed out, and then click on activation link, then after activation, I should be asked to log in manually. In that case, (because experience shows that % of people that fall in this category is so low) this should be a normal login, and user need not be prompted for any action.

Eitherway, I think the activation code should be short-lived. It should not last more than a couple of hours and definitely not longer than 1 day. After all, there's always the "resend activation email" fuctionality, which should always expire the old code and send a new one...

#6 @boonebgorges
12 years ago

  • Milestone changed from Awaiting Review to Future Release

Thanks for the descriptions. My guess is that FB etc are actually logging you in based on cookies that are set during the registration process, *not* based on the activation key itself (a much more secure method, to be sure). I'd have to do some testing.

I think it's worth examining whether there are ways we can modularize the signup process, so that admins can decide on a case-by-case basis when/whether avatar upload is to take place. Moving this ticket to Future Release for further discussion.

#7 @sooskriszta
12 years ago

I think many of the sites differentiate between activated login and inactive account login states.

When customer has not activated the account, (s)he can still log in, but can't use many of the site's functions. Upon activating, it becomes a full account.

Based on this, I agree, many of the above sites are probably not logging you in based on activation key. Instead, as an end-user you get that experience because you are already logged in (inactive login state)...these sites log you in immediately upon registration. What activation key does is that it changes your account status (and therefore privileges).

Last edited 12 years ago by sooskriszta (previous) (diff)

#8 @sooskriszta
12 years ago

  • Version changed from 1.5.4 to 1.5.5

#9 @boonebgorges
12 years ago

  • Version changed from 1.5.5 to 1.5

The purpose of the 'Version' field is to note the first version of BuddyPress where the issue in question was noted. There's no need to change it in this case - if anything, the version should be 1.5, which is the first version where the avatar upload was moved.

#10 @sooskriszta
12 years ago

Any chance of this being sneaked into 1.7?

#11 @boonebgorges
12 years ago

Any chance of this being sneaked into 1.7?

We're too far into development - most of the new feature development for 1.7 is already done. Let's talk about this when we start scoping 1.8.

#14 @sooskriszta
11 years ago

1.8 has been in the wild for a few weeks. 6 tickets for 1.9 are already closed https://buddypress.trac.wordpress.org/milestone/1.9

Hope we get some action on this now.

#15 @sooskriszta
11 years ago

  • Cc vivek@… added

#16 @latinosamorir
10 years ago

Hello.

My name is Giovanni and I own a site that uses buddypress plugin with 5800 users.

After 6 years of having the site and evolving with BP, and learning about UX, etc. I will have to agree with sooskriszta.

The flow after removing the "Upload Avatar" reduced dramatically the funnel of activations and new users.

If you look at my member directory, more than half of the users do not have a photo and the users on the site has become less engaged.

A friend of mine works at Google, she's not a coder but a UX designer and if you're interested, I can ask her to help with the UX flow of registration (which needs a lot of work - based on a focus group I did). She got a PhD in human-machine interaction within the cognitive science department.

In addition, I would love to see a revamp of the user registration experience to focus on growth and user on-boarding. This will help every other install of buddypress and not just mine.

A great presentation about user growth can be found here:
http://www.slideshare.net/gtlenz/growth-hacking-case-studies-1

And a case study on how Facebook onboards its users:
http://www.aginnt.com/post/37636482299/grow-like-facebook-onboarding-and-activation#.UnycFpTwJg1

Please let me know your thoughts and if we can make this happen!

Giovanni Dubois

#17 @sooskriszta
10 years ago

One way to look at it is:
As soon as a person registers, they become a member of the site. AND they are logged into the site.

However, access to the site is role based. Upon registration, a member defaults to "non activated" role. In non activated role, the member has limited access (or no access to) what are typically "logged in" features (add friend, join group, etc). However, a non activated user CAN change his/her own profile.

Also, upon registration (and subsequent automatic login) the next steps (landing page/sequential pages) are

  1. Add photo
  2. Invite friends
  3. Enrich profile
  4. Activate account

Once activation link is clicked, the user becomes a "normal" role user (whatever default role site admin has chosen for new users).

P.S. Registration itself should ask for only 3 fields:
Name (Display Name)
Email
Password

#18 @henrywright
10 years ago

sooskriszta I very much like your idea of a role based approach to registration. Do you know if there are any security implications?

An observation - when a user, say sooskriszta , has completed the registration form but DOES NOT activated their account - a profile page is created for them and is accessible via the URL example.com/members/sooskriszta . The user isn't logged though.

Last edited 10 years ago by henrywright (previous) (diff)

#19 @sooskriszta
10 years ago

I'm no expert in security, but in using this workflow, we do avoid the security issue discussed in #4128

#20 follow-up: @boonebgorges
10 years ago

latinosamorir - I'm definitely open to exploring a more wide-ranging revamp of the new user experience for BP, including registration as well as what happens when the user first visits the site.

sooskriszta's suggestion about logging users in, but not giving them full access until they've activate, is pretty appealing. We would still need to keep email activation (or something like it) to deter bot signups, so we wouldn't be able to adopt a simple "activate account" button. But I do like the simplified flow. The problem with this kind of change, however, is that WP/BP don't currently make it easy to recognize different classes of users and to give them different permissions. See, eg, https://buddypress.trac.wordpress.org/ticket/5121. This problem would need to be solved before we could move forward with the registration workflow sooskriszta describes.

In the shorter term, I'm definitely game for reconsidering the avatar upload workflow. What do people think of DJPaul's suggestion in #4128, namely that a user is prompted to upload an avatar after logging in for the first time? Then this would become more about new user experience - something we need some work on anyway - than about registration itself.

#21 @henrywright
10 years ago

boonebgorges - regarding a role based approach to registration being dependent on 5121 - could a less sophisticated approach be to assign the WP role 'subscriber' to all non-activated users? Once these users activate their account they become upgraded to role 'contributor'. According to the WP codex, subscribers have just read access which is what we'd want for non-activated users: http://codex.wordpress.org/Roles_and_Capabilities

Regarding the member being prompted to upload an avatar after logging in for the first time, would the prompt take the form of a template notice announcement? Or perhaps a redirect to the change-avatar page itself? I think this would be a quick win but as you mention, new user experience could still be improved quite a lot beyond that.

#22 @boonebgorges
10 years ago

henrywright -

could a less sophisticated approach be to assign the WP role 'subscriber' to all non-activated users?

Nope, that won't work. From the WP point of view, Subscribers are limited in what they can do. BP's system is totally separate. With the exception of Administrators (and Network Administrators), all logged-in users - regardless of WordPress role - are on an equal footing in terms of capabilities.

Regarding the member being prompted to upload an avatar after logging in for the first time, would the prompt take the form of a template notice announcement? Or perhaps a redirect to the change-avatar page itself? I think this would be a quick win but as you mention, new user experience could still be improved quite a lot beyond that.

I'd like to see this in the context of improving the NUX broadly, but I don't want to get hung up on it: if there are things we can do in the near-term to fix this issue, we shouldn't avoid doing them just because there are other new-user issues that still need fixing.

But, in any case, there are many ways that the idea could be cashed out. Off the top of my head:

  • When the user logs in for the first time, he is directed right to the Change Avatar page, perhaps with a message like "Hey, it's your first time here...."
  • When the user logs in for the first time, show some sort of overlay/interstitial. It'd say something like "Hey, it's your first time here..." and would encourage people to change their avatars. (In the future, we could use this same space for other NUX enhancements.) The user could then dismiss the interstitial and would never see it again.
  • When the user logs in for the first time, he is redirected to a Welcome page, with content similar to what's described above. This page could be revisited at any time.
  • When the user logs in for the first time, there's some sort of inline notification on the screen - say, a bar across the top of the page - that says "Hey, it's your first time here..." and asks them to change their avatar. The notice-bar would be persistent from page to page, disappearing only when (a) the user dismissed it manually, or (b) the user uploaded an avatar.

All of these would be implemented in such a way that the content itself would be determined by template file, and thus could be overwritten in themes.

Hopefully these are a helpful starting point for different ways the UX might look.

#23 @henrywright
10 years ago

Nope, that won't work

I had an idea it wouldn't be that simple :)

When the user logs in for the first time...

Is there an action which fires on first login only? Perhaps that is all that is needed? That would open the door for plugins and theme authors to do as they please without BP having to hard-code (so to speak) the exact NUX journey.

Last edited 10 years ago by henrywright (previous) (diff)

#24 in reply to: ↑ 20 @sooskriszta
10 years ago

Replying to boonebgorges:

sooskriszta's suggestion about logging users in, but not giving them full access until they've activate, is pretty appealing. We would still need to keep email activation (or something like it) to deter bot signups, so we wouldn't be able to adopt a simple "activate account" button.

Yup...in my suggestion, I assumed that there would be an activation link email, clicking on which will change the user's role.

Replying to boonebgorges:

  • When the user logs in for the first time, show some sort of overlay/interstitial. It'd say something like "Hey, it's your first time here..." and would encourage people to change their avatars. (In the future, we could use this same space for other NUX enhancements.) The user could then dismiss the interstitial and would never see it again.
  • When the user logs in for the first time, he is redirected to a Welcome page, with content similar to what's described above. This page could be revisited at any time.

I like these 2 ideas better than the others. I think it is important to guide the new user through the process step by step, as opposed to taken to edit profile page and left to his/her own devices. In other words, a 3 step process where on one page they are ASKED TO upload photo, on next they are asked to enter all their details into open/visible fields, and maybe a 3rd page where they are asked to join groups is better than a single page where they CAN click links to change their details.

#25 @boonebgorges
10 years ago

Is there an action which fires on first login only?

Yes! http://buddypress.trac.wordpress.org/browser/tags/1.8.1/bp-core/bp-core-functions.php#L845

In other words, a 3 step process where on one page they are ASKED TO upload photo, on next they are asked to enter all their details into open/visible fields, and maybe a 3rd page where they are asked to join groups is better than a single page where they CAN click links to change their details.

I think this is probably true with respect to many individual community sites. The tricky part is that what exactly these three (or however many) steps will be will vary from site to site. A site that does not have groups enabled will not need a Groups step. A site that has disabled avatar uploads does not need an avatar upload step. And so on. Perhaps more importantly (because, of course, we can easily detect when components are switched off), sometimes communities may not *want* to emphasize, say, the joining of groups. (For example, a school site that uses groups to represent classes doesn't need to encourage new members to join groups.) So we need to come up with a workflow that: (a) will be good for maybe 70-80% of BP installs out of the box; (b) is flexible enough to be modified by devs/plugins/themes; (c) is intelligent enough to automatically work differently when different components are enabled/disabled. Ideally, we would be able to build this into BuddyPress without the construction of massive administration panels, without some sort of drag-and-drop interface that lets admins build their own NUX workflow. (Not that there's anything wrong with these sorts of tools - it would make a great plugin - I just think we should strive to come up with something that's general enough to suit most users without large amounts of config.)

#26 @henrywright
10 years ago

Thanks for the signpost to bp_first_activity_for_member

bp_core_activated_user is another good one I just came across.

#27 @sooskriszta
10 years ago

On first login:
Step/Page 1: Upload photo (or skip)
Step/Page 2: Enter profile information (or skip)
Step/Page 3: List of groups to join (or skip) - IF profile component is enabled.
Step/Page 4: Search (by name or email) and add friends (or skip) - IF friends component is enabled.

I feel this would help *most* communities. BTW, this workflow is also *relatively* popular among other social networks.

For example, a school site that uses groups to represent classes doesn't need to encourage new members to join groups.

Interesting use case. But in this case, shouldn't the groups be "closed" i.e. only groups admins can add members?

At step 3 we should only show groups that are "open" for people to join, and if there are zero groups of this type, the step should automatically be skipped.

#28 @boonebgorges
10 years ago

  • Keywords needs-patch added

sooskriszta - I like what you've laid out here. I'd love to see a patch (or better yet, a plugin) that implements the idea. Or even some wireframes.

#29 @sooskriszta
10 years ago

Not skilled enough to cook up a patch. But wireframes I can do. Will post soon.

#30 @henry.wright
10 years ago

sooskriszta, boonebgorges

In an addition to what sooskriszta has suggested, I think the 'before first login' part of the registration process can be improved also.

Before first login

  1. Complete standard registration form
  2. Send activation email if registration form data checks out
  3. Auto log in un-activated user with 'read only' capabilities
  4. User can browse around, see their uncompleted profile and so on... but as soon as they try to do anything such as send a private message, make an activity update etc they get a "please activate your account using the email we've sent" template notice
  5. At some point in time, the user activates their account via the email they've received
  6. User is now an activated member with full capabilities

At this point, sooskriszta's steps 1 - 4 kick in.

The 'read only' stage before activation gives the user a glimpse of what can be done on the BuddyPress site. A peek behind the closed door for want of a better phrase. I think this might encourage more users to activate their account. What do you think?

Last edited 10 years ago by henry.wright (previous) (diff)

#31 @boonebgorges
10 years ago

sooskriszta - Cool, looking forward to seeing something.

henry.wright - This is not a bad idea, but I think we should open a separate ticket. Technically, it's going to be a lot more problematic than what sooskriszta is suggesting. Also, I'm not sure it will be as desirable to as many communities, so I think it might be even better suited for a plugin.

#32 @henry.wright
10 years ago

I'll raise a ticket for discussion, but feel free to close if you decide this sort of thing is plugin territory.

#33 @sooskriszta
10 years ago

Oops...in 7-activation-friend-search-results.png I had intended to put names of the people between their photos and the Add friend button.

This ticket was mentioned in IRC in #buddypress-dev by boonebgorges. View the logs.


10 years ago

#35 @sooskriszta
10 years ago

By the way, just for clarification:

  1. This is more or less how Facebook does it. Google+ does nags as mentioned in the IRC. However, I would go with Facebook on this one. There is always a trade off. If it's upto users many would never upload photos and consequently never engage in the community. Nags might work of user is already engaged and logging in often (email Nags would be spam, pure and simple). So there is a catch 22. Asking them to put in the extra effort up front is great for engagement. Even a little bit of time and effort invested by users up front gets them invested and engaged. .. There has been lots of research on this. Can post links of anyone needs.

Also Facebook is more successful than Google+... In fact bulk of Google+ usage comes from Google strong arming people into signing up for it. Just this fact by itself doesn't mean that whatever Facebook does is correct. In this case I do think it is though. Success is an indication that they have the capability to test many things and do what world's best.

#36 @sooskriszta
10 years ago

  1. Step 3 will activate only if there are public groups. Step 4 will activate only if friends component is enabled and only public profiles will be shown.

#37 follow-up: @henry.wright
10 years ago

Hi sooskriszta

The screenshots look great. My thoughts on your proposal are:

  1. Introducing something like this would need to be done very thoughtfully, keeping in mind the extra steps must not be seen as a 'barrier to entry', rather something that can be done in an engaging way 'after entry'.
  1. The alternative nag approach (used by Google+) looks good, feels good and isn't very obtrusive. What advantage does the sign-up step approach have over the nag approach? My personal view is people love familiarity. People aren't exactly flocking in their droves to use Google+ where as 10% of the world use Facebook. People will be used to the sign up steps. Twitter has them too. That said, familiarity alone doesn't prove it's a better approach to take.
  1. The 'skip step' link is very important. If users feel it's too much effort to complete the step you don't want them closing the browser window, never to see them again.

Overall I think the idea is a good way to 'enrich' a BuddyPress site. Too often you see a BP site with 100s of users with no profile info, mystery-man avatar. That sort of site isn't appealing to new users. Users will feel more at home in a friendly and open community, not so much in a mystery-man driven anonymous community.

#38 in reply to: ↑ 37 @sooskriszta
10 years ago

Replying to henry.wright:

steps must not be seen as a 'barrier to entry', rather something that can be done in an engaging way 'after entry'.

I agree.

From my perspective, we should make registration as easy as possible...if it were upto me, I'd simplify 1-register-form.png and have only email field there. We should email the initial password to the user. Email address can be used as the login name.

But, of course, we are dependent on WordPress so I assume we need the 5 fields.

While I view registration as "entry point" and think that it should be as simple as possible, I think activation is actually "after entry" in the sense that the visitor is already invested in the process...(s)he has gone through the big mental leap of deciding to join, and has provided his/her email. A couple of additional steps at this point don't deter most users. In fact, the users who go through the additional effort turn out to be more engaged.

What advantage does the sign-up step approach have over the nag approach?

As above.

My personal view is people love familiarity...People will be used to the sign up steps. That said, familiarity alone doesn't prove it's a better approach to take.

As it turns out, sometimes familiarity by itself becomes a major usability issue. e.g. objectively, green links are more usable, but blue links became popular in the early days of the web and so they attained a certain meaning for people. There is an expectation now that blue underlined text would behave in a particular way.

The 'skip step' link is very important. If users feel it's too much effort to complete the step you don't want them closing the browser window, never to see them again.

Agree 100%

#39 @sooskriszta
10 years ago

Any other feedback on the wireframes, process or the concept itself?

How can I, not being a coder, help in getting the ball rolling?

#40 @Amid11
10 years ago

I think it should be in the next version of BP Because buddypress isn`t well user friendly and by this way we can improve It.
thanks everyone!

#41 @sooskriszta
10 years ago

  • Summary changed from Upload profile image at activation to Account activation revamp

#42 @sooskriszta
10 years ago

  • Keywords dev-feedback added

Could this...Ahem! Could this be the big user-facing enhancement for 2.1?

#43 @sooskriszta
10 years ago

By the way, for step 1: grabbing user image via webcam, getUserMedia is an option. Firefox, Chrome discuss this, and here's a clarification over at Stack Overflow.

This ticket was mentioned in IRC in #buddypress-dev by OC2PS. View the logs.


10 years ago

#45 @sooskriszta
10 years ago

A good side-effect might be reduction in spam registrations.

#46 @sooskriszta
10 years ago

The steps should depend on the components activated.
e.g. If friends component is not activated, no sense searching friends, or if groups is not activated, no reason to have that screen.

#47 @sooskriszta
10 years ago

We may consider introducing the steps in a phased manner, with the first cut including only step 1, i.e. uploading/capturing profile photo (which incidentally is how this ticket got started)

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.


9 years ago

#50 in reply to: ↑ 49 @sooskriszta
9 years ago

Replying to Slack:

OC2PS we have never hashed it out. i have heard that some people have some objections/concerns/reservations. but havent heard specifically what concerns. i would like to thrash this out and try to address concerns. and hopefully reach a consensus on whether or not this ticket makes sense
Boone: IIRC the primary concern was introducing more friction to the registration + activation process than already exists
So it would be nice for the workflow to be configurable by the admin, so if the admin wanted an in-depth process, they'd be able to have it, or not.
But that introduces lots of infrastructure
JJJ: The one thing I really want is to be able to cherry pick fields that are required on sign-up.
I mean... I think we should simplify sign-ups anyways.
Boone: Yeah, and I'd like to interface with member types
JJJ: For sure
That's huge.

ok. just based on the wireframes, there are a couple of clarifications:

  • There is always a skip link. so should reduce friction. many popular social networks follow this model
  • Remember, this is not registration. I'm all for minimizing registration. This ticket goes hand in hand with #5583
  • If a component (e.g. group or friends) is not active then it shouldnt appear as one of the tabs/steps.

Like jjj I would love for admin to be able to cherry pick fields. Not only here but also on profile summary/cards #4126 But let's not make great the enemy of the good. If we start without the ability to cherry pick fields and add that ability later, it wouldn't be such a disaster.

Ditto for interfacing with member types. It's a bit premature to design FOR something that doesn't exist yet.

#51 @johnywhy
8 years ago

hi, i understand the security concerns of the devs, but those concerns do not apply to our site. You are making assumptions that do not apply to us.

We are a private community, and our registration page is password-protected. We do not even display a public 'Register' link. Plus, we have disabled self-activation-- all new registrations are manually reviewed and activated by the admin.

By not including the avatar-uploader in the reg screen, you are creating overhead for our organization-- we'll have to chase after members to get them to add their image later, after registering.

Our members are kids. It's a big enough challenge for us to get our kids to register in the first place. Did you ever chase after a kid to get them to do something?

It does not have to be there by default, you could make it available in the Fields editor. Also, how could someone upload a virus if the avatar uploader only accepts images?

In researching this issue, i have seen numerous requests from BP users to put the avatar uploader back on the Reg screen. Would be awesome if you could accommodate the several people who would like this feature.

many thx!

Last edited 8 years ago by johnywhy (previous) (diff)

#52 @alexua22
8 years ago

Plugin A.
Am I correctly understand,that is needed following order?:
1-register-form.png - mandatory
2-register-form-submitted.png - mandatory
3-activation-photo.png - can skip
4-activation-profile.png - can skip
5-activation-groups.png - can skip - IF profile component is enabled.
7-activation-friend-search-results.png - can skip - IF friends component is enabled.

6 - don't need, because it included in 7. Is this the correct order?

And have one more question - about items 5 and 7 - So, if this component not enabled (by Admin) than this is page isn't appear for activation or you can't to skip this page?

Version 0, edited 8 years ago by alexua22 (next)

#53 @DJPaul
8 years ago

@alexua22 I don't think consensus was ever reached. This is an old ticket.

I think registration needs to have a very minimal set of data requirements. Auto-login may be a good idea worth re-considering, but there are complexities around requiring better user access controls over content, and how the concept might negatively interfere with other WordPress plugins.

My gut feeling is that the steps for capturing extra data should be after registration and account activation, and probably best handled in a plugin.

#54 @technologypoet
8 years ago

Perhaps I'm misunderstanding, is there a reason a 'Profile Photo' field couldn't be added to the set of profile fields chosen on registration, and then after successful registration auto-login the user and begin profile photo upload?

While I like the idea of a user activation sequence, as @DJPaul points out, there are many plugins that also hijack the 'after registration' page to do other things.

#55 @DJPaul
8 years ago

  • Keywords 2nd-opinion dev-feedback removed

I am still very against auto-login. I think that's insecure, and no way are we going to change this in BuddyPress just to prove me wrong (or right).

is there a reason a 'Profile Photo' field couldn't be added to the set of profile fields chosen on registration, and then after successful registration auto-login the user and begin profile photo upload?

The flaw in your thinking is if we being profile picture upload sometime after the user has activated their account or logged in for the first time... you've already had to upload the photo during registration. It's a bit irrelevant whether the image is assigned to a user or not, it's still uploaded. BuddyPress isn't imgur :)

Going to keep ticket open because we need to digest all the tickets and see what precisely is left to implement or discuss further here.

#56 @technologypoet
8 years ago

Thanks for your reply @DJPaul - I suspect the goal should be less of imgur, and more to enable a registration flow similar to Facebook. This would have minimal initial registration requirements (username/password), with the ability to easily create a flow afterwards to fill out optional profile fields (like image). Option to redirect for post-registration flow, and ability for this post registration flow to redirect elsewhere I think would accomplish this.

It would allow out the box experience to support facebook like registration flow, without requiring images be uploaded before sign-in, and still provide a hook for plugins to enhance the registration flow.

This ticket was mentioned in Slack in #buddypress by oc2ps. View the logs.


8 years ago

#59 @DJPaul
6 years ago

  • Keywords trac-tidy-2018 added

We're closing this ticket because it has not received any contribution or comments for at least two years. We have decided that it is better to close tickets that are good ideas, which have not gotten (or are unlikely to get) contributions, rather than keep things open indefinitely. This will help us share a more realistic roadmap for BuddyPress with you.

Everyone very much appreciates the time and effort that you spent sharing your idea with us. On behalf of the entire BuddyPress team, thank you.

If you feel strongly that this enhancement should still be added to BuddyPress, and you are able to contribute effort towards it, we encourage you to re-open the ticket, or start a discussion about it in our Slack channel. Please consider that time has proven that good ideas without contributions do not get built.

For more information, see https://bpdevel.wordpress.com/2018/01/21/our-awaiting-contributions-milestone-contains/
or find us on Slack, in the #buddypress channel: https://make.wordpress.org/chat/

#60 @DJPaul
6 years ago

  • Milestone Awaiting Contributions deleted
  • Resolution set to maybelater
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.