Skip to:
Content

Opened 2 years ago

Last modified 3 days ago

#4132 new enhancement

Upload profile image at activation

Reported by: sooskriszta Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 1.5
Component: Core Keywords: 2nd-opinion needs-patch
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 8 weeks ago.
2-register-form-submitted.png (7.3 KB) - added by sooskriszta 8 weeks ago.
3-activation-photo.png (19.3 KB) - added by sooskriszta 8 weeks ago.
4-activation-profile.png (15.2 KB) - added by sooskriszta 8 weeks ago.
5-activation-groups.png (16.1 KB) - added by sooskriszta 8 weeks ago.
6-activation-friend-search.png (13.9 KB) - added by sooskriszta 8 weeks ago.
7-activation-friend-search-results.png (29.5 KB) - added by sooskriszta 8 weeks ago.

Download all attachments as: .zip

Change History (47)

comment:1 sooskriszta2 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.

comment:2 DJPaul2 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).

comment:3 sooskriszta2 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...

comment:4 boonebgorges2 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.

comment:5 sooskriszta2 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...

comment:6 boonebgorges2 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.

comment:7 sooskriszta2 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 2 years ago by sooskriszta (previous) (diff)

comment:8 sooskriszta2 years ago

  • Version changed from 1.5.4 to 1.5.5

comment:9 boonebgorges2 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.

comment:10 sooskriszta19 months ago

Any chance of this being sneaked into 1.7?

comment:11 boonebgorges19 months 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.

comment:14 sooskriszta8 months 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.

comment:15 sooskriszta8 months ago

  • Cc vivek@… added

comment:16 latinosamorir5 months 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

comment:17 sooskriszta5 months 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

comment:18 henrywright5 months 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 5 months ago by henrywright (previous) (diff)

comment:19 sooskriszta5 months ago

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

comment:20 follow-up: boonebgorges5 months 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.

comment:21 henrywright5 months 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.

comment:22 boonebgorges5 months 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.

comment:23 henrywright5 months 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 5 months ago by henrywright (previous) (diff)

comment:24 in reply to: ↑ 20 sooskriszta5 months 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.

comment:25 boonebgorges5 months 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.)

comment:26 henrywright5 months ago

Thanks for the signpost to bp_first_activity_for_member

bp_core_activated_user is another good one I just came across.

comment:27 sooskriszta2 months 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.

comment:28 boonebgorges2 months 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.

comment:29 sooskriszta2 months ago

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

comment:30 henry.wright8 weeks 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 8 weeks ago by henry.wright (previous) (diff)

comment:31 boonebgorges8 weeks 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.

comment:32 henry.wright8 weeks ago

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

sooskriszta8 weeks ago

comment:33 sooskriszta8 weeks 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.

comment:34 ircbot8 weeks ago

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

comment:35 sooskriszta8 weeks 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.

comment:36 sooskriszta8 weeks 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.

comment:37 follow-up: henry.wright8 weeks 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.

comment:38 in reply to: ↑ 37 sooskriszta8 weeks 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%

comment:39 sooskriszta3 weeks 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?

comment:40 Amid113 days 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!

Note: See TracTickets for help on using tickets.