dw_suggestions | Entries tagged with site: usability

Title:
"Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

Area:
navigation strip, messaging

Summary:
It is currently very easy to configure your Inbox to serve as an activity notification hub. It would be very useful to have a shorted version of the first page of that Inbox be accessible via a dropdown on the Navigation Strip, and allow some manipulation of your Inbox via that dropdown.

Description:
Each line of the proposed dropdown would contain a one line description of the activity. (N replied to [your post|comment], N messaged you, subject "", N posted to group X, and so on). Each entry would contain an "x" dismissal button which would delete the notification from both the Inbox and the dropdown. Clicking on an individual entry outside of the dismissal button would take you to the item about which you are being notified - the message, the comment made, etc - and mark it as read. A "see all" entry at the bottom of the dropdown could take you to the current Inbox view. Currently, using the Inbox as a notification centre results in large numbers of page swaps and reloads, as you go from Inbox to post to Inbox to reply form to Inbox etc., etc., etc., with mark-as-read and delete-item as separate actions across separate pages. Further, it is difficult to maintain (de-clutter, etc) without engaging in that maintenance as a separate task. As a result, those of us who have this issue end up with over-full Inboxes that we tend to bulk-delete. This suggested feature would allow us both to use our Inbox more easily and maintain it more effectively, resulting in improved usability of the service and - hopefully - fewer notifications being stored on the servers.

Poll #18205 "Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (16.2%)

(I have no opinion)
17 (45.9%)

(Other: please comment)
0 (0.0%)

allen

Title:
Quick jump to next/previous entry

Area:
reading page

Summary:
Add a javascript function to skip to the next or previous entry in your reading page. The function would be available either through a sticky element for desktop, or through a swipe gesture for mobile.

Description:
This is kind of like the Jump Links suggestion (which it looks like was accepted but lost in the bugzilla crash), but with a few differences.

The problem that it's supposed to solve is for when you end up with some long, uncut entries on your reading page (like from changelog or an RSS feed). And then you want to go to the next entry, but end up hitting page down a whole lot. Or worse, you're in mobile and you have to scroll down and keep scrolling and scrolling...

So the idea is to have a javascript function available to scroll to the next (or previous) entry in your page. This could be made available with a sticky module which would be available either in one of the sidebars or (if you don't have a sidebar) at the top of the main entry area. It would have just a 'Next' and 'Previous' button, which would take you to the next or previous entry in your reading list.

We could also include a jquery touch plugin that would add the same functionality with, say, a two-finger swipe up or down.

Edit 2017-04-24 I don't see much love for the sticky idea, but having a way to configure an optional shortcut has at least some support. So now I'm thinking a new tab in My Account Settings for Shortcuts, which would have options for

Enable keyboard shortcuts (checkbox, default unchecked)
Next (text field, default j)
Previous (text field, default k)
Enable touch shorcuts (checkbox, default unchecked)
Next (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)
Previous (options for swipe/disabled, 1,2,or 3 fingers, and up/down/left/right)

I could also add a way to make a link call the JS function so that anyone who wanted to use links instead of key bindings or touch gestures could just include those in their styles.

Poll #18201 Quick jump to next/previous entry

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
11 (34.4%)

(I have no opinion)
6 (18.8%)

(Other: please comment)
3 (9.4%)

lassarina

Title:
System for Marking Entries to Read Later

Area:
Entries

Summary:
Similar to how AO3 allows you to bookmark fic to read later, it would be super convenient to be able to mark a DW entry on my reading page for later, especially if you often read Dreamwidth on mobile.

Description:
I try to read my reading page every day, but I don't always have time to read everything on it, especially when someone is doing heavy lifting for personal issues or has written a long, meaty entry I want time to digest, or hey look there's fic and I don't have time for it right this second but I really want to read it. I often read on mobile, and it's not really feasible to keep dozens of tabs open in mobile browser until I can come back to them. So, I'd love a way to store entries to read later that's separate from the memories feature (which in my mind is for stuff I've already read and want to remember.) I think this would make DW easier to use from mobile as well (oh look there's a post full of images, I don't want to look at that on a cell connection.)

Poll #18023 System for Marking Entries to Read Later

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.2%)

(I have no opinion)
13 (28.3%)

(Other: please comment)
1 (2.2%)

ninetydegrees

Lightboxes are a bad idea so I've submitted a new suggestion to improve our current preview pop-ups. Please comment on this one instead once it's approved. :)

