Effective onboarding is an important key to helping new users to a website get integrated. A great deal of time and money is spent by major social networking sites to optimize their onboarding process.
I'm proposing that we build something similar for Drupal. The module would provide a number of configurable forms common to onboarding flows and handle pulling new users through the flow.
A short list of forms I'm planning on adding include:
* Fill out essential info for their profile
* Upload a picture
* Join groups
* Follow people
There's many more possibilities of course depending on your needs.
The module would ship with a number of common forms and provide a hook to let you add your own. Then on its admin interface, you would be able to turn on the forms you need and place them in any order. The module would then detect when a new user joins the site and guide the user through the process.
Thoughts?
Also, if you have a favorite onboarding process you could share, that would be helpful as we work on providing some good defaults.
Here's a couple of mine:
Twitter: http://www.lukew.com/ff/entry.asp?1128
http://whitneyhess.com/blog/2009/10/06/onboarding-a-sidebar-in-designing...
Comments
absolutely!
Yes, we also need something like this for cod
So...I definitely agree this should be hookable. It probably should put all of the hook implementations in a separate module (since specific sites are likely to have different needs).
One thought on this: the articles you reference have a strong preference for onboarding via forms/wizard when someone creates their account. LinkedIn seems pretty successful in providing a similar tool via a block in the sidebar. Should this try to handle both scenarios? My personal preference/need is more for the sidebar model that can nag you even after you have bailed out of the signup process and are just reading pages of the site.
knaddison blog | Morris Animal Foundation
I think this sounds great.
I think this sounds great. I'd love to help out (in fact I'm also working on COD) and there's plenty of instances where we need to guide users to the next step, keep them engaged on the site etc.
==================================
http://about.me/lisarex
This is a need we're seeing in a few places as well
And in addition to the above links, I've been pondering whether or not signup forms must die: http://www.alistapart.com/articles/signupforms
While the needs vary depending on the goals of the site, making the process of the site as simple as possible while supporting additional interaction/data collection once an account has been created seems like a good strategy.
Which is a long way of saying: make it possible to show some forms during the account creation process, make it possible to show some forms in sidebar blocks after an account has been created.
FunnyMonkey
Content Complete (or some equivalent)?
Does this fit into what you are thinking?
http://drupal.org/project/content_complete
FunnyMonkey
similar goals
That module has a similar purpose. Not sure however if the two could be integrated at all. I need to try out that module and see how it works.
Kyle Mathews
subscribing
.
@greggles -- definitely see
@greggles -- definitely see the value in the sidebar finish-up-your-profile-piece-by-piece approach. Another approach I've seen and like is the little slide down w/ a message/form (what's the name of this technique?). StackOverflow among others uses that to good effect.
So after thinking more about this over the weekend. Here's my latest plan.
Implementing modules return onboarding forms.
In the Onboarding admin UI, you arrange these forms into prebuilt queues. One queue would be for new users. Another would be for a sidebar block. Another could be for the slide-down thing. Each form could be placed into several of the queues.
Some other thoughts:
* Each form should tell the onboarding module when a particular person completes that "task". E.g. after the new user uploads a photo, the submit function calls onboarding_complete("onboarding_user_photo", 1313); // machine_name, User ID
* Each form may have an optional pre-validate function that checks if the form is still needed. E.g. if the user uploads a photo a different way, the user_photo form shouldn't be shown. Pre-validate functions are responsible for calling onboarding_complete().
* I'd need these queues to be exportable. I was thinking of just serializing the data into a variable. Simple and easy.
Thoughts?
Kyle Mathews
seems great
This all seems great to me. The only thing I'm concerned about is:
Is there something here that really makes forms make more sense than html?
knaddison blog | Morris Animal Foundation
formapi?
HTML doesn't make sense to me -- then we'd miss out on all the advantages of the form_api + the onboarding module would have to handle submissions etc. itself.
Maybe I'm missing something, why would you want html over forms?
Kyle Mathews
formapi & html
Right, I'm not suggesting that this circumvent FAPI.
I think most of the time this process should use forms and definitely support for FAPI is important, but I'm just thinking that there could be cases where you want to show someone something that isn't a form.
I guess in that case you could use the markup #type, so if it's easier to make it closely tied to FAPI then that seems fine.
knaddison blog | Morris Animal Foundation
I'd love to see this.. I also
I'd love to see this. I like the sound of constructing queues for use in different locations. It sounds like a recipe for a very deliberate process, allowing the designer to carefully shape the user experience.
2 thoughts:
-I would like it if queues could be recalled periodically based on a condition. Emails to their account have been bouncing, they haven't updated a tidbit of info that the site wants to keep current in x months, etc.. This might be set within the module, or might just be via rules integration.
-If this played nice with CiviCRM profiles I would be happy, though I realize that could be wishful thinking.
Interesting ideas
On forms being periodically checked. The pre-validate function I talked about earlier could do this. So when the onboarding module is choosing a block to load, it would go down the forms in the queue and asking each in turn if it wanted to be loaded. For the email bouncing check, you'd need more code elsewhere to check which emails are bouncing. Then when the pre-validate function is called, it'd check if emails sent to this user's email account had been bouncing. If they were, it'd load a form saying they needed to change their email address.
I don't see why it wouldn't work with CiviCRM. You'd have to write the code to make it work but other than that, it'd work fine.
On "allowing the designer to carefully shape the user experience". Yes exactly. Something I'd love to see eventually is an a/b testing framework for Drupal or at least integration w/ 3rd party tools that do the same thing such as Kissmetrics or Mixpanel. The Onboarding module could integrate with those to allow for simplified testing of changes to the onboarding process.
Kyle Mathews
HRM, +1 on the idea of using
HRM, +1 on the idea of using something like MixPanel, throw in some funnel tracking to get an idea just how effective the onboarding process is, and that would be highly useful!
Mixpanel = YES!
That's a great idea and... lookie at this new module I just found http://drupal.org/project/mixpanel :)
I was thinking of using Mixpanel primarily for event tracking but auto-integrating it with the Onboarding module is a brilliant idea as well. It'd be easy to set things up so all you have to do is turn on Mixpanel and Onboarding and you'd automagically get funnel tracking.
It'd be really nice too, at some point, to get an a/b testing framework built for Drupal (or is there one already) as that'd be super valuable as well for developing/testing/optimizing funnels.
Kyle Mathews
Quant?
There's also http://drupal.org/project/quant via Aquia. Though in-page actions as mentioned in the mixpanel desc. could be very desirable in some cases.
Mixpanel > Quant
Mixpanel's data browsing UI is roughly 10 million times more powerful than Quant. Mixpanel, after a week of playing around with it, has my data-loving heart in a tizzy. It's really an incredible tool for tracking and analyzing event data. Most critical for me is the ability to segment events by all sorts of different variables. One really useful thing the module is doing is tracking event data by cohort or the month that the user signed up for the site. See http://www.avc.com/a_vc/2009/10/the-cohort-analysis.html for more on that.
Anyways, Quant is a nice effort but there's zero chance they'll be able to match Mixpanel's power and sophistication.
Kyle Mathews
Sold.
I'm sold. As someone who apparently just DID a small cohort analysis manually (though I didn't know the name), I'm liking that a lot. You're basically working on most of my dream features, thanks.
A few months agoI put
A few months agoI put together a simple wireframe for what a simple onboarding UI might look like:
Sounds nice - Ubercart integration?
Good idea - would also want to make sure to factor in ubercart role purchasing -- aka buying a role on a site and going thru that in the user creation process as well. Much like email verification already noted, payment verification could work into it. Great stuff!
Connector project
Hi Kyle (et al),
Thanks for discussion around this topic- It's a recurring conversation topic for most new project these days, and somewhat neglected in contrib.
Have you seen the connector project(s)? It would be great to coordinate your, and those efforts (if possible).
Also, Google released some good information/references from about onboarding and identity/authentication in general.
Thanks for the links
I hadn't seen either of those two so I appreciate you passing along those links. The connector project looks particularly interesting. I'm not sure how much our two projects would need to coordinate however as where the Onboarding module steps into play is only /after/ someone has created a new account. So Onboarding should be mostly or completely indifferent to how people create accounts on your site. It will simply do its best to detect when someone has created a new and what they have/haven't done in the onboarding process.
Kyle Mathews
Onboarding and User Registration
Is this really true? I had always considered the user account creation/registration as the most important of the onboarding opportunities. The following is from the google link I posted:
Hope I'm not confusing things.
sorry for the confusion
I meant Onboarding the module (capital O) is indifferent to how people create accounts on your site. Making the user account creation as easy as possible is of course an incredibly important part of the onboarding (lowercase o) / registration process.
The Onboarding module is an API module that helps ease the process of building custom onboarding processes by providing hooks to easily arrange forms within the onboarding process and providing integration with common funnel analysis tools (such as Mixpanel and Kissmetrics) to track and optimize successful onboarding.
So exactly how new user accounts are created isn't that important as different sites will have different ways of doing it (e.g. admin created accounts vs. open access vs. LDAP or other SSO). Onboarding will just do its best to detect the new user when the new user is created and then push the new user through an onboarding process as built for that site.
Kyle Mathews
Thanks for clarifying Kyle,
Thanks for clarifying Kyle, that makes things more clear.
Isn't this kind of similar to
Isn't this kind of similar to pageroute+profile registration? Admittedly, those don't really work very well, but it seems like you might be able to work the bugs out of them easier than developing a module completely from scratch.
I would say pageroute and
I would say pageroute and onboarding overlap in purpose and ability by perhaps 25%. They only deal with node forms and onboarding doesn't (well it could I guess but I never will) deal with node forms but instead, custom created forms. So no, they're not very close and it wouldn't be easier to try to merge what I want to do with them.
Kyle Mathews
Ok, thank you for the
Ok, thank you for the clarification. So, is this module still in the planning stages, or has significant development already taken place? Also, are you planning this for D6 or D7, (or both)?
Planning stages still, first
Planning stages still, first D6 and then later D7.
Kyle Mathews
More on his Topic
Just wanted to reference another posts on this topic at http://groups.drupal.org/node/138949 and http://drupal.org/sandbox/tcarmona/1120194
So where are we on this
So where are we on this topic? Any update in the last few years?
I'm working on upgrading this
I'm working on upgrading this module - http://drupal.org/sandbox/tcarmona/1120194