Hi All!
I am currently working on the system that is used to invite new users to join a
group, as I mentioned earlier
<http://groupserver.org/r/post/23upjUPUkD5uhsJ8o2kGOo>. While the new system
does not go, it is getting closer to working.
There are two big changes. The first it is explicit that the administrator is
*inviting* the new user to join a group, as shown in the screenshot
"groupserver-new-member-invite.png" below. The second big change is the admin
will be able to preview the message, as shown in "Invitation Preview.png"
below.
Both images are showing the default values for the Subject and Message fields.
The preview needs the (non-editable) Accept and Reject links to be shown. Oh,
and the Preview button itself needs some styling, as it is more than a bit meek
at the moment ☺
The
following files were added to this topic:
I have solved the problem with the Preview button to my satisfaction: it is now
in a nice box, with an email icon. Below is a screenshot of what it looks like
on my test install of GroupServer.
Any suggestions will be appreciated!
The
following file was added to this topic:
On Wed, Apr 14, 2010 at 7:36 PM, <email obscured>> wrote:
> I have solved the problem with the Preview button to my satisfaction: it is
now in a nice box, with an email icon. Below is a screenshot of what it looks
like on my test install of GroupServer.
>
> Any suggestions will be appreciated!
It looks like the invited user just gets a small email. What about
links in the message to confirm their acceptance? Where does that text
come from?
I am glad someone spotted the absence of the links, Jim! I am musing about the
links now.
Currently the invitation (to a new user) reads something like this:
To accept the invitation to join this group click the following link
http://groupserver.org/r/join_accept/FEFEFEFEFEFE
To reject the invitation click the following link
http://groupserver.org/r/join_reject/FEFEFEFEFEFE
I will probably have to stick that text at the bottom of the preview with a
little explanation that the links that I will show the admin are broken (just
like the above links are incorrect). I am pondering how to this in a nice way —
as it is problematic showing people borken things.
On a related matter, I *could* reduce the number of links to one. To do this
the single link would send the user to a page where he or she can accept or
reject the invitation. This is how the invitations for an *existing* user
works. My argument for having two links was twofold:
1. It allowed a person to clearly see that invite
can be rejected. However, rejecting an invitation
is very rare, and I suspect that invitations are
more likely to be ignored than rejected.
2. It allows a person to join a group in a single
click. I wanted the system to be usable by those
unfamiliar with All Things Web, so halving the
number of clicks seemed like a Good Thing™.
However, having two links has a cost. First, it breaks the HTTP standard, as
the GET request has a side-effect (which is a Bad Thing™). Second, I think that
for those familiar with All Things Web a page is easier to use, as it is more
clear what is happening, and feedback is more consistent.
So, one or two links? What are your thoughts?
On Thu, Apr 15, 2010 at 11:27 AM, <email obscured>> wrote:
> To accept the invitation to join this group click the following link
> http://groupserver.org/r/join_accept/FEFEFEFEFEFE
> To reject the invitation click the following link
> http://groupserver.org/r/join_reject/FEFEFEFEFEFE
To accept or reject this invitation click on the following link
http://groupserver.org/r/invitation/BADCAFEFOOD
When showing the preview to the admin, just hash out the ID
http://groupserver.org/r/invitation/#############
If they click on it, give them a page that looks like the real one,
but will take no action (so they can't accidentally accept on behalf
of their invitee)
> However, having two links has a cost. First, it breaks the HTTP standard, as
the GET request has a side-effect (which is a Bad Thing™). Second, I think that
for those familiar with All Things Web a page is easier to use, as it is more
clear what is happening, and feedback is more consistent.
One link, a page. Not that anyone else really respects "GET makes no
changes" ...
I think the one link approach is nicer too. Users make mistakes, and
accidentally saying no to something actually has quite a significant
cost, especially if it is a closed group (ie. you have to go back to the
admin and get them to re-invite you). It also makes the email a little
shorter, and makes it look a little less complex, which increases the
chance they'll actually read it.
Even shorter:
http://groupserver.org/r/rsvp/BADCAFEF00D
I recommend the word "decline" over reject. Computers reject things, people
decline invitiations.
Steven Clift
http://stevenclift.com
@democracy
On Apr 14, 2010 7:45 PM, "Richard Waid" <email obscured>> wrote:
I think the one link approach is nicer too. Users make mistakes, and
accidentally saying no to something actually has quite a significant
cost, especially if it is a closed group (ie. you have to go back to the
admin and get them to re-invite you). It also makes the email a little
shorter, and makes it look a little less complex, which increases the
chance they'll actually read it.
Even shorter:
http://groupserver.org/r/rsvp/BADCAFEF00D
I like 'decline', too.
Whether we use one link or two, I like Jim's suggestion about the preview:
When showing the preview to the admin, just hash out the ID
http://groupserver.org/r/invitation/#############
If they click on it, give them a page that looks like the
real one, but will take no action (so they can't accidentally
accept on behalf of their invitee)
This gives the admin even more information that help them to get in the
shoes of the invitee.
On one link or two… if an invitation is not accepted, does it, or should
it expire? If not, why do we need a decline option at all? What if we
only had accept? Then there would be little risk of accidentally declining.
The group admin will always have the option of removing the invitee from
the group, whether they have accepted or not. And the interface is soon
going to provide better feedback about the status of invited members.
Does it make life harder to have a 'perpetually invited' type of user?
If invitations do not expire, then we have that user type now.
It is a privacy issue that an admin can add someone's name to the list
of invited members, without their consent. (This will only show in
private or secret groups.) But that is not unique. I can change my
profile to display your name, now.
Does this does create a new user type to handle in the UI? No, because
the only way they can see the UI is by verifying their email address.
So, if we went with this, we'd have only one link anyway. That leaves
the question of whether it should be a GET request has a side-effect, or
not. The only reason to add a page, and a click, would be to provide
more than the email does, or if you could get to the page some other
way. I do not think either are the case.
I suggest we retain the side-effect, and move 'em straight on to setting
a password.
*Maybe* for private and secret groups, there should be a privacy notice
in the invitation email, letting them know how to remove all trace of
the invitation from the site.
On Thu, Apr 15, 2010 at 2:14 PM, Dan Randow <email obscured>> wrote:
> I suggest we retain the side-effect, and move 'em straight on to setting
> a password.
>
> *Maybe* for private and secret groups, there should be a privacy notice
> in the invitation email, letting them know how to remove all trace of
> the invitation from the site.
Actually, for all types of group you probably should have somewhere to
display terms & conditions, group profile, privacy policy, etc before
they accept.
So I don't think a "move straight on" option helps.
I agree with Jim, that the terms and conditions should be shown to the new
member before he or she signs up. The T&C are shown on the Sign Up page, for
example <http://groupserver.org/request_registration.html>. It makes sense to
place them on an intermediate page, which can display the text far more fluidly
than an email message. Showing the T&C makes the One Link option more
compelling.
I like “decline” too, Steve. As shown in the screenshot below I have changed
the text to say decline; I have also changed the link to "/p/rsvp", as Richard
suggested. Oh, and I show the link now, using Jim's suggested #-text (for now,
I may change it to "example" when I get it going).
At this stage, I am tempted to deal with “perpetually invited” when they become
a problem, Dan. They are not a problem yet, and I do not think they are likely
to be for a while.
I am also playing around with adding an HTML version of the message. Steve had
the idea a while ago <http://groupserver.org/r/topic/1J34hrhnYC2J8iL5bxuicm>,
and I *have* an HTML version of the invitation (I need one for the preview). It
seems to work fine, but I have not *sent* anything yet, I am just printing out
the message before it is sent.
At this stage I will keep the invitation text as a simple text area: no
WYMeditor <http://www.wymeditor.org/> yet. There is a lot changing behind the
scenes and adding a WYMeditor will be a change too much for me ☹
The
following file was added to this topic:
Oh, I should have said earlier, the "Reply-to" header is shown now, too. For
now I am keeping the Reply-to set to the support-address for the site:
* For my development site the support address is my email
address.
* For OnlineGroups.Net it is <email obscured>>
And so forth…
My official reason for setting the Reply-to is that it is about the only way to
get the support-email to the invited user in such a way that does not interfere
with the message too much.
My actual reason for setting the Reply-to is that it causes people to
continually email support with messages thanking the admin for inviting them to
join the group, and expressing excitement about participating. No one ever
emails support about how well things are going, and I am a sucker for good
news, especially as it is quick and easy to forward the message on to the right
administrator.
My test system successfully sends invitations. I spent some time with the
email-standard, and ensured that Unicode characters are supported in the
user-names, subject-line and body of the invitation.
As shown in the screenshots below, the received-email looks quite close to the
preview. The subject line and message-body are both very close to the default
text, except I have added some Unicode characters for testing (a ☺ and a —
respectively). The test-user's name also has a couple of Unicode characters, ❧,
in it for testing purposes.
For the curious, the UTF-8 encoding is used throughout.
The
following files were added to this topic:
I recently helped a gardening group start up a Google Group and they allow
you to just add folks with lots of warning about spam and links to anti-spam
laws to scare you a bit.
I know that Yahoo let's you add 10 a day.
I like making invite truly invite and you might even allow just a simple
list of email addresses to be typed in or like many tools all people to use
their contacts, etc.
With distributed add new members to all group admins (heck make it a premium
feature) I'd use it a few times a week (particularly if add really meant add
existing site members to the various online groups we use for project
involvement with only a decline link).
For us with ten new neighborhood forums in the pipeline and in-person
recruiting the +only+ thing that really works these days, particularly for
inclusion, it would be majorly helpful if we could distribute this add role
for single or small batches (and rely on declines not accepts when a local
forum admin chooses to add someone who +asked+ to be put on). Competitively
if Google, Yahoo, even the new Groupsite trusts their users, GroupServer
needs to figure this out to be competitive as well.
Steven Clift
http://stevenclift.com
@democracy
On Apr 16, 2010 1:15 AM, <email obscured>> wrote:
― Attachment links are at the end of this email ―
My test system successfully sends invitations. I spent some time with the
email-standard, and ensured that Unicode characters are supported in the
user-names, subject-line and body of the invitation.
As shown in the screenshots below, the received-email looks quite close to
the preview. The subject line and message-body are both very close to the
default text, except I have added some Unicode characters for testing (a ☺
and a — respectively). The test-user's name also has a couple of Unicode
characters, ❧, in it for testing purposes.
For the curious, the UTF-8 encoding is used throughout.
GroupServer Development now contains the following files
http://groupserver.org/r/img/1843-2010-04-16T061444Z
Name: preview.png
Type: image/png
Size: 44KB
http://groupserver.org/r/img/1844-2010-04-16T061445Z
Name: email.png
Type: image/png
Size: 65KB
On Fri, Apr 16, 2010 at 11:23 PM, Steven Clift <email obscured>> wrote:
> I recently helped a gardening group start up a Google Group and they allow
> you to just add folks with lots of warning about spam and links to anti-spam
> laws to scare you a bit.
The NZ laws are very difficult to comply with; if you have a
pre-existing relationship with someone you are allowed to invite them
to join (only once), but I don't think you are allowed to just add
them. However it isn't clear to me how strictly these laws apply when
you are not contacting people for 'commercial' reasons. I know I've
"just added" people to groups before now.
In practice of course the costs of legal compliance would fall on the
group owner, with some fallout on onlinegroups.net while they identify
the owner.
Of course, not everyone is subject to the same laws, and the
semi-mythical 'common carrier' status would probably permit
onlinegroups.net to provide the facility but to make it clear that it
is the responsibility of the group owner to comply with laws. It may
even be a good reason to restrict the facility to fee-paying owners,
where there is a higher standard of identification.
The legal compliance that Jim mentioned is something that I am aware of, but it
is not my overriding concern with the design of the invitation system. I am
mostly concerned with empowering users, but reducing errors, and ensuring
security.
❦
Just adding people to a group has the difficulty that the member never sets a
password. Because of this, the member needs help with all parts of the system
other than reading and sending email (which is the primary use, admittedly).
Requiring help *disempowers* the user, and increases the load for support.
I hope that the invitation message will become more personal and more
compelling if I allow the administrator to preview and alter the message before
sending it. This should improve the acceptance-rate of invitations, and reduce
one of the barriers that administrators face when using it.
I am aware that some systems remove the invitation barrier entirely, by just
allowing people to be added to groups. I am also aware of other systems such as
Facebook, Linked In, and Flickr that seem to do all-right with invitations. In
the *general* case, I am not aware of any major usability flaw with
invitations.
❦
Ensuring correct email addresses is very important for email-lists. Invitations
serve the secondary role of verifying that the user's email addresses is
without *error*.
The rate of errors with email-address dropped from around 10% to 0 when we
switched to online sign-up with a Big client. (We know what the error rate is
because the users were highly motivated and contacted us if email did not get
through.) The problem with reading email addresses off a form is that there are
three places for mistakes to occur:
• Writing the address,
• Reading the address, and
• Typing the address.
This drops to one place for a mistake to occur with online sign-up (typing the
address).
❦
A more nuanced *security* system, which will allow a user to say who can do
what to his or her profile, would be ideal. I imagine that the user-interface
would look something like the following.
Group Administrators can
☑ Change my email addresses.
☐ Change my profile information.
☐ Change my group memberships (rather than inviting me).
☐ Post as me.
However, making fundamental changes to the security setup is the sort of task
that few people want to tackle, has wide reaching implications, and is hard to
design.
Steve suggested allowing any member of a group to invite someone else to join.
This would be fine with the current invitation system. However, I recommend
that it be thought about in the context of the above security changes.
Jim, Steve, All,
The ability to "just add" group members is a much requested, and much
debated matter.
With security in mind, it is a classic question of tension between
safety and liveness (although not as much of a classic as the one
currently facing Europe's air space).
With access to the web interface in mind, it is a classic question of
efficiency vs effectiveness (or trading getting the right task done for
getting the task done right). The other notable case of this in the
GroupServer UI is where we use "add to topic" and "start topic" in place
of "post".
Both of these cost group members, which cost groups, which cost sites,
which cost instances. So believe me, I care about them.
Making it easier to get the right people into groups is on, and always
has been on our agenda. However, unfortunately, things have been moving
along slowly. Even the existing interface has sat with some major
problems for some time. Many of the difficulties that admins experience
are caused by these problems, and not the fundamental design of the
system. Finally, we are getting to those.
Alice is well down the track with rebuilding Manage Members, and Michael
is well along with improving the invitations system. Both of these
projects pave the way for improvements to many other aspects of group
administration.
Our plan is to get the current system working correctly first. This will
take out known and uncontroversial barriers to getting people into
groups. With those removed, we will be in a much better position to
understand where the problems actually sit. And we will have a better
technical toolset with which to tackle them.
Ultimately, I think that the system should enable its administrators to
determine how permissive or restrictive it is, with respect to getting
people into groups. What works best varies a lot from one case to the
next. Unfortunately, it will take us some time to get there. In the
meantime, I am delighted to see the progress that we have.
It's an interesting topic -- but I think the strongest point is this:
Facebook has 400 million *active* users. Every single user who has added
a friend, has been sent an 'invitation' to do so (unless there is a way
to switch that off for yourself?).
The average user has 130 friends. That means that Facebook has sent out
Rest of post
-- and had accepted -- 52 *billion* invitations. It seems unlikely to me
that invitations are a real bottleneck, and they serve 3 main objectives:
1: They verify that the address that has been collected is actually
correct (correctness),
2: They verify that the person really wants to receive email (legality),
3: They verify that the person actually cares about participating in
the group (social).
I *totally* understand that some of building a group is about the
numbers. But aren't active users, who actually want to participate in
the group, better?
If we don't have invitations it is perfectly conceivable that there will
be a number of users who will never participate because the address is
totally wrong. There is also the problem that *we aren't google*, and
thus, can't just flaunt the law and expect to get away with it. If we do
it enough, we will get blocked. And we'll get blocked by, ironically,
the big players like Google.
I would propose that we make the invitation and participation tracking
as good as we possibly can, and periodically revisit this issue. The key
things for me are:
1: The invitation itself must be very, very good. We want people who
want to participate to find it trivial to do so,
2: We need a really good way of tracking who has been invited, who
hasn't responded, and reminding them (automatically as well as
manually). It is a fact that in automated surveying systems they have
found the response rate to the first invitation is quite low. People
like to defer things that they don't consider important. Each reminder
bumps up the 'importance' for them because, probably, they want the
annoyance to stop ;)
3: We need a really good way of showing who is bouncing so the admin
can fix it.
4: We need a participation metric -- who are the most active, who
hasn't participated, participation rates per user (posts per week/month?).
I actually think that 2,3,4 might need to be site as well as group
specific. There are going to be users who are in several groups --
reminding and fixing would be an easier task if you could see them all
at once.
Best regards,
Richard.
On a technical note, part of my reimplementation of the invitation system is to
record who sent the invitation, who received the invitation, how many
invitations were sent, and which invitation was accepted. How this data is
presented is a problem for another time ☺
Below is a screenshot of what the new "Respond to the Invitation" page looks
like, sort of. It is actually a screenshot, and it is actually showing the
response page, but it is only sort-of showing an invitation. What it is
*actually* showing is a Preview of the response — the page that is shown when
you click on the link in the invitation-message preview
<http://groupserver.org/r/img/1843-2010-04-16T061444Z>. In turn the Response
Preview page can be used to show the administrator what the group homepage will
look like once the invitation is accepted, or what the Decline page will look
like.
Tour of the Respond Page
━━━━━━━━━━━━━━━━━━━━━━━━
The Respond page is highly constrained, because I do not want the user
wandering off and getting confused. As a consequence, the page has no
site menu, utility menu, context menu or search box. After the page
heading, a personal greeting (to warm the user) and an explanation of
why the user is looking at the page is presented. The rest of the page
is broken into four sections: Accept, Decline, and two About boxes.
The Accept section has a heading, and some instructions. A text entry
accepts the new member's password, which is required before the Accept
button becomes available. The Acceptable Use Policy appears in a
disclosure, before the Accept button.
The Decline section is simpler: a single button that will cause the
invitation to be declined.
Below the Decline section are two about sections: to the left one on the
administrator, and to the right one on the group. The main feature of
the about section for the administrator is a photo, and the
administrator's biography. This will hopefully personalise the
invitation somewhat.
The about section for the group starts by stating what the
real-life-group is. This is followed by some simple statistics on how big
and active the group is. The statistics include the number of members,
the maximum number of posts and the mean number of posts. This is
followed by the group privacy settings, and the privacy policy (in
a disclosure).
The
following file was added to this topic:
I love the Respond to Invitation page, Michael! I can only suggest a
couple of tweaks to wording:
* Because the inviter and the invitee are the same person,
the note that "Some of your profile information is shown...
below" caused me to stop for a moment, as I wasn't sure
whether it was there for the admin or the regular member.
Maybe just preface it with, "As the administrator, " or
"As the person extending the invitation, " perhaps?
* The phrasing of the max number of posts in the group
suggests that it is an actual limit that cannot be
exceeded -- maybe "They have not yet made more than
10 posts in a single day"?
Thanks for the awesome suggestions, Alice! I will fix the Respond to Invitation
page.
In between other tasks I have managed to advance this project further. My
development version allows me to accept and decline invitations. I noticed that
the delivery settings are not stated on the Response page
<http://groupserver.org/r/img/2207-2010-04-23T073912Z/respond.png> but that is
about all the problems I can see so far.
In addition I have had another prune of the code. To this end I have created
the gs.group.member.invite module. In it I have placed all the code for
*issuing* an invitation to an existing user. That code I took from
gs.profile.invite, which will concern itself simply with *responding* to
invitations. (Richard, I almost renamed the "gs.memberdirectory" product
"gs.group.member.directory", but I stopped myself; maybe later.)
My next task is to attack the old "Products.GSGroupMember" product with a saw
and graft the code for issuing invitations to *existing* members onto
"gs.group.member.invite". Then I will take the code for responding to those
invitations and make it part of "gs.profile.invite". Not glamorous work, but
hopefully it will make everything more understandable.
I think being able to invite someone with just an e-mail address (with a cap
on the number per day) would be very useful. It is what GG and YG do.
On Jun 9, 2010 2:51 AM, "Michael JasonSmith" <email obscured>> wrote:
In between other tasks I have managed to advance this project further. My
development version allows me to accept and decline invitations. I noticed
that the delivery settings are not stated on the Response page <
http://groupserver.org/r/img/2207-2010-04-23T073912Z/respond.png> but that
is about all the problems I can see so far.
In addition I have had another prune of the code. To this end I have created
the gs.group.member.invite module. In it I have placed all the code for
*issuing* an invitation to an existing user. That code I took from
gs.profile.invite, which will concern itself simply with *responding* to
invitations. (Richard, I almost renamed the "gs.memberdirectory" product
"gs.group.member.directory", but I stopped myself; maybe later.)
My next task is to attack the old "Products.GSGroupMember" product with a
saw and graft the code for issuing invitations to *existing* members onto
"gs.group.member.invite". Then I will take the code for responding to those
invitations and make it part of "gs.profile.invite". Not glamorous work, but
hopefully it will make everything more understandable.
I am about to work on getting the Sundae release of GroupServer out the door
<http://groupserver.org/r/topic/6IwIFaOtTpvenJlPJ6LOW4>. However, once that is
done I will be getting back onto Invitations. Below is the the Testing document
for invitations, in HTML form. I have tried to link it to the tickets that
exist for the problems with invitations.
The
following file was added to this topic:
