ChiliProject is not maintained anymore. Please be advised that there will be no more updates.
We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.
OpenID : Proposal -- Features, Use-Cases, & Screen Flow -- for Better Intuition & Guidance (Feature #985)
Description
Hi,
Here are a few suggestions below that may be implemented one-by-one. My base observation is with the redmine-openid-selector installed. The proposed suggestions below come from short-comings in the coherence of the concurrent OpenID and user/login system; a concurrence necessary to maintain. but intelligently (example: the lay user should not have a moment's doubt about the password given as the Chili one or the OpenID one).
Context¶
There are two scenarios:
- Sign in by Login / Password (SLP)
- Sign in by OpenID (SOID)
There is also the necessary eventuality of registration:
- Registration by Login / Password (RLP)
- Registration by OpenID (ROID) that could have the same initial screen as SOID
Proposition of Features & Ergonomics¶
Modified Ergonomic /login Screen that Guides¶
Unique /login screen proposes the following (perhaps by DIVs of which only one is visible at any time):
Choice:- Login / Password
- OpenID
On choosing, one of the 2 Forms is present
Variant¶
Offer a third choice "Both Chili Login / Password, and OpenID."
Choice of Login / Password¶
On the screen is shown:
- perhaps on the left, just a login and a password window (no open ID)
- perhaps on the right, just a link to the login page (If registration activated)
Choice of OpenID¶
On the screen is shown the OpenID Selector, but nothing else.
Variant on Choice of OpenID¶
A link can render visible a field for the login.
A link can render visible a field for the email.
If the login or the email (priority to email) are entered, then this OpenID may be associated to this existing account. Password or email verification only on successful OpenID passage. If account does not exist by email or by login, then login and/or email are pre-populated in /account/registration if registration is activated.
Variant Choice of Both Chili Login / Password, and OpenID¶
The current screen stands, but if the login / password are correct, the the OpenID URL is reinitialized.
Continuation of Variant¶
Should the email be taken, a registration screen only asks for the password associated with the username of that email to reinitialize the URL. Now the person may not, in that case, remember his or her password. The "email already used" screen should send an email allowing the continuation of the modification of the link (or at least proposition of existing password reminder).
Special Case¶
Multiple OpenIDs
Change of OpenID
Tests¶
- User with correct OpenID URL logs in.
- User with correct Login / Password logs in.
- User with new OpenID URL logs in and is sent to register screen without existing account.
- User with new OpenID URL logs in and is sent to register screen with existing account (variant: email taken from OpenID).
History
Updated by Christopher Mann at 2012-04-13 10:50 am
Afterthought: Abstract OpenID to allow room for Facebook login.
Updated by Christopher Mann at 2012-04-13 11:26 am
These ergonomics look easier to implement as a first stage:
https://community.webfaction.com/account/signin/
Based on OSQA