dw_suggestions | Entries tagged with page: entries

Title:
Password protect posts so non-DW friends can be included

Area:
entries

Summary:
Add an additional security option between "public" and "friends" where the post is viewable to anyone with the correct password. This would allow users to include friends without DW accounts in non-public posts.

Description:
It's been a few years since this was last suggested ( http://dw-suggestions.dreamwidth.org/147407.html ). Maybe opinions have changed.

WordPress has a password protected post option ( http://en.support.wordpress.com/posts/post-visibility/#password-protect-a-post ). A post with this security setting is viewable to anyone with the correct password. The public and RSS readers can see that a new post is there, but you must enter the password to read the actual content. This allows you to have non-public content available to friends who don't have an account on the site (or who use OpenID). I'd like to see something akin to that implemented here.

A modification suggested in the comments last time would also include the option to make the post (including password prompt) viewable only by direct link.

Having it not only gives you greater control over who outside the site can see your content, it might just pull in new users. They'd come to the site to read your posts, see how it works, and maybe just be tempted to try it themselves.

So it works like this:

Between "Public" and "Access List," there would be an additional security option labeled "Password Protected." When you select that, you enter a password. When the post goes up, you have what amounts to a cut tag hiding the post's contents (including comments) until the reader enters the correct password. An additional sub-option (available via checkbox, perhaps?) would allow you to make even the password prompt viewable via direct link only. Crossposts would link back to DW, where readers would be prompted for the password.

Poll #15787 Password protect posts so non-DW friends can be included

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
9 (16.7%)

Shouldn't be implemented.
23 (42.6%)

(I have no opinion)
12 (22.2%)

(Other: please comment)
0 (0.0%)

snitter

Title:
Comment Threads: Full Collapse

Area:
Comment sections

Summary:
Comment ignore function: implement an option which allows comments and associated threads to be fully collapsed and hidden, showing a placeholder that says "This comment is hidden, click to unhide it".

Description:
Collapsable comment threads:

Allow users to collapse and hide individual comments + threads, effectively giving users the option to put comments and their associated threads "on ignore". Once hidden, the comment will be replaced with generic placeholder text that reads "This comment is hidden, click to unhide it". The comments can be unhidden with the press of a button.

This would be useful the event that a thread becomes long and begins stretching the page, requiring excessive amounts of scrolling to reach the bottom, or if the comment contains an image or discussion content that a user doesn't want to see.

This option is easily implemented with a javascript function, and already exists on certain *chan boards.

Thanks in advance for your consideration!

Poll #15504 Comment Threads: Full Collapse

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (11.4%)

(I have no opinion)
8 (22.9%)

(Other: please comment)
1 (2.9%)

stormy

Title:
[css] Add admin-post css to entry-wrappers.

Area:
styles, entries

Summary:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others.

Description:
When you mark a comment as an official admin/mod hat comment, it applies the admin-post class to the comment's comment-wrapper, but the same does not happen when you mark an entry as official. The entry-wrapper does not gain a admin-post class. I suggest that it does so you can use css to format those posts separately from others. Personally, I'd love to use this as a way to call more attention to those specific entries without having to use a .poster class and have everything marked by a specific user stand out.

An additional suggestion related to this: At current the class .admin-post gets added to comments when they are made official moderator comments. It might be easier to suggest this css is changed to .admin-comment if it is a comment and .admin-post if it is added to an entry. This isn't a necessary step because you could format with ( .entry-wrapper .admin-post AND .comment-wrapper .admin-post ) but it might just be cleaner for those who don't like listing multiple classes together to specify.

Poll #14085 [css] Add admin-post css to entry-wrappers.

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (34.2%)

(Other: please comment)
0 (0.0%)

ninetydegrees

Title:
Comments: also display as admin text and icon in collapsed comments

Area:
comments, communities

Summary:
(as admin) is currently only displayed after's one username if the comment isn't collapsed. I think it could be useful to spot admin comments at a glance instead of having to expand everything.

Description:
.

Poll #13979 Comments: also display as admin text and icon in collapsed comments

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
37 (75.5%)

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

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
11 (22.4%)

(Other: please comment)
0 (0.0%)

deborah

Title:
Add "share" to the interaction links

Area:
entries

Summary:
Dreamwidth isn't a platform for tumblr or twitter style reblogging / retweeting, but it would be nice if it were easier to share others' posts with your readers. Luckily, the functionality is already in the code base! It's just not exposed via the UI.

Let's expose the "share" functionality via the UI.

Description:
We have this awesome share functionality in the code base. If you go to the URL

http://www.dreamwidth.org/update?share=http://dw-news.dreamwidth.org/2013/06/11/dw-news-11-jun-2013.html

You get a new post window, ready for editing, with the subject:

dw_news | Dreamwidth News: 11 June 2013

and the body:

<a href="http://dw-news.dreamwidth.org/2013/06/11/dw-news-11-jun-2013.html">dw_news | Dreamwidth News: 11 June 2013</a>

This is awesome, and we should expose it via the UI, probably in the interaction links, with "track", "share", etc. (The share URL will also work for external sites, but unless someone writes a bookmarklet or some such that's harder to work with in our UI.)

Changes to the current interface I'd suggest:

* Make it work with https (it currently doesn't)
* For dreamwidth internal URLs, change the format of the body text to

<user name="dw-news"> said "<a href="http://dw-news.dreamwidth.org/2013/06/11/dw-news-11-jun-2013.html">dw_news | Dreamwidth News: 11 June 2013</a>".

Poll #13972 Add "share" to the interaction links

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

View Respondents

This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
9 (19.6%)

Shouldn't be implemented.
10 (21.7%)

(I have no opinion)
9 (19.6%)

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

oyceter

Title:
Change "Expand" alt text on cut tag icon to "Collapse"

Area:
accessibility, images

Summary:
Change the alt text on the right-pointing arrow on a cut tag from "Expand" to "Collapse" once the user has clicked on the tag or arrow and expanded the cut tag.

Description:
I browse the site with images off, and sometimes I get confused if I've expanded a cut tag or not because the alt text for the cut tag icon reads "Expand" no matter what state the cut tag is in. If the alt text is changed to "Collapse" when the cut tag is expanded, it will hopefully improve accessibility for people who browse the site without images.

Possible drawbacks: I'm not actually sure how this would work in a screenreader.

Poll #13125 Change "Expand" alt text on cut tag icon to "Collapse"

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (21.8%)

(Other: please comment)
2 (3.6%)

equationhouse

Title:
Having the option of tags appearing at the TOP of entries

Area:
tags

Summary:
Having the option of displaying tags above the actual text portion of an entry would be beneficial in many ways, detailed below.

Description:
As things currently stand, I am under the impression tags appear under the main portion of an entry, and that there is no way to choose otherwise. I remember on LJ there was an option to display many things about an entry above it instead, such as mood, location, etc. I feel that having similar options here on DW, particularly regarding tags, would benefit a great number of people. Particularly, I know that it would help myself and a great deal of my friends who would benefit from having a choice other than completely cutting entries that might be of an upsetting or "triggering" nature.

Tagging entries as triggering is, so far, rather ineffective, since people tend not to see the tags until they have already read at least a good portion of an entry. If these tags were, however, to be placed above an entry, it would be much easier to avoid reading potentially upsetting entries if desired.

Poll #12621 Having the option of tags appearing at the TOP of entries

This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 46

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.2%)

(I have no opinion)
15 (32.6%)

(Other: please comment)
2 (4.3%)

gerald_duck

Title:
I want the date format "Sat 2012-12-01" (or custom date formats)

Area:
Internationalisation/time and date

Summary:
I always use ISO format dates, so definitely want my journal displayed using those. However, in the context of a blog it's also useful to know on what day of the week a posting or comment was made, so it would be nice to have day-of-week followed by ISO date.

Description:
As per the title, and for the reasons in the summary, I would specifically like the date format "Sat 2012-12-01".

However, I have no idea how many other people would like that specific format. Maybe it would be good instead to provide a mechanism for users to specify custom date and time formats?

There are already existing standards for this, such as the trusty old POSIX strftime ( http://pubs.opengroup.org/onlinepubs/009695399/functions/strftime.html ), ICU format strings ( http://userguide.icu-project.org/formatparse/datetime#TOC-Date-Time-Format-Syntax ) or the Microsoft one familiar to users of Windows and/or Excel ( http://msdn.microsoft.com/en-us/library/8kb3ddd4.aspx ).

It would be good to use one of those rather than reinventing the wheel. My vote would be for ICU, provided that library is available to the DW platform.

Poll #12340 I want the date format "Sat 2012-12-01" (or custom date formats)

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.5%)

(I have no opinion)
21 (47.7%)

(Other: please comment)
1 (2.3%)

azurelunatic

Title:
View entryprops for your own journal/administrated community

Area:
entries, self-service support

Summary:
Staff and senior support have the at-need ability to view some of the troubleshooting information attached to entries; this information could be useful to the journal owner.

Description:
All entries have under-the-hood information called "entryprops" (short for "entry properties") attached to them. Staff/senior technical support can view these at need.

Usually there's no need to view this information, but sometimes there's a simple question (like: did all my icon information successfully make it over when I imported? Generally the importer gets this right, but it's usually more reassuring to see for yourself) that could be answered. (And doubtlessly if it were readily available, there would be more helpful uses for it floating around.) It also strikes me as information that would be useful to a community administrator, if it's available to journal owners.

How would it be viewable? (For all of the cases below, this would only be for the journal owner/community admin; if someone didn't have permission to see if they would get an error.) I have a few thoughts.

1) Create a page where you can enter the link to an entry in your own journal (or your community), and the properties are displayed. This is simple and pretty straightforward, does not require monkeying around with any existing pages, but not entirely friendly.

2) Create a URL argument (like the ?view=flat that you can add after the entry in the address bar) to display it on/from the entry. This would be reasonably friendly, but would probably take a lot more developer doing, and you'd have to look up how to do it if you didn't remember and needed to use it. (Depending on what was less of a pain to develop, I would see this as either adding information to the existing display, or going to a new location containing the information and a link back to the regular view of the entry.)

3) Have a little link/toggle near the rest of the entry information (depending on which was less of a pain to develop as described above), labeled "advanced entry information" or similar, to make it discoverable by people who don't already know to look it up.

Questions about the advisability:

1) Is there enough need for this information that someone couldn't just go ask Support? Senior support could tell people better than I could how often they get requests that require entryprops information.

