siderea: (Default)
[personal profile] siderea

Title:
Page Statistics 2: Electric Boogaloo

Area:
entries

Summary:
Native journal stats, like LJ used to do, only not horribly invasive like LJ. How many, not whom. Also integrated into the DW user interface.

Description:
Way back when, somebody else suggested, in a suggestion titled Page stats (http://dw-suggestions.dreamwidth.org/570175.html), "something like LiveJournal's My Guests feature", and the commenters here promptly set the suggestion on fire and then drowned it. The My Guests feature of the LJ Stats page makes *reading* journals less private, and gave many DW Suggestion commenters the heebee-geebees.

Unfortunately, that was the end of the proposal to implement any of the LJ Stats Page here. Unfortunately, because the LJ Stats Page also had lots of other useful analytics information, that was in aggregate and didn't violate anybody's privacy. For instance, from my LJ Stats page I just discovered that my LJ typically gets about 35 daily hits to my journal's RSS feed – information that would otherwise be utterly invisible to me. Since in the past I've wondered if anybody cares about RSS, that is usefully informative to me. For another instance, I am able to see how many visitors – not, mind you, LJ users, just unique visitors – came to a given post. If I had the same stats here on DW, I would be able to see how my efforts to move my readers from LJ to here were working.

When last this was proposed, one of the questions a commenter reasonably asked was "How is it different from the Google stats feature available for paid DW accounts?"

1) It doesn't involve Google for one thing. I have two big problems with Google Analytics:

1a) It is, to me, a much bigger privacy violation than My Guests ever was. My Guests was optional: if you ever wanted not to be counted, you turned it off and you never appeared in anybody's My Guest report. I, as a reader, have no way to opt out of GA – except to use a script blocker to clobber GA, which I in fact do, because....

1b) Google Analytics' degrades site performance. I have to block the GA scripts at my browser, because otherwise, from time to time, page loads start hanging on trying to communicate with google-analytics.com. I don't want GA on my journal both because I don't want to inflict on my readers a privacy compromise I don't want inflicted on myself, and I don't want to inflict on either me or my readers the page load times GA periodically (or is it always? as I said, I block it) causes.

2) As per 1b above, GA is client-side and third party. I don't want this sort of functionality coming through *any* third-party javascript. It will always tax the user's browser and internet connection, and expose information to a third-party. I have no interest in trusting any third-party with, for example, statistics *about my locked posts* the existence of which should be a private.

3) Not having a GA account I can't say what it includes in its reports, but knowing what I do about its implementation, I'm guessing it has no way to tell you *the number of times your post appeared on other parts of the site*. AFAIK, GA only knows – only *can* know – about the concept of "webpages". LJ's Stats would give you *two* numbers: the number of unique visitors to a post's page *and* the numbers of unique viewers of your post _in all the other places it appears on LJ_, such as on friends pages, your own Recent Entires pages, your Calendar pages, etc. LJ Stats leverages LJ's knowledge of its own info-architecture to come up with stats that GA can't.

Finally, it would be great if the interface for such a thing were integrated into the general DW journal interface, such that journal owners would have a contextual stats icon/link (visible only to them) wherever appropriate, that takes them to the corresponding stats page. For instance, such a link would appear on posts, and would take one to the stats page for that specific post. One's Calendar would have it on the day, month, and year views, and take one to one's corresponding day, month, and year stats pages. And that's not something that GA or any third-party javascript-based analytics implementation could manage.

More Details

When last this came around, it became clear most commenters didn't know what LJ did provide. Here's an overview:

There are four top level categories to the Stats page that I propose are of interest to DW: Journal, Comments, Entries, and RSS Readers.

The Journal page shows stats for your whole journal, breaking it out by number of total visits, total unique vistors, and how many of those unique visitors were logged-in LJ users. It allows you to view this information by either your journal itself, or your journal plus all friends pages on which your posts appear, and it allows you to drill down in either of these views to any year (shows bar chart by month), month (shows bar chart by day), or day (shows bar chart by hour). This last allows one to get a sense of on what days and at what times of the day one's readers are seeing one's journal.

