allen: (Default)
[personal profile] allen

Title:
Quick jump to next/previous entry


Area:
reading page


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


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


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


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


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



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

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

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

Poll #18201 Quick jump to next/previous entry
Open to: Registered Users, detailed results viewable to: All, participants: 26


This suggestion:

View Answers

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

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

Shouldn't be implemented.
10 (38.5%)

(I have no opinion)
5 (19.2%)

(Other: please comment)
2 (7.7%)

toudaimori: (Default)
[personal profile] toudaimori

Title:
(Read more...) functioning as the black triangle to the left of it

Area:
Cut

Summary:
Can we please have the (Read more...) link functioning as the cut-opening arrow, not as the direct link to the entry?

Description:
Right now, when you click the (Read more...) link, you are redirected to the whole entry with the comments. If you want to simply open the cut and read what's inside, remaining on the main page of the journal, you have to click the tiny black triangle to the left of (Read more...). Can we please ditch this black triangle, which is barely visible, and have the (Read more...) link functioning as one? As for the direct link to the whole entry, it can be moved to the header, which is currently plain text without any use.

Poll #18025 (Read more...) functioning as the black triangle to the left of it
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

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

Shouldn't be implemented.
25 (55.6%)

(I have no opinion)
5 (11.1%)

(Other: please comment)
1 (2.2%)

lassarina: I'm not coming out until the stupid people have gone away.  ....I can wait all day. (Default)
[personal profile] lassarina

Title:
System for Marking Entries to Read Later

Area:
Entries

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

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

Poll #18023 System for Marking Entries to Read Later
Open to: Registered Users, detailed results viewable to: All, participants: 38


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (34.2%)

(Other: please comment)
1 (2.6%)

ninetydegrees: Drawing: a girl's face, with a yellow and green stripe over one eye (Default)
[personal profile] ninetydegrees
Lightboxes are a bad idea so I've submitted a new suggestion to improve our current preview pop-ups. Please comment on this one instead once it's approved. :)

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

Area:
entries, comments

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

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

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

Poll #18018 Have previews load on same page in small pop-ups
Open to: Registered Users, detailed results viewable to: All, participants: 29


This suggestion:

View Answers

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

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

Shouldn't be implemented.
14 (48.3%)

(I have no opinion)
9 (31.0%)

(Other: please comment)
0 (0.0%)

stargazered: (Default)
[personal profile] stargazered

Title:
Optional "Re-Posting" to add on to current "Share This Entry"

Area:
Share This Entry

Summary:
A re-posting option (that can be turned on or off, so up to the poster) that allows posts to be shared and appear in journals and reading pages like re-tweeting: redirects to the original post (so original poster still controls it)

Description:
The "Share this entry" of Dreamwidth is reaching a point where it's lacking, as it depends only on email and nothing else! Keeping what it has now (emailing), more options should be added. Like Re-Postng, only if the account or community turns this option on. This can be like Retweeting or Replurking: It appears the journal (thus counted as an update) and consequently the reading page of those subscribed to that journal, but it shows the original post and redirects you to it once clicked.

I believe Facebook has something like this, where "(user) shared -> (details here)" and it's the original.

Therefore the original poster still has all power of their post, should they want to edit or delete it. The problem with sites like Tumblr is that reblogging makes it an entirely new and separate post, so the original poster loses control of it (like if they wanted to delete or edit, they cannot because it will still circulate around, even when they delete their accounts). This will help with the exposure of many posts that can welcome plenty of discussion with this already excellent commenting system.

Also, not everyone wants their posts to be reposted in such a manner, even if their account is primarily public, because of personal and privacy reasons. The option to turn it on and off will be required (including whole communities to have the option to turn it on and off, since some communities are personal?)

Reposting also should not be an option for locked posts, obviously for privacy reasons.

Also if possible, individual posts can have the option to be reposted, like how currently some posts can have specific levels of content ratings.

As for a count of how many times it's been reposted, I'm not sure if that is required, but it seems to be consistent with most places that allow this form of sharing, so maybe on or off?