2) Would this answer more questions than it would cause? It would not be fair to Support to release a feature that would cause a deluge of "What's a ____ and why do ____???!?!" questions. If this is implemented, someone grab me and I will write docs.

3) Would any information be revealed that a community administrator shouldn't have?

4) Would any information be revealed that is Dreamwidth-internal and a user shouldn't have? (I doubt it, but I ask for completeness; staff would have to answer this one.)

Development: This sounds like the sort of high-complexity, low-impact project that might sit for 10 years without being claimed.

Poll #12339 View entryprops for your own journal/administrated community

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (76.3%)

(Other: please comment)
0 (0.0%)

thomasneo

Title:
Replace the existing spaces between the brackets in the comment form to non-breaking spaces

Area:
Comment Form Design

Summary:
Same as title.

Description:
Some layouts in Dreamwidth—especially the non-fixed width types—don't specify a width for the brackets in the comment form, so the brackets get wrapped like this.

(http://z5.ifrm.com/30174/148/0/f5154599/SS1.jpg)

I presume this is an oversight, since the brackets do align correctly when viewed in site skin.

(http://z5.ifrm.com/30174/148/0/f5154600/SS2.jpg)

Hence, I suggest to replace the existing spaces between the brackets to non-breaking spaces.

(http://z5.ifrm.com/30174/148/0/f5154601/SS3.jpg)

Advantages:
- A better looking comment form

Disadvantages:
- May break some users' layouts
- May break some Dreamwidth layouts

Poll #12199 Replace the existing spaces between the brackets in the comment form to non-breaking spaces

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.0%)

(I have no opinion)
14 (35.0%)

(Other: please comment)
0 (0.0%)

Edit: Images are now fixed.

chagrined

Title:
Remove unnecessary whitespace from embedded objects

Area:
Entries

Summary:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries to avoid problems with nesting iframes. I want to remove that extra whitespace by fixing the iframe style instead so that the nesting does not cause problems. This will give users more control over entry flow/layout.

Description:
Currently Dreamwidth adds an extra 50 pixels of blank space to embedded objects in entries. I assume this was done because if a user embeds an iframe object in an entry, the Dreamwidth code puts that iframe inside another iframe, and then if the two iframes are the same size, you get scroll bars because the body tag in the outer iframe has a margin of 8px around it (in my browser; other browsers may add other margin sizes). Thus, someone wrote some code to add an extra 50px to the width and height of the outer iframe object.

Unfortunately, this leads to an extra 42px of whitespace below the embedded object (in addition to the 8px of whitespace above and to the left and right). Visually this looks like a bunch of extra line breaks under an embedded object, and makes it frustrating when one is, for example, trying to add text after that object (as an explanation/comment, etc.), because it will show up several lines below. It makes it harder for users to control the visual layout of their own entry because there is no way to get rid of this unnecessary whitespace.

My solution is a patch I have already successfully tested out on my Dreamhack account. It will remove the extra 50 pixels of blank space. Instead, the outer iframe's body tag will be given a style with a margin/padding/border of 0. Then both iframes can have the same height/width. There won't be problems with scrollbars and there won't be lots of unneeded whitespace. As with an image or anything else that can be inserted in a Dreamwidth entry, users will be able to control how much space they want around embedded objects.

Poll #12194 Remove unnecessary whitespace from embedded objects

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (37.5%)

(Other: please comment)
0 (0.0%)

kate_nepveu

Title:
view screened comment upon posting in the same manner as unscreened comments

Area:
comments

Summary:
When you post a screened comment, you're taken to a page that says your comment posted, it's screened, and you can view it at this link. This requires an additional click to check the comment for typos, make sure it threaded properly, etc. You should instead be taken to the comment in the same way you would be if it were not screened.

Description:
DW's reply-but-keep-screened setting is awesome but conducting conversations in screened comments is still more cumbersome than it could be because of this intermediate success-but-screened page. The indication on the entry page itself that a comment is screened should be sufficient to notify the commenter.

Poll #11814 view screened comment upon posting in the same manner as unscreened comments

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (9.5%)

(I have no opinion)
11 (17.5%)

(Other: please comment)
0 (0.0%)

swaldman

Title:
Allow mailto: links in the Links module

Area:
Journal modules

Summary:
It is not possible to add a mailto: link to the "Links" module. I would like to be able to do so.

Description:
At present, if I fill in "mailto:my@email.com" as a link target for the Links module, it gets rewritten to "http://my@email.com", which is obviously something entirely different.

I don't know whether there is a reason for not allowing email links, and thus whether it is intentional that it can't be done, or whether this is an unintended side-effect of tidying up URIs. If it's not a deliberate choice, I think that email links should be allowed.

Poll #11748 Allow mailto: links in the Links module

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
22 (41.5%)

(Other: please comment)
0 (0.0%)

msilverstar

Title:
cut expander should show error when accessing protected post

Area:
page: reading, cut tags

Summary:
Right now, if a reader had access to an entry but doesn't any more, clicking on the cut expander doesn't open the cut -- correct behavior -- but also doesn't display an error message. It's very confusing. Clicking on the cut itself takes the reader to an error page where all is made clear, so a little JavaScript error on the reading would be nice.

Description:
Granted corner case, having opened a reading page when one had access but no longer, due to the poster changing the security, the reader logging out in another tab or window, or the system logging the reader out.

In that case, clicking the disclosure triangle to expand the cut flickers but doesn't expand, and doesn't explain why. It seems like the features is broken. Better error handling would be good.

Poll #11556 cut expander should show error when accessing protected post

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

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
47 (90.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (9.6%)

(Other: please comment)
0 (0.0%)

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

emceeaich

Title:
Enable Embedding GitHub Gists as Media in Posts

Area:
posting, media

Summary:
Enable adding GitHub Gists, which are embedded as scripts, in posts, via the 'add media' option so that DW users can post short blocks of formatted source code for discussion and review.

Description:
Gists are text files hosted on GitHub enabling developers to post short snippets of code for review and comment.

GitHub provides a way to embed a gist on a site, as a script file:

<script src="https://gist.github.com/3290622.js?file=foo.js"></script>

However, DW wisely prevents scripts from being embedded as either media or post content because XSS :)

But adding gist.github.com to a whitelist would enable coders of all skill levels to quickly post nicely formatted snippets of code for review, discussion, and comment.

Poll #11553 Enable Embedding GitHub Gists as Media in Posts

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
30 (56.6%)

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

blue_rampion

Title:
Change date format in site-styled entries

Area:
entries, site

Summary:
Instead of displaying the date in site-styled entires numerically, the month should be displayed as the name of the month.

Description:
Currently, all dates on site-styled entries are displayed numerically in the year-month-day order. But not everyone in the world is used to that order, so this can cause confusion for readers used to differently-ordered dates - particularly when the day is 12 or under. I'm used to dates being written with the day before the month, and I'm always having to stop and think about dates when I'm reading and remind myself that a date like 2012-07-03 is actually July and not March.

I suggest that dates instead be written with the name of the month in text, because regardless of what order you are used to for dates there's no chance for confusion.

Other solutions could include allowing users to set the order for all dates in their account settings. The benefit here is that everyone could have dates set up exactly how there are used to. But, I would imagine that this would be more difficult to implement and could increase decision fatigue.

Poll #11029 Change date format in site-styled entries

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

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
12 (24.0%)

(I have no opinion)
6 (12.0%)

(Other: please comment)
1 (2.0%)

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

View Respondents

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

Dreamwidth Suggestions

Password protect posts so non-DW friends can be included

Comment Threads: Full Collapse

[css] Add admin-post css to entry-wrappers.

Comments: also display as admin text and icon in collapsed comments

Add "share" to the interaction links

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

Change "Expand" alt text on cut tag icon to "Collapse"

Having the option of tags appearing at the TOP of entries

I want the date format "Sat 2012-12-01" (or custom date formats)

View entryprops for your own journal/administrated community

Replace the existing spaces between the brackets in the comment form to non-breaking spaces

Remove unnecessary whitespace from embedded objects

view screened comment upon posting in the same manner as unscreened comments

Allow mailto: links in the Links module

cut expander should show error when accessing protected post

Long ECHI could stand to get broken up

Enable Embedding GitHub Gists as Media in Posts

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

Change date format in site-styled entries

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

Profile

Most Popular Tags

December 2018

Page Summary

Active Entries

Style Credit

Expand Cut Tags

Syndicate