The Comments page shows the stats on numbers of comments and numbers of commenters. Like the Journal page, you can drill down by time span.

The Entries page shows the stats for a given entry (post). It defaults to the most recent entry in your journal, has a list at the bottom of your ten most recent posts with links to their stat pages, for user convenience, and a text box in which you can put the URL to any of your entries to get the stats for it (not the most convenient of user interfaces). For a given entry, it shows Visits, viewers ("Who Viewed"), and Comments. Visits breaks out by Entry Views, All Visitors and Livejournal Visitors. "Entry Views" is the other sense of "entry": when that page is the page-of-entry of a reader to LJ – what happens when somebody follows a link somewhere else, like Twitter or Tumblr or FB or an RSS reader or an email, to a post of yours. That gives one a sense of how much traffic is being driven to a post by virality elsewhere. Visits also allows drill down by year/month/day, same as above. "Who Viewed" gives a break down between the number of all viewers of the post vs. the number of the subset that are Friends of you - it shows you whether it's just Friends reading your posts or other people. Also allows drill down by year/month/day. "Comments" shows comments vs number of unique commenters for the post, with year/month/day drill down.

The RSS Readers page shows a chart of number of requests to one's RSS feed, with drill down by year/month/day.

Poll #18206 Page Statistics 2: Electric Boogaloo
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.6%)

(I have no opinion)
13 (21.3%)

(Other: please comment)
0 (0.0%)

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
11 (34.4%)

(I have no opinion)
6 (18.8%)

(Other: please comment)
3 (9.4%)

ninetydegrees: Art: self-portrait (Default)
[personal profile] ninetydegrees

Title:
Styles: make it easy to list your IDs on other websites in profile module

Area:
modules, interoperability

