Posted by webchick on February 6, 2008 at 4:34am
13 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | user interface text |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | drupal.org identity, ui-text, Usability |
Issue Summary
James is demoing OpenID now in front of the LA meetup. It is not in any way obvious that:
1. It's looking for a URL like http://walkah.myopenid.com/
2. You are going to be whisked away to some other website once you submit the form
3. What happens next.
I almost think this is worth breaking the 6.x string freeze. :\
See attached screenshot for further critique.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| openid-usability.png | 42.33 KB | Ignored: Check issue status. | None | None |
Comments
#1
Here's a first stab.
#2
I love you, Angie.
#3
"Enter an OpenID provider URL"
I think this is too wordy/long, for the label I'd just use "Your OpenID".
For the description, "Enter your full OpenID URL. What is OpenID?".
Using a default value of just one of the many many providers would be a little unfair to the rest, it could also (possibly) cause some people to think that the website only 'supports' that particular provider. So I would take out the default value and use the description text to elaborate if needed.
#4
Agreed. The example could go in the description. Also, I remember that we kind of have the policy of default values being values that can actually be used - placing an "example" here breaks that expectation.
Note: Default form values are used by some websites to indicate an example that should not actually be used. These examples are cleared dynamically on focusing the text field (and could, for graceful degradation, be added dynamically too). However, that is probably more of a feature request for the next Form API - an '#example' for text fields that will be inserted with jQuery when no '#default_value' is set, removed on focus, and colored gray. It's not worth the trouble to manually implement that kind of behavior here...
#5
#6
#7
Here's another updated patch. It does a few things:
I had wondered if we're going about this the wrong way. A dropdown allowing users to choose a provider where the URL is determined automatically might be the best solution. Choose a provider (with an API hook to allow modules to provide more), enter your username, and let Drupal figure the rest out. But, this would be beyond the scope of this issue :).
Thoughts and comments?
#8
The last submitted patch failed testing.
#9
Here is an updated patch which applies against HEAD, but the layout is now slightly broken in the user block and on /user.
#10
Changing status to "code needs review" to request test on new patch.
#11
The last submitted patch failed testing.
#12
Manually patched the failed chunks and re-rolled.
Seeing the following notice whenever the OpenID form is displayed
This is corrected by applying the the patch from comment #14 from #287178: Use hook_form_FORM_ID_alter() where possible
should I roll that in as well?
#13
I'm also receiving the following notices when logging in using OpenID for the first time
* Notice: Undefined index: values in openid_form_user_register_alter() (line 148 of /Applications/MAMP/htdocs/drupal-head/modules/openid/openid.module).
* Notice: Undefined index: values in openid_form_user_register_alter() (line 149 of /Applications/MAMP/htdocs/drupal-head/modules/openid/openid.module).
* Notice: Undefined index: values in openid_form_user_register_alter() (line 156 of /Applications/MAMP/htdocs/drupal-head/modules/openid/openid.module).
which are covered here #230934: Undefined index when creating account via OpenID
#14
Updated patch with CSS fix for OpenID logo & changed form weights so the fieldset always shows below the OpenID login link.
#15
I've attached samples of what #1 would look like.
#16
The last submitted patch failed testing.
#17
I like the changes suggested in #15. Here's an updated patch which implements them. I'm also tagging this issue for the redesign as AFAIK the results of this will eventually be exposed on d.o as it's going to use OpenID for logins on subsites.
#18
I do not think, what is openID should be displayed on a normal login box, rather it should be displayed when one chooses the openID login method (Login using openID).
#19
Looks like the last patch wasn't tested, so sending it to the testbot.
#20
Personally, I'm not sure this help text should be inline and part of every page. That feels a little heavy.
#21
The last submitted patch failed testing.
#22
Also linked from the Redesign project #661708: Meta issue for misc modules: Drupal, OpenID Provider and API because this issue was tagged 'drupal.org redesign'
#23
tagging
#24
This is not critical. We obviously shipped D6 with totally non-sensical help text for OpenID. ;)
#25
subscribing
#26
Not part of the d.o redesign.
#27
#17: 218323_openid_help_text_12.patch queued for re-testing.
#28
talked to webchick, and it's too late to do this for d7, bumping to d8 and marking needs work...