10:52 am

Title:

Area:

Summary:
Use the same mechanisms used for post-by-email to allow comment-by-email. That is, comments by email should only be allowed from your registered address(es), and you should have to enter a PIN.

Description:
Currently DW allows post-by-email (http://www.dreamwidth.org/manage/emailpost) but doesn't allow you to reply to comments by email. This proposal adds commenting while avoiding some of the security problems that Livejournal (allegedly?) has with their reply-form-in-the-email solution.

Basically, we just add an option to the "mobile post settings" saying "Also allow comments by email". When commenting by email, you would have to put the PIN in the text of the comment. We could specify eg. that it should be the first line of the comment:

PIN: blahblah

A simple regexp should be able to strip PINs from comments and then check them against the user's actual PIN and make sure it's the right one.

The comment notification email should include a message to the effect of "Want to reply via email? Set it up here." (if you aren't registered for email replies) or, "To reply by email, simply reply to this message and include your PIN as described here" (with a link to the help or whatever).

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

This suggestion:

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

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

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
17 (35.4%)

1 (2.1%)

### Comment moderation tool: disemvowelling et al

12:41 pm

Title:
Comment moderation tool: disemvowelling et al

Area:
comment moderation

Summary:
Introduce a reversible "mask" that may be turned on at a comment-by-comment level by a journal owner or community administrator, that initially displays a particular comment slightly obfuscated, serving as a warning that anyone who puzzles out the comment as displayed, or goes through to read the full version, that they do so at their own risk.

Description:
Current comment moderation tools involve leaving any possibly problematic (for any reason) comments in place, adding more comments, deleting the possibly problematic comment(s), screening them so only the journal owner/admins and the comment creator can see it, and disallowing any new responses to a particular comment or thread.

Missing from this toolbox is an option that leaves the comment in place, but in a way that clearly signals to a reader that while they *can* read this comment, they may not *want* to, and in a way that is friendly to the sort of fast reader who can take in a paragraph at a time before their brain has caught up with the idea that they may not want to read that, but also in a way that is friendly to someone who already struggles to read the text as presented.

Unlike similar tactics on self-hosted blogs, this would not involve actually editing the comment left by the other party. It would alter the display of the comment, with a clear notice that the display had been altered, and a control that any reader could use to view the comment as originally written.

This could be used for abusive comments, controversial/flamebait/triggery topics, and probably also spoilers and content warnings, and for comment-space games and other fun uses. (Owners might like the ability to proactively turn this mode on to set every comment this way at posting time, for entries likely to collect heated response, or for games. Commenters might like the option to self-moderate in this fashion for games and potentially triggery content.)

Options for the form of alteration could include:

Disemvowelling, where all vowels detected in the original are removed, making text that can often be puzzled out slowly without reversing the obfuscation. Can be read faster by someone who's used to it, makes hash of most HTML included. Popularized & I believe invented on Making Light, where I believe it's done by hand. Suitable for English; not so suitable for languages where vowels are implied rather than stated already; can be trivially defeated by writing in 1337 and other character-substitution methods; would need to have non-Roman vowels identified also.

ROT13, where all characters are moved around 13 places in their alphabet. (This is most useful for alphabets with 26 letters.) This makes text that most readers have to work through character by character, but some very experienced readers can read through at speed. Many existing ROT13 functions leave punctuation and non-English characters intact.

Display of a warning message without context derived from original text. No chance of something leaking through due to algorithmic shortcomings, because nothing would show; 100% chance that anyone wanting to read the comment would would have to request its display, causing a certain amount of potential extra server load.

Display of a warning message with optional context (similar to a comment edit message) to be provided by the journal owner/community admin. For screenreader users, the context should probably appear before the control to reveal the original comment.

Poll #7753 Comment moderation tool: disemvowelling et al
Open to: Registered Users, detailed results viewable to: All, participants: 67

This suggestion:

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

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

Shouldn't be implemented.
15 (22.4%)

(I have no opinion)
14 (20.9%)

1 (1.5%)

01:12 pm

Title:

Area:
icons

Summary:
I had already put in a support request after my screen reader had problems uploading pictures, and many of these are already posted as userpics on LJ, and the list of several icons was confusing and nothing would upload after trying for well over half an hour. My community won't accept anything, saying each time the picture was too big, I would like a one-at-a-time option for screen reader users to make the process less stressful and also suggest an automatic 'picture/icon re-sizer' as a secondary suggestion.

Description:
I am essentially wanting to have a one-stop one pic at a time upload instead of the listed 'pictures 1,2,3, 4 etc, as I've no idea where I am with this, and that compounded my frustration with the icon uploading process. I followed all the steps and it rejected every single icon I wished to upload.

I think the fact it kept telling me my pictures were 'all' too big, especially as many of those chosen were already uploaded on livejournal indicate something is terribly wrong here. I suggest as one medium solution, the development of a 'automatic icon resizer, this would make sure all pictures were made the right size, conversely, the capacity to host larger pictures could become 'expandable' doing the same desired thing.

I feel that would not only benefit blind people wishing to upload as I have no way of knowing the exact visual dinensions of an icon, and I am not tech minded here, but it would smooth out the process.

Specifically, I feel that the fault in the uploading process I encountered, a related issue, where I could not upload anything, needs some investigation, I am still waiting for my support request to be looked at and hope it can be fixed. I fear though, that the rejection of all pics wholesale indicates some kind of bug, or compatibility issue.

The benefits of fixing this, and providing a one at a time uploading link for screen reader users, where better informed labels, or less script dependent buttons can be used or the like, would make it easier. Simple is best, and having too many bells and whistles can inadvertantly cause a lot of pain for people like me who just wish to upload a handful of icons to use in their posts and such. I can't get a default pic no matter what I do, please help!

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

This suggestion:

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (67.7%)

2 (6.5%)

### Allow comment emails to truncate the body and show the message for long posts

07:40 am

Title:
Allow comment emails to truncate the body and show the message for long posts

Area:

Summary:
DW allows a much longer post than other similar sites. Gmail (and maybe other services) thinks comments to such posts makes messages that are too long, so it decides what to truncate. I want to be who decides that.

Description:

This doesn't come up enormously often for me, but it does irritate me about to death when it does. I want to be able to control this behavior myself, and I don't think I can do it from the Gmail end (and also, I don't want to change my Gmail settings for all other messages anyway).

I'm envisioning something in the notifications tab that is an enable/disable ticky, maybe? Where the behavior I can enable is something like, if the total post-plus-comment length of an email notification is greater than X*, truncate the body of the post in the notification in order to ensure the comment appears in the email.

*X being maybe something like the max size of an LJ post, although as long as we are truncating content, it could possibly be quite a bit less than that. I imagine in most cases the first thousand words would be totally sufficient for me to understand what was being commented at. Where Gmail cuts off is maybe somewhere around half again the LJ-post max--I get back about 14,000 words before it cuts off.

So what I'm envisioning is, the notification would be an email that instead of going

20,000 words of body

would go

The first X words of the post content
a note that says the body text has been truncated

Poll #3463 Allow comment emails to truncate the body and show the message for long posts
Open to: Registered Users, detailed results viewable to: All, participants: 51

This suggestion:

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

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

Shouldn't be implemented.
3 (5.9%)

(I have no opinion)
11 (21.6%)

3 (5.9%)

### Copy of posts in email should respect cut-tag

09:22 am

Title:
Copy of posts in email should respect cut-tag

Area:

Summary:
When someone replies to a post, the emailed copy of the post should respect the cut-tag.

Description:
Every time someone comments on a post, the email I get includes a full copy of the post replied to, as well as their response. This is really useful.

However, with Dreamwidth allowing such huge posts, occasionally this makes for one giant email. For example, a 50,000 word story that needed at least five separate posts on LJ, fits into a single post here (which I love!). When someone comments on the story, I get the whole 50,000 words in an email, plus that comment, which might be just a few words. Gmail automatically truncates such big emails, which means I have to click through several times before I can even read the comment. The links to read and reply online are at the bottom, so I can't get to them easily either. Worse, when I'm checking my mail on my mobile phone I have to download a huge email and scroll through the whole thing to get to the part I want to read. This is really, really slow, and while I love having a copy of most posts so I can make sense of comments easily, in cases like this it's much more trouble than it's worth.

Would it be possible for the emailed copy of the post to either cut off at a certain length or, better still, to respect a cut-tag, so the copy looks like the version people will see on friends pages? That would be more than enough for me to know what is being responded to, and I'd actually be able to read the emailed comment.

Poll #2472 Copy of posts in email should respect cut-tag
Open to: Registered Users, detailed results viewable to: All, participants: 63

This suggestion:

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

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

Shouldn't be implemented.
18 (28.6%)

(I have no opinion)
2 (3.2%)

4 (6.3%)

12:59 pm

Title:

Area:

Summary:
When a post is very large and there is an email notification of a comment to it, Gmail will truncate the message after X characters. Probably other webmails do the same. This means that when you open the notification, you can't see the comment, or have access to the links to interact with it, like reply.

Description:
There are a few potential ways to fix this. If a post is larger than a set character count, the notification email could be reformatted so the comment is at the top, followed by the post, which will get truncated. Alternatively, the notification could truncate the entry already so that the comment still follows it like usual, but is sure to show up.

Poll #2057 Reformat email comment notifications to show comments on large entries
Open to: Registered Users, detailed results viewable to: All, participants: 42

This suggestion:

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

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

Shouldn't be implemented.
12 (28.6%)

(I have no opinion)
5 (11.9%)

2 (4.8%)

### Add help icon/text to Profile page

10:35 am

Title:
Add help icon/text to Profile page

Area:
help, profile, usability

Summary:

Description:
Adding a standard information-icon will direct new users right to the specific FAQ/help page that explains the relevant section of the Profile. For example, the subscription and access sections may not be immediately intuitive to new users, and providing a simple and obvious icon to "learn more about this" will help new users learn without complicating or cluttering the page for familiar users.

'Information icon' from the silk-icon set is viewable at http://www.famfamfam.com/lab/icons/silk/previews/index_abc.png -- it's in the 7th column, 7th icon down.

Poll #1832 Add help icon/text to Profile page
Open to: Registered Users, detailed results viewable to: All, participants: 20

This suggestion:

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

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

Shouldn't be implemented.
2 (10.0%)

(I have no opinion)
5 (25.0%)

1 (5.0%)

### More options when importing - add tags, set security, set icon

07:35 pm

Title:
More options when importing - add tags, set security, set icon

Area:
Importer

Summary:
When importing entries, have the options to add a new tag, apply an access filter, and choose a default userpic to/for the batch.

Description:
Mostly for those importing entries from multiple journals.

1. Have an option when importing to add a new tag to the entries being imported (in addition to any tags that may exist in the original entries).

This would help journal owners and readers keep track of what came from where.

It would also allow essentially the reading of the original journal. Anyone who wanted to review the original journal or catch up on it (and might not be on the offsite access list) could just click the tag to pull those entries out, sorted by date.

2. Additionally, have the option to import to an access filter. That is, apply an access filter to an entire batch of imported entries. Or, more generally, set a new minimum security level for the batch.

This would be used when importing a private journal or one with a specialized access list.

It would also allow the journal to be imported as a private archive, even if the journal being imported has a higher offiste security level.

3. Have the option to pick a different default userpic for a batch of imported entries (to be applied as a one-shot deal by the importer). Useful for when you don't want to import all userpics from the original journal but don't want the DW default userpic applied to the imported entries.

Downsides:

Higher resource demands on the importer.

Not sure what, if any, coding issues would be involved.

As cool as more flexibility/options/bells&whistles can be, increasing options can lead to increased chance of confusion and errors.

Poll #1814 More options when importing - add tags, set security, set icon
Open to: Registered Users, detailed results viewable to: All, participants: 26

This suggestion:

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (42.3%)

0 (0.0%)

### Secure Login Option in Preferences

02:32 pm

Title:

Area:

Summary:
In Gmail logins are normally sent unencrypted but there is an option in their settings menu to remember your preference to login securely every time without having to click the "secure" button. I would like this to become available on DW.

Description:
I would like to be able to login securely to DW every time since I use public computers where my usage is tracked, albeit not keylogged. In gmail there is an option to remember this preference, which has become essential since the gmail bot introduced last year that harvests the many unencrypted passwords sent out when logging into gmail. I would like an option for this put onto the account settings- privacy page.

Having said that, I do hope I haven't misunderstood the fundamental nature of passwords on DW. I looked in the FAQs but there was nothing about this topic.

Poll #1758 Secure Login Option in Preferences
Open to: Registered Users, detailed results viewable to: All, participants: 26

This suggestion:

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

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

Shouldn't be implemented.
2 (7.7%)

(I have no opinion)
4 (15.4%)

1 (3.8%)

### Replace "OpenID URL" field with "Name" and "Website" fields

04:46 am

Title:
Replace "OpenID URL" field with "Name" and "Website" fields

Area:
Posting comments when you aren't logged into Dreamwidth

Summary:
Make it easier for people to identify themselves, without confusing them with technical jargon.

Description:
This suggestion was prompted by discussion on http://dw-suggestions.dreamwidth.org/185270. Basically, the idea is that nobody knows OpenID exists, and they shouldn't have to be given a crash course just to be able to comment. But everyone has a website they call home, so having a "website" field gives them a chance to tell us who they are. And if their site plays nice with OpenID, then we all get the added benefit that we know they are who they say they are.

I also suggest adding a note right underneath, which says "LiveJournal users, enter the URL to your LiveJournal so that your identity can be verified using OpenID." Even if they don't know what OpenID is, that lets them know that their identity is being verified. Meanwhile, people who know what OpenID is will see that magic word, and know that we're doing authentication here.

Poll #1707 Replace "OpenID URL" field with "Name" and "Website" fields
Open to: Registered Users, detailed results viewable to: All, participants: 36

This suggestion:

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

Should be implemented with changes. (please comment)
17 (47.2%)

Shouldn't be implemented.
4 (11.1%)

(I have no opinion)
4 (11.1%)

1 (2.8%)

### Make "OpenID URL" thing clearer for LiveJournal users and others

02:33 am

Title:
Make "OpenID URL" thing clearer for LiveJournal users and others

Area:
Posting comments when you aren't a logged-in Dreamwidth user

Summary:
We need to make it clearer to LiveJournal users that they should put their LiveJournal's URL in the OpenID URL field.

Description:
Y'know the place where it asks for your "OpenID URL" in the comment form? The one time that a LiveJournal-using friend of mine (an intelligent, Linux-using friend, mind) commented on my Dreamwidth journal, he just left a comment as anonymous. Even though my auto-crosspost included text saying to use OpenID.

You can say the problem's that he didn't read all the way, but I think OpenID is confusing, poorly explained and not self-explanatory. It's remarkably convenient, but we haven't yet found a good way of telling people how to use it. And I think probably most of the LiveJournal users who come here won't know that they can. Blogger and WordPress users might be more savvy, but then again, they might not.

I'm not sure how well it'd go over to give totally new readers a mandatory crash course in OpenID. But I think we need to somehow make it more clear that if you have a LiveJournal (or other OpenID-enabled) account, this option is for you. To use terminology that they'd be familiar with, and to specifically call out LiveJournal and/or other likely sites as places you can bring your account from.

So I thought I'd put in a ticket suggesting that. >.>b

Poll #1705 Make "OpenID URL" thing clearer for LiveJournal users and others
Open to: Registered Users, detailed results viewable to: All, participants: 17

This suggestion:

Should be implemented as-is.
5 (29.4%)

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

Shouldn't be implemented.
4 (23.5%)

(I have no opinion)
5 (29.4%)

1 (5.9%)

### Forbid OpenID recycling

12:16 pm

Title:
Forbid OpenID recycling

Area:
OpenID

Summary:
DW is an OpenID provider. OpenID is becoming more widely used by a variety of types of site. When a journal name is deletd, purged, and re-sold, the associated OpenID is (AIUI) also re-sold. This presents privacy concerns.

Description:

Disadvantages: forbidding this means either no sale of reconditioned usernames, or those usernames being sold with their OpenID features disabled.

Alternatives: tell people deleting their journal in big letters that they should attempt to remember all the places they entered their OpenID and go around removing private details and/or deleting accounts on the remote sites and/or telling their contacts to revoke their privileges. I don't think this is often terribly feasible - one of the joys of OpenID is that it makes it easy to sign in and do stuff in lots of places without keeping track of lots of usernames.
Even for people who've never knowingly used OpenID at all, they may have read privileges such as those granted by DW's import tool.

I'd really rather there was a technical solution whereby this wasn't a problem. I'm not an OpenID expert; hopefully someone else in the community is!

Poll #1286 Forbid OpenID recycling
Open to: Registered Users, detailed results viewable to: All, participants: 31

This suggestion:

Should be implemented as-is.
11 (35.5%)

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

Shouldn't be implemented.
7 (22.6%)

(I have no opinion)
7 (22.6%)

1 (3.2%)

### Preserve username tags in crossposter

07:27 pm

Title:

Area:
crossposting

Summary:
If any "user name=" tag looks correct in a Dreamwidth post, it should also look correct in the crossposted copy of that post in your external blog.

Description:
Suppose I write a post on my Dreamwidth journal that mentions:
&lt;user name="whoever.livejournal.com"&gt;

On the Livejournal post that the crossposter creates, this text shows up as "[Bad username: whoever.livejournal.com]", even though if I write:
&lt;user name="tim"&gt;

in my original Dreamwidth post, that shows up correctly as a link to tim.dreamwidth.org, on the LiveJournal side.

I understand that you're supposed to use the "site" attribute -- however, from a usability standpoint, since "user name='whoever.livejournal.com'" shows up correctly on DW, it should also look the same on any crossposted versions of the same post.

ETA: I didn't quite understand the distinction between the Dreamwidth account whoever.livejournal.com and the LiveJournal account whoever before. So I'll amend my suggestion to suggest doing what suggests in a comment on this post.
Poll #1219 Preserve username tags in crossposter
Open to: Registered Users, detailed results viewable to: All, participants: 31

This suggestion:

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

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

Shouldn't be implemented.
2 (6.5%)

(I have no opinion)
5 (16.1%)

2 (6.5%)

### Shorter references to the original entry in e-mail comment notifications

07:47 am

Title:
Shorter references to the original entry in e-mail comment notifications

Area:

Summary:
Put only the subject and the x first characters of the entry instead of the whole text of the entry in the e-mail notification.

Description:
Right now, when someone comment on an entry (or a comment, but it's less of a problem) you wrote and you get the notification by e-mail, you see the whole text of your entry. If you had a big entry (fanfiction, pic!spam...) scrolling past it can get annoying fast.

Quoting only the subject and the 42 first characters (or another number) before quoting the comment would allow the original poster to identify their entry and get to the important information right away.

The text of the notification would go something like that :
User replied to your Dreamwidth entry titled [Title] which started with [the first 42 characters or whatever number]. Their reply was ...

Poll #1115 Shorter references to the original entry in e-mail comment notifications
Open to: Registered Users, detailed results viewable to: All, participants: 59

This suggestion:

Should be implemented as-is.
7 (11.9%)

Should be implemented with changes. (please comment)
25 (42.4%)

Shouldn't be implemented.
24 (40.7%)

(I have no opinion)
2 (3.4%)

1 (1.7%)

12:03 pm

Title:

Area:
suggestions

Summary:

Description:
I can never remember the URL of the suggestions generator, so whenever I want to make a suggestion, I wind up going to the suggestions community to find it. It's a niggling roundabout way to have to make a suggestion, and I'd like a more convenient method. Create seems to me like the most logical place to put it, although maybe just the site map would work.

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

This suggestion:

Should be implemented as-is.
7 (21.9%)

Should be implemented with changes.
21 (65.6%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (9.4%)

1 (3.1%)

### Accessible Layouts

11:40 am

Title:
Accessible Layouts

Area:
Identifying accessible layouts

Summary:
It'd be good to make it easier on folks with vision issues (or who use handhelds) so they can quickly and easily find layouts suited to their purposes.

Description:
I presume eventually DW will follow LJ's path of having provided layouts tagged (seasonal, colorful, minimal, etc). I think there needs to be a tag for users with vision issues, so they can quickly and easily find layouts that are usable with screen readers, screen magnifiers, even handheld devices. (The latter two work best with single-column layouts.)

The same tag, or an overlapping tag (meaning some layouts would qualify as both), would sort out the high-contrast or reverse layouts (stark white on black, stark white on wordperfect blue). Then another tag for layouts with default fonts greater than 14px, and a tag for low-contrast layouts, for users who actually *get* vision problems from too many high-contrast designs.

So there's the categories: vision-accessible, high contrast, low contrast, single-column, and large-font. If I were really dreaming, I'd suggest DW contact its user-comm for blind/vision-impaired users and invite them to be panelists/judges for reviewing/nominating which layouts are "screen-reader-friendly" versus "screen-magnifier-friendly". That way, layouts with that designation really are tested as being good for those purposes, and not just because a good-vision person (like me) says it looks like it satisfies the basic requirements.

(For more info and a great example of designing vision-friendly, see the BBC's info pages on accessible layouts: http://www.bbc.co.uk/accessibility/. It's a wealth of information.)

Poll #998 Accessible Layouts
Open to: Registered Users, detailed results viewable to: All, participants: 47

This suggestion:

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

Should be implemented with changes.
2 (4.3%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (6.4%)

0 (0.0%)

### Add Posting Filters to Communities

12:55 am

Title:

Area:
Entries

Summary:
Allow the creation of posting filters in communities, just as they are in personal journals.

Description:
There are times you, as an owner or moderator of a community, wish to speak to only a subset of the community, usually the other owners/moderators of the comm. You can set up posting filters in your personal journal to make an entry that's only visible to a selected group, but not in communities. Yes, you can do a workaround by sending your fellow admins email, but it can be useful [as well as easier] for there to be a record of "admin backchannel" right there in the comm itself. And right now, while a whole comm can be made private, you can't drop in posting filters to further create subsets.

If it existed, it could be managed by just adding another tickybox [or two] to the permissions the comm owner checks off when adding comm support personnel: one allowing the selected individual to see filtered entries, the other allowing them to create/edit filters. If the person left the comm, they would not longer be able to see such filtered entries; if they were removed as a moderator or administrator they could be removed from the filter. Their ability to delete filtered posts would be governed by the same permission they'd have to delete member posts, or, if they didn't have the user rights to create/edit filters, that could automatically deny them the user rights to delete filtered posts.

Poll #937 Add Posting Filters to Communities
Open to: Registered Users, detailed results viewable to: All, participants: 38

This suggestion:

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

Should be implemented with changes.
10 (26.3%)

Shouldn't be implemented.
9 (23.7%)

(I have no opinion)
6 (15.8%)

1 (2.6%)

## Profile

Dreamwidth Suggestions

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

No cut tags