All posts in the topic Joining a Group and Registering an Account Using the Web (Short link)
Summary
- There are 59 posts — by 7 authors — in this topic.
- Latest post made by Michael JasonSmith at Jun 19 03:47 UTC
An unregistered user joining a group is the most complex thing I can think of a
user doing in GroupServer. The following is phrased for the typical case of a
user joining a public group, with exceptions to follow. Things are more complex
than they seem because the Web and email are being used simultaneously.
However, I shovelled the complexity into seperate pages ☺
Joining a Group and Registering an Account Using the Web
To post to a group, and receive email messages from a group, you must
register an account with GroupServer. To use the Web to register an
account with GroupServer, carry out the following tasks.
1. Click Register and Join in the group you wish to join. The
Register and Join page will be shown.
2. Enter your email address in the Email Address entry.
3. Click Next. Two things will happen:
* A email address verification message will be sent to you (see
Adding an Email Address, Step 4)
http://groupserver.org/r/post/6b5rm4OsiHJ4kWpZ37jUOl
and
* You will be shown the Edit Profile page.
4. Edit your profile. Your profile will allow other users of
GroupServer to get to know you better. At this stage you can also
join other groups, by selecting them in the Groups section of
your profile.
Tip: Nickname
Your nickname is a single word that is used to identify you and
your profile. Its primary purpose is to create the link to your
profile. By default, your nickname is created out of your
display name, with the spaces removed.
5. Click Next. You will be shown one of two pages.
* If you have not verified your email address (see Adding an Email
Address, Step 4) you will be shown the Waiting for Verification
page; once you verified click Next to see the Set Password page
(see Resetting Your Password step 6).
http://groupserver.org/r/post/3JJvi3M6zykWP5SCogRZK
* If you have verified your email address, you will be shown the
Set Password page (see Resetting Your Password, Step 6).
http://groupserver.org/r/post/3JJvi3M6zykWP5SCogRZK
6. Set your new password. You will be shown your profile page after
the password has been set.
Note: Administrator Registration
If you do not have an account with GroupServer, an administrator
can create one for you. If this happens, you will receive an
email message informing you that this has occurred. Clicking on
the link in the email message will take you to the Edit Profile
page (Step 4 above) and verify your email address.
I imagine that an administrator could set as much information about the user as
he or she wishes; the user would have the option of correcting everything,
because of the Edit Profile page.
When entering e-mail I highly recommend a repeated e-mail field that when
submitted confirms that they are the same. I am guessing that up to 10 percent
of users mistype and this accounts for a high percentage of our unverifed
users.
Why not just make display name the member profile link? And skip the complexity
of another choice.
We want to avoid terms like Nickname in e-democracy land with our real name
policy.
I did not explain the nickname clearly, Steve. Sorry.
The nickname is used to form the URL to the user's profile, not the link-text.
The nickname is an advanced feature for those who like nice URLs, much like the
Web Address in the settings of a Flickr account. I have all sorts of ideas for
the display name, such as making the user's roles more explicit, but that is
for another topic ☺
There are two reasons for introducing the nickname. First, the display name can
get quite large, and is not nice to write down: MichaelJasonSmith rather than
mpj17. This becomes important as we want to introduce the *option* of public
profiles, so people will be sharing the profile-URL more. Second, we are
dropping the current user-IDs, in favour of randomised user-IDs that will never
be shown to the user. The Nickname currently takes over the (partly) visible
role of the user-ID.
Is that clearer, Steve?
I wondered about getting the user to retype the email address, and decided against it, for three reasons. First, four keystrokes renders the second box a useless annoyance Control-A Control-C Tab Control-V or the ⌘-key equivalents. Second, there is an equally large chance that the user will mistype the email address in the second box, while getting it correct in the first, once again rendering it a useless annoyance! Finally, we can rely on auto-complete in the user's browser to assist us to get the user's email address correct. On my scribbles I have a provision for correcting the user's email address, but it is at a different time to the one you suggested, Steve. I thought about adding it to the help above http://groupserver.org/r/post/1KOtevr6QTbZtnO4PBMuVu I decided against it, as adding all the error conditions complicates matters! I also need some help with figuring out what to do in one circumstance. The following (can) go in with Step 5 in the above help text. While waiting for verification of your email address, you will be presented an opportunity to correct the email address. Type in the correct email address into the Email Address entry and click the Verify button. A new verification email message will be sent to the new address. The nice thing about presenting the email address at this point is the user has nothing to do *except* check his or her email address. However, I am unsure what should happen if the user enters an existing email address. Normally we would send out a password-reset message, but by the Waiting for Verification stage, the user has potentially filled out the profile, and I am loathe to throw away the user's work. Someone tell me to stop worrying about a rare corner case…
Below (in editable SVG and viewable PDF) is a state transition diagram
of the registration process on the Web. It is the simplest view of
registration that I have managed to come up with and I have tried to
represent registration in many ways, including plain text and flow
charts.
A state-transition diagram shows the states that something can be in,
such as a user. Each arrow, which comes out of a state, represents an
action of some sort. In our case the actions are normally filling out
forms, but they can also be replying to an email message. I have hidden
some complexity around the steps involved with verification, but it is
mostly all there, unless Richard can see something that I have missed
Later I will add mock ups of the pages that the user will see in each
state.
The following file was added to this topic.
- Name: registration-state-transition.pdf
- Type: application/pdf
- Size: 39.33KB
The following file was added to this topic.
- Name: registration-state-transition.svg
- Type: image/svg+xml
- Size: 17.44KB
Below is a mock up of the first page the user will see when registering using
the Web.
The initial paragraph is designed to say what is going to happen on the next
few pages. Not that I expect anyone to read the text. The second paragraph
contains the faux-legal text for the site.
Then comes the actual interface. Like the Reset Password page, it is very
simple technically: it only contains a single entry and a button! If the user
enters an email address that already exists, the system will fire off a Reset
Password message. Hopefully we can add JavaScript code to do a sanity check, so
we know that the address is *vaguely* sane, even before it is sent to the
server ☺
The following file was added to this topic.
- Name: register-01-email.png
- Type: image/png
- Size: 16.81KB
On Wed, 2007-09-26 at 16:57 +1200, Michael JasonSmith wrote:
> The initial paragraph is designed to say what is going to happen on the
> next few pages. Not that I expect anyone to read the text. The second
> paragraph contains the faux-legal text for the site.
Is there going to be a way (popup maybe?) to read the actual T&C without
hunting for it?
The second page (below) is the most complex in all of verification and
registration. From the user's view, the purpose is to fill out the biography,
with things like the name, and additional contact details. From the system
point of view, the purpose of this page is to keep the user busy, so the email
address verification message has a chance to get through.
JavaScript could be used for three things on this page. First, constantly
checking to see if the email address has been verified. Second, ensuring that
the required attributes have been set. Finally, JavaScript could be used to
bring up some tips for the attributes, such as the one for Crack Smoking in the
image below.
At this stage I can see a couple of problems:
* We need to figure out how to indicate the required attributes better, and
* The email address needs to be an attribute.
“Required” attributes come in two flavors: those that are required for a site,
and those that are required to post to a group. My current feeling is that the
two should not be distinguished at this stage, but they should be indicated by
an icon.
I may do some mock-ups of specific parts of the interface, such as the groups
selector and an email address attribute.
Also of note, there will need to be different introduction text for those that
are invited to join the group, as the user will already have a verified email
address, and not go through the first registration screen.
The following file was added to this topic.
- Name: register-02-profile.png
- Type: image/png
- Size: 41.30KB
> Is there going to be a way (popup maybe?) to read the actual T&C
> without hunting for it?
An excellent question Richard. My idea is to use a simple link to show
people the terms and conditions ☺ The user can use back to return to the
initial page after reading the T&C. Back is the second most widely used
part of the browser, after hypertext-links, so I imagine that most
people will be able to cope with it.
On Wed, 2007-09-26 at 18:37 +1200, Michael JasonSmith wrote:
> > Is there going to be a way (popup maybe?) to read the actual T&C
> > without hunting for it?
>
> An excellent question Richard. My idea is to use a simple link to show
> people the terms and conditions ☺ The user can use back to return to the
> initial page after reading the T&C. Back is the second most widely used
> part of the browser, after hypertext-links, so I imagine that most
> people will be able to cope with it.
I wouldn't count on it, personally. While 'back' might be commonly used
and understood, I wouldn't count on the user's reaction at being taken
completely away from a form as anything other than panic. What if it
takes them away, and they *assume* it was a new page and close the
tab/window? I've done that on more than one occasion, even realising
that it wasn't a new page (after reading a T&C and AUP, the brain tends
to be a little soft).
In this particular situation I think it could even be modal, since it's
*extremely* unlikely that the user would want to proceed at the same
time as reading the T&C (ie. they would either not bother reading it,
start reading then close or finish reading then close).
I would really like to avoid modal interfaces, if at all possible.
On the first page of registration, the user has done little (written his or her
email address) or no work. All in all, I think that the user will be more
confused by a pop-up window.
I have an alternative idea! We could put the T&C in a DIV, set it to scroll
("overflow: scroll") and put it in a disclosure widget. That way the user can
see them if he or she wants, but we do not pretend that the user is *actually*
going to read it! (It is not as if the Acceptable Use Policy, Terms of Use
Policy and Privacy Statement are not on every single page on most of our
sites.)
Below is an example of what I am thinking of when it comes to the terms and
conditions interface: the disclosure button gets the terms and conditions out
of the way, but they are there. I had a bit of fun loading a page using AJAX,
which is why it does not *actually* show the terms and conditions for this site
(as they are on OnlineGroups.Net, which is technically a different domain, so
the JavaScript security kicks in).
What do people think?
The following file was added to this topic.
- Name: t-and-c.html
- Type: text/html
- Size: 1.45KB
Excellent use of the disclosure button!
On Thu, 2007-09-27 at 15:50 +1200, Alice Murphy wrote:
> Excellent use of the disclosure button!
I like it. One thing I've been wondering about generally though: can we
make things disclose ... faster? Not so much an issue for things like
this (where it's quite neat visually), but it gets quite tedious in
other parts of the interface (like the search 'refine' for example).
Below is the latest mock-up of the Registration pages: set password. There is
not much to say about the page, except that I have tried to give an idea of
what the help-text for the page would look like. The normal Set Password page
would look very similar.
The following file was added to this topic.
- Name: register-03-password.png
- Type: image/png
- Size: 28.54KB
I have not been following this discussion, but it did look at this note. I like the very clean interface. But for me the text is getting very small. Michael JasonSmith wrote: > Below is the latest mock-up of the Registration pages: set password. There is not much to say about the page, except that I have tried to give an idea of what the help-text for the page would look like. The normal Set Password page would look very similar. > > > GroupServer Development now contains the following file > > http://groupserver.org/r/file/705799-2007-09-27T044543Z > Name: register-03-password.png > Tags: "" > Type: image/png > Size: 28KB > > > All the files that have been added to GroupServer Development can be viewed at
The following file was added to this topic.
- Name: jsveitch.vcf
- Type: text/x-vcard
- Size: 0.29KB
On Thu, 2007-09-27 at 19:34 +1200, John Veitch wrote:
> I have not been following this discussion, but it did look at this note.
>
> I like the very clean interface. But for me the text is getting very
> small.
Yep, I agree, the help text in particular is getting very small. Having
said that, it is just an image mockup -- the final version will be CSS
and so the minimum font size will conform to the user settings.
This is the last mock-up page for the Join and Register task: Awaiting Verification. The mock up below has a lot of text, but this should not be a problem as we want to use up some time, so the verification message has a chance to get through. In addition, the user is in a reasonably complex state, and it takes a bit to explain it ☺ After the first explanation is the *disabled* Next button, along with some help text explaining that it will become available once the user's email address is verified. The idea is to have some Ajax code checking with the server to see if the address is verified or not, and for the button to automatically become available automatically. Under the Next button is the second part of the page, which will allow the user to correct the email address, if it is wrong. If the user corrects the address a new verification message will be sent out and the Awaiting Verification page will be shown again. This is the “different time” I mentioned earlier http://groupserver.org/r/post/7ojOA069zPQquIRZrWzpmR In addition to the correction interface, some handy hints are provided, to avoid the verification message getting lost in the morass of spam filters.
The following file was added to this topic.
- Name: register-04-waiting.png
- Type: image/png
- Size: 31.76KB
I generally like it ... but I think the label 'correct' is a potentially
poor choice -- some users may think that it's asking for validation that
the address is correct (ie. if it's already correct, they will click on
it again).
How about they use it to re-send verification, and can, at the same
time, change it if it's wrong?
An excellent point, Richard: the word Correct is misleading. What I am unsure
of is what you mean by “it”:
How about they use it to re-send verification, and can, at the same
time, change it if it's wrong?
On Fri, 2007-09-28 at 11:48 +1200, Michael JasonSmith wrote:
> An excellent point, Richard: the word Correct is misleading. What I am unsure
of is what you mean by “it”:
> How about they use it to re-send verification, and can, at the same
> time, change it if it's wrong?
Sorry, I mean the 'correct' feature. Perhaps relabel it 'send again' and
allow them to alter the address (as it stands now), plus change the help
text slightly to reflect.
Something like the mock-up below, Richard?
The following file was added to this topic.
- Name: register-04-waiting.png
- Type: image/png
- Size: 33.07KB
I like that better. It also gives people "permission" to enter a
different email address if they wish, rather than just correct the one
they supplied previously.
I would change the Things to Check though: I think saying "ensure"
implies that the user should have known to add the verify email address
to their address book. Perhaps change it to "Add the address... to your
address book" and the title to "Hints"?
Good idea, Alice. The current wording is deliberately preachy, so I remember to
change it! The exact wording is something to debate later, once we actually
have test pages up and running ☺
Mike: I like the new one. Alice's tweaks are also very good.
On Fri, 2007-09-28 at 12:09 +1200, Alice Murphy wrote:
> I like that better. It also gives people "permission" to enter a
> different email address if they wish, rather than just correct the one
> they supplied previously.
This raises a question. If I have the (valid) addresses:
<email obscured>
<email obscured>
And I enter the first at the first prompt, and the second when I'm asked
if I'd like to send another verification ... what do we do? Do we
discard the first address? I might end up actually *receiving* both ...
We may be able to be cunning and actually *detect* the bounces from the
verification addresses and thus *tell* the user that their address
bounced...
Dealing with multiple valid addresses is something that we do need to handle.
My preference is for letting the user continue (click the Next button) when the
first address is verified, and add the second address to the user's profile
when it is verified.
As for bounce detection, I will leave that magic in your capable hands ☺
Could we show a log?
01:01 UTC - Verification email sent to dan@foocom
01:02 UTC - Verification email sent to <email obscured>
01:07 UTC - Verification email sent to <email obscured>
Not a bad idea. I like it a lot ☺
Steve and John, you have close contact with the users. Could you put yourself
in their shoes and see if log will confuse them?
On Mon, 2007-10-15 at 16:00 +1300, Michael JasonSmith wrote: > After the introductory text is the disclosure buttons for the terms of use and the privacy policy. I need to refactor the way the T&C is stored on OnlineGroups.Net, to allow AJAX to retrieve the document; the prototype currently uses a page from the user-guide. Other implementations of GroupServer will have their own way of introducing the terms and conditions, but I thought I would show the OnlineGroups.Net method, because I think it will be very useful and usable. > > The email-address entry has the same styling issues as the password-reset page. > http://groupserver.org/r/post/70IrnZed1jJOlYSENtobkb > > Just before the Register button is a plea to the user to add the verification email-address to his or her address book. I hope this will mitigate the problem of messages falling into the clutches of the spam filters. > > Anyone see any problems with the page as it stands? Maybe a little tweak to the plea: "before clicking 'register'". Not too much point in doing it after they click register and it's already in their spam trap ;) A tweak in the future could be to look at the address they have entered, and with AJAX display a help message telling them how to whitelist the address in their specific freemail account. This isn't as onerous as it sounds -- there are really only a handful of popular freemail services, and they account for a *huge* volume of our email. Other than that, it's looking clean and not to forget, simple.
Great idea, Richard! I added the text “Before clicking the Register button”
[1]. I also referred to the address as a “contact”, as that is what Google,
Yahoo! and MSN call it. Speaking of which, we can do a lot by simply linking to
the appropriate help pages. It does assume that the user knows the name of his
or her freemail service…
1. In help text, buttons are always referred to as buttons, to
distinguish them from links.
On Tue, 2007-10-16 at 17:12 +1300, Michael JasonSmith wrote:
> appropriate help pages. It does assume that the user knows the name of his
> or her freemail service…
Well ... @gmail.com, @hotmail.com, @yahoo.com etc. are pretty big
giveaways (that probably takes care of about 40-50% of users I'd guess).
You would hope that the address would be a giveaway — but there is no
harm in GroupServer doing the mapping with JavaScript, as you suggested
☺
On Tue, 2007-10-16 at 17:42 +1300, Michael JasonSmith wrote:
> You would hope that the address would be a giveaway — but there is no
> harm in GroupServer doing the mapping with JavaScript, as you suggested
> ☺
I actually meant we would parse the address, and provide the correct
information (or generic information, as the case may be) -- just to make
sure I'm being clear :)
I have added some more JavaScript fun and games to the prototype Register page http://groupserver.org/groups/development/register_prototype The first is an improvement to the web-mail check, while the second is to prevent bogus addresses being entered. I have cleaned up the checking of the email-address, so the help-link becomes available as soon as the user types the start of a recognised web-mail address (@hotmail, @gmail, @yahoo). This should make the help-link available sooner, and it should be tolerant of the various Yahoo! address: @yahoo.ca, @yahoo.co.in, @yahoo.co.jp, @yahoo.com, @yahoo.com.au, @yahoo.com.br, @yahoo.com.cn, @yahoo.com.hk, @yahoo.com.tw, @yahoo.co.nz, @yahoo.co.uk, @yahoo.de, @yahoo.dk, @yahoo.es, @yahoo.fr… The other addition to the registration page is to disable the Register button, until the user types in something that vaguely looks like a valid email address. The regular expression used is /[a-zA-Z0-9\._%-]+@([a-zA-Z0-9\-]+\.)+[a-zA-Z]{2,4}/ It is based off a similar expression in von Weitershausen, Philipp, “Web Component Development with Zope 3”, Second edition, Springer, Berlin 2007 If anyone knows of a better expression, I will be more than glad to use it ☺
I have posted the prototype of the Edit Profile page http://groupserver.org/groups/development/edit_profile_prototype The page only shows the "core" attributes, and I expect that many sites will want to extend them. As far as the UI goes, generic popup help and required-attributes interlocking both work. The popup help appears when any of the text-entry fields have the focus (but not the timezone selector, for some reason). The data for the popup help is specified in the Zope 3 Schema for the page, just like the rest of the form; jQuery magic is used to create the popup-help elements, and attach the "focus" and "blur" events to the widgets. Interlocks prevent a person from carrying out an action, unless a particular condition has been met. For example, every microwave oven has an interlock that prevents cooking while the door is open. The interlock on the Edit Profile page prevents the Edit button from being hit until all required fields have been filled out. Interlocks are also present on the other prototype pages that I have posted. My next task is to link all the pages together…
The Acceptable Use Policy and Privacy Policy on the Request Registration page
are now the *actual* Acceptable Use Policy and Privacy Policy of
OnlineGroups.Net. While OGN-specific, I think the use of disclosure buttons
for these two documents is a good one:
* The documents do not get in the way, and
* The user can read the documents without leaving the
Request Registration page.
The new interface for “Joining a Group and Registering an Account Using the Web” is available for testing: http://groupserver.org/groups/development/register_prototype/request_registration.html?form.groupId=development [In deployment, the URL will be a lot shorter!] Registration via the Web uses five pages. The examples use OnlineGroups.Net policies and terminology, but every page can be skinned using the Zope 3 skinning mechanism. Request Registration is the first page that the user sees. It has one entry, for the user's email address. I have placed a JavaScript interlock on this page to ensure that something vaguely approaching an email address is entered. If the user enters an address that already exists on the site, then he or she is directed to either the login page, or the password reset page. Otherwise * A new profile is created, * An email-address verification message is sent, and * The user is taken to the Edit Profile page. Edit Profile (Registration) page is almost the same as the normal Edit Profile page, which has been running since the beginning of the year. The text at the top of the page is different — as is the list of groups that the user can join, which is the bottom of the page. However, all the widgets in between are the same as the normal Edit Profile page. By default, the user's name is set to the left-hand side of the email address, while all the other fields are blank. The purpose of this page, is to slow the user down, so the email address verification messages has a chance to come through. Once the user's profile is complete, then he or she is sent to either the Waiting for Email Address Verification or Set Password pages. The user sees the Waiting for Email Address Verification page if his or her email address is not verified, after the profile has been edited. The page has three roles. The first role is to halt registration until the user's email address has been verified. The second role is to allow the user to *correct* the email address. Finally, the page allows the user to send out another email address verification message. When the user's email address has been verified, the Next button becomes available, and the user is sent to the Set Password page. Verify Email Address page is a simple static page. The user gets to it by following the link in the email address verification message that is sent out when the Request Registration page is submitted. As a side effect of visiting the page, the user's email address is verified. When the user's email address is verified, this is noticed by the Waiting for Email Address Verification page, which polls the server every eight seconds. The Set Password (Register) page is almost exactly the same as the normal set password page, except the user is sent to the site homepage once the password is set.
As Tim and Richard commented to me off-list, there is a oddity when using the prototype user-verification page. When you complete the profile you are joined to all groups that you selected in the Joinable Groups list. This is meant to happen ☺ However, currently GroupServer sends out a Welcome email for each group you join, even though your email address is not verified. This is not meant to happen. Until we have email verification working across the board, there is not a lot we can do about it; it will be fixed Real Soon Now. By the way, the Edit Profile page that is shown during registration is configurable, so sites with *lots* of public groups http://forums.e-democracy.org/groups/ need not worry about the list becoming too long ☺
On Jan 30, 2008, at 4:06 PM, Michael JasonSmith wrote: > The new interface for Joining a Group and Registering an Account > Using > the Web is available for testing: > http://groupserver.org/groups/development/register_prototype/request_registration.html?form.groupId=development > [In deployment, the URL will be a lot shorter!] Michael: Overall, its looking pretty good. I'll want to look at the exact instructions that go along with the process later to offer more specific input, right now I'm focused on the process and mechanics. #1) There were some visual issues that you are probably already aware of. I'm attaching two screen shots, just in case. #2) I already mentioned my confusion about the join and verification email coming together. But, you already knew about that. #3) When I tried to enter my password, I got a RED message saying that my password did not match, before I ever tried to match my password. It felt like it was telling me that I'd made a mistake, before I'd even done anything. This was confusing. That's all I have time for now. I'll look at it again later and see if I have any more feedback. Tim ERickson
The following file was added to this topic.
- Name: Password Page.tiff
- Type: image/tiff
- Size: 185.46KB
The following file was added to this topic.
- Name: Registration Screen Shot.tiff
- Type: image/tiff
- Size: 143.87KB
Thanks Tim!
I was aware of the visual issues with the popup-help. I have a fix committed to
SVN, but I have not had a chance to update the servers. (I need both Alice and
Richard to help me change the core CSS file, and today was the first day all
three of us were in this week!)
I am struggling with getting the Set Password page right, and your comments are
extremely helpful in directing my changes. I was confident that the message
about the passwords not matching would cause problems — but it causes fewer
problems than not popping up the message. I will alter the message so it is not
styled as an error, just as plain text. I could be *really* sneaky, and only
pop up a message when the user types in an incorrect letter in the second box,
after entering text in the first box — but no, I think that it will be better
to have a poor algorithm that people can understand.
❦
There is another issue with registration using the Web that Dan though of, and
I had a ponder about while listening to Salmonella Dub. A user may abandon the
registration process part-way through and then want to resume. In this case we
should be able to help the user recover from the mess.
1. The user to enters his or her email address on the
initial registration page.
2. The system notices that the user has one, unverified,
email address.
3. Resend the verification message.
4. Go to the Awaiting Verification page.
5. Carry on registration, same as before.
In my current state, the above five steps make sense ☺
Hi Michael,
Congratulations on the progress you have made with this. I think this is an
enormous improvement on our current system, and I'm excited to see it so nearly
ready. Below are some comments.
Dan
. . .
1: I can access the Register page when I am logged in. As we have discussed, it
is not clear whether this is a bug or a feature. In any case, it's probably a
rather rare case, as we won't show the user a 'register' link if they are
logged in. Effectively it will function like the "invite someone to join"
feature, but without the chance to add a personal message. As we are working on
a sensible invitation feature, this is probably a reason to restrict the use of
"register and join" to non-logged in members. Anyone else got any comments
about this?
2: Register page text.
PARA ONE
You must register with GroupServer.org to add
posts to topics, receive email messages and
join private or secret groups.
LATER IN THE PAGE
Once you complete registration, you will be
logged into GroupServer.org — and you will be
able to join groups, post messages, and receive
email messages from groups.
The later para seems to say the same as the earlier one, but in different
terms. Why not either omit one of the two statements of what you can do if you
are registered, or use the same terms in both statements? Also, "you must A to
B" is slightly ambiguous. You could interpret it to mean "you must A". Here's
my draft for para one.
You must register with GroupServer.org before you can
join groups, post messages, or receive email messages
from groups.
3: Password reset email text.
CURRENT TEXT
Hi Dan Randow,
We received a request to reset your password. This is done, and now
all you have to do is log in and set your new password. To do this go
to the following address
http://groupserver.org/r/password/5iGKy5fCm7D0Eo8fzXhnT5
--
GroupServer.org is powered by OnlineGroups.Net
COMMENTS
I suspect that many people will not know that 'reset' means that their old
password will no longer work. But who cares whether is will or not, as they are
likely to have forgotten it anyway.
I also suspect that many people will not get what is meant by 'This is done,'.
The receipt of a request?
The user does not have to log in to reset their password. We know that the link
logs them in, but is this the time to make that clear to them?
Let's reserve indenting for urls or email addresses. I much prefer missing a
line to indenting the first line of a para. We never use that anywhere else.
PROPOSED TEXT
Hi Dan Randow,
We received a request at GroupServer.org to reset your password.
All you have to do is set a new password. To do this go to the
following address.
http://groupserver.org/r/password/5iGKy5fCm7D0Eo8fzXhnT5
--
GroupServer.org is powered by OnlineGroups.Net
4: Error page when you follow an expired set password link.
As discussed, we suspect most people are seeing this after double-clicking the
link. This will not happen when we alter the system so that it removes the
password reset token from the database when a password is actually set, rather
than as soon as the link is clicked.
5: What happens if I don't verify my email address?
I see that you have handled this very well.
http://groupserver.org/r/post/3YizGNPQLRUpOYV5POGLNC
Effectively, if you abandon the process, you can restart it from the beginning,
perhaps having skipped the "edit profile" stage.
I have changed the registration page (requires restart) and the reset-password
email message ☺
I will look at the rest tomorrow.
On Feb 10, 2008, at 10:33 PM, Michael JasonSmith wrote:
> I have changed the registration page (requires restart) and the
> reset-password email message ☺
>
> I will look at the rest tomorrow.
Michael:
It's looking good. I don't think I was able to fill out my profile,
while waiting for my email to verify, when I tried this last week. Is
that new?
I assume so. Its a good idea, but I can see where it would create
additional opportunities for the user to interrupt the registration
process. What happens if the user spends 20 minutes filling out their
profile in detail, is interrupted and never completes the email
verification process. Will they loose their work, or will the system
keep their data.
I ask this, because after filling out my profile and hitting the
"edit" button, it took a long time before the profile edits were
accepted. While I was waiting, I verified my email. Afterwards, its
unclear to me whether or not the system was waiting for my email to
verify before accepting my profile edits. In fact, once I verified my
email, my edits were accepted, but this might have been cooincedence.
If not, then there is a chance that I might have not verified my email
at all - and lost whatever work I put into my profile (unless you've
planned for that). :-)
Best wishes,
Tim Erickson
On Feb 11, 2008, at 10:39 AM, Tim Erickson wrote:
> I ask this, because after filling out my profile and hitting the
> "edit" button, it took a long time before the profile edits were
> accepted. While I was waiting, I verified my email. Afterwards, its
> unclear to me whether or not the system was waiting for my email to
> verify before accepting my profile edits. In fact, once I verified my
> email, my edits were accepted, but this might have been cooincedence.
I tried again and see that acceptance of my profile edits is NOT
dependent upon verification of my email. Which means, that I can login
and set up a profile, without having a verified email address in the
system.
I'm not sure that there is a problem with this, as long as we prevent
anyone without a verified email address from actually posting a
message, which I assume will be the case.
Tim Erickson
Tim:
Your analysis is totally correct, having a profile is deliberately
independent of verification now. The only thing that a user will require to
be 'verified' is a verified email address, which means that that we no
longer have to maintain other special states for the user, and we can have
a *much* more polished experience.
In fact, the profile is *designed* to delay the user from checking their
email and verifying. This gives additional opportunity for it to arrive in
their inbox.
I hope the time we spent designing this new system shows!
I just took a peak:
1. "Secret" seems unnecessary, suggests inequality. Private says enough.
2. I like the correct e-mail verification web option, but is there a
reason that unlike password where you ask for it twice, that you don't
simply ask for e-mail twice up front? If someone does not yet have a
login/password if they surf away, I am not sure how the current "is this
correct" option helps.
3. Terms. What are your thoughts on adding a requirement for [ X ]
instead of just saying they agree by joining?
4. Profile verbiage. "You will be able to *fill out your profile*" ... I
wonder what else we should say here or on the profile input page to
connect this term to a "profile page." Perhaps something like this on
the profile input page, "You can edit your optional profile (a simple
page about you for other registered group participants to get to know
you), while waiting for the message to arrive in your email inbox." I
wouldn't use "Edit" for the button since you normally click that to be
taken to a page to change something not confirm changes, perhaps "Update"
5. Recommended Display Name - Doesn't it make better sense to recommend
the display name from First and Last Name than the first part of an
e-mail address. Starting with text from an e-mail doesn't have space or
proper capitalization.
6. First and Last Name - Since sorting by last name is more professional
(what I'd like to see on edem and keep on dowire), I recommend you use
those in the default profile. I am also interested in how user profile
links are permanent, stable, and intuitive (/firstlastname).
7. Login in with Display Name, First Last Name? Since old users names
seem to be diminished, it would be nice if people can login using their
display name/flastname, particularly if the existing e-mail address is
no longer active and they want to change their e-mail. Of course that
doesn't help the person who doesn't remember their password and no
longer has access to the registered e-mail. I haven't see reference to
asking "security" questions ... but we might want to consider doing it
since most users will only have one e-mail assigned and are then stuck
asking for admin support (a huge pain).
8. Verification e-mail reset: "Changed your email address from
|<email obscured>| to |<email obscured>|." I actually change my
e-mail the other direction. Check this twice.
9. I tried to click on the verify e-mail and got page not found.
10. Bio WYSIWYG - It wasn't clear what all of the fields in the pop-ups
meant.
11. Profile photo - What's the plan here?
Keep up the good work.
Tim, you are quite right that the user could abandon registration before verifying his or her email address. Dan also noticed this ☺ My (unimplemented) solution is to send the user to the Awaiting Verification page when he or she returns to the site http://groupserver.org/r/post/3YizGNPQLRUpOYV5POGLNC
Michael, On the "Edit Profile" page, "control" is misspelt in the following text. An email message has been sent to your email account, asking you to verify that you controll the address Some people will not want to complete their profile in detail while waiting to register. Should we make it clear that they will be able to edit their profile later? I really like the summary of the privacy info around profiles on that page, and the link to the privacy policy. I also have some comments about the "Verify Address" notification, but I'll make them in "Email Address Verification". http://groupserver.org/r/topic/36FHisEoV621HXYA6lPq77
On Tue, 2008-02-12 at 10:21 +1300, Michael JasonSmith wrote: > Tim, you are quite right that the user could abandon registration > before verifying his or her email address. Dan also noticed this ☺ My > (unimplemented) solution is to send the user to the Awaiting > Verification page when he or she returns to the site > http://groupserver.org/r/post/3YizGNPQLRUpOYV5POGLNC We can also remind users to verify (I think once after 3 days seems about right).
Thanks for looking at registration, Steve ☺
Secret groups do more than promote inequality, Steve, the enforce it ☺ I
am not a big fan of secret groups either, but they are quite common on
GroupServer sites, so I suggest that the text should remain on the
default registration page.
As to your second point, Steve, I do not know what “the correct e-mail
verification web option” is ☹
I thought about having
☐ I agree
on the initial registration page, but it only adds an irritation. I know
it is common to have an “I agree”, but I could not think of a circumstance
that either the site or the user is any more protected because of it.
As for the Edit Profile page that is presented during registration, it
should be connected to the user's profile more. However
* The user's profile is not optional, the user will get a profile even
if he or she does not want one!
* The page is far from simple: it contains a lot of highly structured
text, as well as dynamic search results ☺
I take your point about the Edit Profile page and its button. However, I
am against Update as the label on the submit button. The principal that I
followed is that all dialogs (which the Edit Profile page is an example)
should be named after the action that opened them, and the button should
be named after the dialog:
Action Title Button
──────────────────────────────────
Open… Open Files Open
Save As… Save As… Save
Print… Print Print
This is a very well established interface design guideline; it provides a
consistent and clear user experience. The Edit Profile page gets its name
from the Edit Profile link on the Profile page. I vacillate between Edit
and Change for the names of those pages (for example, Change Site
Introduction Text) but I am settling on Edit more and more, as I suspect
that is the keyword the user is looking for (rather than Change or
Update). I have documented the design guidelines that I am following when
creating forms
http://groupserver.org/groupserver/guidelines/form
There are two reasons for not constructing the preferred name from the
given name and family name of the user. First, GroupServer does not record
the family name or given name of the user by default. Second, we do not
want to ask for anything other than the email address on the initial
registration page. Only asking for the email on the initial registration
page allows us to send out the email as quickly as possible, and gives
greater equivalence to registration-via email, where we will not
(necessary) have a name to associate with the user.
As to using family and given names in the default profile, I am strongly
against it.
* It does not internationalise well, as the given name may not
be first, and the last name may not be the family name.
* It adds a lot of complexity, which is not worth it for most
GroupServer installations.
* It causes issues if we want to support email-only users.
As for the sanity of profile-links, the nickname will deal with this
issue.
http://groupserver.org/r/post/1KOtevr6QTbZtnO4PBMuVu
http://groupserver.org/r/post/21rz9PU01ymb2LIyz7UsDQ
I do not understand how the inactivity of an email address would effect
logging in, Steve. Could you explain more? You seem to argue yourself
around in the same paragraph that you introduced the problem ☺
Security questions are poor for security, so I am against implementing
them.
I will look at the message that is returned when the user's email address
is changed on the Awaiting Email Verification page. Thanks for the report,
Steve ☺
What do you mean when you say you clicked on “the verify e-mail”, Steve?
Did you click on the link in the verification email? Did you get a
regular Page Not Found, or the User Not Found page? Had you already
verified the email address, Steve?
Could you clarify what fields were unclear in the “Bio WYSISYG”, Steve?
My plan for the profile photo is to leave it off all the the Edit Profile
pages for now, as it complicates my server-side code too much ☹ I
would definitely like to see it on the Edit Profile page i