Topics

locked Invite flow

 

1) The Email address box could parse these as equivalent:

Display Name <email@...>
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.


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.


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.


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.


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.

-- Shal

 

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@...>
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.


Thanks,
Mark 

 

Mark,

2) The Invite Message box looks like a plain text entry box.
...
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.
As long as there's some constraint in what the devious or criminally minded can do with the HTML. The iframe and script tags once bedeviled Yahoo Groups home pages (and Messages archives) until Y!Groups implemented a whitelist of "safe" tags. But that was in simpler times, I don't know what they do now.

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?
Having done it a few times on your site now I'm kind of with you on that. And I've always chuckled to myself as I paste a freshly generated password into both boxes on conventional sign-up forms - that doesn't really confirm anything so the purpose was lost.

On the other hand, my initial reaction tells me that your friend has a point. A Confirmation entry box is a familiar clue to the user that this is a place to register a new password. Right now the invite landing page says:

"Enter A Password For Your Groups.io Account".

The use of "A" instead of "The" is a pretty subtle clue. Perhaps it could say:

"Choose a new password to create your Groups.io account"

That's even more explicit than a Confirmation box. I'm being a little subtle too: I refer to "new password" here (and in join) to reinforce the idea that the user shouldn't re-use a password they're using elsewhere.

The other reason to have a Confirmation box is that the small bother now may avoid a larger inconvenience (or other cost) associated with correcting it later if you get it wrong. But I think your password reset mechanism (having now been through it too) is facile enough to eliminate this concern.

-- Shal

 

I've gone ahead and changed the wording for the password. I've also fixed the issue with HTML in the invite message (I decided to keep it plain text, and I'm just escaping tags now). You can now specify a name when inviting someone. And I fixed the problem with sending invitations again.

Thanks,
Mark


On Sun, Oct 12, 2014 at 1:15 PM, Shal Farley <shal@...> wrote:
Mark,

>> 2) The Invite Message box looks like a plain text entry box.
>> ...
>
> 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.

As long as there's some constraint in what the devious or criminally minded can do with the HTML. The iframe and script tags once bedeviled Yahoo Groups home pages (and Messages archives) until Y!Groups implemented a whitelist of "safe" tags. But that was in simpler times, I don't know what they do now.

> 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?

Having done it a few times on your site now I'm kind of with you on that. And I've always chuckled to myself as I paste a freshly generated password into both boxes on conventional sign-up forms - that doesn't really confirm anything so the purpose was lost.

On the other hand, my initial reaction tells me that your friend has a point. A Confirmation entry box is a familiar clue to the user that this is a place to register a new password. Right now the invite landing page says:

"Enter A Password For Your Groups.io Account".

The use of "A" instead of "The" is a pretty subtle clue.. Perhaps it could say:

"Choose a new password to create your Groups.io account"

That's even more explicit than a Confirmation box. I'm being a little subtle too: I refer to "new password" here (and in join) to reinforce the idea that the user shouldn't re-use a password they're using elsewhere.

The other reason to have a Confirmation box is that the small bother now may avoid a larger inconvenience (or other cost) associated with correcting it later if you get it wrong. But I think your password reset mechanism (having now been through it too) is facile enough to eliminate this concern.

-- Shal



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links:

You receive all messages sent to this group.

Mute This Thread: https://groups.io/mt/2597?uid=3
Change Your Subscription: https://groups.io/org/groupsio/beta/editsub?uid=3
Unsubscribe: https://groups.io/org/groupsio/beta/leave
Group Home: https://groups.io/org/groupsio/beta
Terms of Service: https://groups.io/static/tos
-=-=-=-=-=-=-=-=-=-=-=-


Frances
 

When I just checked the status of an invitation, in Outstanding Invitations, I saw one with the status of accepted and one with the status of Sent. That's okay. But the reason for both is Success.

What function does the Reason column have? What else could be there other than Success? There already is a Status column.

 

On Sun, Nov 9, 2014 at 4:06 PM, Frances <travel@...> wrote:

When I just checked the status of an invitation, in Outstanding Invitations, I saw one with the status of accepted and one with the status of Sent. That's okay. But the reason for both is Success.

What function does the Reason column have? What else could be there other than Success? There already is a Status column.


Status can be Sending/Sent/Deferred/Accepted/Failed. Really, Reason only applies to Deferred and Failed, which means that we either had a temporary problem emailing the invite, or had a permanent problem emailing the invite. The problem will be displayed in the Reason column, and is the response we've gotten from the invitee's email server. Most often, you'll get a Failed because the email address you tried to invite does not exist. Different email services have different responses for when that happens, but they'll be displayed under Reason.

It can get a bit technical, but I know that it can be frustrating when invites don't go out and you don't know why, and I wanted to provide all the information that we have.

Perhaps I need to reformat that page. For most of the time, Reason will be Success, which I admit doesn't make a lot of sense.


Thanks,
Mark