[personal profile] swaldman

Title:
Allow mailto: links in the Links module

Area:
Journal modules

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

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

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

Poll #11748 Allow mailto: links in the Links module
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (9.4%)

(I have no opinion)
22 (41.5%)

(Other: please comment)
0 (0.0%)

kasman: (Default)
[personal profile] kasman

Title:
page selection

Area:
entries

Summary:
Instead of having to navigate by previous page/next page, it would be nice to be able to navigate by a page number. This would be handy particularly if you are considering deleting entries in bulk and don't want to get rid of the earlier entries.

Description:
Instead of having to navigate by previous page/next page, it would be nice to be able to navigate by a page number. This would be handy particularly if you are considering deleting entries in bulk and don't want to get rid of the earlier entries.

Poll #11689 page selection
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
11 (28.2%)

(I have no opinion)
19 (48.7%)

(Other: please comment)
2 (5.1%)

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:

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

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

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

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


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

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

Title:
Remove Zesty from List of Official Styles

Area:
styles

Summary:
Remove Zesty from list of official styles

Description:
Zesty is a style that was rushed into being an official style because the first official style only had a black theme. While that first style ¿Negatives? was cleaned up to fit into the style guidelines, Zesty has never been revisited. It lacks many of the features of Dreamwidth styles: multiple column configurations, the editor is different, the placement of elements within an entry is different (which may be more of a feature than a bug), the CSS is different (making it difficult to manipulate for style designers). To be blunt, the only way in which it is a Dreamwidth official style is that it is available to choose from the official style interface.

Until/unless some noble style designer takes on the challenge of getting zesty to conform to the normal features of an official Dreamwidth style, let's remove it so that all style guides and style announcements can be written without the asterisk *except for Zesty.

(I assume that making it unofficial will not remove the style from Dreamwidth, i.e. anyone who currently has Zesty selected as their style should still have it, it's still a public style, it just won't be in the style chooser.)

Poll #11551 Remove Zesty from List of Official Styles
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (14.3%)

(I have no opinion)
21 (37.5%)

(Other: please comment)
2 (3.6%)

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

[personal profile] septim

Title:
Allow users to pick with type of CAPTCHA test they see

Area:
comments, entries

Summary:
Allowing users to choose which type of CAPTCHA (text-based or graphic based) they will see/take through Manage Account.

Description:
Users choosing what type of CAPTCHA they will see/take allows greater accessibility.

I have dyscalculia and the text-based CAPTCHAs are full of arithmetic problems, thus I keep failing them. As of now, there's no way to choose which CAPTCHAs you will take, only what type of CAPTCHAs others will see in your journal.

Poll #10625 Allow users to pick with type of CAPTCHA test they see
Open to: Registered Users, detailed results viewable to: All, participants: 78


This suggestion:

View Answers

Should be implemented as-is.
56 (71.8%)

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

Shouldn't be implemented.
3 (3.8%)

(I have no opinion)
17 (21.8%)

(Other: please comment)
1 (1.3%)

leeneh: (Default)
[personal profile] leeneh

Title:
Blockquote tag in html turns text into italics

Area:
Entries in html

Summary:
'Blockquote' tag in imported html entries turns text into italics; 'br' tag disappears; and spacing between paragraphs is erratic.

Description:
Hello!

After many failed tries, I have finally managed to import contents from elsewhere to my Dreamwidth journal, about which I am very content!

However going through some of my imported entries I discovered to my surprise that a lot of my html does not render properly. My main concern is that the 'blockquote' tag automatically turns all text into 'italics' - which it naturally shouldn't. Another problem is that the 'br' tag many places has simply disappeared. The third problem is that the spacing between paragraphs seems to vary (even within the same entry) greatly.

Not being a programmer I don't have any solutions to the problem, unfortunately, but I hope it is something you will look into so that entries made in plain html are rendered as they should!

ETA: Yup, been thinking a bit, and what I'd like to suggest is that the style designers are instructed to leave text formatting tags alone when they make their styles. Having all text turn italics (like in the 'blockquote' tag mentioned - I have yet to find a nice style that doesn't do this) actually renders the italics tag completely useless as a tool for expression.

ETA II: The entries that show huge spacing after some but not all paragraphs, show 'br' closing tags when I look at the source code that DW generates. Since there is no closing tag for the 'br' tag and I did not put them there I can only assume it's a bug or bad programming from DW's side. In any case it is something that should be taken care of. I made a test entry to show you what it looks like. It shows up in both IE8 and the latest versions of Firefox and Opera. In the source code you can see the row of "illegal" 'br' closing tags. Thanks to a commenter I now know you're aware of this!

- Leeneh

Poll #10251 Blockquote tag in html turns text into italics
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
9 (19.1%)

(I have no opinion)
27 (57.4%)

(Other: please comment)
2 (4.3%)

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

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

Title:
Integrate better with LiveJournal's "spoiler" tag

Area:
entries, comments, importing, crossposting

Summary:
LiveJournal has implemented a <lj-spoiler> tag, which should be accounted for when importing and crossposting.

Description:
There's been past discussion (most recently http://dw-suggestions.dreamwidth.org/1303478.html ) about how to best make a spoiler/trigger/not-expanded-by-default tag work for entries and comments on Dreamwidth. LiveJournal has since implemented a method to do just this, and it would be wise to remain compatible with it.

When importing, entries with <lj-spoiler> tags should retain the type of concealment it is, the custom warning text if any, and the text within.

When importing, comments with <lj-spoiler> tags should not lose any data.

When Dreamwidth implements its own version, things tagged with <lj-spoiler> should be backwards compatible - if already posted, they should be treated accordingly.

New crossposted entries containing the <lj-spoiler> tag should be passed on to LiveJournal without mangling the tag; when our version happens, it should convert to LiveJournal syntax when crossposting to LiveJournal, just as usernames are.

New entries containing the <lj-spoiler> tag should be displayed sensibly on Dreamwidth, either consistent with a regular <cut> tag (if that's quick and easy to set up before implementing it properly) or properly.

Whatever method we use should remain accessible. If implemented with scripts for inline expansion, non-script viewing should retain any custom warning text and the fact that this was concealed, and give sufficient time and space for people to decide to stop reading (this should accommodate very fast readers who skim and can absorb the gist of whole sentences/paragraphs in seconds before their executive function has caught up, as well as screen reader users who may need time to tell their screen reader to stop reading). It should also not suck for mobile device/small screen users.

One possible method would be to automatically add "spoiler space" as was done manually on email lists of old: for example, typing <mask text="OMG!">WTF!!</mask> (or however it's decided to do locally) might result in:

*** MASKED CONTENT: OMG! ***

*
*
*
*
*

WTF!!

*
*
*
*
*

*** END MASK ***

Poll #9954 Integrate better with LiveJournal's "spoiler" tag
Open to: Registered Users, detailed results viewable to: All, participants: 73


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (21.9%)

(Other: please comment)
1 (1.4%)

cesy: "Cesy" - An old-fashioned quill and ink (Default)
[personal profile] cesy

Title:
Option to show "originally posted as" on imported entries and comments

Area:
entries, comments, importing

Summary:
Expose "originally posted as" on imported entries and comments, as an option that can be added to styles if desired.

Description:
Some users would like to be able to see where a comment or entry has been imported from, if they are importing from several locations or different names, or wish to display the history in full on Dreamwidth. Other users would prefer to keep the current display. I propose that the importer is updated to preserve the username and site/OpenID name at the time of import, so that this information is available to style designers, who can then create styles with it displayed, or add it to their styles as an option for those who want to show it on their journals. For previously imported entries where the original import site has not been saved, this would display something like "Originally posted as: information not available".

Poll #9857 Option to show "originally posted as" on imported entries and comments
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
10 (15.9%)

Shouldn't be implemented.
7 (11.1%)

(I have no opinion)
24 (38.1%)

(Other: please comment)
0 (0.0%)

momijizukamori: Green icon with white text - 'I do believe in phosphorylation! I do!' with a string of DNA basepairs on the bottom (Default)
[personal profile] momijizukamori

Title:
Add 'Jump Links' to Recent Entries and Reading Circle pages to make skipping between entries fast

Area:
Reading pages

Summary:
Add links to the next and previous entry to each entry on the recent entries and reading circle pages, allowing users to quickly skip between entries

Description:
So <user name="exor674"> coded a neat little custom S2 thing, which is probably most easily explained by linking to her recent entries page - http://exor674.dreamwidth.org/?style=original The '<|>' right underneath the subjects are links that take you to the subject line of the previous/next post of the page, respectively. I thought this was so cool that I offered to write it up as a suggestion, for inclusion as an option in the core2 default page *g*

It's particularly handy for situations where scrolling a lot is hard or irritating - on a phone, for instance, or for skipping several long entries that you've already read (or don't want to read, for whatever reason) quickly, rather than having to scroll past them. And while her code would need a little bit of clean-up for core2 inclusion, the basic functionality has already been written. I would suggest this as an 'opt-in' option, probably, in the Customize menu.

Poll #9853 Add 'Jump Links' to Recent Entries and Reading Circle pages to make skipping between entries fast
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

Should be implemented as-is.
29 (52.7%)

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

Shouldn't be implemented.
1 (1.8%)

(I have no opinion)
19 (34.5%)

(Other: please comment)
1 (1.8%)

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

Title:
Styles: make is possible to have the navigation links at the top in most styles

Area:
styles

Summary:
Currently, only a few styles let you have the navigation links at the top (i.e. above or in the header). I suggest that this becomes a standard option whenever possible so that people who find this more convenient can easily choose to have them there.

Description:
Being able to have the navigation links at the top is one of the main reasons I'll pick a style over another one, sometimes even my very first criterion (particularly for communities). If I can have this as an option in many different styles, it leaves me with more styles to choose from.

As for above or below journal titles: whatever's easiest to implement and looks best.

Edit: rephrased for better clarity.

Poll #9803 Styles: make having the navigation links at the top a default option
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)
1 (1.8%)

Shouldn't be implemented.
6 (10.5%)

(I have no opinion)
19 (33.3%)

(Other: please comment)
0 (0.0%)

facetofcathy: four equal blocks of purple and orange shades with a rusty orange block centred on top (Default)
[personal profile] facetofcathy

Title:
Make the cuttag arrows scalable.

Area:
Entries

Summary:
This is a very small suggestion about some very small things--the cuttag arrow images. They are small in size on the screen--11-15 pixels a side. Small in file size--around 100 bytes. And small in target--the image link has no padding on it.

They should be bigger and scalable.

Description:
Make the images scalable.

It's easy to make the arrow images scale up with a user's font size. You just need to set a width on the image in ems--something like .7em, which at a 16px font would show the arrow the same size it is now, but would let the image get bigger as the font size went up.

The problem is that the images are so low resolution, even very minor enlargement makes them very blurry. Making the images much higher resolution to begin with means that they start out shrunk down and they have room to grow.

Users of touch screens that zoom on the arrows to make them big enough for a finger to hit will also benefit from a less blurry image.

This increases the file size of the image. I made an 88 pixel square .gif of the right-facing arrow and it went from 91bytes to 573bytes. Something more in the 44px range is likely adequate if file size is a concern--that would give a clean image at up to a 62px font size.

Make the target bigger for everyone.

"Target" refers to the area you have to hit with your cursor or your finger to click a link. Right now it is the size of the image, nothing more.

I use a padding of 0.2em on the image and it gives me an 18px square to hit at default font size, instead of an 11px square. It makes a huge difference. (By the way, the span class .cuttag is inconsistently applied in the code and doesn't appear on the closing collapse arrow.)

Making the image scalable and putting some padding on it would make it a feature more users can enjoy.

Poll #9802 Make the cuttag arrows scalable.
Open to: Registered Users, detailed results viewable to: All, participants: 73


This suggestion:

View Answers

Should be implemented as-is.
56 (76.7%)

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

Shouldn't be implemented.
2 (2.7%)

(I have no opinion)
15 (20.5%)

(Other: please comment)
0 (0.0%)

pacific_rain_acim: (Default)
[personal profile] pacific_rain_acim

Title:
"Order View" button enabling viewers to see entries in EITHER oldest first OR newest first

Area:
Journal Entry Page of journals

Summary:
Please create a drop down box, link or button that would change the appearance of a journal's main page from the current default "Newest Entry First" to an optional view of "Oldest Entry First"

Description:
Ok :) The idea is basically what ever they do on shopping sites and in windows, where you can hit a button at the top of a column and choose to have the most recent or most distant date first. (Or highest price & lowest price.)

1. Issue to improve: Any journal that is about a process, telling a story or play, history, building of anything, diary, ...
For instance - I just created a journal to be focused ONLY on what I'm learning as I study A Course In Miracles. I wish that viewers of that journal could choose to see the beginning of the journey first - and so the First entry on top, second in second place, etc. In other words, I wish this journal had an option to show up Oldest Entry First. People starting to look at A Course In Miracles in the future might find it comforting to see what someone thought and be able to talk about it as they were reading the same pages. Also if I like it, and read it again in the future, it would be easier to follow along with myself the second or fifth time around.

2. Why my solution is best: IDK about "best" but it's easiest for the journal owner. The only other one I can think of is to use an enormously long system of tags...a tag for every 10 pages or every date? Or the option below - of adding stock journal styles that automatically show up as Oldest Entry First.

3. Problems: there would be code that would change the links at the top of every journal, that would probably be hard. Someone would just wake up and see a new button or link "Order View" next to "Recent Entries" - but for you guys it would probably be a big code?

4. Other Ways: There could be a set of the stock journal layouts that were ONLY set to "Oldest First." We could just go in and search "Oldest First" and a set of them would come up. It would be harsh, as it takes a lot of time to get your fonts, colors, etc right. But we could do it over if it really mattered to us.

*****Unless you created an Oldest First alternate down at the bottom of the layout options page - where you now have a choice of how your columns appear.

I don't know which would be cleanest and easiest for you guys.
* added button/link to each journal that switches the view of dated entries from newest on top default, to Oldest First.

* set of journal layouts that are just coded to default the Oldest First in the entries section

* a template that can be layered on or removed (like those column options at the foot of the style page)

Poll #9497 "Order View" button enabling viewers to see entries in EITHER oldest first OR newest first
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (10.7%)

(I have no opinion)
21 (37.5%)

(Other: please comment)
1 (1.8%)

kate_nepveu: sleeping cat carved in brown wood (Default)
[personal profile] kate_nepveu

Title:
expand all respondents in poll

Area:
entries

Summary:
The new "View Respondents" options for polls is awesome, but would be even more awesome with an "expand all responses" option like for cut-tags.

Description:
This would be handy the first time you looked at a poll's results, or if there were a lot of responses between viewings.

Poll #9495 expand all respondents in poll
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

Should be implemented as-is.
45 (73.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
16 (26.2%)

(Other: please comment)
0 (0.0%)

kate_nepveu: sleeping cat carved in brown wood (Default)
[personal profile] kate_nepveu

Title:
"View Respondents" in poll results in chronologically-based order

Area:
entries

Summary:
The new "View Respondents" options for polls is awesome, but the respondents don't seem to be listed in any obvious order, making it hard to tell what responses are new. They should be listed in reverse-chronological order (and noted to be in that order), and possibly marked with datestamps as well.

Description:
I have a rotten memory for usernames, so placing the respondents in a chronologically-based order would mean I only had to expand the new responses rather than try to remember who already responded and end up expanding all of them.

Poll #9494 "View Respondents" in poll results in chronologically-based order
Open to: Registered Users, detailed results viewable to: All, participants: 55


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (23.6%)

(Other: please comment)
0 (0.0%)

skakri: (Default)
[personal profile] skakri

Title:
OpenGraph implementation

Area:
frontend, accessibility, cross-site data sharing

Summary:
It would be nice if sites, that use OpenGraph metadata, could use our provided data, instead of crawling the page in question and collecting arbitrary data (article image, article title, author, etc.)

Description:
Sites that support OpenGraph Protocol (http://ogp.me/), like Facebook and Google+ would benefit from already provided data; that would help those sites 1) categorize that data (entry title, tags), 2) provide correct information, when posting to FB or G+ (title, image), instead of full page title (username | post, for example).

Example - http://skakri.grab.lv/2360053.html (check source; done: profile username, entry image, entry title, publishing date and used tags). Could be implemented also in profile pages - user.domain.tld/profile

Poll #9490 OpenGraph implementation
Open to: Registered Users, detailed results viewable to: All, participants: 39


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.7%)

(I have no opinion)
31 (79.5%)

(Other: please comment)
0 (0.0%)

timeasmymeasure: kerry washington with a rose held right below her lips (Default)
[personal profile] timeasmymeasure

Title:
Be Able To Customize "Member Posts" Text In Communities

Area:
communities, customization

Summary:
We should be able to customize the navigation text for the reading in page in communities.

Description:
Currently, the reading text for communities defaults to "Member's Posts", which makes sense. However, it also makes sense that we should be able to customize the text in the 'Customize Journal Style - Text' page like we can with the other navigation links.

Poll #9397 Be Able To Customize "Member Posts" Text In Communities
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.7%)

(I have no opinion)
19 (31.7%)

(Other: please comment)
0 (0.0%)

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