Summary:
Dreamwidth displays links to other sites on your profile page but not on your journal. I suggest adding picture links to your other accounts (Facebook, Twitter, Instagram, etc.) to the profile module (or to another module if that's a better idea).

Description:
The idea is that you could enter your usernames on other sites and Dreamwidth would automatically create the appropriate picture links to the other accounts using the correct logos and display them into your profile module. This can already be done manually in the custom text module but I don't see why it shouldn't be easier to do. This is a pretty standard feature on several major websites now and I feel it's missing on DW. Ideally this could be further automated by using the 'other sites' part of your profile page and a simple option such as 'show links to other sites as filled out on my profile'. However, this part of our profiles is missing major sites such as Facebook, Instagram and YouTube so that would limit the usefulness of this new feature imo.

Poll #18045 Styles: make it easy to list your IDs on other websites in profile module
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (7.0%)

(I have no opinion)
9 (20.9%)

(Other: please comment)
0 (0.0%)

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
26 (52.0%)

(I have no opinion)
6 (12.0%)

(Other: please comment)
1 (2.0%)

ninetydegrees: Art: self-portrait (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%)

hatman: HatMan, my alter ego and face on the 'net (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: 54


This suggestion:

View Answers

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

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

Shouldn't be implemented.
23 (42.6%)

(I have no opinion)
12 (22.2%)

(Other: please comment)
0 (0.0%)

vass: Small turtle with green leaf in its mouth (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: 40


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
17 (42.5%)

(Other: please comment)
1 (2.5%)

marahmarie: (M In M Forever) (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%)

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (34.2%)

(Other: please comment)
0 (0.0%)

pauamma: Cartooney crab wearing hot pink and acid green facemask holding drink with straw (Default)
[personal profile] pauamma

Title:
Remove sticky entries from ?poster=(mumble) community journal view

Area:
page: journal, site: community features

Summary:
When viewing entries by a specific poster in a community, like http://dw-dev-training.dreamwidth.org/?poster=pauamma, sticky entries shouldn't be displayed on top. This is because the reader is likely looking for a specific entry by author name, and the sticky entries will likely stand in the way of seamless scanning.

Description:
It's unclear to me what should happen to sticky entries by the user specified in ?poster=. wouldnt want them displayed as sticky/in sticky position. Instead, I'd have them display in normal time-of-posting order. But there may be reasons to do it otherwise, or with a controlling option in the URL or elsewhere.

Poll #13978 Remove sticky entries from ?poster=(mumble) community journal view
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (9.5%)

(I have no opinion)
15 (35.7%)

(Other: please comment)
0 (0.0%)

kaberett: Trans symbol with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett

Title:
Community sticky posts editable by all admins

Area:
page: entries, site: community features, workflow: community administration

Summary:
It would be helpful if community accounts could make sticky posts inside the community, then editable by everyone with admin rights within that community.

Description:
Communities already make use of sticky posts for a variety of reasons - e.g. dw_suggestions has one (made by denise) that acts as an introduction and usage guide to the comm.

I suggest that it would be helpful for communities to be able to contain sticky posts nominally made by the community account itself, giving all community admins editing rights over it. I imagine this working via the "post as: another user" module in the new update page.

Example use cases: in dw_dev_training, I envisage this being used as an up-to-date centralised record of current babydev bait; Momijizukamori has said they'd love something like this to link to resources, beyond the bare bones in dreamscape's community profile.

ISSUES that I can come up with:
- community accounts currently can't be associated with posts, as far as I know, so that would be an exciting thing to work with
- would probably want there to be one post permitted per community (so would need to work out how to limit this - wouldn't just want automatic overwrite of pre-existing posts!)


Alternative solutions/workarounds:

(1) Create a mutual admin account (as in use at <user name="poetree"> with the shared account <user name="poetree_admin">). Downsides: security hassle - DW tends to discourage sharing accounts, I think? Logging out/in/out/in hassle - this will presumably be removed as and when seamless account switching is implemented.

(2) Some styles permit insertion of custom text to be displayed in the sidebar. Standardisation of this feature across styles (complete with full mark-up!), including choice as to where to site the custom text within the layout, might be a suitable alternative that would be editable by all admins.

Poll #13974 Community sticky posts editable by all admins
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (9.3%)

(I have no opinion)
14 (32.6%)

(Other: please comment)
3 (7.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%)

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: a closeup of a dark horse's face, cropped to show from above the eye to halfway down muzzle, mane shining chestnut because of light from offscreen, brown eyes deep (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: 44


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.5%)

(I have no opinion)
21 (47.7%)

(Other: please comment)
1 (2.3%)

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Add "view my entries in this community" to post-entry-creation page for communities

Area:
community membership, workflow: entry posting

Summary:
When you successfully make an entry in a community, add the link to view the rest of your entries to the little menu.

Description:
There's a list of suggested/possible/common actions to take after posting an entry, and I noticed on a recent change, that for successful posting in a community, the "edit my entries" link was removed -- for good and sufficient reason, because making that specific link work with communities was basically just not on from a developer perspective.

Something that currently exists and is relevant is the http://community.dreamwidth.org/?poster=username link, which locates all of the users entries to that community.

It would not be particularly development-difficult to add this link to the list of common possibilities, and it could help drive discovery of that really fascinating and useful feature.

Also, if someone needed to edit their past entries to the community, the entries would be listed right there.

Poll #12338 Add "view my entries in this community" to post-entry-creation page for communities
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (10.2%)

(Other: please comment)
0 (0.0%)

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

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

Title:
view screened comment upon posting in the same manner as unscreened comments

Area:
comments

Summary:
When you post a screened comment, you're taken to a page that says your comment posted, it's screened, and you can view it at this link. This requires an additional click to check the comment for typos, make sure it threaded properly, etc. You should instead be taken to the comment in the same way you would be if it were not screened.

Description:
DW's reply-but-keep-screened setting is awesome but conducting conversations in screened comments is still more cumbersome than it could be because of this intermediate success-but-screened page. The indication on the entry page itself that a comment is screened should be sufficient to notify the commenter.

Poll #11814 view screened comment upon posting in the same manner as unscreened comments
Open to: Registered Users, detailed results viewable to: All, participants: 63


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (9.5%)

(I have no opinion)
11 (17.5%)

(Other: please comment)
0 (0.0%)

marahmarie: (M In M Forever) (Default)
[personal profile] marahmarie

Title:
Add the ability for logged-in users to visibly sort the Tags Page by access level.

Area:
Styles

Summary:
There is currently a hidden feature on the Visible Tags Page: the ability to show the approximate access-level assigned to each tag. I would like DW to add CSS or a combination of JavaScript and CSS to all our journals to show the hidden feature to everyone who opts-in.

Description:
Currently the Visible Tags page shows all your tags in a single, alphabetically sorted list but does not *visibly* indicate which tags are used on private, access-list-only or public posts. So one day about a year ago I asked myself, "Why not?" and wound up writing CSS that exposed the access-level of all my private and access-list-only posts. This became a fantastic sorting system since I have no other way to tell what I've thrown where without using the Manage Tags page, which can be kind of awkward and time-consuming.

So a week ago I took this a little further and refined the CSS so that 1) only logged-in users see the access-levels alongside each tag and 2) logged-in users see the exact access level used on each tag - public, private, or access-list-only. Here's a screen cap of my current Visible Tags page using my latest CSS for it (logged-in view - logged-out you won't see any of the extra information shown in this screen cap):
http://i287.photobucket.com/albums/ll128/marahstest/expose_access-level_tags_page.jpg

