You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Change onboarding service to allow for a donating state #1098
The onboarding service needs refactored to allow for an additional state of donating and the project you were donating to in order to handle redirects and make logical sense of the signup flow.
There are inconsistencies here in relation to other issues that are part of this project.
According to several other tasks, there would be two new states:
signed_up_donating - initial state when signed up from the donated page
donated - state that goes right after signed_up_donating
The signed_up_donating state can't really deal with any sort of redirection. A user will sign up in order to donate to a project, but we do not store information on which project that is. Even if we did, we would effectively lock the user into donating to a single project until they cancel out or complete that process.
The easier approach would be to use session redirection upon signup/sign in provided by ember-simple-auth, which is what #1183 does.
The donated state could be functionally equivalent to signed_up, or we could handle it through the onboarding header described in #1095.
If we make it functionally equivalent, the it's a matter of rewriting the _steps array and the _currentStep computed.
For the onboarding header approach, we should move the discussion into #1095
I've started some of this, and also addressing #1094 in the process.
Effectively, we need a sense of our allowedRoutes where we do not try to transition, vs the routes in the onboarding process where you are supposed to transition in a specific order.
One idle thought, while I'm thinking about it, is that we shouldn't really have any problem with people skipping steps in the onboarding process. We should still attempt to guide them through it, but allowing a "skip" link below the buttons (in the start routes) would be fine, as would going back a step. We'd ideally track the skipped steps, too.
This might make our API transitioning more flexible.
On the client, every allowed route can be transitioned to, but no disallowed route can be transitioned to.
The difficulty mostly then lies in handling transitions from one of the donation routes to the index route (by clicking the header). This is an edge case that's not really handled.
I feel that forcing users into steps makes things easier for us later, maybe, but it also pushes users away, so we should allow freedom where we can. We're not making great use out of onboarding at the moment anyway, since task/project matching is still in the works. Letting them skip it means more of them get to the project/task/donate pages, where we really need them right now.
I a header or some other UI element that guides is something that would allow most users to go through onboarding eventually, but at the same time, push the fewest amount of users away before they ever get to the site content.
Activity
begedin commentedon Mar 22, 2017
There are inconsistencies here in relation to other issues that are part of this project.
According to several other tasks, there would be two new states:
signed_up_donating- initial state when signed up from the donated pagedonated- state that goes right aftersigned_up_donatingThe
signed_up_donatingstate can't really deal with any sort of redirection. A user will sign up in order to donate to a project, but we do not store information on which project that is. Even if we did, we would effectively lock the user into donating to a single project until they cancel out or complete that process.The easier approach would be to use session redirection upon signup/sign in provided by ember-simple-auth, which is what #1183 does.
The
donatedstate could be functionally equivalent tosigned_up, or we could handle it through the onboarding header described in #1095.If we make it functionally equivalent, the it's a matter of rewriting the
_stepsarray and the_currentStepcomputed.For the onboarding header approach, we should move the discussion into #1095
joshsmith commentedon Mar 24, 2017
I've started some of this, and also addressing #1094 in the process.
Effectively, we need a sense of our
allowedRouteswhere we do not try to transition, vs the routes in the onboarding process where you are supposed to transition in a specific order.One idle thought, while I'm thinking about it, is that we shouldn't really have any problem with people skipping steps in the onboarding process. We should still attempt to guide them through it, but allowing a "skip" link below the buttons (in the
startroutes) would be fine, as would going back a step. We'd ideally track the skipped steps, too.This might make our API transitioning more flexible.
On the client, every allowed route can be transitioned to, but no disallowed route can be transitioned to.
The difficulty mostly then lies in handling transitions from one of the donation routes to the
indexroute (by clicking the header). This is an edge case that's not really handled.begedin commentedon Mar 24, 2017
I'm inclined agree with that idle thought.
I feel that forcing users into steps makes things easier for us later, maybe, but it also pushes users away, so we should allow freedom where we can. We're not making great use out of onboarding at the moment anyway, since task/project matching is still in the works. Letting them skip it means more of them get to the project/task/donate pages, where we really need them right now.
I a header or some other UI element that guides is something that would allow most users to go through onboarding eventually, but at the same time, push the fewest amount of users away before they ever get to the site content.