Text review & related UX: invitation expiry

[BeccaMelhuish]

@kevincrepin @ilmartyrk @anettlinno @oksks

A couple of thoughts re these strings below:
("Oops! This invitation has expired. We apologise for the inconvenience. You may try requesting access to this topic again."
"Oops! This invitation has expired. We apologise for the inconvenience. You may try requesting access to this group again.")

• I wonder if we do want to say we are sorry? As if we have a good reason for making them expire (not sure what it is though?) then no need to apologise? Feels a bit like we're saying we wish they didn't expire, so we're sorry that they do..
• Re the suggestion that that they request access to the topic again, I'm wondering if we have a way for them to do so on the redesign (for a private topic/group, when they are at this point in the flow - trying to access with an expired invite)? As unless they somehow have the contact details of the person who sent it already outside of the platform, I don't believe on our current platform there is actually a way for them to follow our suggestion? (And if not it's maybe more annoying than helpful at this point).

[kevincrepin]

I would say let's get rid of the "oops" because that's what makes it sound accidental/a mistake. But I would keep the "apologise for inconvenience", that's just being considerate :)

Good point. I don't know how you can request to access a topic that is not visible for you since it's private...? And if it's public there's no need to request... I am a bit confused :D

[BeccaMelhuish]

@kevincrepin Ok thank you! Will remove the Oops :)
@ilmartyrk @anettlinno do you have any insight/thoughts on the second point? :)

[BeccaMelhuish]

And if it's not currently possible to request another invite (unless you have their email address already somehow), should we build in the possibility to do so at some point? Could be quite a simple button on the email potentially, the clicking of which notifies the person who sent it to send it again?

[anettlinno]

In the first point I agree with both of you @kevincrepin and @BeccaMelhuish and I would even took both (oops! and apology) out and leave only:
This invitation has expired. You may try requesting access to this topic again.

Regarding the expiration of the invitation, I already questioned in its necessity a few months ago after a user asked why invitations expire and only good reason I could bring was that it´s for the safety reasons (if baddies get access to your email account, then they can log in to the topic/group).
o, I think it´s even a bigger question here -- why do the invitations expire after 14 days? @ilmartyrk @kevincrepin @BeccaMelhuish

[oksks]

Just came here to ask the same thing - what's the reason for expiration? Invite emails don't expire in other services I use (unless invite revoked or content deleted), so we probably shouldn't, either - it's a pretty frustrating experience for the user.

[BeccaMelhuish]

Had the same thought when I first discovered it (I never knew they expired, and also don't see the reason for it). But maybe @kevincrepin or @ilmartyrk know of a good reason for it?

[ilmartyrk]

I don't have any good reason why they expire. Original issue with the discussion is here citizenos/citizenos-fe-old#112

[anettlinno]

Thanks @ilmartyrk. This is what I caught from the issue citizenos/citizenos-fe-old/issues/112 thread:

Mikk: IF we're showing latest info in the invite UI, we need to create an access token for the Topic information. That token cannot live forever. How long do you think it makes sense for an invitation to be valid? I would think if you haven't reacted 14 days, it should expire. The inviter can always send a new invite. We MAY want to implement expired invitation flow where you can re-request access, but that would create significant amount of UX and BE work. BUT, overall the feature of requesting an access makes sense to me. You MAY want to request access to edit a public topic?
Margo´s answer: I think invites should expire regardless of whether we go with token access or static invites. Everything dies. Invites should too :) 14 days sounds as good a lifetime as any. We should clearly communicate this to the user, though, both when sending and on the invite itself.

@ilmartyrk this decision has technical reason? IF we're showing latest info in the invite UI, we need to create an access token for the Topic information. That token cannot live forever I understand it´s because the token must expire?

Otherwise I don´t see any strong arguments for invitations to expire in 14 days AND Users are also confused for this behavior. So, I would propose that invite emails would not expire after 14 days, but if the token needs to expire then it would expire after 90 days or something like that?

WDYT?

[ilmartyrk]

Lets change the expiration time to 30 days.

[BeccaMelhuish]

Agreed with @ssin1901 to move this to 'next' due to this causing some significant inconvenience for a General Assembly admin, plus it should be a quick fix (we assume).

User insight (for the record):
She was sending hundreds of invites to a GA, and would have needed them not to expire before 3 weeks time, for her particular use case, to not risk having to get hundreds of requests to re-send the invites, if people (as would often be the case) don't log in as soon as they get the email, but see they have plenty of time to before the vote deadline.

[BeccaMelhuish]

Dev task summary:

• Change the expiry date of topic and group invitations to 30 days.
• I assume URL share links don't expire. But in case they do currently, then the expiry date should be removed and they should remain active forever unless a new code is generated for that topic/group.