Dreamwidth's always been wonderful in keeping good privacy options, good flexibility when it comes to filters and keeping power to the poster. So if it has a sharing option like this, it should have one that upholds its ideals while still giving us that option to spread posts around. At the moment, the ideas and points I have suggested keep the reposting of Dreamwidth posts to just other Dreamwidth accounts, just to keep this simple first.

Poll #18013 Optional "Re-Posting" to add on to current "Share This Entry"
Open to: Registered Users, detailed results viewable to: All, participants: 45


This suggestion:

View Answers

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

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

Shouldn't be implemented.
14 (31.1%)

(I have no opinion)
3 (6.7%)

(Other: please comment)
1 (2.2%)

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.9%)

(I have no opinion)
26 (74.3%)

(Other: please comment)
0 (0.0%)

stormy: βͺ ππŽπ“πˆπ‚π„ ❫ 𝑫𝑢 𝑡𝑢𝑻 𝑻𝑨𝑲𝑬 𝑴𝒀 𝑰π‘ͺ𝑢𝑡𝑺 ⊘ (Default)
[personal profile] stormy

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

Area:
styles, entries

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

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

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

Poll #14085 [css] Add admin-post css to entry-wrappers.
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (32.4%)

(Other: please comment)
0 (0.0%)

ysobel: (Default)
[personal profile] ysobel

Title:
Search reading page

Area:
Entries? Search?

Summary:
Allow search of reading page - like sitewide search but only within subscribed journals

Description:
I fairly often find myself wanting to find a post on my reading page -- sometimes it's because I finally saw a specific movie or tv show a few weeks later than most people and want to read other peoples' reactions to it, sometimes just that I remember the content but not who posted it.

It would be awesome to have a "search subscribed journals" option. At the moment I can search a specific journal, or do a sitewide search, but nothing in between. Something in between would be good!

I'd imagine this would be a paid account feature, just because searches tend to be resource intensive,

Poll #13971 Search reading page
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (19.6%)

(Other: please comment)
0 (0.0%)

damerell: NetHack. (Default)
[personal profile] damerell

Title:
entries serving as "events" with dates in future

Area:
entries

Summary:
Allow a special class of entry, an "event", with in addition to posting time, a start and finish in the future. Allow a special class of comment saying that one is/is not attending such an event. Facilitate display of upcoming events amongst one's watchlist.

Description:
<user name="liv"> (who has nothing to do with this specific proposal) and I were discussing the depressing popularity of Facebook in spite of its universally acknowledged awfulness.

It seems to me that one of the main drivers behind it is familiar; it's the reason Exchange crops up so widely in a corporate context in spite of its awfulness. Shared calendaring, or similar.

I suggest that something of a similar nature could piggyback on the existing entry infrastructure. An "event" would have additional metadata in the form of start and end times (ideally conveniently organised so that a one-day event can be created without saying "00:00 on Monday 24th July ... 24:00 on Monday 24th July"), and the creation interface would strongly encourage adding a meaningful title to the entry. There's some obvious wishlist stuff for repeating events, but none of that is really necessary. Other than that, they'd be normal entries, with users free to enter what text they pleased, make them public or fiendlocked, etc. (The interface might, wishlist, warn about the creation of public events).

In addition, there'd be a format for metadata in comments which would indicate that a given user was or was not attending an event. Comments consisting purely of such metadata would not be ordinarily displayed. An "event" entry would still permit conventional comments or comments with both text and attendance metadata.

The tricky bit would be in the display; in making this facility as convenient to use as possible. I would suggest, for example, that (optionally) when viewing a watchlist (including a custom view), I would see at the top of the page a list of upcoming events in the next n days posted by users on that list, including their titles and radio buttons to mark my intent to attend them, perhaps mentioning how many others in my Circle are attending. Viewing the entry for an event might present the attendees list in a convenient format assembled from the comment metadata.

Poll #13638 entries serving as "events" with dates in future
Open to: Registered Users, detailed results viewable to: All, participants: 40


This suggestion:

View Answers

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

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

Shouldn't be implemented.
13 (32.5%)

(I have no opinion)
21 (52.5%)

(Other: please comment)
0 (0.0%)

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

Title:
Allow paid communities' reading pages to load by date

Area:
paid features, communities, reading page

Summary:
Loading reading pages by date is a paid feature. Some communities have paid accounts. This is not one of the paid features that extends to communities. Could it be done without killing the site?

Description:
There's a paid feature where you can add /?date=2012-12-12 (for example) to the end of your reading page, and you'll see your reading page as it would have been on that date (had your circle been in the state then that it is now).

This works on your own reading page, but apparently not the reading pages of paid communities. Was this an oversight or a deliberate choice?


Why this would be useful:

Communities' reading pages are usually not particularly useful on a regular basis -- they collect the public entries of the community's members. If you want to read someone regularly, usually you add them to your own reading page or put them in your RSS reader or bookmark them or whatever.

I'm trying to catch up on Alternity this weekend. (Alternity is a journal-based roleplaying game. Most of the character journals are members of the community, and only character journals are members of the community.) It would be really convenient if I could just find the start date and progress through the archives day by day (possibly after throwing a paid account at the community).


Limitations:

It might be a good idea to not have the whole site suddenly hitting a community's reading page for whatever reason.

* Limiting who can do this to community admins would parallel the individual feature, but wouldn't necessarily be useful to the community.
* Limiting who can do this to community members would make sense in general, but wouldn't work for this specific application.
* Limiting who can do this to community subscribers would discourage the casual bot from cruising through and hitting the site with all the hammers.

I believe limiting the timespan available to the reading page was originally done (on LJ with the friends page) because of the load it takes to retrieve entries from all the different journals on all their disparate clusters, particularly when the entries are not recent, and therefore haven't been fetched recently, and therefore are not already cached.

An individual's use of the feature is already calculated into the cost of a paid account. If this were available to anyone who wanted to use it with a paid community, there would be no data on how much it would get pounded if it is used. On the other hand, there are paid communities that would never use it. Another way of paying for the load, if the community's own paid account is not sufficient, would be to require that both the community and the reader have paid accounts in order to fetch this.


Would this be a privacy problem?

It would only contain public information, and community reading pages are already available for two weeks from the current date, for all communities (regardless of their membership restrictions).

It would present the public entries it in a context that would take a bit of doing to get otherwise. Someone could get the same information by adding all the members to their own reading list (in a custom reading group), and getting a paid account, or they could visit all the members' journals from that day.

Poll #13126 Allow paid communities' reading pages to load by date
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
20 (45.5%)

(Other: please comment)
0 (0.0%)

oyceter: teruterubouzu default icon (Default)
[personal profile] oyceter

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

Area:
accessibility, images

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

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

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

Poll #13125 Change "Expand" alt text on cut tag icon to "Collapse"
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (21.8%)

(Other: please comment)
2 (3.6%)

equationhouse: - (Default)
[personal profile] equationhouse

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

Area:
tags

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

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

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

Poll #12621 Having the option of tags appearing at the TOP of entries
This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.2%)

(I have no opinion)
15 (32.6%)

(Other: please comment)
2 (4.3%)

gerald_duck: (Default)
[personal profile] gerald_duck

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

Area:
Internationalisation/time and date

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

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

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

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

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

Poll #12340 I want the date format "Sat 2012-12-01" (or custom date formats)
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.7%)

(I have no opinion)
20 (46.5%)

(Other: please comment)
1 (2.3%)

[personal profile] chagrined

Title:
Remove unnecessary whitespace from embedded objects

Area:
Entries

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

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

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

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

Poll #12194 Remove unnecessary whitespace from embedded objects
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (37.5%)

(Other: please comment)
0 (0.0%)

msilverstar: (Default)
[personal profile] msilverstar

Title:
cut expander should show error when accessing protected post

Area:
page: reading, cut tags

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

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

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

Poll #11556 cut expander should show error when accessing protected post
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (9.6%)

(Other: please comment)
0 (0.0%)

emceeaich: A close-up of a pair of cats-eye glasses (Default)
[personal profile] emceeaich

Title:
Enable Embedding GitHub Gists as Media in Posts

Area:
posting, media

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

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

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

&lt;script src="https://gist.github.com/3290622.js?file=foo.js"&gt;&lt;/script&gt;

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

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

Poll #11553 Enable Embedding GitHub Gists as Media in Posts
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
30 (56.6%)

(Other: please comment)
0 (0.0%)

blue_rampion: A blue rose in the rain (Default)
[personal profile] blue_rampion

