siderea: (Default)
[personal profile] siderea in [site community profile] dw_suggestions

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


This suggestion:

View Answers

Should be implemented as-is.
19 (59.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
9 (28.1%)

(Other: please comment)
0 (0.0%)

solarbird: (Default)
[personal profile] solarbird in [site community profile] dw_suggestions

Title:
"Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip

Area:
navigation strip, messaging

Summary:
It is currently very easy to configure your Inbox to serve as an activity notification hub. It would be very useful to have a shorted version of the first page of that Inbox be accessible via a dropdown on the Navigation Strip, and allow some manipulation of your Inbox via that dropdown.

Description:
Each line of the proposed dropdown would contain a one line description of the activity. (N replied to [your post|comment], N messaged you, subject "", N posted to group X, and so on). Each entry would contain an "x" dismissal button which would delete the notification from both the Inbox and the dropdown. Clicking on an individual entry outside of the dismissal button would take you to the item about which you are being notified - the message, the comment made, etc - and mark it as read. A "see all" entry at the bottom of the dropdown could take you to the current Inbox view. Currently, using the Inbox as a notification centre results in large numbers of page swaps and reloads, as you go from Inbox to post to Inbox to reply form to Inbox etc., etc., etc., with mark-as-read and delete-item as separate actions across separate pages. Further, it is difficult to maintain (de-clutter, etc) without engaging in that maintenance as a separate task. As a result, those of us who have this issue end up with over-full Inboxes that we tend to bulk-delete. This suggested feature would allow us both to use our Inbox more easily and maintain it more effectively, resulting in improved usability of the service and - hopefully - fewer notifications being stored on the servers.

Poll #18205 "Activity"-like view of 1st page of Inbox, in a dropdown, from Navigation Strip
Open to: Registered Users, detailed results viewable to: All, participants: 29


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (17.2%)

(I have no opinion)
15 (51.7%)

(Other: please comment)
0 (0.0%)

melannen: Commander Valentine of Alpha Squad Seven, a red-haired female Nick Fury in space, smoking contemplatively (Default)
[personal profile] melannen in [site community profile] dw_suggestions

Title:
When uploading images, display most recent upload at top

Area:
Upload Images page

Summary:
On the wonderful, amazing new image upload page, it would be nice to be able to immediately tell if the correct image uploaded. Changing the display so the most recent image is on top would fix this.

Description:
Most of the time when I use the image upload page, it's from my phone camera, on a tiny mobile screen. Currently, when I'm uploading multiple images, the only way to tell if an image was correctly uploaded is to scroll down to the bottom of the page to see it, and then scroll back to the top to upload the next image. This quickly gets tedious with more than a couple images. If the new image preview appeared directly below the upload box, it would be immediately visible and make workflow much smoother on mobile. I can't think how it would make it harder for anyone. (If that's not technically doable for some reason, any kind of upload confirmation that is visible near the upload box on mobile would be nice.)

Poll #18204 When uploading images, display most recent upload at top
Open to: Registered Users, detailed results viewable to: All, participants: 38


This suggestion:

View Answers

Should be implemented as-is.
32 (84.2%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (13.2%)

(Other: please comment)
0 (0.0%)

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

Title:
Support Board: add exclude filter

Area:
support, site interface

Summary:
The Support Board has a filter to show you all requests from category Z. I'd like the opposite of that: show me all requests but the ones from category Z.

Description:
The board could certainly do with more complex filter options such as letting you filter and exclude multiple categories but that's a discussion for when the board will get a full redesign. I think the exclude Z filter would be a simple yet still practical option for now.

Poll #18203 Support Board: add exclude filter
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (35.5%)

(Other: please comment)
0 (0.0%)

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

Title:
Unscreen your comments from Post Comment Success page

Area:
entry comments

Summary:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page.

Description:
Dreamwidth screened comment settings currently entail screening our own comments when we choose to screen all comments on our journals (I'm not sure if this behavior is the same for communities). I'd like to suggest we save time for journal owners, specifically, by allowing them to unscreen their own comments from the Post Comment Success page (https://www.dreamwidth.org/talkpost_do). This saves time - no more going back to the entry or your DW Inbox or off-site email to find and unscreen the comment you just replied made in reply to someone.

Poll #18202 Unscreen your comments from Post Comment Success page
Open to: Registered Users, detailed results viewable to: All, participants: 29


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (51.7%)

(Other: please comment)
0 (0.0%)

allen: (Default)
[personal profile] allen in [site community profile] dw_suggestions

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

April 2017

M T W T F S S
     12
3 456789
10111213141516
17181920 212223
24252627282930

Most Popular Tags

Expand Cut Tags

No cut tags