[personal profile] alexbayleaf

Title:
Allow comments by replying to email notification

Area:
email, comments

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

Poll #12343 Allow comments by replying to email notification
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

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

(Other: please comment)
1 (2.1%)

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

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:

View Answers

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

(Other: please comment)
1 (1.5%)

theplotbunny: (Default)
[personal profile] theplotbunny

Title:
smaller and simpler uploading for icons by screen reader users

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!

Poll #4947 smaller and simpler uploading for icons by screen reader users
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

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

(Other: please comment)
2 (6.5%)

florahart: (snailp)
[personal profile] florahart

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

Area:
notifications

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:
When a post is longer than some limit, emailed comments fail to work tidily. In Gmail specifically--and maybe in other services--the comment and the links to the entry get cut off in favor of showing the first X amount of the body of the entry to which the comment is made, and instead there's a link to see the full message text. I have to then open that link in order to A. see the comment, and B. see the other links that come with notifications, such as view all comments to this, answer this, view this thread. So basically the notification doesn't tell me anything except there IS a comment, and then if I want to see what that comment IS, I have to open the message, click a link, wait for a separate tab to load, and THEN if I want to go to the entry to reply, click ANOTHER link and wait for a tab to load, which is just annoying.

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
link to entire body plus comment and other links

would go

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

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:

View Answers

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

(Other: please comment)
3 (5.9%)

briarwood: Gal Godot as Wonder Woman (Default)
[personal profile] briarwood

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

Area:
Comments

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:

View Answers

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

(Other: please comment)
4 (6.3%)

lightgetsin: The Doodledog with frisbee dangling from her mouth, looking mischievious, saying innocence personified. (Default)
[personal profile] lightgetsin

Title:
Reformat email comment notifications to show comments on large entries

Area:
notifications

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:

View Answers

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

(Other: please comment)
2 (4.8%)

kaigou: this is what I do, darling (Default)
[personal profile] kaigou

Title:
Add help icon/text to Profile page

Area:
help, profile, usability

Summary:
Add information-icon to colored-strip header lines on Profile page.

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:

View Answers

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

(Other: please comment)
1 (5.0%)

hatman: HatMan, my alter ego and face on the 'net (Default)
[personal profile] hatman

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:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (42.3%)

(Other: please comment)
0 (0.0%)

stealthily: kim pine from scott pilgrim in a yellow bikini, her arms folded and side-eyeing someone (Default)
[personal profile] stealthily

Title:
Secure Login Option in Preferences

Area:
login, security, privacy,

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:

View Answers

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

(Other: please comment)
1 (3.8%)

feathertail: (Default)
[personal profile] feathertail

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:

View Answers

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

(Other: please comment)
1 (2.8%)

feathertail: (Default)
[personal profile] feathertail

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:

View Answers

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

(Other: please comment)
1 (5.9%)

pseudomonas: (Default)
[personal profile] pseudomonas

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:
I use my OpenID as an identity on sites X,Y, and Z (which I may forget about subsequently, the Internet and my memory being what they are). I delete my DW account, and you buy the username. You then find out that site X thinks you're me (not allowing you to change "immutable" details such as date of birth) and site Y has banned the username for abuse. Site Z has personal information about me in that you now have access to and which I cannot revoke. My friend has given the OpenID read-access to her journal on a remote site - you can now read her locked entries.

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:

View Answers

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

(Other: please comment)
1 (3.2%)

leonard_neeble: "The entire truth is often dull." (Default)
[personal profile] leonard_neeble

Title:
Preserve username tags in crossposter

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:
<user name="whoever.livejournal.com">

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

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 [personal profile] cesy 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:

View Answers

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

(Other: please comment)
2 (6.5%)

syderia: lotus Syderia (Default)
[personal profile] syderia

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

Area:
e-mail comments notification

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:

View Answers

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

(Other: please comment)
1 (1.7%)

zvi: self-portrait: short, fat, black dyke in bunny slippers (Default)
[personal profile] zvi

Title:
Add suggestions generator to Create menu

Area:
suggestions

Summary:
Add the suggestions generator to the Create menu

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.

Poll #1019 Add suggestions generator to Create menu
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

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

(Other: please comment)
1 (3.1%)

kaigou: this is what I do, darling (Default)
[personal profile] kaigou

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:

View Answers

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

(Other: please comment)
0 (0.0%)

ivorygates: (Default)
[personal profile] ivorygates

Title:
Add Posting Filters to Communities

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:

View Answers

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

(Other: please comment)
1 (2.6%)

Profile

Dreamwidth Suggestions

April 2017

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

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom