locked Re: Invite flow


Hi Shal,

On Sat, Oct 11, 2014 at 5:38 PM, Shal Farley <shal@...> wrote:
1) The Email address box could parse these as equivalent:

Display Name <email@...>

Currently it rejects the first with
"Display Name <email@...>: Invalid email address "

Better, it could take "Display Name" as the tentative name of the member, confirmed or overridden when the member responds to the invitation..

Excellent idea. It's on the TODO list.

2) The Invite Message box looks like a plain text entry box. When I put simple HTML code in it I saw the literal code, as if editing in a plain-text entry form.

However, that code controlled the formatting inside the invitation email. Apparently the handling of that text is HTML-aware in at least some sense, as the text/plain message body of the invite had the HTML tags stripped, whereas the text/HTML part retained my coding. I had expected the opposite: the text/plain would show exactly what I typed and the text/HTML would have the tags escaped so as to show as plain text.

I don't suggest that the processing be changed to match my expectation, rather add a hint somewhere to the invite form that lets the user know that (at least limited) HTML is ok in the Invite Message. Or perhaps better still, make that an HTML edit control like the Post composition window.

Hmm. I'm a little surprised that the HTML wasn't escaped in the message itself. Anyways, the text box should be HTML and you should be able to enter HTML in the invite message. I've put it on the TODO list.

3) This is an edge case, but in testing I invited an address, accepted via email, then removed that new member. A second attempt to invite the address gave me the error "Already invited". Sure enough, the address still showed on the "Outstanding Invitations" tab, but if I hadn't thought to look there I wouldn't have known what to do.

I'm not sure whether there's an action item here or not. It is tempting to suggest that the member should be removed from the Outstanding Invitations list if they leave or are removed from the group. But since "Send Again" is an action in that list I don't know if that is necessary.

Right, I'm not sure the best way to handle this. Right now, invites stick around forever, regardless of what the invitee does. Rescinding the invitation just deletes the invite record from the database, it doesn't affect the invitee's subscription, if there is one. So the moderator can 'maintain' the invite list this way. But perhaps some automation would help.

4) The "Send Again" item does not appear to work. It unchecked the box but gave no other indication of sending another invitation. Nor was another received. Probably related to the above edge case. The "Rescind Invitation" action removed that address from the list and allowed me to send a new invitation.

Ugh. I looked the code, and found the following:

case "again":
// send it again. TODO

So it does nothing right now. Oops. Sigh.

5) The "Password" lacks a second box to confirm the password. Oops?

Clicking on "Accept Invitation" in the invitation email brings me to a Join Group page that asks only that I set a Password and select the Email Delivery. Does the Password need a confirmation box?

Maybe. I guess the password reset mechanism is an adequate backstop for the (hopefully rare) case of a mistyped password. After all, who doesn't use a password manager these days? It just runs counter to experience, so it seems odd.

Yeah, I'm not sure. I don't ask to verify email addresses either. A friend of mine who is in user interface thinks I'm crazy for not asking for verification. But I hate having to type everything in twice. What do you think?

I will fix the invite issues this week.


Join main@beta.groups.io to automatically receive all group messages.