Group-income-simple: Design page for managing all invite links

Created on 13 Aug 2019  Β·  23Comments  Β·  Source: okTurtles/group-income-simple

Problem

Currently there is no place you can go to in order to see which invite links have been created, and info about them (like how many invites per link are remaining, and anything else we might decide is useful to include, like maybe the ability to invalidate an invite link, etc.).

Solution

Brainstorm & design a page where all of this is done.

Related: #609

Frontend UUX High

Most helpful comment

@mmbotelho Because it's theoretically possible for the following situation to occur:

  1. Group approves Alice's motion to invite Bob
  2. Bob declines/ignores invite
  3. 10 months later, Alice decides to use this "Generate new link" button to invite her friend Jain to the group without permission, compromising the group's privacy and violating the group's trust

All 23 comments

This was already solved on the new Dashboard. Invites are tied to proposals, and we already list the invites/proposals there.

You can see an example here (third widget variation).

@mmbotelho Yes I see that, but that's not exactly what I had in mind, because that focuses on showing proposals, not links, and feels a bit cluttered to me.

I'm thinking about a page that is link-first, where you see a list of links and can manipulate them. Maybe the links will have links referencing the original proposal too, but each link needs to be in its own block focused exclusively on it and its properties, something that hasn't currently been designed.

I'm thinking maybe the best place to put this "page" is under its own section under Group Settings...

Do you think we really need to separate those two concepts? Isn't it more intuitive for the end user to think of invites as part of proposals - since they resulted from them? I understand your reasoning, but isn't this something that is more useful for a dev then an actual user?

Where can the group creator manage the initial invite link?

@mmbotelho

Do you think we really need to separate those two concepts?

Yes, I think so. It is useful to see just a list of invite links, together, separate from a list of proposals (which can include invite links, or information about all kinds of things totally unrelated to invite links).

but isn't this something that is more useful for a dev then an actual user?

No, because, for example, we may want to make it so that an admin, and/or the person who made the original proposal, is able to invalidate invite links, etc. Invite links should be treated as separate, but related, to proposals for another reason: in the future we might want to make it possible for a special user to generate invite links on demand, without proposals.

Where can the group creator manage the initial invite link?

This is what I'm talking about, there should be a special page/section for doing stuff like this.

@mmbotelho I think an even better place than the Group Settings to put this container is in the Invite component/container itself, so that when you click to invite a user you can see a list of all the existing open invites.

For each invite, it should show:

  • The invite link
  • How many available invites it represents
  • How many responses have been received (accepted and declined)
  • When the invite expires
  • If (and only if) there is an associated proposal, a link to the original proposal
  • If (and only if) this invite can be invalidated, a link to invalidate it
  • The invite link

Agreed βœ…

  • How many available seats it represents

I think showing how many seats are left and how many seats existed originally might be more useful.

  • How many responses have been received (accepted and declined)

There's no way to decline an invite, there are only "ignored" or "unfilled seats". I think showing available seats vs taken seats already addresses this need.

  • When the invite expires

Do we want to add the ability to extend the validity of an invite? Going through a voting process is a time-consuming action, that requires everyone's attention in the group. If for some reason the invitee cannot use the link in time, the person who started the voting process should be able to extend it.

  • If (and only if) there is an associated proposal, a link to the original proposal

Agreed βœ…

  • If (and only if) this invite can be invalidated, a link to invalidate it

Can you elaborate on this? Who would be able to do this? In what circumstances?


This list is missing who can see the invite links. From our previous discussions, I am assuming that:

  • If the group is still in the onboarding period - everyone can see the 60 seat link;
  • If there was a voting process - only the person that started the proposal can see the link. Others can see a "locked" link, and who's the group member that can use it;

@taoeffect

I think showing how many seats are left and how many seats existed originally might be more useful.

Yes, sorry, that is what I meant. :)

There's no way to decline an invite, there are only "ignored" or "unfilled seats". I think showing available seats vs taken seats already addresses this need.

There could be a way to decline an invite (by clicking a "Decline" button), however it is true that invites can also be left out to expire instead.

The reason a "Decline" button might be useful is to invalidate the invite earlier, for the sake of the group's privacy, since the link can be used to allow anyone who has it to join the group. Therefore I do think it would be a good idea to make it possible to decline invites.

Do we want to add the ability to extend the validity of an invite? Going through a voting process is a time-consuming action, that requires everyone's attention in the group. If for some reason the invitee cannot use the link in time, the person who started the voting process should be able to extend it.

To be clear, the link expiry period starts from the moment it is generated, not from the moment the proposal is generated. The link is generated only once the proposal is closed (and approved).

However, perhaps you are right and it might still be useful to allow the link expiry to be extended. How about a "revive" link? This will breath new life into links that have expired and still have available seats associated with them.

Can you elaborate on this? Who would be able to do this? In what circumstances?

Similar to the "revive" link, the proposal initiator might reasonable change their mind about inviting someone.

If there was a voting process - only the person that started the proposal can see the link. Others can see a "locked" link, and who's the group member that can use it;

Hmm. That's a good point. It doesn't make sense to make these links visible to everyone except during the onboarding period. Agreed. πŸ‘

Can you elaborate on this? Who would be able to do this? In what circumstances?

Similar to the "revive" link, the proposal initiator might reasonable change their mind about inviting someone.

Also, people publicly post private information all the time -- usually accidentally, but occasionally maliciously. Because these are meant to be close-knit groups, it's important that the "carte blanche" invite link be able to be invalidated in case it's accidentally posted to and left up on a public timeline instead of sent by dm.

If there was a voting process - only the person that started the proposal can see the link. Others can see a "locked" link, and who's the group member that can use it;

Hmm. That's a good point. It doesn't make sense to make these links visible to everyone except during the onboarding period. Agreed. πŸ‘

Would this mean that if the original proposer was somehow incapacitated that the only way to add the new member to the group would be to open a new proposal? (i.e. single point of failure)

Would this mean that if the original proposer was somehow incapacitated that the only way to add the new member to the group would be to open a new proposal?

Yep. But I think "that's a risk we'll have to take" πŸ˜„

Thank you for the replies @taoeffect @dotmacro , I agree with everything! The only thing I'm still not 100% sure is

The reason a "Decline" button might be useful is to invalidate the invite earlier, for the sake of the group's privacy, since the link can be used to allow anyone who has it to join the group. Therefore I do think it would be a good idea to make it possible to decline invites.

I understand how this can be useful, however, if we put ourselves in the shoes of someone who is invited to a group they don't have the intention of joining, the most probable action is no action at all πŸ˜‚I don't see why someone who is not interested in joining a group would go through the trouble of clicking the link only to decline it.

the most probable action is no action at all

True. If you think having a decline button available would detract enough from the design, then you don't need to include it. But if it doesn't make much of a difference, feel free to add it!

Ok, will do! πŸ˜„

Ok, so here's how you manage invite links in Group Income! (Figma)

I decided to add this to the Group Settings page because after trying a lot of other alternatives, this was the one that made more sense to me. Some things that you might notice, that were slightly different from what we discussed:

  • A user can only see the links that they own themselves. I figured that showing information that the user cannot act upon would not be that useful, and that we can simplify;
  • I added a column to show who the invite is meant for.

Here's a quick preview:
Captura de ecrã 2019-08-27, às 16 48 08

Screen Shot 2019-08-27 at 6 25 43 PM

I'm thinking that maybe it's best to just force a new proposal to be created instead of being able to revive links. (I'm going to copy this comment to the GH issue since we had that discussion there.)

Can you elaborate a bit more? Why do you think it would be best to create a new proposal @taoeffect ?

@mmbotelho Because it's theoretically possible for the following situation to occur:

  1. Group approves Alice's motion to invite Bob
  2. Bob declines/ignores invite
  3. 10 months later, Alice decides to use this "Generate new link" button to invite her friend Jain to the group without permission, compromising the group's privacy and violating the group's trust

Makes sense!

Also (just to note) if this view will only be showing active invite links (per discussion on Figma), all expired links will be hidden anyway.

Also (just to note) if this view will only be showing active invite links (per discussion on Figma), all expired links will be hidden anyway.

However... we do need to give thought to that. It can be useful to see a full history of invite links, perhaps for the group admin (if we create such a role). In which case it may really be better to move this out of the Group Settings and to its own page...

In which case it may really be better to move this out of the Group Settings and to its own page...

I would leave it there for now. When and if we add member roles, we can address this issue then. Does that make sense?

The solution has been fully discussed and designed. You can find the mockups for this here:
https://www.figma.com/file/mxGadAHfkWH6qApebQvcdN/Group-Income-2.0?node-id=3824%3A0

See issue #664 for the development of this feature.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hubudibu picture hubudibu  Β·  8Comments

sandrina-p picture sandrina-p  Β·  8Comments

taoeffect picture taoeffect  Β·  8Comments

taoeffect picture taoeffect  Β·  4Comments

sandrina-p picture sandrina-p  Β·  8Comments