Improve login workflow when trying to access a protected post while not logged in (esp. w/OpenID).

[jtspender]

Title:
Improve login workflow when trying to access a protected post while not logged in (esp. w/OpenID).

Area:
login

Summary:
When trying to access a protected post (http://[username].dreamwidth.org/[post id].html), go to http://www.dreamwidth.org/login instead of http://www.dreamwidth.org/. Display an appropriate error message on the page. Include the openid login box from http://www.dreamwidth.org/openid/ directly on http://www.dreamwidth.org/login. And make sure that at the end of either login path you can easily get to the protected post you were trying to get to in the first place (http://[username].dreamwidth.org/[post id].html).

Description:
Disclaimer: While I've been watching the Dreamwidth project for a while I'm just now making the move here from LJ, so I mostly only have experience with this from the LJ/external-site side. While I'm happy to do a bunch of work setting crossposting and other things up on my side, I'm trying to make things as seamless as possible for the people who are still reading my stuff on LJ, and this is the one big thing I wish worked better.


I suspect that one of the first direct exposures many folks have to the Dreamwidth site is clicking through the link at the bottom of a crossposted post to comment directly on the original DW post. As has been mentioned in a number of different arenas this is currently more difficult than it needs to be, especially when trying to login via OpenID to comment on a protected post. This suggestion includes some ideas on how to fix some of those issues.

There are a couple other somewhat related bugs/suggested posted by others that I was able to find. I've listed them at the end of this post, but I think this suggestion has a different focus than they do. Technically this suggestion encompasses a few different items, some of which could be considered separately, but which I think make the most sense considered together.

Anyway, here's the existing workflow:

1) User follows a link to a protected post http://[username].dreamwidth.org/[post id].html
2) Browser is redirected to the home page (http://www.dreamwidth.org). No error message is displayed. (The actual URL does have ?returnto=[protected post URL]&errmsg=notloggedin parameters so it looks like there were originally some error handling here, and LJ does display an error box on the homepage telling the user to login using the box in the navigation bar.)

Things diverge here depending on whether the user is trying to log in via a DW account or OpenID:

If using a DW account:
3) If the user figures out that the problem is that they are not logged in, and logs in via the box in the navigation bar, they are redirected to their original destination and they're done.

If using OpenID:
3) User needs to click on the "Log in with OpenID?" link which leads to http://www.dreamwidth.org/openid/.
4) User types in OpenID URL and clicks login button.
5) Various authentication processes may or may not happen on the OpenID server site.
6) User is logged in and ends up back at http://www.dreamwidth.org/login. This is pretty much the end of the line.


Here are the main issues I see with the workflow:

a) The initial redirect to http://www.dreamwidth.org after step 1 seems an odd choice. There's a lot of text on the home page which is totally unrelated to what the user was actually trying to do, which may especially confuse folks coming from a crossposted entry on another journal site.

b) The lack of an error message after step 1 makes it unclear what went wrong and why the user isn't at the page they expected to be at (the protected post).

c) http://www.dreamwidth.org/openid/ is a great page information-wise, but it's an unnecessary jump with a bunch of extraneous text once you know what you're doing and all you really need is the OpenID login box.

d) Once you do login using OpenID at step 6, you end up stranded at http://www.dreamwidth.org/login with no way to get to the protected post you were originally trying to see without mashing back multiple times or reloading whatever page linked to it.


I suggest the following changes:

i) When a user tries to access a protected page while not logged in, redirect to http://www.dreamwidth.org/login instead of the homepage.

I think it's a pretty safe assumption that the vast majority of the people who hit the redirect just want to log in so they can see the page (or possibly make an account, which you can also do from the login page). There isn't much on the current login page so it *is* kind of redundant with the navigation bar right there, but that's probably okay since this *is* something you're reaching in an error condition and it is probably less confusing than going to the home page.

ii) Whichever page the user is redirected to should include an error message explaining what happened. (I'm guessing the lack of an error message on the home page was just an oversight from when you overhauled that page.)

iii) Include the OpenID login box from http://www.dreamwidth.org/openid/ on
http://www.dreamwidth.org/login. You could either just sneak the box in there, or you could restructure the page a little bit. I know from reading the comments on some of the other OpenID suggestions that non-members often get confused and try to login with their name/password from other sites in the normal box. Maybe putting things side-by-side might make it a little more obvious? Something like:

Left side: "Dreamwidth Members:", and the normal login form
then some kind of vertical separator, then
Right side: "Not a Dreamwidth Studios member?" and present the two alternatives of using the OpenID box (with a link to more info) or the create an account button.

On the downside, this may clutter up the login page a bit more. And there is something to be said for forcing people to go to the current http://www.dreamwidth.org/openid/ page since it does explain things well. But people who are just trying to comment on an entry might not want to have to care.

iv) Once the user logs in via OpenID, they should be able to get to the post they were originally trying to get to. It probably makes sense for this to be a straight-up redirect to keep parity with logging in using a DW account. Alternatively, this could continue to go to the logged-in version of the login page, and under the list "From here you can:" one option could be "Read the protected post you were trying to access" or something like that.

v) Include the "Remember me" checkbox anywhere the OpenID login box appears the same way it shows up everywhere the DW login boxes appear.


Related suggestions/bugs:

http://dw-suggestions.dreamwidth.org/310059.html - A request to make it more obvious how to get to the OpenID login page. I suspect some but not all of the desire for this may be LJ folks following this workflow and getting stuck at step 2.

http://dw-suggestions.dreamwidth.org/269907.html - Another suggestion for making it easier to login/comment when coming from crossposted entries. The discussion in this suggestion took a slightly different tack, focusing a little more on the difficulty of figuring out how to get folks successfully from their LJ (or other service) username to the correct OpenID URL and such. Some of the ideas there are complementary to this suggestion (other methods for entering site/username info to get an OpenID might replace the OpenID box on the login page) while others might make these suggestions less important (putting something directly on crossposted posts to make it easier to login via OpenID and jump directly to the original post, which is sort of the whole point of the changes to the login page).

http://bugs.dwscoalition.org/show_bug.cgi?id=645 - Related bug. It's possible that this is actually referring to the problem I'm making the suggestion for, but I took it to mean logging in using "(OpenID?)" link on the mini navigation bar (navigation strip?) that you see at the top of a journal page. Either way the issues are related and are probably worth solving at the same time.

Poll #3092 Improve login workflow when trying to access a protected post while not logged in (esp. w/OpenID).

Open to: Registered Users, detailed results viewable to: All, participants: 43

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
40 (93.0%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (7.0%)

(Other: please comment)
0 (0.0%)

Choose whether timestamp of entry is taken from email header or from time set for journal

[draconic_voices]

Title:
Choose whether timestamp of entry is taken from email header or from time set for journal

Area:
posting by email

Summary:
Add an option under the mobile settings page of account settings where the journal owner can choose whether to timestamp email entries with the time that they are posted to the journal or the time that the email is sent

Description:
Dreamwidth recently changed the posting by email setup so that the timestamp on the post reflects the time that the email was sent at, which is taken from the email header (as per http://dw-suggestions.dreamwidth.org/147571.html). However, a problem arises if the server that the email is sent from is in a different time zone from the time zone set for the journal. The entry is timestamped with whatever time it is in the time zone that the server is in. If that server is in a timezone ahead of the one that the journal is set for, any other attempts to post from email from the same timezone as the one the journal is in encounter a date-out-of-order error.

This is particularly a problem if you are using an automated journal posting client such as loudtwitter whose server is set at EST+4, making it impossible to post by email until four hours after loudtwitter posts if you are in the EST timezone and longer if you are anywhere West of it.

The original post by email set up used the time that entries posted to the journal as their timestamp. Would it be possible to add an option to the mobile settings page to allow users to choose whether to use the time posted or the time the email was sent as their timestamp?

Poll #3091 Choose whether timestamp of entry is taken from email header or from time set for journal

Open to: Registered Users, detailed results viewable to: All, participants: 35

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
19 (54.3%)

Should be implemented with changes. (please comment)
2 (5.7%)

Shouldn't be implemented.
2 (5.7%)

(I have no opinion)
12 (34.3%)

(Other: please comment)
0 (0.0%)

Easier sysban modification

[pauamma]

Title:
Easier sysban modification

Area:
spamfighting, maybe TOS

Summary:
When querying whether a single IP address (or whatever) is sysbanned for a given sysban type, the sysbans for that address (or at least those you can set) should be modifiable, not readonly.

Description:
That would avoid needing to load the ginormous page listing all sysbans of a (single) type you can modify, which (for the sysbans spamwhackers use) make the browser sluggish at best (and usually unresponsive) for a few minutes.

In addition, seeing all sysbans you have access to and letting you modify them would make it possible to take cross-type decisions. (not just easier - currently, you need to load the aforementioned ginormous page once per type, which doesn't scale at all).

Poll #3090 Easier sysban modification

Open to: Registered Users, detailed results viewable to: All, participants: 26

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
6 (23.1%)

Should be implemented with changes. (please comment)
0 (0.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (76.9%)

(Other: please comment)
0 (0.0%)