[User Stories] [IMPORTANT] New Hangout / Connect flow

[lpatmo]

This is a proposed user flow for a new user joining V3.

Comments under each step welcome!

[lpatmo]

Story 1: User signs up on the homepage, and shares what they're looking for (which can be a potential pairing hangout)
Design discussion: #137

[lpatmo]

If the user is filling out the "I am looking for" flow, the implementation detail is that the data will be saved in localStorage until they reach the last step where they submit the form to signup.

If a user never confirms their email, can we have the post never show up in the resulting list? But at that point the data would be saved in Postgres until they confirm their email.

(Let me know if that doesn't make sense)

[BethanyG]

It doesn't. One is a registration flow. The other is a Hangout flow.
The concern for the Hangout flow is that it needs to be saved in the DB with a status -- as does the registration. But the hangout is dependent on membership..and membership isn't confirmed until the email is confirmed. So if both are created in the same action... you shouldn't list the Hangout at all until the related user actually is a member...otherwise, it is going to get really messy if other members message someone who is "pending".

[BethanyG]

Thinking about it a little more -- yes -- we can save these "hangout requests" to Postgres with some sort of "hold" or pending status.

We just want to be really clear that we are doing that, and what that implies -- along all the steps of the process. And then anything with "status 3" (just using that as a .. placeholder for this) would be something filtered out when the FE asks for a list of "pairings" or "requests".

We'll also want to make sure to create the "user" first - then the paring. 😄 or we won't be able to associate them correctly! We may also want to think through how a pairing is displayed to the "pending user" in their profile. Probably the way we do everything else -- but with a big, honking warning over the top that tells them to go confirm their email.

[lpatmo]

So if both are created in the same action... you shouldn't list the Hangout at all until the related user actually is a member...otherwise, it is going to get really messy if other members message someone who is "pending".

Yeah, that's what I was thinking too -- the "looking for" post won't be listed until the user has confirmed the email.

Thinking about it a little more -- yes -- we can save these as some sort of "hold" or pending. We jus want to be really clear that we are doing that. And then anything with "status 3" (just using that as a .. placeholder for this) would be something filtered out when the FE asks for a list of "pairings" or "requests".

Yep!

So... from a FE perspective on the user signup flow, we save info in localStorage until user reaches the last step. When they click "submit", we make two calls:

1. to /auth/users to create the user with user profile info
2. to /hangouts (or whatever we name the endpoint) to create the hangout at stage 3 (placeholder), aka a status of unconfirmed or something, so that this "looking for" post won't show up in the "looking for" list on codebuddies.org/connect.

[BethanyG]

So side note (so we don't lose it, and remember to be formal about it later): We will need to have explicit checks run when a user "confirms" their email. We'll want to query for any "pending" Hangouts or pairings that they've made, and then if there are any, we'll want to do an update on the status, so they show in the UI, at the next query.

[lpatmo]

Story 2: User fills in required fields like email, timezone, general availability, username and completes the signup process
Design discussion: TODO

[BethanyG]

So - does this Hangout process look different for confirmed vs unconfirmed users, or is this flow the same?

• if the user is signing up, will they have messaging that this is for their general preferences for their profile?
• if the user is already signed up, will this info pre-fill from user preferences?

[lpatmo]

The hangout flow will look different for confirmed vs. unconfirmed users!

If the user is signing up, yess... we should make sure to tell them this will populate their profile. (Also, they'd be able to change their profile details later)

If the user is already signed up, they'd see a different form when they click to add a new post to the "looking for" list. I forgot to create a user story for that; will create it below!

[lpatmo]

Story 3: On codebuddies.org/connect, the user sees a list of "looking for" posts as well as a list of live and upcoming public hangouts.
Design discussion: TODO

[lpatmo]

I was thinking of following what we have on codebuddies.org right now.... that is, the only thing non-signed-in users won't be able to do is to create a new post / interact / request to join public hangouts.

[BethanyG]

ah! Ok - so display pretty stuff to entice - and if they want to take action, they then signin/signup. Ok.

[BethanyG]

Just a note here: I know for MVP we won't be doing social auth -- but we might want to note where hooks into that would be, for when we do add it. For instance, we'd show a social option here when a non signed in user tries to take an action.

[lpatmo]

fwiw, for social auth... the only one I can imagine integrating into in the future would be GitHub, heh.

[BethanyG]

FWIW, we already have the modules in place for doing social auth...so it is "fairly" simple to set that up. Added advantage is a pre-confirmed email. Magic links with social auth is more complex, but (I think) do-able. But let's not prioritize it for the MVP.

[lpatmo]

Story 4: User can click on a button schedule a hangout for right now (or sometime in the future). The button will live near the list of live and upcoming public hangouts on codebuddies.org/connect. Clicking on it will open up a form where the scheduling happens, and the user can specify what type of hangout they'd like it to be -- such as watch me code, presentation, cowork with me, study group, and pairing.

If the hangout is checked open to other codebuddies, it will appear on the "calendar" list. Otherwise, only admins will be able to see that it was scheduled.

Design discussion: TODO

[BethanyG]

will this form pull info from their preferences? If so, can it be overridden?
how does the calendar list differ from the looking for? Are calendar posts one that have a minimum of 2 users?

[BethanyG]

What happens if someone doesn't want to pair with someone who's "accepted"/"scheduled" a Hangout in "reply" to their "looking for" post? Will there be an accept/reject interaction?

[lpatmo]

will this form pull info from their preferences? If so, can it be overridden?

Can you elaborate on the preferences you were thinking would be pulled into the "schedule a hangout" form? 🤔

how does the calendar list differ from the looking for? Are calendar posts one that have a minimum of 2 users?
The "calendar list" would include any "open to other codebuddies" events as well as singular "watch me code" events that people might want to schedule spontaneously, since a calendar list hangout could be one of several types:

• pairing (minimum of 2)
• presentation (minimum of 2)
• cowork with me (minimum of 2)
• study group (minimum of 2)
• watch me code

^ list I just came up with, btw; open to edits

Gah, your question about "minimum of 2" makes me wonder if we should make that a requirement. Or even let the poster click a checkmark to put it into the "looking for___" section. 🤔

The difference between the "calendar" and the "looking for" list is that the "calendar" is basically a list of all of the public hangouts, and the "looking for" list isn't a list of hangouts... it's more of an "ideas" list listing out what people are looking for, to help them get organized.

What happens if someone doesn't want to pair with someone who's "accepted"/"scheduled" a Hangout in "reply" to their "looking for" post? Will there be an accept/reject interaction?

Was thinking that the creator of the "looking for" post would also be the one taking the initiative to create the hangout. So once they create it (and if they make it open to the public), they'd be able to accept/reject joiners.

[BethanyG]

Can you elaborate on the preferences you were thinking would be pulled into the "schedule a hangout" form? 🤔

I was thinking these:

Story 2: User fills in required fields like email, timezone, username and completes the signup process.

Somehow, my brain was adding in "preferred times". But of course, it's not there! Just thinking here that anything that we can pull from a user's profile to make this easier would be good. So if we are going to have them fill out an availability or preferred time, we should then use that here. We should also display times based on their stated preference ... not their inferred browser timezone.

The difference between the "calendar" and the "looking for" list is that the "calendar" is basically a list of all of the public hangouts, and the "looking for" list isn't a list of hangouts... it's more of an "ideas" list listing out what people are looking for, to help them get organized.

Right....so... how does a subject or topic move from one list to the other? Do they?? What is the triggering event? If it is the OP -- what is to stop them from just ....wandering away, after a bunch of people express interest? Will we remind them? Will those statuses be listed in their profile? Will things "age off" the list?? And if this is just and ideas list.....that feels like it doubles up the work, since the OP will have to go create a hangout anyways....or will there be a conversion feature? And if there IS a "convert this to Hangout" -- will it then come off the "I am looking for ____" list? Apologies -- I just have a LOT of questions! lol

[lpatmo]

So if we are going to have them fill out an availability or preferred time, we should then use that here. We should also display times based on their stated preference ... not their inferred browser timezone.

Agree! I'll update to hint at: User fills in required fields like email, timezone, general availability, username and completes the signup process.

Right....so... how does a subject or topic move from one list to the other? Do they?? What is the triggering event? If it is the OP -- what is to stop them from just ....wandering away, after a bunch of people express interest? Will we remind them? Will those statuses be listed in their profile? Will things "age off" the list?? And if this is just and ideas list.....that feels like it doubles up the work, since the OP will have to go create a hangout anyways....or will there be a conversion feature? And if there IS a "convert this to Hangout" -- will it then come off the "I am looking for ____" list? Apologies -- I just have a LOT of questions! lol

LOL, these are all excellent questions! looks for UX goddesses cough @adachiu for help

_> Er... so will take a stab at some thoughts.

I initially wasn't think that the "looking for" post would convert automatically to a "calendar" list post -- more that the user would click on a "schedule" button to create the event, but... thinking more about this, a "convert to a hangout" button that's always at the bottom as a textual signifier makes sense.

And if there IS a "convert this to Hangout" -- will it then come off the "I am looking for ____" list?

Hmm... if we're implementing the "looking for" list as part of a hangouts flow, it would be easier to implement if the post came off of the "I am looking for___" list, right and moved to the right, right? That way the "looking for" list would be a GET call to something like api.codebuddies.org/v1/connect?status=pending and the "calendar" list would be a GET call to something like api.codebuddies.org/v1/connect?status=scheduled (just off-the-cuff ideas for naming rn)

what is to stop them from just ....wandering away, after a bunch of people express interest? Will we remind them?

Sigh, good point. Maybe we need a "automatically close if no activity after 2 weeks" cron job XD. As well as a "remind after 1 week" transactional email.

Will those statuses be listed in their profile?

Proposal: all of a user's "looking for" and "scheduled hangout" posts will be listed in their profile.

[lpatmo]

Story 5: A user can request to join any public hangout. The OP will have to approve them before the user shows up in the RSVP list and can join the Zoom (or external hangout URL).

Design discussion: TODO

[lpatmo]

Note: on codebuddies.org/hangouts currently, any user can "Click to RSVP" to any public hangout. Open discussion if we want to change this to "request to join" so that hosts will have to approve each user before they can join.

[BethanyG]

So accept/reject can happen here..but this is after the "pairing" -- correct? Or is this the same flow that would happen for the I am open to pair ones where someone is proposing a hangout?

[lpatmo]

Yep, this story assumes that someone has created a public hangout (whether or not it was organized after a "looking for" post).

I was imagining the "looking for" list to be similar to what we have in the #pair-programming Slack channel... open requests asking for X, but ultimately the OP can decide whether or not to follow up with the people who responded in replies. That is, they can decide to close a "looking for" post, and then create a private hangout and only invite certain users. (Or create a public hangout and accept requests from certain issues)

Maybe there's a UX interaction or some alternate UX behavior here that I'm missing 🤔

[lpatmo]

Story 6: For each post in the "looking for" list, users will be able to leave comments expressing interest. Each of these posts can also be closed once a hangout is created (either private or public), or if a comment answers a question. "Closed" posts won't go away, but will be sorted at the bottom.

Design discussion: TODO

[BethanyG]

What are the actions the OP can take here to communicate with the interested parties? What does that back and forth look like? How will we convey to users that one or more have been "scheduled" -- and others have not?

[lpatmo]

Ha, was just mentioning in my last reply that I might need some UX help here 🤔

My original thought is that the back and forth would simply be threaded replies.

How will we convey to users that one or more have been "scheduled" -- and others have not?
A couple of ideas:

• the OP (and admins) will be able to close a "looking for" post.
• the OP (and admins) will be able to append an optional hangout link if a private (or public) hangout resulted as part of the discussion.
• Followers of the thread will see that the hangout has a public hangout link
• If there is a private hangout, followers of the thread will simply see that the thread was closed

[BethanyG]

I like this. I think (depending on how the other "list removal" discussion goes) that then there is maybea time period (for a scheduled hangout) where the post stays visible, then goes to closed? Or maybe we message the followers?? 🤔

[BethanyG]

Leaving a note here: took a "first pass" at the BE models and JSON. See codebuddies/backend#161 & codebuddies/backend#164