ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Site-styled entries: remove 'UTC' or only display it when it's really UTC

Area:
entries, site

Summary:
Time in site-styled entries displays like so: @ 2012-06-21 22:51 UTC or @ 2012-06-21 10:51 pm UTC but, unless I'm mistaken, it uses your time (i.e. the time on your computer clock when you posted the entry) and doesn't convert it to UTC (or at least not all the time). I think it's confusing and should either display when it really is UTC or not display at all.

Description:
Tried this logged in and logged out, whether I had set a time zone or not and still got *my* time.

Poll #11024 Site-styled entries: remove 'UTC' or only display it when it's really UTC
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
52 (91.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (3.5%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Mobile Reading page: add previous/link at the bottom too

Area:
reading page, mobile

Summary:
On http://www.dreamwidth.org/mobile/read, add a link to view previous/next entries at the bottom.

Description:
This would let you see past entries without having to go back to the top of the page.

Poll #9858 Mobile Reading page: add previous/link at the bottom too
Open to: Registered Users, detailed results viewable to: All, participants: 65


This suggestion:

View Answers

Should be implemented as-is.
58 (89.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (10.8%)

(Other: please comment)
0 (0.0%)

turlough: deckchairs on Brighton Beach, June 2013 (Default)
[personal profile] turlough

Title:
Confusing display settings for entry/comment pages

Area:
entries, display

Summary:
The settings for "Entry View Style" and "Comment Pages" (under My Account Settings: Display) are sufficiently alike to be confusing and should be reworked into one setting for how you see your own pages and another for how you see other people's pages.

Description:
The Display tab under My Account Settings has two different settings that concern the same thing.

Both "Entry View Style" and "Comment Pages" govern the way you see entry/comment pages. The options they offer are almost, but not entirely, alike - "Entry View Style" lets you choose between viewing both your own and other people's pages in Original Style / Site Skin / My own style / Light format, and "Comment Pages" lets you choose between viewing comment pages (presumably other people's) in your own journal style or the journal owner's style by way of a tickybox - which means that I never feel completely sure that the settings I've chosen will give me the result I desire.

It's very confusing and I feel it would be so much easier if these two settings were reworked into a setting for how you see your own entry/comment pages and a setting for how you see other people's entry/comment pages.

I would suggest that the options for your own pages should be My Journal Style / Site Skin / Light Format, and that the options for other people's pages should be Original Journal Style / My Journal Style / Site Skin / Light Format.

Poll #8857 Confusing display settings for entry/comment pages
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (15.4%)

(I have no opinion)
18 (34.6%)

(Other: please comment)
7 (13.5%)

transcendancing: Darren Hayes quote "Life is for leading, for not people pleasing" (Default)
[personal profile] transcendancing

Title:
Crossposting to Dreamdwidth from Posterous

Area:
Crossposting

Summary:
I have what I call my 'grown up' blog over at Posterous (www.posterous.com) and maintain my beloved personal blog here on DW. Posterous auto crosspost to LJ and I desperately want an auto crosspost feature to DW.

Description:
Posterous (www.posterous.com) is a kind of tumbleblog and they have in place mechanisms to do auto-crossposting to other services. They don't yet do this to Dreamwidth and I've suggested it to them on multiple occasions, and I wonder if Dreamwidth approaching them whether it might actually happen. At present it seems to suffer from being at the bottom of the list of their priorities, and I respect that but it's increasingly difficult to make the best use of my blogging and time having to manually do the post/cross posting thing.

I am hoping that because DW is based on the LJ sourcecode that the work needed to have a DW auto cross post would be less work than they perhaps think it will be. I'm not a coder and I can't speak to that, sorry.

Having this ability will improve shareability between platforms, for those of us who do have multiple blog spaces it cuts down the time needed to manually post/link to/update all the spaces.

The drawback is that I'm asking DW about it and it relates to a push from another service to DW which possibly makes it not possible from this end. It may be that I need to push at Posterous and provide them with more context and detail as to how to go about implementing this.

This is a potential alternative actually, could you provide me with some support to liaise with Posterous so that I can make a better case to them about having the auto-crosspost feature if it's not within your purview or capability to directly engage with Posterous about this?

Hoping that I've provided a useful amount of detail for you and that it's a suggestion that is useful in some way.

Many sincere thanks for how approachable and involved you and the entire volunteer team of DW coders are with regard to improvements on the service and engaging with all the things big and little that matter to DW users.

Poll #8833 Crossposting to Dreamdwidth from Posterous
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

Should be implemented as-is.
9 (18.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
39 (81.2%)

(Other: please comment)
0 (0.0%)

cat_77: Picture of Ghost with booze (Default)
[personal profile] cat_77

Title:
Safari Compatability

Area:
entries

Summary:
Allowing scrollable entry boxes compatable with iPad's version of Safari to make it easier to edit.

Description:
The iPad version of Safari does not permit scrolling in the entry boxes (like what I am typing in now), which makes it quite difficult to read through and edit entries that are longer than one "box worth" of information. This holds true for the original entry prior to posting, as well as attempting to edit a pre-existing entry. As there are no scrolling arrows on the iPad keyboard (only the Bluetooth accessory), you cannot simply use those within the entry box to get back up to an earlier part of the entry.

LJ has the same issue, but has an iPad compatable app which you can use instead. Understandably so, it does not crossover to any other journal site so you can only use it for LJ and not DW, which I much prefer to use.

Is there any sort of coding fix to allow this (likely a frames-related issue), or possibly a DW app in the works?

Much appreciative for any information you may be able to provide.

Thanks!

Poll #8379 Safari Compatability
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.4%)

(I have no opinion)
26 (70.3%)

(Other: please comment)
1 (2.7%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Account Settings: merge 'Comment Pages' option with 'Entry View Style' option

Area:
settings

Summary:
See below as it's quite complicated.

Description:
On Account Settings [http://www.dreamwidth.org/manage/settings/?cat=display], you have two options:

1- Comment Pages - View comment pages in your own journal style

This is the option DW inherited from LiveJournal.

When enabled, clicking on 'Leave a comment', 'Read comments', a permalink or a cut anywhere on the site will append style=mine to the target URL. Comment and reply pages get therefore loaded in your own style or the site skin if you've disabled custom comment pages.


2- Entry View Style - When viewing entry pages (including yours), use this style: Original Style/Site Skin/My own style/Light format

This is the new option Dreamwidth implemented.

When enabled, comment and reply pages always get loaded in the style you've chosen. This is also transparent as nothing gets added to the URL. Magic!


As you can see, the two options are very similar and even overlap in some cases*. The main difference between the two is that option 1 requires you to click on some specific links while option 2 doesn't. If someone links to an entry page in their post and you click on the link, option 1 will not load it in your style. Option 2 will. If you click on the cut text, both options will load the entry in your style. The other difference is that one changes the URL while the other doesn't.

*To prevent this, option 2 isn't used when option 1 is and vice-versa. Except not always. If you have selected the light format for option 2 then it overrides option 1 for instance. As I said, it's complicated.


I suggest the first option to be phased out and to automatically set option 2 to 'my own style' for users who had checked option 1.


Why? I think option 1 seems simple but is actually uselessly complicated, and having these two options seems confusing to me. I also wonder whether many people chose to set 1 but not 2 and did so deliberately. From comments I've seen here and there, some people don't understand that entry pages and comment pages are one and the same, plus the description text for the the first option is vague because explaining how this option works exactly is impossible. It gets even more complicated if you add the fact that once you've got style=mine added to an URL, you're stuck with it so any link you will click on the page will get style=mine too. And let's not talk about Nav Strip overrides.


But what do I know, right? Hence this suggestion to see if it's a good or a terrible idea, and also to know why someone would deliberately use option 1 and not option 2 because it's intriguing. *g*

Poll #7847 Account Settings: merge 'Comment Pages' option with 'Entry View Style' option
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
1 (2.2%)

Shouldn't be implemented.
5 (11.1%)

(I have no opinion)
14 (31.1%)

(Other: please comment)
1 (2.2%)

yvi: Kaylee half-smiling, looking very pretty (Default)
[personal profile] yvi

Title:
Make order on invite code list make sense

Area:
Invite codes frontend

Summary:
The order on http://www.dreamwidth.org/manage/invitecodes?full=1 is not optimal - make it so.

Description:
http://www.dreamwidth.org/manage/invitecodes?full=1 seems to have three tiers of order:

1. the unused codes
2. the used codes, ordered by date the person joined ascending
3. the used codes that were sent to someone via e-mail, ordered by date the person joined ascending

I suggest joining 2 and 3.

Poll #7730 Make order on invite code list make sense
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
36 (67.9%)

Should be implemented with changes. (please comment)
1 (1.9%)

Shouldn't be implemented.
1 (1.9%)

(I have no opinion)
15 (28.3%)

(Other: please comment)
0 (0.0%)

ciaan: revolution (Default)
[personal profile] ciaan

Title:
Memories Icon Different If Post Already Memoried

Area:
memories, entry pages

Summary:
In the site style, the "add to memories" button on an entry is a heart with a plus mark over it. It would be nice if, when the entry was already in your memories, this button changed in appearance to something slightly different, and the alt text changed to "edit memory."

Description:
I'm not sure what the new icon should be, though.

Poll #7557 Memories Icon Different If Post Already Memoried
Open to: Registered Users, detailed results viewable to: All, participants: 71


This suggestion:

View Answers

Should be implemented as-is.
62 (87.3%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (9.9%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Chronologically Sort Used Invite Codes

Area:
site interface

Summary:
On http://www.dreamwidth.org/manage/invitecodes?full=1, you can see when your invite codes were used. They're more or less sorted chronologically (by year definitely for me; by month, day and time only approximately). I'd like them to be fully sorted chronologically.

Description:
I'm sure some people would like to be able to sort them by other criteria such as 'recipient' and 'sent on' so it might be best to do all the cats at once.

Poll #7124 Chronologically Sort Used Invite Codes
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
22 (40.7%)

(Other: please comment)
0 (0.0%)

vass: A sepia-toned line-drawing of a man in naval uniform dancing a hornpipe, his crotch prominent (Default)
[personal profile] vass

Title:
'Remember saved draft' feature should remember access status

Area:
entries

Summary:
The 'remember saved draft' feature should, as well as remembering your text, remember whether your entry was private, filtered, access-locked, or public.

Description:
Here's the scenario: you are writing something you only want a few people to know. You select the correct access filter. You type your entry. Your browser crashes. You restore it, but forget to re-check the filters. Alas! The caching mechanism remembers your draft, but forgets that it was filtered. You hit post, and everyone who reads your journal can see the private post. All die, oh the embarrassment.

This should not happen. The 'remember saved draft' feature should remember your access level.

Poll #5571 'Remember saved draft' feature should remember access status
Open to: Registered Users, detailed results viewable to: All, participants: 69


This suggestion:

View Answers

Should be implemented as-is.
59 (85.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (14.5%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
Mutual Interests Magic: add option to filter to personal journals OR communities (not just both)

Area:
explore

Summary:
On http://www.dreamwidth.org/interests, there's a very nifty option allowing you to find journals matching your or someone else's interests ("Find people or communities with interests similar to those of:"). I'd like to be able to refine the results to 'just people' or 'just communities'.

Description:
Or directly to be able to search for 'just people' or 'just communities'.

Poll #5181 Mutual Interests Magic: add option to filter to personal journals OR communities (not just both)
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

Should be implemented as-is.
43 (81.1%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (18.9%)

(Other: please comment)
0 (0.0%)

ratcreature: RatCreature's toon avatar (Default)
[personal profile] ratcreature

Title:
include "post to" among the fields that are remembered with the restore

Area:
entries

Summary:
When an entry has been unfinished and not posted, and posting was interrupted, DW currently does not remember if you already had selected a community in the "post to:" field. I think it would be nice if it cached that also and restored it.

Description:
Yesterday I was writing a post intended to go to a comm. I had the community selected in the field where you choose where to post, the icon chosen, the title and started on the text. My posting was interrupted and later on I restored what I had written so far, and it remembered the entry title, the icon, and the text so far, which was great, but the place to post had switched back from the comm to my journal. I almost overlooked this, because in my previous editing I had already been past this field, and DW remembered the other fields.

I double checked all fields before hitting "post" so I noticed, but I think it would be better if the "post to" field was remembered and restored too.

Poll #4873 include "post to" among the fields that are remembered with the restore
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

Should be implemented as-is.
61 (96.8%)

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
1 (1.6%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees

Title:
E-Mail notifications for comments: make Reply the first link instead of the last one

Area:
notifications

Summary:
When you get an e-mail notification for a new comment, you have a list of links at the bottom to take further action. Reply is the last one in the list. I suggest it be the first one.

Description:
I would think Reply is the link people use most and it seems logical to me to encourage conversations.

It would also save me some scrolling when I use my cell phone.

Poll #4746 E-Mail notifications for comments: make Reply the first link instead of the last one
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

Should be implemented as-is.
27 (42.9%)

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

Shouldn't be implemented.
13 (20.6%)

(I have no opinion)
19 (30.2%)

(Other: please comment)
1 (1.6%)

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
[Suggestion submitted by OpenID user, reposted by moi.]

Summary:

Add ability to import Vox journals by the end of September 2010.

Description:

Since Vox is shutting down at the end of September 2010, is it possible for you all to add the ability to import a Vox journal in such a short time?

Suggested by:

ext_83128

Poll #4323 Add ability to import Vox?
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is
34 (59.6%)

Should be implemented with changes (please comment)
1 (1.8%)

Shouldn't be implemented
1 (1.8%)

(I have no opinion)
20 (35.1%)

(Other: please comment)
1 (1.8%)

birke: (Default)
[personal profile] birke

Title:
Compatibility with Dragon NaturallySpeaking (MSAA)

Area:
Link programming

Summary:
I suggest making links MSAA compatible. The dictation program Dragon NaturallySpeaking uses this to 'read' websites and click links using voice commands.

Description:
I'm coming to this with ignorance of the technical details. Dragon NaturallySpeaking, the foremost dictation program out there and one frequently used by people with hand/arm disabilities, allows me to follow links, enter text, switch tabs, jump from one text box to another... all by voice, in either Internet Explorer or Mozilla Firefox. But there are some popular sites where this breaks down, including Google, LJ, and DW. At DW, I can enter text and follow some links -- such as those on the main page -- by reading the link out loud, e.g. "Reading" or "Post." But on my reading list, if I tried to open a cut text or follow an external link by reading aloud, e.g., "More under the cut" or "nytimes.com", DNS wouldn't recognize that text as belonging to a link on the page.

I asked why at a speech-recognition forum, and got this answer:

"The reason Dragon cannot see some websites is simply because of the programming components that were used to create the website. Dragon uses mainly MSAA( Microsoft active accessibility) to pick up the text links, images, combo boxes, list boxes etc and if the MSAA API can't see the particular components (usually because they are customised components) used on the websites you mentioned them there will be no command access. So to give the short answer if the developers of the websites you mentioned make it MSAA compatible then DNS will be able to access it."

I don't know what you can do about this, but I feel it's important that you know about it. Google didn't know about it when they started, and now they have built what another forum member called "a largely inaccessible Web empire."

Thanks for listening!

Poll #4243 Compatibility with Dragon NaturallySpeaking (MSAA)
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (25.8%)

(Other: please comment)
2 (6.5%)

azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Bulk invite code testing tool for dw_codesharing admins

Area:
administrative tools, invite codes

Summary:
If it does not already exist, it should: an interface for bulk-testing a group of invite codes and showing which work and which do not.

Description:
This tool would take inputs of single or multiple invite codes, probably on separate lines rather than a comma-separated list, and show which ones are still good.

Why? Because when you're helping assist in dw_codesharing, occasionally there will be entries with a lot of codes, and you want to test which ones work and which do not. The actual create page is rate limited, as it very sensibly should be.

To prevent abuse, this should only be available through granting privs, and should only display whether or not the code is good/unused, rather than showing more details such as the journal the code originates from, the username of the journal that claimed the code, and other things -- they would be useful to someone at a site owner level, but they're not needed at a dw_codesharing admin level.

For bonus shiny, the output could include a section with the working codes stuffed into a https://www.dreamwidth.org/create?code= link, for easy copying and pasting.

Poll #3832 Bulk invite code testing tool for dw_codesharing admins
Open to: Registered Users, detailed results viewable to: All, participants: 26


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (42.3%)

(Other: please comment)
0 (0.0%)

juniperphoenix: Fire in the shape of a bird (Default)
[personal profile] juniperphoenix

Title:
Automatically cut entries from syndicated feeds

Area:
entries

Summary:
I would like to be able to set a preference whereby all entries from syndicated feeds (or all those over a certain length) would be automatically placed behind a cut on my Reading page.

Description:
I subscribe to a lot of syndicated feeds. Many of these feeds come from blogs where cut tags are not used at all, and the posts are often very long and/or contain multiple photos. I would like a way to reduce the amount of space taken up by these posts on my Reading page.

I don't know how this could be accomplished from a coding perspective, but as an end user what I'd like to see is a preference somewhere in my account settings that would let me automatically place all entries from feeds behind a cut. It would be even better if it were sensitive to the length of the entry -- if, for example, it could leave the first 100 words uncut as a teaser and place the rest behind a cut.

Now that we have expandable cut tags, it would be very easy for users to expand and read the entries if they wanted to, and it would save a lot of clutter on Reading pages.

It would be awesome if any solution to this could apply to Network pages as well as Reading pages.

Thanks for your consideration!

Poll #3497 Automatically cut entries from syndicated feeds
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

Should be implemented as-is.
35 (72.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (22.9%)

(Other: please comment)
0 (0.0%)

jtspender: Paul at Vichy Elementary (Default)
[personal profile] 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


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

cheyinka: A sketch of a Metroid (Default)
[personal profile] cheyinka

Title:
style=mine in Inbox

Area:
inbox / notifications

Summary:
Links to entries and comments from the Inbox don't use style=mine even when you've specified that you want to "View comment pages from your Reading Page in your own style", but they should.

Description:
If you've specified that you want to view comment pages in your own style, links to those comment pages have style=mine appended, unless it's a link from your recent entries or archive page (where it'd be superfluous).

This is true even if you go to someone else's recent entries or archive page - it's not just links from your reading page, like the option suggests.

But it's *not* true for links from the inbox, and as far as I can tell there isn't a separate setting for that. Since it already is more than just your reading page, it should include the inbox, also. (That way if someone *wants* to see the other person's style, the "style=mine" can be deleted, rather than having to *add* that to make the link from the inbox readable.)

(Either way, the wording of the option should be made clearer, since it's a) not just the reading page and b) could be site scheme instead of your journal style, if you've unselected "Show entry pages in my journal style rather than the site layout" from the Customize Journal Style page.)

Poll #3033 style=mine in Inbox
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

Should be implemented as-is.
34 (61.8%)

Should be implemented with changes. (please comment)
5 (9.1%)

Shouldn't be implemented.
4 (7.3%)

(I have no opinion)
12 (21.8%)

(Other: please comment)
0 (0.0%)

holyschist: Image of a medieval crocodile from Herodotus, eating a person, with the caption "om nom nom" (Default)
[personal profile] holyschist

Title:
Warn if crossposted security may change

Area:
Crossposting

Summary:
If someone is using different security settings on DW and another site, editing a crossposted entry can change remote security settings. This is not obvious, so I think we should warn for it.

Description:
If a user has a default security setting of Friends-Only on Livejournal or another site, but a default setting of Public on Dreamwidth, the crossposter will respect this. However, when the user edits the entry, the Dreamwidth security setting will be applied to the cross-posted entry on the other site. There is no warning for this, and I have seen people who were confused, thinking it was a glitch. Since this is not a glitch but a standard behavior, I think providing a warning when editing a cross-posted entry (to the effect of "Your Dreamwidth access setting will be applied to all crossposted entries. If you want to preserve different settings, you will need to manually edit security levels on your cross-posted entries.") might help relieve confusion and remind people that they need to check their cross-posted entries for security levels.

Poll #3025 Warn if crossposted security may change
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

Should be implemented as-is.
42 (84.0%)

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

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
7 (14.0%)

(Other: please comment)
0 (0.0%)

Profile

Dreamwidth Suggestions

April 2017

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

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom