denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
[site community profile] dw_suggestions: A User's Guide

So, you want to learn more about the [site community profile] dw_suggestions process! This entry will be made the "sticky entry" in the [site community profile] dw_suggestions community (replacing the existing one, which was starting to show its age) to serve as an introduction to the Suggestions process, Dreamwidth development, and just what the heck people should be keeping in mind while they're discussing things here.

Let us begin our magical mystery tour.

dw_suggestions: A User's Guide )

And that is Everything You Ever Wanted To Know About [site community profile] dw_suggestions But Were Too Shy To Ask Or Just Kept Forgetting To Bring Up! Any further questions?
marahmarie: Sheep go to heaven, goats go to hell (Default)
[personal profile] marahmarie

Title:
Add complete pre-filled custom s2 template for beginners on the Wiki.

Area:
Styles

Summary:
Add a complete, pre-filled custom s2 template on the Wiki for Dreamwidth s2 beginners that anyone can edit to add more example code as desired, to help users help themselves to more customized code without necessarily having to ask for help in one of the style communities or hunt down the exact page containing the code they want in the Wiki.

Description:
Ever wonder how to add something not given to you out of the box on your Dreamwidth journal, like an extra row of links in your DW's header or a second custom text box in your sidebar? So have I. The answer is you need a custom theme layer to add Dreamwidth's s2 code to - and you need to know or else figure out the right chunks of s2 code to add to it. By adding the right chunks of code you can make different things on your journal like the extra custom text box or basically almost anything that won't automatically be stripped out by the s2 compiler.

For the most part, if I have a question about how to write the correct code to pull off one of my latest ideas, I'll ask for expert help over in our style_system community and most of the time I'll receive excellent answers and help with all of the code wrangling needed. But not everyone is willing to wait on asking others for help and/or learning to any extent how the code works (or why it doesn't); they just want the shiny and to teach themselves the code for it (or ask for help in learning it) as they go along - maybe later, or maybe never.

The question in one's mind at this juncture may be, "Why should there be this big code hurdle for me to jump just to get at some of the shiny"?

So my suggestion toward this is based on our s2 Cookbook which is kept here: http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook

My idea is to keep the separate pages we already have on the wiki for adding modules (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Modules), making the heading work as a link (http://wiki.dwscoalition.org/wiki/index.php/S2_Cookbook:_Linking_the_title_on_your_journal_to_your_main_journal_page) and so on, and to add more pages for other similar functions as needed, but to also add a new page that shows all of that code and more working together at once, starting from the opening lines (which are generally something like, "layerinfo "type" = "theme"; layerinfo "name" = "layer name";") for a sort of One Stop Shop where you can choose which bits of code you want for what or compile the entire thing to see how it all works and looks together at once.

With the code properly commented, it will be easy to see if any part of the code does what you need it to do and by reading the code under each comment you might get a sense of how it's doing what it does. For anything beyond that you can always still ask in the style communities for extra help.

Maybe this new Wiki page could be called "All known custom s2 functions adapted by our users - on one page!" and could be found under the "S2 Cookbook: Other Examples" heading, and be clearly marked as an example of how much each journal can be modified to do more interesting things and offer more interesting features. Anyone could contribute to it, so say if you learned in one of the style communities how to add extra previous and next links beyond what a standard DW offers out of the box (http://style-system.dreamwidth.org/108697.html), you could add the finalized code on that page to this new Wiki (besides giving it its own page on the Wiki like a few other functions already have) so others can see it as part of a complete example custom theme layer.

Poll #16807 Add complete pre-filled custom s2 template for beginners on the Wiki.
Open to: Registered Users, detailed results viewable to: All, participants: 20


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (30.0%)

(Other: please comment)
1 (5.0%)

rosefox: Green books on library shelves. (Default)
[personal profile] rosefox

Title:
Crosspost to TinyLetter

Area:
crossposting

Summary:
Add TinyLetter to the available crosspost options.

Description:
TinyLetter creates newsletters that are basically blog entries, but in addition to being posted on the TinyLetter site, they're emailed to subscribers. TL users get a few basic MailChimp tools like tracking opens and clicks.

Enabling crossposting from DW to TL would be a relatively easy way for DW users to permit non-DW users to sign up for emailed updates of DW posts. It would also give DW users access to those MailChimp tools, which can be handy.

The TinyLetter web interface is quite straightforward: you get a subject line and a message body, and that's it. The message body permits formatting. TL also accepts posts via email. This would probably be the simplest way to crosspost from DW to TL: send the DW post as a formatted email to the user's unique TL post-by-email address. Here's what the TL FAQ says about that:

"To publish through your private address, create a message in your own email client to send to the address. Format and design it however you like, and be sure to include a subject line. When you're ready, just hit send. We'll create a new draft in your account and send a confirmation email as soon as it's done. After the draft is created you'll be able to log in to TinyLetter to review and send your message. Or, you can reply to the confirmation email we send once the email is beamed in. To send the message directly from your email client, simply reply to the confirmation message, keeping the subject line and address field intact, and we'll send out that newsletter to your list of subscribers."

So the user would need to confirm via email, but it's still faster and easier than copying and pasting a post from DW to TL.

If there's a TL API, there's no mention of it on their website, but one might exist.

Possible advanced feature: only crossposting posts that have the "tinyletter" tag.

Poll #16806 Crosspost to TinyLetter
Open to: Registered Users, detailed results viewable to: All, participants: 22


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (4.5%)

(I have no opinion)
13 (59.1%)

(Other: please comment)
0 (0.0%)

pseudomonas: (Default)
[personal profile] pseudomonas

Title:
In Case of Emergency write-only access

Area:
Posting

Summary:
Give limited access to a small number of other DW users to make posts on your behalf, with restrictions. [New feature suggestion]

Description:
What I want is a write-only function where (say) I nominate (say) you as an In-Case-of-Emergency poster for if I'm (say) ill in hospital; you can then post to my DW, but without any ability to see locked entries, modify settings, modify circle, or anything else; furthermore there'd be a prominent heading applied to any posts you made saying "posted by [YOURUSERNAMEHERE]", so impersonation wouldn't be possible. I can always delete or modify the posts that you have made on my behalf. Crossposting would work as normal.

Other methods:
a) implement this as an external website, using OpenID to verify you and store my password. Requires competently-run, secure, trustworthy third-party site. Need to remember to log in to that site every time I change my DW password.

b) give you my password. Trusts you to keep it safe, not lose it, and I have to tell you every time I change it. Allows impersonation and account-modification.

c) Give you my post-by-mail credentials. As above, but doesn't allow impersonation, eats an address slot per person, and only works for paid/permanent users.

d) The one that usually gets done these days - you making unlocked posts and hoping that enough of my circle see the post and that I don't have anyone I'd rather didn't know. This has the advantage of being simple, but is really not an effective solution to the problem.

Considerations:
I would favour the poster having the ability to post using any publicly-visible security setting that would let the poster see the post (at least "access-list-only" or "public") and possibly edit posts that they have themselves made (but not remove the header saying that the post was made by them). I don't see much need for anything beyond that; they can comment on posts as themselves.

I would envision small number of people given these posting privileges, though I don't have a particular limit in mind, and I don't see a really good reason to put a hard-limit on things.

There's always a risk that someone will post a malicious or spurious report, but really they can do that *anyway* via method d), it's called lying, and it's a social problem that is solved by only authorizing people that you trust not to do that kind of thing.

Poll #15788 In Case of Emergency write-only access
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
31 (54.4%)

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

Shouldn't be implemented.
2 (3.5%)

(I have no opinion)
11 (19.3%)

(Other: please comment)
0 (0.0%)

hatman: Glowing Dreamwidth logo. Caption: "OOO, SHINY!" (Default)
[personal profile] hatman

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: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
23 (48.9%)

(I have no opinion)
10 (21.3%)

(Other: please comment)
0 (0.0%)

vass: A sepia-toned line-drawing of a man in naval uniform dancing a hornpipe, his crotch prominent (Default)
[personal profile] vass

Title:
Filter entries by tags AND security level

Area:
tags, access filters

Summary:
It would be great to have a straightforward way to filter someone's current entries by both tags and security level, at the same time.

Description:
Currently, you can filter someone's entry by tag, e.g. user.dreamwidth.org/tag/banana would display all User's entries tagged 'banana' .

You can also filter it by security level, e.g. user.dreamwidth.org/security/public . This would display all User's current public entries.