What I'm humbly hoping for is this system of sorting tags by access-level, as seen in the screen cap, gets adapted site-wide either as the default view on the Visible Tags page (of course, it will be visible to logged-in users by access-level only) or else becomes an opt-in default option (which is where JavaScript would probably come into play; otherwise, this is a pure CSS hack).

There are a few possible issues with adapting this styling: 1) it may take more firepower to serve up the additional CSS (but I'm thinking it would not be enough to crash servers or do anything that dramatic as things stand; it's just hard to calculate how much this might slow things down without knowing how much firepower DW has to spare) and 2) there is currently an issue where if you use a tag at more than one access level (say you use your "cats" tag both publicly and on several access-list-only posts) it will get an HTML tag indicating it's for public use only, which means DW won't be able to style it with the specific CSS to reflect that you used it three times publicly and three times for access list readers. Until that split-usage quirk is fixed, my idea makes for an imprecise-at-best look at how your tags are being used. But I think it's still better than not having any sorting system in place at all; in the meantime you can still use your Manage Tags page to drill down more precisely.

If this were to get adopted, I could see future improvements to it such as sorting tags by access level on the Visible Tags Page instead of sorting them entirely alphabetically as we do now, adding the ability to style each access level separately, and so on.

Poll #11751 Add the ability for logged-in users to visibly sort the Tags Page by access level.
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.4%)

(I have no opinion)
28 (59.6%)

(Other: please comment)
1 (2.1%)

marahmarie: (M In M Forever) (Default)
[personal profile] marahmarie

Title:
Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag

Area:
Styles

Summary:
Currently the post view that shows your entries organized by tag (for example: http://marahmarie.dreamwidth.org/tag/book+reviews) has the same body class as the front page of our journals, that is, it uses the .page-recent body class. I'd like to suggest that we add a body class specifically for the entries-organized-by-tag view, so that it gets the new body class .page-tag (not to be confused with .page-tags, which is currently in use on the Visible Tags page, the one that simply lists all your tags on one page).

Description:
As a casual (but slightly obsessed) DW CSS designer, I'm often confounded by not being able to style every page view on DW individually. Because we have a sorting feature on our DWs that lets users browse full posts by each tag used on them, I want to style those pages to work as well and look as good as all the other pages on our DWs do. But the front pages of our journals and the tag views of our posts? They share the same HTML body class (.page-recent), which means tag views can be sort of weird-looking because they inherit .page-recent's styling, which often does not work on the tags view of our posts for an assortment of reasons. Which makes me think: why not just add a new, separate body class so we can style those pages, too? I humbly suggest we add the body class .page-tag to all views on our DWs that sort posts by the tags used on them (for example: http://marahmarie.dreamwidth.org/tag/book+reviews would get the new .page-tag body class, as would all other similar page views on our DWs).

Poll #11750 Add a body class to http://exampleuser.dreamwidth.org/tag/each-tag
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)
12 (30.8%)

Shouldn't be implemented.
3 (7.7%)

(I have no opinion)
17 (43.6%)

(Other: please comment)
1 (2.6%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags

Syndicate

RSS Atom