Priscilla asked me to write-up a workflow sketch and mock-up screens
for the Sign-up workflow. After I finished, I realized that I was
working off of 0.5 rather than qacosmo. :o/ So I was unfamiliar with
the newfangled Sign-up form in a dialog design.
http://wiki.osafoundation.org/bin/view/Journal/CosmoSignUpWorkflow
I chatted with Travis a bit on IRC about the motivation behind the
move to the dialog and a few interesting things came out.
For the log, see: http://wiki.osafoundation.org/script/
getIrcTranscript.cgi?channel=cosmo (starting at 17:05)
+ Popping up the sign-up form in a dialog is faster...and we all like
that.
+ The sign-up pop-up was put in place *before* the notion of
requiring new users to activate their account. So the workflow would
have been:
1. User types in osaf.us and is taken to the Login page
2. User has no account and clicks on 'Create new account'
3. Sign-up form pops-up in a dialog
4. User fills out the form and clicks Submit
5. Sign-up confirmation message replaces the sign-up form in the pop-up
6. User clicks Okay; and finds themselves back on the Login page
7. User logs in.
In 0.6 however, we will be introducing the notion of account
activation. Jared, is that correct? Now, the workflow will be quite a
bit different:
1. User types in osaf.us and is taken to the Login page
2. User has no account and clicks on 'Create new account'
3. Sign-up form pops-up in a dialog
4. User fills out the form and clicks Submit
5. Sign-up confirmation message replaces the sign-up form in the pop-up
6. User clicks Okay; and finds themselves back on the Login page
7. User is tempted to Login...
...Unfortunately, the user cannot log in until they go to their email
client, find an email from the nice people at osaf.us, click on the
link in the email, which will open a new browser page congratulating
them on successfully activating their account...with a link to the
Login page.
8. Now the user may proceed to Login.
In this case, we actively don't want to construct a workflow that
prematurely encourages the user to Login. We shouldn't rely on users
to have read the confirmation msg in step 5 carefully enough to know
that they have to activate the account before they can login.
I originally thought we would just move to a model where the Sign-up
page replaced the Login page, the Confirmation message replaced the
Sign-up, etc, etc...
Travis had the brilliant idea of keeping the Sign-up form in a
dialog, while removing the 'Cancel' button, thereby creating a
'forcing function' which shuttles the user away from landing on the
Login page before they've had a chance to activate their account.
Instead, the user will be presented with a link to the Login page
from the account activation page.
So, that was the long way of explaining that as far as the mock-ups
go, it looks like the user is going to new pages when they move from
Login to Sign-up to Confirmation...and then from Activation to Login.
However, under the hood, Travis will be implementing this workflow as
a series of dialogs.
Does anyone see any issues with this proposal? Missing scenarios?
Thx,
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