Title:
Have previews load on same page in small pop-ups

Area:
entries, comments

Summary:
We have wonderful magic for Quick Reply and a nice pop-up for browsing icons. I'm thinking that something along these would be nice for previews too. So no more loading the preview in the same tab (like DW does for comments) or even loading it in a new window (like DW does for entries). Just a small pop-up you could post your entry and comment from if you're happy with what you see or with a link to go back to the editing page, which would close the pop-up (it is currently not possible to post an entry from its preview page or go back to editing from there; you can only close the window). This type of previews is already implemented on several sites.

Description:
On the Comments preview page, there is additional info (such as which HTML tags are allowed). I think this info should be accessible before you click preview (I don't see how you're supposed to know you have to click on preview to get it in the first place). It could be via a ? button or a text link.

Feel free to suggest better implementation! There may be even better preview magic I haven't seen yet :)

Poll #18018 Have previews load on same page in small pop-ups

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
3 (10.3%)

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

Shouldn't be implemented.
14 (48.3%)

(I have no opinion)
9 (31.0%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Create Entries beta : help button for HTML and Markdown

Area:
entries

Summary:
I suggest adding a help button (i) or link to help us with editing. If you have forgotten which HTML tags are allowed or how to write something in Markdown, you're currently out of luck on the beta page. There is not 'help with editing' link anywhere. I think it would be nice to have one (or two; one for HTML and one for Markdown).

Description:
A help panel we could switch to and from from without leaving the page would be awesome but links to the following in new tabs/windows would be great too:

http://www.dreamwidth.org/support/faqbrowse?faqid=82 (What Dreamwidth-specific markup/HTML tags can I use?)

http://www.dreamwidth.org/support/faqbrowse?faqid=260 (How can I use Markdown to format my entries?)

http://daringfireball.net/projects/markdown/syntax (Markdown formatting and syntax)

http://www.dreamwidth.org/support/faqbrowse?faqid=103 (What HTML can I use in my entry?)

Poll #18017 Create Entries beta : help button for HTML and Markdown

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (18.2%)

(Other: please comment)
0 (0.0%)

style_tester

Title:
Add time/date stamp to Inbox messages

Area:
Inbox, messages

Summary:
The Dreamwidth Inbox is set up to stamp any incoming messages, be they comments or PMs, as having arrived nth seconds/minutes/days/weeks/months/years ago. I'd like to see those stamps added to or replaced by an actual time/date stamp.

Description:
The Dreamwidth Inbox is set up to stamp any incoming messages, be they comments or PMs, as having arrived nth seconds/minutes/days/weeks/months/years ago.

(And I have to speak to semantics here; "34 seconds ago" is admittedly a pretty precise date/time/stamp, but "two weeks ago", IMO, very much isn't.)

My suggestion is since we already have an Inbox function for date/time stamps (it's just not a date/time stamp) to either change it from [posted, received] 'nth seconds/minutes/days/weeks/moths ago' to putting an actual date/time stamp on it, like the UTC date/time stamps we have in DW's comment sections, or else to simply add the date/time stamp to the [posted, received] 'nth seconds/minutes/days/weeks/moths ago' stamp we already have.

I discovered this was A Thing after returning to a neglected PM in my DW Inbox today and realizing I'd have to check my email to figure out exactly when it was sent. I can't stay on site to do that. And it made me feel bad that I'd have to hold up my reply a bit longer as I searched for the email notification so I could reply by saying: "...about the message you sent last Wednesday".

(Again, there are some semantics at work: I could get a calendar and count backward from today to determine what day/possibly month/possibly year "six days ago" was, but like checking my email for the date/time, it's another step I'd have to go offsite or into an OS or phone app to take.)

The system is not too difficult to use to learn when comments were posted (just check the entries comments were posted on) but it's also true no account holder on Dreamwidth can determine, merely by viewing their Inbox notifications, exactly when that was.

Poll #18016 Add time/date stamp to Inbox messages

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (11.4%)

(Other: please comment)
0 (0.0%)

zaluzianskya

Title:
Allow linking to parent comment with only one child thread

Area:
Comments

Summary:
I guess this would be sort of like reddit's context links: A way to view a comment's parent comment, but without any other children of that parent.

Description:
Sometimes I want to link to a specific comment or thread, but there's important context in that comment's parent. However, the parent comment might already have tons of other children. Especially when those other children are above the one I'm linking to, that's really inconvenient for the person I'm sending the link to!

Some way to show just the comment I want along with the parent comment would be a godsend. Preferably with some way to indicate that this isn't the entire thread (possibly with some kind of [click here to see X number of other comments] link, or some other indication).

Poll #18012 Allow linking to parent comment with only one child thread

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (8.8%)

(I have no opinion)
11 (32.4%)

(Other: please comment)
1 (2.9%)

zaluzianskya

Title:
Add ability to add a Memory without leaving the page

Area:
memories

Summary:
Adding an entry to Memories is complicated. It should be easier.

Description:
What I propose is, when you click on the heart button to add an entry to your Memories, a box could pop up on the page for you to select a title and the labels for the Memory. If your browser doesn't support this, the code can degrade gracefully by taking you to the Add Memory page that currently exists.

This would make it less of a hassle to add Memories, since right now you have to go to another page, add the Memory, and then it takes you to a page that lists a bunch of other options like "go back to the entry", "view all your memorable entries", etc. Too many clicks, in my opinion.

Poll #16836 Add ability to add a Memory without leaving the page

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
26 (60.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (34.9%)

(Other: please comment)
2 (4.7%)

dredmorbius

Title:
Provide OPML feed import/export options

Area:
Reading Page

Summary:
Providing OPML support would allow for a standards-compliant improvement in the ability to manage RSS/Atom feeds on user's Reading Pages.

Description:
DW offers users the ability to add and manage feeds of RSS/Atom sources as a "Reading Page" feature, effectively a Web-based Newsreader.

Management of feeds (adding, removing, organizing, modifying) is done through a series of Web interfaces, principally http://www.dreamwidth.org/feeds/, http://www.dreamwidth.org/manage/circle/edit, http://www.dreamwidth.org/manage/subscriptions/filters, and http://username.dreamwidth.org/read.

Some of these tasks, as well as archival and distribution or sharing of lists, would be much easier if feeds could be exported in OPML format, a standard data exchange format for RSS and Atom feeds used by many feed readers. Providing import/export for Dreamwidth feeds would avoid a significant amount of front-end and back-end redesign to improve the feeds management process while providing for much greater user flexibility and ease in management.

https://en.wikipedia.org/wiki/Opml

This is *not* a request to allow re-syndication of feeds (though people would be able to share the feeds lists they subscribe to). E.g., request #9210 is an entirely different matter: http://dw-suggestions.dreamwidth.org/9210.html

Among challenges:

- DW feeds are based on local feeds, not the original source. Translating between these would have to be provided for.
- Allowing both feeds *and* filters to be exported/imported would be most useful. This would require some design and planning.

There's an earlier (2009) suggestion which mentions OPML though it's not clear where it is access or what the files contain: http://dw-suggestions.dreamwidth.org/133555.html

Poll #15785 Provide OPML feed import/export options

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.9%)

(I have no opinion)
26 (74.3%)

(Other: please comment)
0 (0.0%)

azurelunatic

Title:
Differentiating inbox notifications from suspended users

Area:
inbox, suspension

Summary:
Inbox notifications should differentiate what kind/where a message from a suspended user originated.

Description:
Currently inbox notifications involving suspended users all have a very uninformative "(Reply from suspended user)" giving the username of the suspended user.

It would be good to at least differentiate between different types of notification (comment, private message -- poll vote? birthday notification?). It would be extra-fancy if there was more information, like, was it a comment in your own journal, a reply in another journal or community (when that goes through the inbox), a comment on something you're tracking, or other information to better contextualize what's going on.

Turns out it's startling when someone with an entirely locked journal doesn't realize they have private messages turned on, they get a message from a spammer who is subsequently suspended, and they have a sudden moment of alarm wondering if there was some kind of security incident. Situations like this could be better avoided with more context for inbox messages.

Poll #14595 Differentiating inbox notifications from suspended users

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
2 (5.6%)

(Other: please comment)
0 (0.0%)

marahmarie

Title:
Make Sidebar and Tags Page Tag Counts Into Links

Area:
tags, styles

Summary:
On other websites (in all truth, I can't remember exactly which ones) I've seen tag counts (such as "News: 20 uses", for example) displayed as links. By clicking the number 20 in my example - or the whole line, "20 uses", depending on how exactly the usage count is worded/displayed - one is taken to a page that shows all uses of that tag, exactly the way clicking on the tag *name* itself works right now on DW. I would like to 1) see the tag count included in the tag name link, for both styling and accessibility purposes or b) make another link for the tag count itself.

Description:
Right now tag counts don't have their own CSS classes or any fine-grained styling options in the Customize Style interface (but these first two issues are initially covered in another suggestion I've recently made), nor do they display as links. On my own DW I often look at the tag counts, in the sidebar in particular, and wonder why they can't also possibly function as links. It seems intuitive that you might read a user's tag names, check the tag counts on each one, then might want to, for example, click through based on a particularly high or low number of uses on at least one or more of those tags. But the ability to click through on a tag count isn't there so as a mouse user, for example, you might have to swing your mouse back across the screen to click on the tag name instead. This could sort of be a hassle, especially if there's more than one tag you want to click through on. My solution is to simply linkify the tag counts.

Poll #14589 Make Sidebar and Tags Page Tag Counts Into Links

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (18.5%)

(I have no opinion)
12 (44.4%)

(Other: please comment)
0 (0.0%)

hebethen

Title:
Small change for filter option when posting an entry

Area:
Post an entry

Summary:
Right now, in order to designate an entry as viewable by a certain filter, one must select 'Custom' from the 'Show this entry to:' dropdown menu. Only then do the individual filters show up as checkboxes. I think it would be clearer if the option said something like 'Access Filter', or if the filter checkboxes were visible from the get-go.

Description:
Well, I'm not sure how much more I can say about it! Just that it's not very clear to a first-time user that there are Filters, and I remember I was a bit confused as to the wording of that dropdown menu option myself. If it's just a text change, it's a pretty minor thing and I don't think there are any drawbacks or problems.

On the other hand, listing out the filters and their checkboxes right up front would also solve the issue of clarity, and streamline the selection of a filter. I never really saw the point of having filters hidden until you select 'Custom', from a user's point of view. But I understand that it's probably more complicated, codingwise, to (e.g.) have the checkboxes right there and make the dropdown automatically jump to 'Custom' when the user clicks a checkbox.

Poll #13651 Small change for filter option when posting an entry

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
13 (41.9%)

Shouldn't be implemented.
3 (9.7%)

(I have no opinion)
9 (29.0%)

(Other: please comment)
0 (0.0%)

aedifica

Title:
When posting a new comment to a collapsed thread, automatically expand that comment and its parent

Area:
commenting, entries

Summary:
On collapsed comment threads, when you post a new comment you should see it expanded, not collapsed, and also the comment it's a reply to.

Description:
The current behavior for comment-heavy posts is that if you make a comment on a collapsed thread, when you hit "Post Comment" the next thing you see is that collapsed thread, with your comment also collapsed.

I propose that instead, when you hit "Post Comment" you then see everything collapsed (everything that would normally be collapsed, at least) except your new comment and the comment you were replying to. That way you can make sure you commented where you meant to and have a chance to notice all the typos that you never see until after you post.

(This is superficially similar to another suggestion, http://dw-suggestions.dreamwidth.org/1360804.html , but not identical to it or any other suggestion I've seen.)

Poll #13644 When posting a new comment to a collapsed thread, automatically expand that comment and its parent

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (13.0%)

(Other: please comment)
1 (2.2%)

pauamma

Title:
Display unregistered and renamed-without-redirect usernames as struck through

Area:
site-specific markup, renaming, registration, usability

Summary:
<user name="thisusernamedoesntexist"> is displayed with no strike through when the username was never registered, or was renamed to something else without redirection. This makes it harder to spot typos, and may have minor privacy consequences in the latter case. It should be made consistent with the way usernames of deleted accounts display.

Description:
Drawback: This would introduce an incompatible change for people who relied on the current behavior to display made-up generic usernames without having to register them or find ones already registered for that purpose, like "exampleuser". Finding one suitable for that purpose - eg, not that of an actual site user or community which might feel singled out - would become harder, and maybe even impossible without actually registering it, for languages other than English.

Poll #13088 Display unregistered and renamed-without-redirect usernames as struck through

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
2 (4.0%)

Should be implemented with changes. (please comment)
18 (36.0%)

Shouldn't be implemented.
16 (32.0%)

(I have no opinion)
11 (22.0%)

(Other: please comment)
3 (6.0%)

whipcracks

Title:
Sort Icon Page by Active/Inactive Status

Area:
icons

Summary:
On the View Icons page (and possibly the Upload Icon page) allow a sort option which will group Active/Inactive icons (preferably Active on the top/first page) together for ease of finding them.

Description:
Since there are already sorting options for Keyword and Upload Order, having this additional sorting option would be beneficial for accounts which have had paid or premium status previously and are expired, etc. particularly now that there are permanent icon slots available which increase the overall capacity of an account's icon slots.

I believe the method dictating which icons are left active go by most-used in journals followed by most recently uploaded? (I could be wrong on this, it's just what I've observed). However these options both leave active icons scattered through the overall icon page(s). Although the icon browser does only load active icons IF the user still has a paid, it doesn't help free accounts who may be trying to search out 15 active icons from 100, 250, or even more.

I'm not foreseeing any immediate problems if this were implemented due to the fact that there are other existing sort options, but if anyone spots something I've missed...?

Poll #12197 Sort Icon Page by Active/Inactive Status

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.5%)

(I have no opinion)
7 (10.4%)

(Other: please comment)
1 (1.5%)

ladyasul

Title:
Long ECHI could stand to get broken up

Area:
comments, comment display

Summary:
When the ECHI (Explicit Comment Hierarchy Indicator) gets very, very long, like in a 100+ comment-deep thread, it can do odd and ugly things to the layout. Perhaps it could be broken up with spaces, every so many levels, to avoid mauling page formatting and allow it to wrap and improve ease of reading/understanding?

Description:
On comment pages, when a thread of comments gets very long (as often happens in some conversations, but mostly happens in roleplay threads, in my experience) the ECHI (Explicit Comment Hierarchy Indicator) can get VERY long. As in, absolutely ridiculous. It stretches comment headers and collapsed comments alike, and tends to make the layouts I've tried, including the site-schemed pages, behave poorly because of it.

Plus, after a while, it simply seems to blur into one long trail of characters, to try to read it. Phone numbers are broken up into groups of usually 3 and 4 digits for readability (and ease of remembering.) It would be great if the ECHI output could be broken up as well (by spaces every so many characters?) so that it could be made more human-readable and wrap within comment headers, too.

For example, one actual ECHI from an RP thread I was trying to read is 326 characters long (counting the period at the end.) It would be far nicer if it could be displayed more like this instead:

86a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a.

My default font size is fairly normal (14-15px) so I can only imagine how badly the page layouts would break for someone who has their font sizes set much higher for eyesight reasons.

I've tried mucking about with Stylish to make the comments' headers and the collapsed comments simply scroll sideways when this happened, but couldn't find CSS which would do this to my satisfaction and still let the comments stretch horizontally with the page how I wanted them to.

As it is, I switched accounts just so I could read that thread without scrolling horizontally to read each comment's text.

I'm not sure what drawbacks such a fix would have. Maybe there would be disagreements over where to add the spaces so that the ECHI can be wrapped, or it would be difficult to implement? I know that long ECHI strings aren't an issue for most people, but it would be nice for something like this to be implemented for those times where it does become an issue.

Poll #11554 Long ECHI could stand to get broken up

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (30.2%)

(Other: please comment)
1 (2.3%)

pauamma

Title:
Merge full FAQ search form into FAQ list

Area:
User documentation

Summary:
Add a language field to http://www.dreamwidth.org/support/faq (like http://www.dreamwidth.org/support/faqsearch has) and redirect http://www.dreamwidth.org/support/faqsearch into http://www.dreamwidth.org/support/faq.

Description:
There's no real reason to have a separate search form since there's ample space for the one missing field (FAQ language), and the complete form isn't linked from the simplified one, meaning the only way to find it is through the sitemap. Then, the site map should be updated to merge the 2 items, and likewise for any applicable menus. (I can't use them because they don't work for me, so I don't know what's in them.)

Alternatively, there should be a link to the complete search form from the FAQ list (but since thw in-index search was added to avoid that, that's a markedly poorer solution.)

Poll #11271 Merge full FAQ search form into FAQ list

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (43.9%)

(Other: please comment)
0 (0.0%)

waterbends

Title:
Disabling the automatic population of "re:" in comment subjects.

Area:
comments

Summary:
Dreamwidth is a site heavily utilized by the online RP community. The "re:" that populates automatically in subject headers can be really annoying, and we would love the chance to disable them!

Description:
Is there any sort of option for us to turn off the automatic "re:" that appears in subject headers? If not -- is it possible at all to create that option for us?

Take a look at the RP-based post here: http://adstringendum.dreamwidth.org/414634.html

Every single one of the almost 300 comment replies has had to manually remove the "re:" that automatically populates in the subject header, and it's a pain in the butt to have to do it when you're replying via phone. It gets really, really tedious, especially when you're churning out dozens of tags in a sitting.. and the header itself is necessary, because the mode of communication is something that's important to keep track of. Having a way to disable that would be just plain AWESOME!

Thank you so much.

Poll #11270 Disabling the automatic population of "re:" in comment subjects.

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
66 (56.9%)

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

Shouldn't be implemented.
23 (19.8%)

(I have no opinion)
23 (19.8%)

(Other: please comment)
0 (0.0%)

ciaan

Title:
don't show comments I've posted in the "latest received"

Area:
recent comments management

Summary:
I want "comments received" to be only the comments I actually received from other people, not things I said myself.

Description:
I always get annoyed when I check the comments management page to look at the recent comments I've received and the list includes comments by me. Those are obviously duplicated in the recent comments I've posted section. And it means that I am not actually seeing the latest 150 (or whatever other number allowed) of comments that I have received from other people. I want "comments received" to be only the comments I actually received from other people, not things I said myself.

Poll #11120 don't show comments I've posted in the "latest received"

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (3.1%)

(I have no opinion)
16 (25.0%)

(Other: please comment)
0 (0.0%)

swaldman

Title:
List box on the Manage Tags page should remember position

Area:
Manage Tags page

Summary:
The list box on the Manage Tags page should remember your position when the page is reloaded.

Description:
http://www.dreamwidth.org/manage/tags has a list box with a huge great list of all the tags in my journal. Sometimes I go through merging or renaming to catch spelling errors. (OK, I have done this once. I like to imagine I am more organised). When doing this, when I click Rename, Merge, or whatever, it does the requested operation and then reloads the page with the list of tags back at the top. When the list is long, this is annoying.

I don't care about long-term , but it would be good if it could remember my position in the list within a single session.

Poll #11119 List box on the Manage Tabs page should remember position

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (26.4%)

(Other: please comment)
0 (0.0%)

Dreamwidth Suggestions

"Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

Quick jump to next/previous entry

System for Marking Entries to Read Later

Have previews load on same page in small pop-ups

Create Entries beta : help button for HTML and Markdown

Add time/date stamp to Inbox messages

Allow linking to parent comment with only one child thread

Add ability to add a Memory without leaving the page

Provide OPML feed import/export options

Differentiating inbox notifications from suspended users

Make Sidebar and Tags Page Tag Counts Into Links

Small change for filter option when posting an entry

When posting a new comment to a collapsed thread, automatically expand that comment and its parent

Display unregistered and renamed-without-redirect usernames as struck through

Sort Icon Page by Active/Inactive Status

Long ECHI could stand to get broken up

Merge full FAQ search form into FAQ list

Disabling the automatic population of "re:" in comment subjects.

don't show comments I've posted in the "latest received"

List box on the Manage Tags page should remember position

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate