Send Invites Creation/Send Behavior Confusing

[dcavins]

Currently, a user chooses a friend to invite to a group, and upon clicking the check box, the user is added to the invitation list via AJAX and an entry is created in the groups table, but the invitation is not actually 'sent' or finalized until the user click the "Send Invites" button at the bottom of the list.

However, there's no way for the user to tell which users are halfway invited but haven't been sent an invitation.

One way to avoid this problem is to add a note next to the users who have not yet been sent invitations, so that the status is discernible. Another might be to add a "Confirm invitation" button next to "Remove invitation" if the invitee has not been sent an invitation. Or, a confirmation dialog could prompt the user to send new, unsent invitations if he attempts to navigate away from the page without finishing the invitation process. (Or the confirmation/send invitation step could be removed. I'm not sure what the history is on this function, though.)

Thanks for your thoughts on simplifying this interaction.

[boonebgorges]

Funny that you post this now. I was just working on the very issue for a client last night, and I was planning to implement a new system in my Invite Anyone plugin.

The way I was planning to do it was to create two lists on the Send Invites page: Pending and Sent. Sent would be invites that had been sent. Pending would be users I'd added to the list, but whose invites had not yet been sent (pending my clicking the Send Invites button).

What do you think of this as a possible solution? It seems like it might be a bit more straightforwad in terms of interface than putting all invitations in a single list with a special marking for unsent invites (they might get lost in the shuffle).

[dcavins]

I like the idea of two separate lists quite a bit. Then the "Send Invites" button would have some context. (At the moment, its function isn't obvious unless you're watching the database table while using the page.)

However, that would complicate pagination, which is kind of important on my site (some of the larger groups have dozens of outstanding invitations.) Another option would be to add an ORDER BY invite_sent clause to pull the unsent invitations to the top of the list, set them off with a header, and add a "sent invitations" divider below. (Although then the "Send Invites" button loses its context again.) Are you imagining that both lists would be visible and page-through-able at once, or were you thinking of using tabs or similar and only showing one list at a time?

Are we sure that the two-step creation/send process for invitations is necessary? It would be simplest if it were one step. :)

[boonebgorges]

I'm working on an update for #5423 that will take care of the pagination issues.

As for one-step vs two-step. If we went to one-step, we'd have to do one of two things:

1. Stop creating invites in the database on the AJAX call (after clicking a checkbox). Only create those invites when the form is submitted.
2. Remove the Send Invites button. Create *and* send invitations immediately when clicking a checkbox.

The problem with (b) is that it'll result in lots of people misclicking and sending invitations (and email notifications) mistakenly. I think it's good to require a form submit. So that leaves (a). But then we miss the ability to have a "draft" list - people you plan to invite, but haven't yet. Maybe that's not a big deal - what do you think?

[dcavins]

The "draft" or "proposed" invitations list actually kind of makes sense, and makes even more sense if the invitations list is visible to more than just the person who made the invitation. (Although then it kind of also makes sense to be able to confirm the invitations one at a time--you wouldn't want to have to remove many of the draft invitations before clicking "send" to invite a subset of the draft group.)

If we went for single-step option 1, I think that the new users added to the list would have to be marked "not yet sent" or similar, and we'd need to have a confirmation dialog on leaving the page that the new invitations have not been sent. But the experience for the casual user would be much simpler.

I agree that option 2 would result in mistakes.

I'm leaning towards simpler in this case; I'm not sure invitations should be complicated. I think that option 1 strikes a balance between preventing mistakes and guiding the user through the process.

Are there other users who could offer feedback on the current process?

[boonebgorges]

makes even more sense if the invitations list is visible to more than just the person who made the invitation.

Hm, this complicates things a bit. It seems wrong that one user would be able to create a "draft" invitation and then another user would be able to confirm it.

This suggests to me that we go with something like (a), where the items are not created in the database at all, and there is no such thing as a "saved draft". If we thought that this was a feature that users enjoyed, we could probably build something similar using a cookie.

As dcavins notes, it'd be great to get feedback from others.

[dcavins]

I think there are other tickets that are addressing some of the problems of the invitation system, so I'm closing this one.