But there is no obvious way (AFAIK - please correct me if I'm wrong) to do both at once, e.g. if you could use user.dreamwidth.org/security/public/tag/banana to display all User's current public entries tagged 'banana'. And some people have hundreds of entries per tag, so checking all by hand might not be practical.

This would be useful for if you need to quickly check if something a person told you is public knowledge before running your mouth about it in your own journal ("Looks like User's banana posts are all access-locked. I'd better ask them first before posting publicly about meeting them at the banana festival!") or, potentially, for checking your own security levels ("I try to make sure my posts on lutefisk are in an opt-in access group for my fellow lutefisk enthusiasts, but I think I might have forgotten to filter a few. Let me just check user.dreamwidth.org/security/access/tag/lutefisk and the same for security/public/tag/lutefisk to make sure of that.")

Potential drawbacks:
- it might hit the database too hard? IDK.
- people have custom security groups with / in the title, and people have tags with / in the title, and this would make it more difficult to form a URL, not matter whether it's /security/level/tag/tagname, or /tag/tagname/security/level.

Poll #15786 Filter entries by tags AND security level
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (40.5%)

(Other: please comment)
1 (2.7%)

dredmorbius: Dr. Edward Morbius (Default)
[personal profile] dredmorbius

Title:
Provide OPML feed import/export options

Area:
Reading Page

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

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

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

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

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

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

Among challenges:

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

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

Poll #15785 Provide OPML feed import/export options
Open to: Registered Users, detailed results viewable to: All, participants: 33


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (3.0%)

(I have no opinion)
25 (75.8%)

(Other: please comment)
0 (0.0%)

ninetydegrees: Drawing: a girl's pale face, with a yellow and green stripe over her right eye (Default)
[personal profile] ninetydegrees

Title:
Admin posts: connect 'as admin' post with 'admin' icon keyword

Area:
icons, communities, entries, comments

Summary:
If one has an icon with the 'admin' or '_admin' keyword automatically select it when making a post or a comment as an admin (I meant when you tick the 'as admin' checkbox).

Edit: looks like _admin or something even more unusual would be better as there would be a good chance *only* users who wanna have this would.

Description:
Not sure automatic selection is possible in which case it could be automatically use (so you wouldn't even have to select an icon the way it works at support). The latter could be problematic if you wanted to use a different icon for once.

Poll #15508 Admin posts: connect 'as admin' post with 'admin' icon keyword
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (5.9%)

(I have no opinion)
21 (61.8%)

(Other: please comment)
1 (2.9%)

katherine: Girl with glasses: Fuzzy cat with a folded pair of glasses by her paw. (Default)
[personal profile] katherine

Title:
Add "Edit entry again" to Journal entry was edited Success page

Area:
entries

Summary:
Add "Edit entry again" to Journal entry was edited Success page "From here you can" options.

Description:
The page Success when one has edited a journal entry is:
<blockquote>
Success

Journal entry was edited.

From here you can:

* View this entry
* View your journal entries
* Manage your journal entries
</blockquote>

Having another option be "Edit this entry again" would be handy when one is making a number of changes to the same entry in a row, or saved and immediately realised another edit to make.

Poll #15507 Add "Edit entry again" to Journal entry was edited Success page
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
54 (88.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (11.5%)

(Other: please comment)
0 (0.0%)

caput_mortuum: (Default)
[personal profile] caput_mortuum

Title:
add youtube as a site recognized by the account-linking tag

Area:
entries

Summary:
see title

Description:
I'd like to be able to link to youtube accounts with the DW tag. Currently it's not possible because youtube uses /user and not /users.

Poll #15506 add youtube as a site recognized by the account-linking tag
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.7%)

(I have no opinion)
16 (35.6%)

(Other: please comment)
0 (0.0%)

ketsu: (Default)
[personal profile] ketsu

Title:
A way to easily copy and paste Create Entry setting preferences

Area:
Posting

Summary:
It would be nice if an option could be implemented, once the new Create Entries page is out of beta, to quickly and easily copy-and-paste one's setting preferences.

Description:
The new Create Entries page, which is currently in beta, has a lot of different options to customize the page to a user's liking. But for users who have multiple accounts, for RPing or other reasons, remembering those options and applying them the same way to several different accounts might be troublesome. I'm opted-in to the beta and I have the page set up in a way I like for this account, but when I switch to other accounts it's jarring because things aren't the same way. I could manually set them all up in the same way (and I probably will after I finish posting this suggestion, since it's on my mind now), but it would be nice to have a way to rapidly apply all of my preferences at once.

My suggestion is to have some sort of button you can click somewhere, maybe on one of the Manage Account tabs, to generate a textual list of your preferences that you can copy, and a textbox somewhere else on the same page where you can paste those preferences and automatically apply them. (Once you've logged into the account you want to apply them on, of course.) The list would read something like:

entry_field:column;show_panels:entry-link,tags,currents,journal,comment-settings;panel_arrangement:(some sort of... thing to indicate what order and location the panels are arranged in)

Obviously that's just garbage spewed out by someone who doesn't have the faintest clue how this stuff works, so I wouldn't expect it to look exactly (or even necessarily remotely) like that. But something along those lines!

It would also be nice for users who have a specific way they want their page layout to look, but feel like temporarily changing it either to see if there's another way they like better, or perhaps for Support troubleshooting; they could save their preferences and easily revert to them this way.

Poll #15505 A way to easily copy and paste Create Entry setting preferences
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (8.3%)

(I have no opinion)
19 (52.8%)

(Other: please comment)
0 (0.0%)

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


This suggestion:

View Answers

Should be implemented as-is.
20 (60.6%)

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

Shouldn't be implemented.
4 (12.1%)

(I have no opinion)
8 (24.2%)

(Other: please comment)
1 (3.0%)

azurelunatic: Azz and best friend grabbing each other's noses.  (Default)
[personal profile] azurelunatic

Title:
Control emailed image display sizes

Area:
entries, files

Summary:
In the department of more options, a set-and-forget page-saver for emailed images. Set the maximum dimensions you'd like to display unaltered for attached images, and have the included images automatically use that size version with a link to the full size.

Description:
Modern smartphones take some rather large pictures sometimes. If your post-by-email use case involves a smartphone and pictures, there's the risk of warping your circle's reading pages if you forget to include a <cut> at the end of the message.

One part of the image-handling backend is going to be the resizer, which will generate appropriately sized versions of emailed-in images for thumbnails and not breaking reading pages.

Upon receiving an image attachment, the back end currently saves it somewhere in the user's /file/ area, and appends the relevant <img src="exampleusername.dreamwidth.org/file/12345.jpg" /> on the tail of the entry. It repeats this process for however many image attachments there are.

When activated, my proposed change would cause the back end to save the image attachment somewhere in the user's /file/ directory, and append <a href="http://exampleusername.dreamwidth.org/file/12345.jpg"><img src="exampleusername.dreamwidth.org/file/100x100/12345.jpg" /></a> (or whatever the appropriate size specification is) on the tail of the entry, repeating for however many image attachments there are, generating a scaled version of the appropriate size in accordance with how that bit is supposed to work. Fancier versions might include detecting the size of the image, and omitting the resizing bit if it's below the threshold defined by the user.

How to define this? It would be lovely if I could go in somewhere in my post-by-email settings and declare that I would like to default to images no larger than (pick from a menu of dimensions). Then I would rest secure in the knowledge that should I ever forget, my circle would be safe from my carelessness, and should they still like to view the larger version, there would be a link.

Poll #14596 Control emailed image display sizes
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (25.0%)

(Other: please comment)
0 (0.0%)

azurelunatic: Azz and best friend grabbing each other's noses.  (Default)
[personal profile] azurelunatic

Title:
Differentiating inbox notifications from suspended users

Area:
inbox, suspension

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

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

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

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

Poll #14595 Differentiating inbox notifications from suspended users
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
2 (5.6%)

(Other: please comment)
0 (0.0%)

fiddlingfrog: (Default)
[personal profile] fiddlingfrog

Title:
Add a new HTML tag to allow navigation across multiple entries in a single tag

Area:
tags, entries

Summary:
Across the web, multi-part series often have a section of navigation links to enable readers to find their way across multiple pages, articles, etc... First/ last page, prev/ next, list all pages/ articles... there's lots of different ways to make it easier for the reader. What I propose is to add a new HTML tag, like <cut>, that will auto-generate some navigation links when included in an entry.

Description:
This suggestion is based on an idea that I had on LiveJournal last year [ http://suggestions.livejournal.com/1107879.html?thread=17520039#t17520039 ]. The idea is that when an author has written something in several parts, whether that is fanfiction, how to articles, a travelogue, or a guide, the existing tag navigation is often insufficient for a reader to browse the entire series.

Say I've written several different entries about my experiences traveling in Scotland. I could just rely on the reader to click on the "Scotland 2012" tag and find all the entries. If I have more entries in this tag than fit on a single page, the reader might miss some. Alternatively, I could edit every entry in the series whenever I publish a new entry, making sure to link to the next in the series, and maybe the latest, and possibly make sure that each entry in the series links to all the others. But that's a lot of work, and it gives a high likelihood for error.

So what I suggest instead is a custom HTML tag that will auto-generate navigation links. At the end of any entry in my series I could add a tag like <series tag="scotland 2012">. This would be displayed in the entry like so:
scotland 2012
First - Prev - Next - Last
Subject of 1st entry
Subject of 2nd entry
Subject of 3rd entry
* Subject of 4th entry, the one currently being read
Subject of 5th entry

If the series contains more than five entries, the fifth and subsequent entries should be hidden behind a link to save space. In addition, there could be several options. Perhaps you can include a title, so instead of saying "corruption" the navigation link header might read "Bribery in City Hall". Maybe the author would like the articles displayed in reverse-chronological order. Or maybe the author wants to include the date/time stamps along with the entry subject line.

One advantage of this approach is that no new UI is needed. All of the links are included as part of the entry, instead of attached to the entry, so no new buttons are necessary. And since the links are auto-generated, authors only have to remember to add the 'series' tag once, when they first write the entry, instead of having to constantly update every entry in the series.

Poll #14594 Add a new HTML tag to allow navigation across multiple entries in a single tag
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
11 (25.0%)

Shouldn't be implemented.
8 (18.2%)

(I have no opinion)
7 (15.9%)

(Other: please comment)
0 (0.0%)

wordbird: (Default)
[personal profile] wordbird

Title:
For multiple admins in a Community

Area:
Communities

Summary:
More editing options on posts in a community not made by the admin wanting to edit it.

Description:
In a community I am an admin for, there are several admins, and all take turns making new posts when previous posts max out on comments. Sometimes comments get out of hand and the post needs to have its comments frozen for an hour or two. Dreamwidth fluctuates between whether or not it allows an admin who did not pen the post to freeze the comments of that post, requiring the admin who penned the post to be online, which is inconvenient, especially if they are an admin less often around. I suggest that anyone who is at Admin level in a community be allowed to edit the comment options(including disabling them) in any post in the community. It would make moderating much easier.

Poll #14593 For multiple admins in a Community
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.8%)

(I have no opinion)
6 (16.7%)

(Other: please comment)
1 (2.8%)

fluffymormegil: @ (Default)
[personal profile] fluffymormegil

Title:
Option to disable tag auto-completion

Area:
tags

Summary:
Add an option to disable tag auto-completion.

Description:
The tab auto-completion system interacts poorly with at least older (2.x) Android browsers, because the text entry system on those devices does not support "overtype to erase selected text". It would be useful to have an option to disable tag autocompletion, so that users of such devices can fill in tags without heavy use of backspace.

Poll #14592 Option to disable tag auto-completion
Open to: Registered Users, detailed results viewable to: All, participants: 32


This suggestion:

View Answers

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

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

Shouldn't be implemented.
11 (34.4%)

(I have no opinion)
9 (28.1%)

(Other: please comment)
0 (0.0%)

ladyasul: A picture of the back of a fairy, with their red-and-gold wings spread out. (Default)
[personal profile] ladyasul

Title:
Add ability to link OpenID account to DW account during content imports from other sites

Area:
site: openid, workflow: importer, and maybe site: usability

Summary:
Subsuming your OpenID while importing content created by the OpenID's account (such as associating the OpenID of Username@Livejournal while importing Username's journal contents from Livejournal) seems a very logical thing. Suggest there be an option on the Import Content page, which is easily reachable in the larger DW-sitescheme header, to do that in the course of importing content, or at least a link to the page for associating the OpenID, with a blurb explaining what it's for. To an end user, these two processes look to be rather closely related, so to have them obviously linked seems neatly intuitive.

Description:
I imported an account from LiveJournal a while ago and checked an entry's page, only to finally realize that comments made by that account, while it was on LJ, to its own posts... did not register as belonging to the new account on Dreamwidth, although the entries in the journal correctly said that they belonged to the DW account.

I realize that importing content from a non-DW journal to a DW journal and claiming ownership of that non-DW journal's comments are two separate things, but they feel as though they should go together somehow.

I can see two ways of doing this quite neatly, and in a way that makes things clear to the new user. The first would be to include a note on the Import Content page stating that "importing the comments on a journal's entries does not claim ownership of the journal's own comments, but this tool can take care of that for you: (and a link to the appropriate page for subsuming your OpenID accounts)" or something to that effect.

The other way, which I suspect would be more work, but still end up pleasing many users, would be to combine the two pages, so that you could take care of both tasks at once, if you wanted. There's all sorts of options for what to import, exactly, and you already need to enter your username and password, and specify which site to import from. Taking ownership of that account's comments, especially on its own pages, seems a logical and intuitive part of the process, to me.

If the second idea is gone for, still having a note and link like the first idea, in the Import pages (and it being pointed out that taking ownership of the OpenID account works for all OpenID sites, whereas importing the content only currently works for LiveJournal and InsaneJounral, would be great too) would be very handy, especially as it isn't linked directly in the header navigation, while Import Content is.

Poll #14591 Add ability to link OpenID account to DW account during content imports from other sites
Open to: Registered Users, detailed results viewable to: All, participants: 26


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (34.6%)

(Other: please comment)
1 (3.8%)

marahmarie: Sheep go to heaven, goats go to hell (Default)
[personal profile] marahmarie

Title:
Add a CSS Class to Comment Count on View Month Page

Area:
styles

Summary:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2013/01/. I've had to add sort of wonky CSS to compensate for that. The CSS doesn't target anything specific so in my case it messes things up (for instance, on my DW, it results in comment count text displaying both too small and too big - yes, all at the same time - which could be my own error, but still). So my suggestion is to simply add a separate span class for the comment count on the View Month page so it can be styled independently of other elements on the page.

Description:
Right now there is no CSS class for the comment count shown after each post on the View Month Page (this page and all pages like it): http://exampleusername.dreamwidth.org/2013/01/. I've had to add sort of wonky CSS to compensate for that. The CSS doesn't target anything specific so it messes things up (for instance, on my DW, it results in comment count text displaying both too small and too big - yes, all at the same time - which could be my own error, but still). My suggestion is to simply add a separate span class for the comment count on the View Month page so it can be styled precisely and independently of other elements.

Poll #14590 Add a CSS Class to Comment Count on View Month Page
Open to: Registered Users, detailed results viewable to: All, participants: 33


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (3.0%)

(I have no opinion)
13 (39.4%)

(Other: please comment)
0 (0.0%)

marahmarie: Sheep go to heaven, goats go to hell (Default)
[personal profile] marahmarie

Title:
Make Sidebar and Tags Page Tag Counts Into Links

Area:
tags, styles

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

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

Poll #14589 Make Sidebar and Tags Page Tag Counts Into Links
Open to: Registered Users, detailed results viewable to: All, participants: 27


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (18.5%)

(I have no opinion)
12 (44.4%)

(Other: please comment)
0 (0.0%)

marahmarie: Sheep go to heaven, goats go to hell (Default)
[personal profile] marahmarie

Title:
Expose Tag Count Tooltip Option to Customize Style User Interface, Make New CSS Class for Tag Count

Area:
tags, styles

Summary:
Based on a thread in the Style System community (http://style-system.dreamwidth.org/102224.html?thread=826448#cmt826448) I'm positing that we expose the sidebar tag count tooltip option to the Customize Style User Interface (basically, to put an option to use it on this page: http://www.dreamwidth.org/customize/options?group=modules) and to make the option a checkbox choice with the label "display tag count only as a tooltip". To be clear, this was originally user ninetydegree's idea, but I was given her permission to post it here if she didn't submit it first herself. :)

Description:
Right now as a DW user you may, for aesthetic or other reasons, not want to expose the tag count to users in your sidebar (a 'tag count' being how a sidebar tag might say, for example, "0 uses" or "20 uses" right after it). Rather than hide it via clumsy CSS ('clumsy' being, um, the only CSS guidance I could offer in that thread, given that there is no specific CSS class for the tag count) the idea is to expose the "display tag count only as a tooltip" in the Customize Style/Modules user interface to give users that option. Right now they can only access it by creating a custom theme layer and coding it in via DW's s2 programming language.

I'd also like to suggest that we have a separate CSS class for sidebar tag counts so we can style them however we want (this is the part of the suggestion I think DW designers will benefit from the most - but exposing the tooltip option also sounds like awesome sauce to me).

Poll #14588 Expose Tag Count Tooltip Option to Customize Style User Interface, Make New CSS Class for Tag Count
Open to: Registered Users, detailed results viewable to: All, participants: 26


This suggestion:

View Answers

Should be implemented as-is.
14 (53.8%)

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

Shouldn't be implemented.
1 (3.8%)

(I have no opinion)
11 (42.3%)

(Other: please comment)
0 (0.0%)

Profile

Dreamwidth Suggestions

August 2014

S M T W T F S
     12
3456789
1011 1213 141516
17181920212223
24252627282930
31      

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom