Review the volunteer dashboard to suggest materials and next steps

[conoramurphy-zz]

Business Goal

For any new volunteer (first 3 months), make sure we have clear next steps on the dashboard. We hope to see increased engagement and increased retention.
https://docs.google.com/document/d/1xVZSRaiZ_gsvaVWwFsQkFLTNYiRvu1drD31XULofHeo/edit#

Task

Tweak messaging and the "This is the most important things" section on the dashboard for new volunteer experiences.

[conoramurphy-zz]

First Suggestions here

https://share.goabstract.com/b0212c5e-d6a6-4c86-bf85-085155265802

[Wardormeur]

So, a couple of points:

1. Even if we hide it after 3 months, we can't currently tick anything, there are no storage dedicated to that (and unsure we'd like to)
2. The scenarios for showing it needs to be defined. I think not only 3 months (which is long for the life of a Dojo) but as well as "not being part of a Dojo with an event", elsewhat the whole screen's going to turn purple. As well, to me, this "main action" (whatever we decide it is) should only be part of the main block while you're not a volunteer, but applied to be. If you're a volunteer already, see 3)
3. The top part was reserved for single-click/very clear call to actions. Having a todo-list here is against the whole design of a "simple, clear path to follow". It could be part of a less intrusive experience within the side-bar (think of Reddit/board-like dashboard with pinned topics), or as a randomly selected tip "Did you know".
   However, that leads back to "What's the main call to action for newcoming volunteers". A tour of the dashboard, showing tips about "new content", followed by "the important links" could be something.
4. Pending requests can use a similar design than events, and not being part of that list of links (separated as a different ticket here : Show notification of pending requests to join for a mentor #1251). That could be used both for awaiting requests (that the user requested) as for awaiting approval (from a champion perspective), and help us putting some alternate actions in case of lack of response (contact support for example)
5. Regarding the content of those links overall:

• You shouldn't have a Find a Dojo link as part of that list: if we do, it means we don't even know the user is willing to volunteer, so that display should not exists at all.
• Safeguarding is fine
• Guide to mentoring is not something I would set here. That's a lengthy document. If you want people to not come back, that's probably a good way
• Yes-ish for projects, but it's displayed lower in the page, in a way better manner
• Keep going/become a co-champion: he's barely a volunteer, irrelevant and even dangerous (co-champion).
  Overall on that list, only 2 are, to me, meaningful at that stage for the user. The list itself doesn't seem justifiable and we could either better content, or more impactful design.
  As a counter example for parents:
  Find a Dojo is a single action, it's not:
• Find a Dojo,
• Register your kids,
• review our ethos,
• become a volunteer yourself
• Start your own dojo

[conoramurphy-zz]

So I'm proposing a simpler version.

There are theoretically 4 stages to a volunteer path on CoderDojo

1. Just signed up and haven't even applied to a Dojo.
2. Applied to a Dojo and no reply (biggest opportunity here from the data)
3. Been accepted recently and/or go to an actual event, first 6 months
4. Have been going to events a lot and maybe been 6 months in a Dojo (secondary opportunity here to try to push them to be a champion)

My proposal is... treat them separately. Create issues about doing a small messaging change to support 1. A larger piece like a small pathway to support 2. and for 4 suggest adding in a footnote about becoming a co-champion.

Pros
Smaller focused pieces of content for each of them that target the specific problem we've noted. Less design work.

Cons
Less of a redesign and no major improvement except for (2). Not a major con to be honest!

[conoramurphy-zz]

###Proposal in detail
https://share.goabstract.com/b0212c5e-d6a6-4c86-bf85-085155265802

Three stages are now included in this ticket.

First state : New volunteer no club or applications to join. Tweaked message in above screens.
Second state : Volunteer with open applications, no club. Second screen above, new card with suggested next steps and some mild time fillers.
Third state : Volunteer with both open applications, and a club, and it's the first 3 months. This is to cover a case where someone applied for several clubs. Third screen in abstract. Basically they should still be shown most of the second state date until 3 months pass and then we can assume they understand the process.

Notes:

• The 3 months only applies if they joined a club. If they don't successfully join a club they should always be shown the first or second state.
• If possible (need to run through journey) redirect volunteers to the dashboard after they join a club. The dashboard then acts as confirmation
• Some of the spacing in abstract and the real frontend are different. Just review with me live if we need to make a choice there.

[Wardormeur]

First state:

• not defined how we identify that case, we don't know he wants to volunteer without requesting it in the first place
  Second state:
• OK, not a big fan of the design, but can probably work around it and offer something a tad different
  Third:
• If you're already part of a club, I wouldn't show the list here. You already have experience with a Dojo, either as a Ninja (unlikely) or as a mentor. Everybody else will fall in case 2, which is the most likely scenario to happen. This will just be a nuisance to already experienced mentors. I would push it as a side-info at that point, even for any experienced mentors .
• Projects is still here despite being more visible under.

Notes: there is a strange difference between waiting a few days for a requests, and displaying for 3 months a guide. I understand they serve a different goal, but you'll have fresher data from our list of projects for example than any links in the current projects.rpf platform (maybe the new homepage ?). As well, the safeguarding module is a 10 minutes action that is going to be there.. for 3 months. You're unlikely to come back to it because of its simplicity (which is not the case of the guide, for example).
That's why overall, I'm pushing for a side-list of links for already-in mentors, it's because those resources are good as references, but aren't useful for 3 months or are already displayed in a better manner next to it (projects). If this becomes an accepted solution, I would recommend changing the titles to something more neutral, such as "Our projects website" or "Discover more projects".

[conoramurphy-zz]

For not defined how we identify that case, we don't know he wants to volunteer without requesting it in the first place Should have clarified that should generally just be the default message for all users that have 0 actions done and haven't created a lead or anything.

Fair enough on the 3 months. It's always an arbitrary choice. It can be 30 days on the list of actions part. The 3 months is more for the pending applications part so we can split the pending and the list. If for state 3 you want to push the list into the side no problem, I will survive (but genuinely no problem there, the first two states by far the most important for this ticket).

[Wardormeur]

So, the way forward can be seen in 2 ways:

1. migrate endpoints to v3 for join_requests, stick to the current db structure
2. migrate endpoints to v3 for join_requests, change the db structure to reflect its nature

The second point means migrating the join_requests from the user profile and the user db to the cd_usersdojos (club membership) table from the dojo db. However, this impact retro-compatibility in 2 ways:

• selecting from the cd_usersdojos table would need to exclude those join_requests, which is used by the Seneca services
• Current front-facing interfaces making use of the current table (such as the manage-users "accept/decline" interface) needs to be redone in the process, on top of the solution 1).
  I expect the length of solution 2) to be the same as solution 1), which for a part of the system that have been hardly touched in 3 years, overly expensive.
  Now, we can go the "efficient but with technically wrong" solution (1) or "technically pure but way more work" (2)
  Thoughts @ArayB @nyashamaphosa ?

[ArayB]

At some point we are going to have to pay off this tech debt and start making these changes to db schema/ re-organising of services.
Do you have any estimates for how long each solution would take? You say the length of solution is the same, but then that one is way more work so I'm a little confused.

If we go with the efficient solution and leave the db as it is what is the outcome, the services are harder to reason about because the same or very similar functionality is in different services?

If we don't move things now, under what circumstances to we ever take the decision to move something.

[Wardormeur]

Sorry, by "the same", I meant to say that the length of doing 2) is as long as twice 1), due to the dependencies of the front-end to that API. That would force us to deprecate that part of the v2 API since the back-end would be different; and hence requiring either a rework of the front by either using the new API despite being in the ng1 version; or a total rework of the page in vueJs.
If we go with the efficient solution (1), it means the data is not part of the db I would expect to be in (the dojo db) and hence the logic will belong to a service I would not expect to be in (in this scenario, the logic will need to be in the user-service instead of the expected club-service).
As well, in solution 1) the process would not be replicated, but will coexist with the v2 version as they rely on the same data structure and db. That means that some interfaces will make use of the v3 API (request to join as, booking process which makes people join as parent/attendee), and others will use the v2 (champion's display for managing requests likely).
If we don't move now due to the size of the task, I would ensure that every interfaces making use of that entity have been rewritten. At that point, only the first bullet point (selecting from the cd_usersdojos table..) will be the issue, which isn't that big (probably 1 day writing, 1 day testing) by itself.
The reason for solution 1) are to avoid trying to solve 2 very different and large issues at a time (Seneca deprecation AND schema being a bit all over the place) while solution 2) is about getting it right (once and for all until something else happens) whatever the cost.

[Wardormeur]

For 2nd state, should we filter the requests to join created after a certain date? I'd like to avoid a weird experience with requests to join which are 3 years old.
@conoramurphy