dw_suggestions | Entries tagged with site: usability

Title:
Rearrange the logged-in homepage

Area:
homepage

Summary:
Make the logged-in homepage more appealing by modernising the UI, showing more relevant and dynamic content near the top of the page, adding pointers to help new users, and grouping notifications in the right sidebar.

Description:
Today I looked at the Dreamwidth homepage and thought about what it might look like to a new user who's recently signed up, especially those who might be coming from non-LJ-like sites. (In this case, I was thinking of Google+, but it probably holds for other sites as well.) It occurred to me that the page looks a little lifeless and doesn't really point people at the stuff they are most likely to need. At the same time, I know that I (and some friends I asked, also long time LJ/DW users) don't really use the homepage, but head straight for our reading pages or the update page. I'd like to see actual stats on this, but I suspect this is a common pattern. So, what I'm going to suggest is mostly intended to be useful to newer users, but I hope it won't horribly bother older users who regularly use the homepage.

Currently the page shows:

MAIN COLUMN:
<user name="dw_news"> update
Quick update form
Inbox

RIGHT COLUMN:
Search DW
Reading list
Account stats
Tag cloud (your own tags)
Community management (required actions)
Your current theme

Here's what I'd like to suggest:

MAIN COLUMN:
Quick update form
Reading list (see notes below)
People/content discovery (see notes below)
Themes (see notes below)

RIGHT COLUMN:
Search DW
DW news (link only)
Birthdays
Inbox
Community management

Here's my justification.

1. READING LIST

Firstly, most other modern social network stream-like sites, these days, have your "stream" on the front page when you login: Twitter, Facebook, Google+, etc. New people, especially, are going to expect to see some action on the front page. A lot of new DW people I talk to don't really understand about the "reading" page and how awesome it is. So I'd like to put some of that stream of posts right in front of them, and explain why they want to go to the reading page for the full experience.

Here's what I think it should show:

* ~5 recent posts, in short form (userpic, user name, date, subject, first couple of lines of the body, comment count)
* "See more on your reading page. Your reading page lets you see all your friends' posts, etc etc..." (i.e. a short blurb about why the reading page is where the action's really at)

2. PEOPLE/CONTENT DISCOVERY

New users often seem to wonder how they can find stuff on DW. It would be good to have a bit of information with some pointers here, including eg. "latest things", searching the directory, promo communities, stuff like that.

3. THEMES

We currently show your current theme on the front page. Yawn. People generally know what their current theme is! But why not combine this with promoting new themes? Widen the "theme" box and stick it at the bottom of the main content column, and say "You're currently using theme X. Did you know DW has hundreds of themes to choose from, that you can use to customise your own journal and reading page? Check out themes Y and Z!"

4. NOTIFICATIONS

I'm going to collapse "DW news", "Birthdays", "Inbox", and "Community management actions" into "Notifications" here. These are all things that are like "Hey, this is a timely new thing you might want to pay attention to." Grouping them would be a good idea.

I think that the "DW news" thing should be reduced to a smaller link. People get the news notifications by email anyway (by default), and many have them on their reading lists. A notification that says "hey, there's a newish one" might be helpful but it doesn't need to sit there taking up prime real estate for weeks.

The rest should be obvious -- birthdays, inbox, community management, etc. All things you probably want to know about as they happen. Putting them all near each other just seems like a sensible UI choice to me.

5. ACCOUNT STATS AND TAG CLOUD

These just seem to be taking up real estate without serving much purpose, IMHO. The account stats are duplicated on your own profile page, and the tag cloud is duplicated on most people's themes (in the sidebar or wherever). Lose 'em.

I'm sure people will want to pull all this apart and put it back together differently, and I have to say, I'm not deeply committed to any particular part of this proposal, but I do want to reiterate the main point: the logged in homepage should be rearranged to be more dynamic and appealling, and to point new DW users at DW's best features and help them find their way around.

Potential drawbacks: I'm sure there are some people who are very fond of the current layout, who'd be disappointed with this. I can't really think of any other drawbacks.

Implementation: This is mostly a UI rearrangement and shouldn't require a lot of new functionality under the hood. I think it should be relatively straightforward, though it would require a few design iterations to make it really good. (I know it's not as complex as the new posting form's redesign, but it might be nice to do the iterations in a similarly public manner.)

Poll #7988 Rearrange the logged-in homepage

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
20 (32.8%)

(Other: please comment)
0 (0.0%)

melia244

Title:
Adding Feeds

Area:
feeds

Summary:
Option for adding feeds inside the manage circle page. Alternatively add a separate "manage feeds" entry on the organize tab.

Description:
This is related to http://dw-suggestions.dreamwidth.org/87376.html

Every time I decide to add a feed to my reading list I seem to fumble around a lot before I can remember how it is done. My intuitive response has always been:
1. Click on "Manage circle". From there I can add people/communities, and I can also modify my relationships to them. I can also unsubscribe from feeds, but I cannot add them. That seems incongruous.
2. Go to the home page and click on the "organize" tab, where all the other "manage" options reside.
For me "read->feeds" would probably mean the page where I get to read the feeds I subscribe to.

Thus my suggestion is to add the option for adding feeds to the manage circle page. Alternatively, add a separate "manage feeds" entry on the organize tab.

Poll #7895 Adding Feeds

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
14 (29.2%)

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
14 (29.2%)

(Other: please comment)
3 (6.2%)

ninetydegrees

Title:
Index page for ways to filter a page

Area:
usability, recent page, reading page

Summary:
Create /index or /filter pages for recent and reading pages which list all the ways you can filter them, give example URLs or link to existing pages when necessary (and, of course, hide them from viewers if they're supposed to be private).

Description:
You can currently filter recent pages by year, month, day, tag, and/or tag combos, poster, security level and also group and type of account for reading pages, and sometimes even a combination of several filters. It's getting hard to remember what all the possibilities and their URL formats are.

This is inspired by at least two great suggestions: http://dw-suggestions.dreamwidth.org/545274.html and http://dw-suggestions.dreamwidth.org/33097.html.

Poll #7084 Index page for ways to filter a page

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
53 (88.3%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (11.7%)

(Other: please comment)
0 (0.0%)

anyssia

Title:
Enlarged boxes on the Manage Icons page

Area:
icons

Summary:
Enlarging comment/description/keyword boxes on the Manage Icons page

Description:
I just realized, while updating my icons, that the boxes on this page have a set size, which isn't easy to use, because I can't see all my text/description.

Especially when you add the "username=blah, site=blahblah" script in the box.
It very annoying to have to use the arrow keys every damn time to rename/modify my 100+ icons so I can credit properly everybody.

Would it be possible to enlarge the boxes so we could see more of what we are writing?

Poll #7083 Enlarged boxes on the Manage Icons page

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
17 (28.8%)

(Other: please comment)
0 (0.0%)

erika

Title:
Filter Comments in Most Recent page

Area:
manage comments

Summary:
When using the <a href="http://www.dreamwidth.org/tools/recent_comments">Recent Comments</a> tool, I'd like to be able to filter out the comments that were made by me.

Description:
The issue: someone gets a lot of comments on random entries. They go to their most recent comments tool to find out where they were left and to respond to them. But unfortunately, as they respond, their own comments will push the other comments off. Plus it's a hassle having to go through and make sure it's SOMEONE else's comment that you're responding to (peeps with no short term memory, represent!)

Honestly, I can't think of anything more to say. It'd be nice if there was some sort of implementation of a star or graphical/textual indication that showed when a recent comment had already been responded to, but mostly I just want to be able to filter out my own comment.

Poll #7078 Filter Comments in Most Recent page

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
22 (43.1%)

(Other: please comment)
0 (0.0%)

vass

Title:
Remove redirect on logging out

Area:
site

Summary:
When you log out, you are asked to confirm if you want to log out. Then when you confirm, you are taken to the main site page. I think you should be taken back to the page you were on.

Description:
What should happen: you click 'log out' and then you are logged out but still on the same page.

What actually happens: (as of the last code push) you click 'log out', you are redirected to a confirmation page, then when you confirm your desire to log out, you are redirected to the front page. If you want to go back to the page you were on, it takes two more clicks, one of the back button to get you there, one of the reload button to get the logged out version of the page.

In general, I think it's better to redirect users as infrequently as possible.

Poll #6510 Remove redirect on logging out

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
49 (68.1%)

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

Shouldn't be implemented.
3 (4.2%)

(I have no opinion)
19 (26.4%)

(Other: please comment)
1 (1.4%)

marahmarie

Title:
"Send Private Message" link should be on all site scheme pages.

Area:
site schemes

Summary:
For the sake of convenience, a link to the Private Message composer should be included on all site scheme pages. I hacked together an example of what I mean (which shows where I think the link should be): http://i287.photobucket.com/albums/ll128/marahstest/send_pm_link_on_all_site_scheme_pages.jpg

Description:
Sometimes when you're using Dreamwidth, you'd like to compose a private message, but the way it works now, the link to the Private message composer is not on the site scheme pages.

It's only directly available on the Profile page, and the link to that unfortunately only lets you compose a message to yourself (not that you can't change that once you're in there, but by default, it automatically links to you).

An example of what I mean by "including the link to compose a private message on all site scheme pages" is here (extra link is highlighted in yellow):
http://i287.photobucket.com/albums/ll128/marahstest/send_pm_link_on_all_site_scheme_pages.jpg

Adding the compose private message link to all site scheme pages will allow Dreamwidth users to compose a message without having to hover over the "Read" links dropdown, or else click the "Inbox" link under their username on the site sheme pages, then click the "Inbox" link, then click the "New Message" button.

Three steps gone, now it just takes one!

It will also end Dreamwidth users taking the "shortcut" of clicking the PM link on their profile pages, then erasing their own names from the "To" field in order to compose a new message to another Dreamwidth user.

With the new link in place, composing messages will be speedier, easier, and less of a hassle.

The only drawbacks are the time and testing it will take for site devs to add the link to all site scheme pages and ensure it's working properly.

Poll #5517 "Send Private Message" link should be on all site scheme pages.

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
10 (21.3%)

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

Shouldn't be implemented.
16 (34.0%)

(I have no opinion)
20 (42.6%)

(Other: please comment)
0 (0.0%)

peoppenheimer

Title:
"Refresh" link at the top of the Inbox

Area:
Inbox

Summary:
Add "Refresh" link at the bottom of the Inbox.

Description:
The "Refresh" link currently exists only at the top of the Inbox. If I had a nickel for every time I have scrolled to the top of the page in order to refresh it, . . . . The "Refresh" link should be added to the bottom of the page as well.

Poll #4240 "Refresh" link at the top of the Inbox

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
23 (63.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (27.8%)

(Other: please comment)
0 (0.0%)

ratcreature

Title:
improve the workflow while using the poll creator

Area:
poll creator

Summary:
When I use the poll creator, and then add a new question, I pick a type (like radio buttons/ticky/scale etc) and push the "insert question" button, but then when the page redisplays with the new empty question field to fill out I get transported to the top of the page and have to scroll down and down until I'm back at the new empty field to actually fill in any question.

For me obviously the next step after adding another question is that I want to type in the text for that question, I do not want to go to the "poll options" field again that I filled out at the start.

Description:
I thought this was a bug, but the support board suggested it might be intended behavior, that some people first create lots of empty fields before filling anything out, so here I am making a suggestion.

However wrt creating fields vs filling in text first, I'd like to point out that the current behavior brings you neither to the "insert question" button at the top nor the bottom, but to the "Poll Options" area at the very top. Also if you create the second question before filling out the first you get an error saying "You have one or more errors in your poll. Please scroll down for more details." So I do not actually think you are meant to first create all empty fields and then fill the text.

The scrolling isn't so bad if you just have one or two questions, but it seriously got on my nerves when I made a poll with ten questions. Sometimes I display the code for just one question to remind me of the syntax and then do the rest manually to escape this scrolling excess, but it would be nicer if the poll creator was less annoying.

I suggest that after adding a new question the page brings you to the field where you enter said question, not the top.

Poll #4239 improve the workflow while using the poll creator

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.9%)

(I have no opinion)
6 (17.1%)

(Other: please comment)
0 (0.0%)

matgb

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

View Respondents

This suggestion:

View Answers

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

(Other: please comment)
1 (2.9%)

ninetydegrees

Title:
Account Settings/Display/Site Scheme: add preview pics

Area:
site scheme

Summary:
Add preview pics above (next to?) site schemes names to give you an idea of their layout and main colors and make selecting one easier.

Description:
Also use attributes (alt or title or something else) to provide a description.

Poll #3934 Account Settings/Display/Site Scheme: add preview pics

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
4 (10.8%)

(Other: please comment)
0 (0.0%)

aphenine

Title:
Wiki-style alternative to mark-up in posts

Area:
posting

Summary:
DW allows the use of HTML tags in entries and also has its own tags for use. However, most of these tags are quite long to write, and formatting lists properly in HTML means switching off auto-formatting and doing everything manually. As a compromise, it would be useful if DW provided an option to use Wiki style mark-up for posting.

Description:
Dreamwidth currently allows HTML in posts, and also has a simple autoformatting option to handle straight text, plus provides its own tags to enable site features (e.g. cuts, usernames).

These features are pretty awesome in general and I would not want to touch them, however they have a few annoyances.

For example, the user tag takes lots of typing to use and HTML in general is not the most compact language for formatting. Plus HTML formatting is broken by the autoformatter, meaning either one has to switch it off and do everything by hand, or not use it.

Wikis have this same formatting problems with HTML, and they fix this by providing their own set of mark-up that is simple and quick to use and has become standardised over different sites. It's easy and its well known.

This simple mark-up system can be adopted quite successfully to fix the same problem in Dreamwidth. By providing an option to use Wiki mark-up in Dreamwidth users could:

use [[username]] to refer to a username and [[lj:username]] to refer to off-site usernames, saving a lot of typing;
use * and # to generate bulletted and numbered lists automatically;
use ==Heading== to provide some heading (although, we don't really need nested heading levels, do we?);

Plus any other useful features that other users can think of.

There would be an issue in using [http://www.awebsite.org|The Website I am linking to] to refer to external sites as people do use square brackets in entries, but I think leaving that out and using automatic url parsing would be appropriate.

Likewise, DW could create some of its own Wiki conventions appropriate to a blogging site.

Poll #3895 Wiki-style alternative to mark-up in posts

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
4 (6.8%)

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

Shouldn't be implemented.
44 (74.6%)

(I have no opinion)
6 (10.2%)

(Other: please comment)
0 (0.0%)

matgb

Title:
Add entry title to "view this entry" email link

Area:
notifications

Summary:
The links at the bottom of an email to a specific entry should include the name of the entry where appropriate.

Description:
When I receive an "X has posted a new entry email", the link to the entry is at the bottom of the email. If X has posted multiple entries, some email clients/systems^[1] will truncate duplicated content thinking that it's duplicated.

This is especially annoying if using the HTML view of Gmail on a mobile device, where clicking the 'read more' link will reload the thread, marking all unread as read.

If the "view this entry" text was replaced by "view entry TITLE", this would cease to happen.

Alternatively, if the title of the entry at the top of the notification was also a link, this would also solve the specific gmail problem.

(I and Miss_S_B subscribe to each other, and tend to work different shifts, we have metered bandwidth on our mobiles, and while neither of us gets close, extra pageloads for no reason is annoying, this is a specific gmail issue, but it may apply to other clients)

ETA: [1] This includes Gmail and Conversation View in Outlook 2010, and may include other email clients, feel free to comment.

Poll #3479 Add entry title to "view this entry" email link

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (33.3%)

(Other: please comment)
0 (0.0%)

matgb

Title:
Allow/encourage title attributes to links list entries

Area:
styles

Summary:
Create text area within the Links list for link TITLE text, that would then display as per browser standards.

Description:
Currently, the only option we have for a Links List entry is URL and link text. It's good practise to give links Title text as well, that normally, depending on browser settings, then displays as a tool tip.

Other platforms, such as Wordpress, allow and encourage links to be given Title attributes, following usability guides and allowing users to give expanded explanations of what a link is, and why it's there in the sidebar.

Example: in my links list, I link to Miss_s_b using her name. For sidebar space reasons, that's all I can give. I'd like to allow users to know if they hober over a link that she's my fiancée and give a brief description of her content. That's good practise, recommended by usability experts. It can also aid search engines and is recommended white hat SEO behaviour.

Poll #3478 Allow/encourage title attributes to links list entries

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
17 (50.0%)

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

Shouldn't be implemented.
7 (20.6%)

(I have no opinion)
10 (29.4%)

(Other: please comment)
0 (0.0%)

alashandra

Title:
Make the site schemes fit the browser size

Area:
Site Schemes

Summary:
The default site scheme uses a very small amount of the browser width. Those that use the full browser width are too dark to be comfortable to some.

Description:
I admit that my browser isn't exactly the usual. I have a wide screen which means that my browser is wider, too. But I found that using Tropospherical Red and Tropospherical Purple that these site schemes seem to be framed, so that anything that runs beyond the width of the header end up with an interior scroll bar at the bottom of the page.

Checking out the other site schemes, I found that Celerity squished up the later replies to a long thread. The Gradation schemes also take advantage of the full browser width, but they're dark enough to be difficult to the eye.

There should be a few more site scheme choices, including ones with lighter backgrounds. Even a lighter version of the Gradation schemes would be useful.

Poll #3196 Make the site schemes fit the browser size

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
12 (27.9%)

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

Shouldn't be implemented.
4 (9.3%)

(I have no opinion)
20 (46.5%)

(Other: please comment)
0 (0.0%)

trixtah

Title:
Implement SPF records for email

Area:
Administration

Summary:
Implment DNS SPF records to facilitate email delivery to large webmail providers

Description:
SPF is an industry standard way of guaranteeing which email servers are permitted to send mail on behalf of your domain. At present, there seems to be a perennial problem with Dreamwidth bulk email being rejected from time-to-time - the "big four" email providers (Gmail, Hotmail, Yahoo and AOL) -do- use SPF records to positively weight email spam scores in favour of bulk emailers.

Dreamwith.org sends mail from one server - it is simple to implement a DNS TXT record that reads "v=spf1 mx ~all" that will verify to any email receiver that checks SPF that your MX server is permitted to send mail on behalf of "@dreamwidth.org" senders.

It also makes the likelihood of future spammers spoofing dreamwith.org addresses in order to send mail much less.

SenderID is also a useful solution, but SPF is simple to implement and will assist with delivery of bulk email to most large email service providers.

Poll #3195 Implement SPF records for email

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
17 (37.8%)

(Other: please comment)
1 (2.2%)

zaluzianskya

Title:
Display user's display name when hovering over userpic

Area:
comments

Summary:
Currently, when you hover over the icon someone's used on a comment, the title text displays their screen name and icon keyword. Instead of the screen name, it should display their display name.

Description:
This behavior is a little confusing for people who are used to how it works on Livejournal and its clone sites; it's become commonplace to hover over a userpic to see what name someone has chosen to use. Here, though, it just displays their screen name, which is already available just a few pixels to the right of the picture.

There are many benefits to showing the display name in title text rather than the user name -- Depending on what's been set, it can help let you know what name someone prefers to go by, and it can help you use the appropriate gender pronoun for someone you're talking to, if their screen name is ambiguous. These benefits don't apply 100% of the time -- for example, my display name, ℵ0, is neither gender-specific nor the name I prefer to go by -- but I think they apply often enough that it's worth looking at. You can still see the display name by going to their profile, but it's an added, unnecessary step.

Another major use of the display name is that it's where roleplayers put their characters' names, so that you can see them at a glance, just by hovering over the icon. This is so prevalent among roleplayers that some games make it a rule to put your character's name in the name field, and some people on Livejournal actually complain loudly when they come across journals that haven't done so. In this case, you can -- again -- see the character name by going to the journal's profile, but it's still inconvenient to have to do that.

The fact that this behavior is so different from LJ and its clone sites suggests that there was some reason for this change, but I can't find any documentation anywhere explaining it, and I can't think of a single good thing that comes of it.

Poll #3094 Display user's display name when hovering over userpic

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
29 (42.0%)

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

Shouldn't be implemented.
21 (30.4%)

(I have no opinion)
16 (23.2%)

(Other: please comment)
2 (2.9%)

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

jeshyr

Title:
Reloading a page with a returnto= URL should go to the return URL if already logged in

Area:
login, entries

Summary:
If you try to view protected content while logged out you're bounced to the front page where (with most site schemes) you can log in. If you reload this page while logged in, I think it should bounce you back to the page you came from automatically.

Description:
Say I try to view the friendslocked entry http://rb.dreamwidth.org/1.html but I'm not logged in. I'll be bounced back to the front page so I can log in. The URL will now be:
http://www.dreamwidth.org/?returnto=http://rb.dreamwidth.org/1.html&errmsg=notloggedin
If I then log in, the page will automatically direct me back to http://rb.dreamwidth.org/1.html where I started from.

Now, supposing that I accidentally open three friendslocked entries in this manner while not logged in - I now have three front page screens staring at me, screens which will only automatically take me back to the original entries if I log in separately on each open login page. This is annoying and sorta frustrating... especially if you are like me and keep open tabs in your browser which will make this happen every time you open your browser.

My suggestion is that if I am faced with multiple login pages with returnto= parameters like this, I should use one of them to actually log in (DW now knows I'm logged in) and then for the other login pages I should just press reload on my browser and DW redirects me back to the page in the returnto= parameter in the URL. I can't think of any legit use case where somebody already logged in would be at a login prompt with a returnto= in the arguments, so I don't think this would mess anything up.

[ BTW, I know it's not a recommendation, but this is equivalent to what Facebook already does in this case :) ]

Poll #3071 Reloading a page with a returnto= URL should go to the return URL if already logged in

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (14.3%)

(Other: please comment)
0 (0.0%)

allchildren

Title:
link "user icons" page from "manage userpics" page

Area:
userpics

Summary:
Add a link to "user icons" from the "manage userpics" page.

Description:
So, I'm kinda obsessed with icons, and a lot of others are too. The first thing I do after uploading several pics is to look at the non-edity user icons page, to see how they look to everyone else. Currently there's no shortcut to the allpics from the manage page, and That Is A Pain. (Yes, I know to go up to my navbar, hover, and click on my icon there. But to do that you have to already know the trick and be able to remember it, and not everyone uses the navbar anyway.)

I propose adding a text link at the top of the Manage Pics page to the User Icons page. Something like "See your uploaded icons here." Simple and unambiguous, much like the newly added (and very useful) keyword/upload order sorter! :)

Poll #3029 link "user icons" page from "manage userpics" page

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
56 (88.9%)

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
5 (7.9%)

(Other: please comment)
0 (0.0%)

Dreamwidth Suggestions

Rearrange the logged-in homepage

Adding Feeds

Index page for ways to filter a page

Enlarged boxes on the Manage Icons page

Filter Comments in Most Recent page

Remove redirect on logging out

"Send Private Message" link should be on all site scheme pages.

"Refresh" link at the top of the Inbox

improve the workflow while using the poll creator

Make returnto work from the OpenID login page

Account Settings/Display/Site Scheme: add preview pics

Wiki-style alternative to mark-up in posts

Add entry title to "view this entry" email link

Allow/encourage title attributes to links list entries

Make the site schemes fit the browser size

Implement SPF records for email

Display user's display name when hovering over userpic

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

Reloading a page with a returnto= URL should go to the return URL if already logged in

link "user icons" page from "manage userpics" page

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate