### Improve OpenID claiming

03:07 am

Title:
Improve OpenID claiming

Area:
OpenID

Summary:
Claiming your OpenID may help with future imports that bring over your comments, but there are other areas it does not cover.

Description:
We have a mechanism where a DW user can "claim" an OpenID identity (e.g., an LJ account that has been used to post comments elsewhere on DW). That records the claim in a table and kicks off a job to change ownership of all the OpenID identity's previous posts. Thereafter, if an import of some other journal is going to bring over comments owned by that user on the remote site (which would normally be shown using their OpenID identity), ownership is changed to reflect the DW user during the import. However: - I don't think the claim relationship is shown anywhere in the DW profile or metadata for the OpenID userid. Perhaps the profile for that userid should just redirect to the claimant anyway, like a renamed user. - I think it's still possible for the user to log in and comment using OpenID, and then those new comments cannot be changed over to the DW user because that OpenID identity is already claimed. Like the importer, comment posting probably ought to check claimed_by first. - We don't update the circles of everyone who has trusted the OpenID identity. This could probably be done in the same worker that changes ownership of posts. These things are probably all unexpected behavior if you're migrating from another site to DW. Thoughts?

Poll #17823 Improve OpenID claiming
Open to: Registered Users, detailed results viewable to: All, participants: 17

This suggestion:

Should be implemented as-is.
8 (47.1%)

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

Shouldn't be implemented.
1 (5.9%)

(I have no opinion)
8 (47.1%)

0 (0.0%)

11:26 am

Title:

Area:
openID (sort of)

Summary:

Description:
A lot of my readers these days don't come from LJ or Dreamwidth, may not have an OpenID, or even if they do have one (most likely Google) don't know what an OpenID is. But most of them have a Twitter account. It would be nice if Twitter OAuth could be used as an identity for commenting. Possibly other OAuth providers too.

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

This suggestion:

Should be implemented as-is.
30 (65.2%)

Should be implemented with changes. (please comment)
7 (15.2%)

Shouldn't be implemented.
3 (6.5%)

(I have no opinion)
6 (13.0%)

0 (0.0%)

### Add ability to link OpenID account to DW account during content imports from other sites

12:40 am

Title:
Add ability to link OpenID account to DW account during content imports from other sites

Area:
site: openid, workflow: importer, and maybe site: usability

Summary:
Subsuming your OpenID while importing content created by the OpenID's account (such as associating the OpenID of Username@Livejournal while importing Username's journal contents from Livejournal) seems a very logical thing. Suggest there be an option on the Import Content page, which is easily reachable in the larger DW-sitescheme header, to do that in the course of importing content, or at least a link to the page for associating the OpenID, with a blurb explaining what it's for. To an end user, these two processes look to be rather closely related, so to have them obviously linked seems neatly intuitive.

Description:
I imported an account from LiveJournal a while ago and checked an entry's page, only to finally realize that comments made by that account, while it was on LJ, to its own posts... did not register as belonging to the new account on Dreamwidth, although the entries in the journal correctly said that they belonged to the DW account.

I realize that importing content from a non-DW journal to a DW journal and claiming ownership of that non-DW journal's comments are two separate things, but they feel as though they should go together somehow.

I can see two ways of doing this quite neatly, and in a way that makes things clear to the new user. The first would be to include a note on the Import Content page stating that "importing the comments on a journal's entries does not claim ownership of the journal's own comments, but this tool can take care of that for you: (and a link to the appropriate page for subsuming your OpenID accounts)" or something to that effect.

The other way, which I suspect would be more work, but still end up pleasing many users, would be to combine the two pages, so that you could take care of both tasks at once, if you wanted. There's all sorts of options for what to import, exactly, and you already need to enter your username and password, and specify which site to import from. Taking ownership of that account's comments, especially on its own pages, seems a logical and intuitive part of the process, to me.

If the second idea is gone for, still having a note and link like the first idea, in the Import pages (and it being pointed out that taking ownership of the OpenID account works for all OpenID sites, whereas importing the content only currently works for LiveJournal and InsaneJounral, would be great too) would be very handy, especially as it isn't linked directly in the header navigation, while Import Content is.

Poll #14591 Add ability to link OpenID account to DW account during content imports from other sites
Open to: Registered Users, detailed results viewable to: All, participants: 26

This suggestion:

Should be implemented as-is.
16 (61.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (34.6%)

1 (3.8%)

### On the system default footer for crossposts, make the word OpenID a link to information about OpenID

12:53 am

Title:
On the system default footer for crossposts, make the word OpenID a link to information about OpenID

Area:
crossposting

Summary:
According to http://www.dreamwidth.org/manage/settings/?cat=othersites the current default footer for crossposted entries is
<span style="font-size: smaller;">This entry was originally posted at <a href = "%%url%%">%%url%%</a>. Please comment there using OpenID.</span>".

I suggest changing it to
<span style="font-size: smaller;">This entry was originally posted at <a href = "%%url%%">%%url%%</a>. Please comment there using <a href="http://www.dreamwidth.org/openid/">OpenID</a>.</span>

Description:
I believe that many people, particularly users of LiveJournal who don't try to use their LJ as their main cross-site "internet identity", may not understand that the phrase "Please comment there using OpenID" at the end of a crossposted DW post using the default footer means they are likely to be able to comment on that post at Dreamwidth without creating a DW account by using their LiveJournal account via OpenID. They may not have any idea what OpenID is or that they already have one (or several) OpenID identities that they can use with minimal hassle. I base this assumption on the fact that I've had reasonably clueful LJ friends post anonymously to my DW posts and "sign" them in the body or subject line with their LJ identity rather than post them using OpenID (based on the type of comments, this is not a situation where it's likely someone is impersonating someone else).

Turning the word OpenID in the footer into a link to http://www.dreamwidth.org/openid/ would give readers a way to find out more about what OpenID is (and a place to log in using it) without cluttering up the footer with additional explanatory text. I am making the assumption that the amount of detail to include in the system default footer has been previously considered and that it's been decided not to include a lengthier explanation of OpenID in the text of the footer itself (I can see arguments both for and against this).

Note: I have no idea what the system default footer crosspost text actually is right now. I've changed mine around several times and am assuming the text at the bottom of http://www.dreamwidth.org/manage/settings/?cat=othersites is accurate. If it's not, I have an additional suggestion of updating that page to accurately reflect whatever the system default footer currently is, ideally by pulling the correct string automatically if this is not currently done.

Poll #12914 On the system default footer for crossposts, make the word OpenID a link to information about OpenID
Open to: Registered Users, detailed results viewable to: All, participants: 55

This suggestion:

Should be implemented as-is.
41 (74.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (25.5%)

0 (0.0%)

### Aggregate External Identities (like OpenID)

02:15 am

Title:
Aggregate External Identities (like OpenID)

Area:
profile

Summary:
A list of OpenID identities to be shown on my profile page.

Description:
I have a lot of OpenID identities across the internet. I do not have a place to put this information where it can be authenticated appropriately.
Ideally, this information would be displayed on my profile page, with degrees of privacy settings.

I trust Dreamwidth with this information. Not all users will. Your mileage may vary. People should be informed about what this trust entails.

Poll #11692 Aggregate External Identities (like OpenID)
Open to: Registered Users, detailed results viewable to: All, participants: 45

This suggestion:

Should be implemented as-is.
16 (35.6%)

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

Shouldn't be implemented.
7 (15.6%)

(I have no opinion)
21 (46.7%)

1 (2.2%)

### Option to show "originally posted as" on imported entries and comments

02:18 pm

Title:
Option to show "originally posted as" on imported entries and comments

Area:

Summary:
Expose "originally posted as" on imported entries and comments, as an option that can be added to styles if desired.

Description:
Some users would like to be able to see where a comment or entry has been imported from, if they are importing from several locations or different names, or wish to display the history in full on Dreamwidth. Other users would prefer to keep the current display. I propose that the importer is updated to preserve the username and site/OpenID name at the time of import, so that this information is available to style designers, who can then create styles with it displayed, or add it to their styles as an option for those who want to show it on their journals. For previously imported entries where the original import site has not been saved, this would display something like "Originally posted as: information not available".

Poll #9857 Option to show "originally posted as" on imported entries and comments
Open to: Registered Users, detailed results viewable to: All, participants: 63

This suggestion:

Should be implemented as-is.
22 (34.9%)

Should be implemented with changes. (please comment)
10 (15.9%)

Shouldn't be implemented.
7 (11.1%)

(I have no opinion)
24 (38.1%)

0 (0.0%)

### Send inbox notification to new OpenID accounts upon comment or entry importation

10:42 am

Title:
Send inbox notification to new OpenID accounts upon comment or entry importation

Area:
inbox, importer

Summary:
When the importer imports a comment, it should leave a notification in the inbox of the associated OpenID account stating "A comment you left at {original site} has been imported to {Dreamwidth journal/community name}."
When the importer imports an entry from a community import, it should leave a notification in the inbox of the associated OpenID account stating "An entry you wrote in {original community} has been imported to {Dreamwidth community name}.

Description:
Currently OpenID accounts have very little ability to find comments, and soon entries, that have been imported to Dreamwidth. The Recent Comments page only goes back 10 comments, and deleting one of those comments doesn't let another one slide in at the back of the list. Currently the search by poster function [http://foo.dreamwidth.org/?poster=] doesn't work for OpenID accounts, not by using the displayed name {bar.livejournal.com} nor by using the internal name {ext_###}. Unfortunately, it's too database heavy to try and search for all comments and entries an account made anywhere that isn't their journal, so my idea is to give the user a place to start looking themselves.

When the importer imports a journal or community, it should leave a notice in the Dreamwidth inbox of the OpenID account that's been created (or added to) stating what action just happened. It only needs to leave one notification per import.

Under this idea, a user from LiveJournal would log into Dreamwidth for the first time using their OpenID credentials and find an inbox with several notices already waiting for them, like this:

"Comment imported to {Journal A}"
- A comment you left in {Imported journal's original address} has been imported to {Journal A}
"Entry imported to {Community B}"
"Comment imported to {Community B}"
"Comment imported to {Journal C}"

Edit: It's one message per import, not one message per comment/entry.  If you count the community and comment import as a single job, it's up to two message per import.
For example, say somebody decides to import to DW. In my OpenID account's inbox I'd get one notification saying that an entry or entries I posted there had been imported to DW. I'd get another notification saying that comments I had left there had been imported to DW. And that's it.

Upsides: OpenID users feel more in control of imported content.
Downsides: Will probably slow down the importer.

Poll #9001 Send inbox notification to new OpenID accounts upon comment or entry importation
Open to: Registered Users, detailed results viewable to: All, participants: 59

This suggestion:

Should be implemented as-is.
18 (30.5%)

Should be implemented with changes. (please comment)
11 (18.6%)

Shouldn't be implemented.
5 (8.5%)

(I have no opinion)
25 (42.4%)

0 (0.0%)

### Make ?poster= work for OpenID accounts.

07:43 pm

Title:
Make ?poster= work for OpenID accounts.

Area:
Communities

Summary:
With community importing on the way, the ability to search communities by poster should be extended to work for OpenID accounts as well.

Description:
Currently, you can search communities by poster with the URL format http://foo.dreamwidth.org?poster=bar (so, for example, http://dw-suggestions.dreamwidth.org?poster=denise). This doesn't work for OpenID accounts, as I found when testing it out in scans_daily, one of the few communities that has already had entries imported. The URL format http://foo.dreamwidth.org?poster=bar.livejournal.com (or .insanejournal.com, etc.) should also work for searching communities.

Poll #8902 Make ?poster= work for OpenID accounts.
Open to: Registered Users, detailed results viewable to: All, participants: 86

This suggestion:

Should be implemented as-is.
71 (82.6%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (17.4%)

0 (0.0%)

### Prevent OpenID from cluttering up the Subscribers list

05:58 pm

Title:
Prevent OpenID from cluttering up the Subscribers list

Area:
profile

Summary:
OpenIDs should be separated from the rest of the usernames and start on a new line in Subscribers just as in Gives Access To.

Description:
I love having the OpenIDs in a block all by themselves underneath the rest of the usernames in Gives Access To. It makes looking through the list so much easier. Suprisingly enough (to me at least) the same wasn't done for the Subscriber list. In my experience the Subscribers list can often be even more in need of de-cluttering than the Gives Access To list. So I suggest that the same separation between DW usernames and OpenIDs that's been done for Gives Access To should also be done for the Subscribers list.

Poll #8856 Prevent OpenID from cluttering up the Subscribers list
Open to: Registered Users, detailed results viewable to: All, participants: 71

This suggestion:

Should be implemented as-is.
50 (70.4%)

Should be implemented with changes. (please comment)
6 (8.5%)

Shouldn't be implemented.
1 (1.4%)

(I have no opinion)
12 (16.9%)

2 (2.8%)

### Improve UI for commenting when not logged in

10:22 pm

Title:
Improve UI for commenting when not logged in

Area:
entries

Summary:
Users who are not familiar with Dreamwidth may not realize they can post comments on public posts in journals that have anonymous commenting disabled but OpenID enabled. I suggest improving the text that's part of the comment area.

Description:
I have anonymous commenting disabled on my journal, but have OpenID commenting enabled. If someone isn't familiar with DW and follows a link to one of my public posts, and they want to comment, what they see is a grayed-out "anonymous" radio button option and a grayed-out "OpenID" radio button, with the text "OpenID commenting on this post is limited. Please sign in here." To someone who is reading quickly, I don't think that text conveys the message "You can post a comment here using credentials you already have." Indeed, I had someone think that they couldn't comment on my blog without buying a DW account.

I suggest changing the text that appears when non-logged-in users view the comment areas on public entries to say "You can comment here without creating a Dreamwidth account, using OpenID", with a link to an explanation of OpenID. I'd welcome any comments as to how to make that text even more user-friendly -- I just know it's not good enough as is.

Poll #5110 Improve UI for commenting when not logged in
Open to: Registered Users, detailed results viewable to: All, participants: 38

This suggestion:

Should be implemented as-is.
28 (73.7%)

Should be implemented with changes. (please comment)
8 (21.1%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (5.3%)

0 (0.0%)

### Selector box for popular OpenID providers

03:02 pm

Title:
Selector box for popular OpenID providers

Area:
OpenID, user interface

Summary:
In the OpenID account creation process, and possibly also the OpenID login process, include suggestions of popular OpenID providers. A common form of this is a box with the icons and names of popular providers. The user picks one, it fills in the format of that site's OpenID URL, and the user fills in their username there. Then validation proceeds as normal.

Description:
If you don't know what OpenID is, it's easier to pick from a list of suggestions a provider that you have, rather than going through places you've got accounts with and trying to see whether any of them might have OpenID. It seems to be a common plugin for WordPress and wikis.

We might want to customize it by researching which other OpenID providers our existing users use themselves and have friends at, and having those added or moved into prominence -- or perhaps make sure that every place that someone can import a journal from is visible there.

Poll #4953 Selector box for popular OpenID providers
Open to: Registered Users, detailed results viewable to: All, participants: 57

This suggestion:

Should be implemented as-is.
39 (68.4%)

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

Shouldn't be implemented.
3 (5.3%)

(I have no opinion)
13 (22.8%)

0 (0.0%)

### User-level control for allowed OpenID/other external identity provider sources

04:25 pm

Title:
User-level control for allowed OpenID/other external identity provider sources

Area:

Summary:
Occasionally there is an external identity provider that makes any given user want to flee screaming; might be useful to allow that user to deny comments from external users from that source. Like, say, Facebook.

Description:
Dreamwidth doesn't (yet) have Facebook integration, but LiveJournal does. The future of the web seems to be going in an "everybody talks to everybody" sort of direction. The word on the street is that Facebook Connect is eventually going to be converted into OpenID 3.0, and eventually Dreamwidth will wind up with OpenID 3.0, and then the matter of "Will Dreamwidth really really allow Facebook users (with the site's policy about legal names and the related high potential for privacy shenanigans) to comment in my (likely pseudonymous) journal?!?" will be moot.

With Dreamwidth's commitment to openness, it would not make sense for Dreamwidth as a whole to deny users from any one given site the chance to log in and play along, unless that source were a complete pit from whence only spam and blatantly-illegal-in-the-US material emerged.

However, Dreamwidth also has a thing about control; would it make sense for Dreamwidth to allow users to create either a blacklist or a whitelist (or both, with any not specified screened before display) of external ID providers?

One can, of course, already add any given user to one's Circle; presence on someone's access list ought to exempt commenters in personal journals from certain anti-spam, anti-abuse control measures if it doesn't already. One can ban any given user. However, if one wants to exclude one entire broad class of offsite users, one has to bring out the laser cannon to use as a flyswatter, and deny commenting to all but those on the access list. This is easy to explain to someone who's just tried to comment but can't (user only allows comments from this specific list of registered users), but not necessarily fair to the journal owner if they would like to have more permissive comment settings but for whatever reason do not want comments from that source. (I so often see these things framed as "not fair to the people who would like to comment but can't", but I'm tired of that argument.)

It would mean telling users who tried to comment "You cannot comment to $USER's journal because$USER does not allow comments from \$LOCATION OpenID accounts (here's how to get a real account, or you can try another OpenID provider)", which is not really friendly. It would mean disallowing a broad class of identified people based on the site they choose to come from. But it would also mean more control for journal owners in their own space.

Poll #4519 User-level control for allowed OpenID/other external identity provider sources
Open to: Registered Users, detailed results viewable to: All, participants: 74

This suggestion:

Should be implemented as-is.
31 (41.9%)

Should be implemented with changes. (please comment)
3 (4.1%)

Shouldn't be implemented.
25 (33.8%)

(I have no opinion)
14 (18.9%)

1 (1.4%)

### Make returnto work from the OpenID login page

03:35 am

Title:
Make returnto work from the OpenID login page

Area:
Logging in, OpenID

Summary:
If redirected to the login page, a DW user will get returned to their original position after logging in, OpenID users won't. They should be treated in the same way as normal users as much as is possible.

Description:
If someone logs in from the OpenID page with a returnto URL, they'll get redirected to that locale if they're a DW user. But if they use the OpenID login box, they'll instead get directed to the 'welcome back' page.

This is, in normal circumstances, good, as we want to ensure OpenID users get the full site experience. But it's bad if they've been directed there for a reason, such as inadvertent logging out or for a poll. If you've not encountered returnto working properly, and want to see it, logout, then follow this link:
http://www.dreamwidth.org/openid/?returnto=/users/miss_s_b/1087048.html (that's the link I'm working on, it can work on any site site page). It's a useful feature that improves workflow, and should work for OpenID users.

Drawbacks: New openID users won't see the welcome message, or get prompted to validate their email, this could be fixed by an interstitial, a popup, or similar if considered important enough. Advantage: improved UX for new users, makes site less offputting and encourages engagement.

If comment boxes and polls can have an OpenID AJAX login that keeps the user on the page itself, this suggestion might be considered redundant, but given OpenID users can use many site functions, I think it's still useful.

Poll #4090 Make returnto work from the OpenID login page
Open to: Registered Users, detailed results viewable to: All, participants: 34

This suggestion:

Should be implemented as-is.
24 (70.6%)

Should be implemented with changes. (please comment)
4 (11.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (14.7%)

1 (2.9%)

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

05:18 pm

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

Area:

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:

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:
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

This suggestion:

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%)

0 (0.0%)

### Prevent OpenID relationships from cluttering profile pages

07:33 pm

Title:
Prevent OpenID relationships from cluttering profile pages

Area:
profile page

Summary:
On profile pages, relationships with DreamWidth accounts should stand out from those with OpenID accounts.

Description:
OpenID accounts that are given access tend to drown out actual DreamWidth accounts on the profile pages of people who used the import tool.

I suggest displaying DreamWidth accounts first, then OpenID accounts grouped by site, using the compact style — <user site="www.site.com" name="username" /> — for known sites.

Poll #2871 Prevent OpenID relationships from cluttering profile pages
Open to: Registered Users, detailed results viewable to: All, participants: 66

This suggestion:

Should be implemented as-is.
15 (22.7%)

Should be implemented with changes. (please comment)
40 (60.6%)

Shouldn't be implemented.
4 (6.1%)

(I have no opinion)
7 (10.6%)

0 (0.0%)

### Make OpenID creation/login screen more obvious

05:56 pm

Title:
Make OpenID creation/login screen more obvious

Area:

Summary:
It's not obvious to people coming from LJ or elsewhere how they can create an OpenID on the site; I think this needs to be a separate link on the front page.

Description:
There are currently two methods of getting to the OpenID creation/login screen from the front page:

Of these two, only the last link in the first option makes it clear that this is the same place to create an OpenID account and where you log in from. Everything else merely says "Log in", which while technically correct, might put off people who want to *create* their account first - not realising that the two are the same operation. Also, the first path requires three clicks and lots of reading.

As such, I think a new link is needed on the front page for "Create/log in to an OpenID account", maybe in the "Join Dreamwidth" section (although maybe that's too long?). It should probably also be linked from the Create Account page in case people look there directly.

Poll #2787 Make OpenID creation/login screen more obvious
Open to: Registered Users, detailed results viewable to: All, participants: 43

This suggestion:

Should be implemented as-is.
32 (74.4%)

Should be implemented with changes. (please comment)
4 (9.3%)

Shouldn't be implemented.
1 (2.3%)

(I have no opinion)
6 (14.0%)

0 (0.0%)

### Allow OpenID users to post to communities

10:40 pm

Title:
Allow OpenID users to post to communities

Area:
communities

Summary:
OpenID lets you have a single digital identity that follows you everywhere ... except to DW comms. Maybe we should fix that?

Description:
Right now we let people from other sites leave comments that are authenticated using OpenID. We don't let them post entries, though, which makes sense; if people are using an OpenID, then they have a journal or other site elsewhere. We don't need to give them their own, and we can't afford to, either. That's why we have the invite codes.

As it stands, though, people from other sites still can't participate fully on Dreamwidth. This is because the "no posting" rule applies to comms, too, thus making our comms communites of Dreamwidth members only.

If that's the intent, then this is a feature and not a bug. It makes it awfully hard to get conversations going though, because right now our limited membership means that a lot of comms are failing to reach critical mass. Plus, some members might <em>want</em> their communities to be open to outsiders, such as friends who don't have or don't want Dreamwidth accounts.

Personally, I chose Dreamwidth to host the community for <a href="http://becomeyourfursona.com">my and my mate's site</a>, <user name=becomeyourfursona>, because we both use Dreamwidth and our target audience includes a ton of Dreamwidth and LiveJournal users. It seemed more sensible to create a comm than to make a forum, with separate identities and siloed data. If this suggestion is totally against the intent of what should be allowed, though, we may have to reconsider that.

If this idea is implemented, I suggest just making it automatic for any comm that allows OpenID users to join and to comment. (I don't suggest doing the same for anon users, though.)

Poll #2559 Allow OpenID users to post to communities
Open to: Registered Users, detailed results viewable to: All, participants: 67

This suggestion:

Should be implemented as-is.
21 (31.3%)

Should be implemented with changes. (please comment)
4 (6.0%)

Shouldn't be implemented.
34 (50.7%)

(I have no opinion)
8 (11.9%)

0 (0.0%)

### html and OpenID

11:52 pm

Title:
html and OpenID

Area:
OpenID

Summary:
I think you're going to develop a more receptive user base if you give OpenID folks the ability to use html in comments.

Description:
I recently had some OpenID folks expressing unhappiness with their inability to use html in a thread in my journal. I've already met with quite a bit of resistance to my decision to switch to dreamwidth from livejournal, and I suspect that others are meeting with similar resistance. I don't know whether OpenID is handled differently when posting to paid accounts (I do have a second account that is paid but have not done much with it so far). I think that at minimum you should try to fix this for paid account users, but will do best to elliminate the problem entirely.

Note: I chose not to report this as a bug because I don't know whether it was a deliberate design decision.

Poll #1690 html and OpenID
Open to: Registered Users, detailed results viewable to: All, participants: 42

This suggestion:

Should be implemented as-is.
13 (31.0%)

Should be implemented with changes. (please comment)
15 (35.7%)

Shouldn't be implemented.
11 (26.2%)

(I have no opinion)
2 (4.8%)

1 (2.4%)

### Ban page accepts OpenID url account name as account to ban

03:12 pm

Title:
Ban page accepts OpenID url account name as account to ban

Area:

Summary:
http://www.dreamwidth.org/manage/banusers only accepts the ext_#### form of an OpenID account as an account to ban. It should also except the url name (e.g. example.net) as an account name.

Description:
We've had a couple of support requests and a suggestion about managing deleted accounts. One of the things one can do to change how/where a deleted account appears in relationship to you is to ban it.

However, if the account in question is an OpenID account, there is no way of which I am aware for a user to discover the ext_#### account name, in order to actually do the banning. (Even if the OpenID account is active, DW has done a lot to make it unnecessary for users to be aware of that form of the account name, so I'm not sure how many users would know how to ban an active OpenID account through the ban page.)

So, I think this would make the ban page more effective with OpenID account users.

Poll #1685 Ban page accepts OpenID url account name as account to ban
Open to: Registered Users, detailed results viewable to: All, participants: 38

This suggestion:

Should be implemented as-is.
38 (100.0%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
0 (0.0%)

0 (0.0%)

### Enable sending PMs to OpenID display names

07:55 pm

Title:
Enable sending PMs to OpenID display names

Area:
inbox

Summary:
Currently OpenIDs can only receive PMs sent to their ext_12345 system names. It would be nice to be able to send PMs to their normally-displayed names.

Description:
Today I was corresponding via PM with an OpenID user. The OpenID user had no problem sending me a private message, but when I clicked Reply in my inbox, typed up my message and went to send, the system told me that this other user's x.livejournal.com OpenID name -- which was what the system had inserted in the recipient field *for* me when I hit reply -- was not a valid username. To reply to the PM I had to go look around the user's profile page until I was able to figure out their ext_ system name, which was not exactly an intuitive process. Since Dreamwidth goes out of its way not to make users deal with the ext_ names whenever it can be avoided, it would be nice if we could also send PMs to OpenID folk via their regular display names.

Poll #1597 Enable sending PMs to OpenID display names
Open to: Registered Users, detailed results viewable to: All, participants: 42

This suggestion:

Should be implemented as-is.
39 (92.9%)

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

Shouldn't be implemented.
1 (2.4%)

(I have no opinion)
2 (4.8%)

0 (0.0%)

## Profile

Dreamwidth Suggestions

S M T W T F S
1
23456 7 8
9 101112131415
16171819202122
23242526272829
30

No cut tags