Title:
Change date format in site-styled entries

Area:
entries, site

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

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

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

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

Poll #11029 Change date format in site-styled entries
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

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

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

Shouldn't be implemented.
12 (24.5%)

(I have no opinion)
6 (12.2%)

(Other: please comment)
1 (2.0%)

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

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

Area:
entries, site

Summary:
Time in site-styled entries displays like so: @ 2012-06-21 22:51 UTC or @ 2012-06-21 10:51 pm UTC but, unless I'm mistaken, it uses your time (i.e. the time on your computer clock when you posted the entry) and doesn't convert it to UTC (or at least not all the time). I think it's confusing and should either display when it really is UTC or not display at all.

Description:
Tried this logged in and logged out, whether I had set a time zone or not and still got *my* time.

Poll #11024 Site-styled entries: remove 'UTC' or only display it when it's really UTC
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
52 (91.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
2 (3.5%)

(Other: please comment)
0 (0.0%)

solitarywalker: (Default)
[personal profile] solitarywalker

Title:
Reading pages for interests

Area:
Entries

Summary:
When you click on or search for an interest, the resulting page, in addition to listing people & comms with that interest, should offer a link to a page showing the recent public entries of the people who have that interest.

Description:
Here is something I sometimes do: I pick an interest on my interests list, click to see who shares that interest, then look at the individuals' journals to see if maybe I'd like to subscribe to that journal. Thing is, it can get a bit tedius clicking on all those links. Many have no public entries, so it turns out there's nothing to see at all. There's got to be a better way...

That better way, I think, would be a page for each interest that works like a "reading" page for that interest, displayed in the user's reading page style. It would show, in reverse chronological order, the public entries of people who have that interest.

A link to an interest's reading page (IRP) could be placed on the page you see now when searching for or clicking on an interest. There are already a few links there with simple explanations, above the list of accounts with that interest; add the IRP link there. Nothing needs to go away.

IRPs should respect users' privacy selections and avoid inadvertantly exposing anything that a user might not want exposed. To simplify this suggestion (!) I'll just say it should work like the "Latest Things" page does, with the really cool five minute delay thing etc. (So an IRP is a little like an interest-specific Latest Things.)

Possible problem: Journals that post large numbers of entries in relatively short periods of time could overwhelm the IRPs of all their interests. Based on Latest Things I'm guessing there aren't journals like that, but if there are, their entries should probably be excluded from IRPs.

Another possible problem: Depending on the database structure, generating IRPs might be a lot of work for the server. If that's the case... maybe generate on first request, cache, and use the cached version for a while (an hour? more or less depending on load?) instead of creating it fresh every time.

Poll #11020 Reading pages for interests
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

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

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

Shouldn't be implemented.
7 (14.3%)

(I have no opinion)
17 (34.7%)

(Other: please comment)
0 (0.0%)

dens_extra_pups: Just white text on a dark blue background. Text reads "Dens Extra Pups" (Default)
[personal profile] dens_extra_pups

Title:
Rating System Suggestion

Area:
journal entries

Summary:
A better rating system with more options for rating levels of communities and individual journals.

Description:
There's only three levels of journal classification. The "Safe for everyone" classification is what I'd consider G to Y7 rating, which is right where it should be, so there's no problem there. The "Should be viewed with discretion" triggers a tag that reads "NSFW" on all the entries, which borders on a bit too high of classification, in my opinion. I understand that the "18+" warrants the "NSFW" tag, which is as it should be. I think that there should be more levels of classification between the "Safe for everyone" and "Adults Only 18+", as there are a lot of things that fall in between there, and most journals would likely not come close to needing an "NSFW" tag.

Ideally, the levels of classification would be as follows:

"Safe for everyone": Leave it as it is.
"Cautious": Around PG-13 level.
"Some discretion advised": Bordering on R rating.
"Adults only 18+": Leave it as it is.

Poll #10250 Rating System Suggestion
Open to: Registered Users, detailed results viewable to: All, participants: 76


This suggestion:

View Answers

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

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

Shouldn't be implemented.
56 (73.7%)

(I have no opinion)
15 (19.7%)

(Other: please comment)
1 (1.3%)

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