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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (28.2%)

(Other: please comment)
0 (0.0%)

marahmarie: my initials (MM) (Default)
[personal profile] marahmarie

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (50.0%)

(Other: please comment)
0 (0.0%)

feicui: (Default)
[personal profile] feicui
Title:
Allow users to specify an account as a roleplaying account

Area:
accounts, statistics

Summary:
Allow users to specify an account for roleplay without affecting paid account services.

Description:
This is a suggestion mainly for statistical purposes! Dreamwidth has an active, sizable roleplaying community, a consequence of which is that there are a lot of "character accounts" scattered across the site. As someone who's very curious about DW's site statistics, I can't help but think that means there's a lot of essentially fictional data skewing things one way or another.

If possible, I'd like for roleplayers to be able to specify an account as being made for roleplay. It would have to be in a way that doesn't affect paid services, since some get paid/paid premium accounts and some don't. In addition to being able to choose it during account creation, there would also need to be an option for existing accounts to "switch over", since there are many, MANY existing character accounts.

Challenges involved: oh boy! I'm not at all familiar with site coding, especially Dreamwidth's, so I can't imagine how complicated this might be. I also don't know how many people would actually use this option, but I thought I'd throw this out there anyway.

Poll #18026 Allow users to specify an account as a roleplaying account
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (37.5%)

(Other: please comment)
1 (1.8%)

marahmarie: my initials (MM) (Default)
[personal profile] marahmarie

Title:
Give Us The Ability to Delete Junk Data and Spam From Polls

Area:
Polls/Entries

Summary:
Someone just spammed/trolled/junk data'd my poll at http://www.dreamwidth.org/poll/?id=17242. I'm not sure why anyone would do so, and of course we have zero power over what people post as answers in the polls. But if we at least had the power to either delete unwanted data or report it and have it deleted by Dreamwidth staff, this would be immensely helpful.

Description:
I've only ever posted a few polls and the most recent one is the first to suffer from a junk data problem from an anonymous user who used my poll's various text fields to 1) spam, 2) write in junk data and 3) otherwise trample upon the spirit and intention of my poll. Of course as soon as I saw what this user had done I looked for a way to remove their input but was unable to do so.

I'm not sure why anyone would spam and otherwise post junk answers in a poll. But if we at least had the power to either delete unwanted data, or else report it and have it deleted by Dreamwidth staff, this would be immensely helpful.

Poll #18015 Give Us The Ability to Delete Junk Data and Spam From Polls
Open to: Registered Users, detailed results viewable to: All, participants: 36


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
14 (38.9%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (22.2%)

(Other: please comment)
0 (0.0%)

killing_rose: Raven/corvid in the frozen surf (Default)
[personal profile] killing_rose

Title:
Ability to freeze comments to an entry

Area:
entries, managing comments

Summary:
I think it'd be useful to have the ability to freeze <i>all</i> comments to an entry at once, instead of manually doing so.

Description:
Occasionally, you want to disable the ability of people to leave comments without destroying those already there, and quite frankly, going through and manually freezing each thread is a) time consuming, and b) a little annoying. If there was a way to mass-freeze all threads so that new comments couldn't be added, it'd be useful. The options to delete, screen, and unscreen en masse are already there, after all. I'd be a whole lot more likely to mass freeze all comments rather than delete them, but I have the functionality to do the latter and not the former

Poll #13464 Ability to freeze comments to an entry
Open to: Registered Users, detailed results viewable to: All, participants: 70


This suggestion:

View Answers

Should be implemented as-is.
58 (82.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (8.6%)

(Other: please comment)
3 (4.3%)

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

Title:
View entryprops for your own journal/administrated community

Area:
entries, self-service support

Summary:
Staff and senior support have the at-need ability to view some of the troubleshooting information attached to entries; this information could be useful to the journal owner.

Description:
All entries have under-the-hood information called "entryprops" (short for "entry properties") attached to them. Staff/senior technical support can view these at need.

Usually there's no need to view this information, but sometimes there's a simple question (like: did all my icon information successfully make it over when I imported? Generally the importer gets this right, but it's usually more reassuring to see for yourself) that could be answered. (And doubtlessly if it were readily available, there would be more helpful uses for it floating around.) It also strikes me as information that would be useful to a community administrator, if it's available to journal owners.


How would it be viewable? (For all of the cases below, this would only be for the journal owner/community admin; if someone didn't have permission to see if they would get an error.) I have a few thoughts.

1) Create a page where you can enter the link to an entry in your own journal (or your community), and the properties are displayed. This is simple and pretty straightforward, does not require monkeying around with any existing pages, but not entirely friendly.

2) Create a URL argument (like the ?view=flat that you can add after the entry in the address bar) to display it on/from the entry. This would be reasonably friendly, but would probably take a lot more developer doing, and you'd have to look up how to do it if you didn't remember and needed to use it. (Depending on what was less of a pain to develop, I would see this as either adding information to the existing display, or going to a new location containing the information and a link back to the regular view of the entry.)

3) Have a little link/toggle near the rest of the entry information (depending on which was less of a pain to develop as described above), labeled "advanced entry information" or similar, to make it discoverable by people who don't already know to look it up.


Questions about the advisability:

1) Is there enough need for this information that someone couldn't just go ask Support? Senior support could tell people better than I could how often they get requests that require entryprops information.

2) Would this answer more questions than it would cause? It would not be fair to Support to release a feature that would cause a deluge of "What's a ____ and why do ____???!?!" questions. If this is implemented, someone grab me and I will write docs.

3) Would any information be revealed that a community administrator shouldn't have?

4) Would any information be revealed that is Dreamwidth-internal and a user shouldn't have? (I doubt it, but I ask for completeness; staff would have to answer this one.)




Development: This sounds like the sort of high-complexity, low-impact project that might sit for 10 years without being claimed.

Poll #12339 View entryprops for your own journal/administrated community
Open to: Registered Users, detailed results viewable to: All, participants: 38


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (76.3%)

(Other: please comment)
0 (0.0%)

zaluzianskya: (Gay!!)
[personal profile] zaluzianskya

Title:
Make pressing "enter" on Links List save changes

Area:
Customize Journal Style

Summary:
If you're managing your links list (http://www.dreamwidth.org/customize/options?group=linkslist) and have your cursor inside one of the text boxes and press enter, it activates the More Links button rather than the Save Changes button. I propose that this be changed.

Description:
When I push the enter key while my cursor is in a textbox, I expect it to activate the Save Changes button. I obviously can't speak for everyone, but that's pretty universal behavior for most forms.

If most people prefer the current behavior and would rather it be kept, can the page at least be forced to, when you hit the More Links button, remember unsaved information in the textboxes so users won't have to re-type what they already had there?

Poll #11755 Make pressing "enter" on Links List save changes
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)
4 (8.2%)

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
18 (36.7%)

(Other: please comment)
1 (2.0%)

torachan: (Default)
[personal profile] torachan

Title:
Deleting the text of an entry should not delete the entry or should warn first

Area:
Entries

Summary:
Deleting the text of an entry should either not cause the entry to be deleted, or if it does, it should warn before deleting.

Description:
Back in the day, the only way to delete an LJ entry was to delete the text and then save the entry. Now, of course, on both LJ and DW, there is an actual delete button. Using the delete button gets you a "do you really want to delete?" type message before it deletes the entry. However, the old way of deleting still exists, and worse, it doesn't ask you if you really want to delete, it just does it.

There are many reasons why someone might delete the text without wanting to delete the entry. They might want to just keep the title and comments but no longer have the text of the entry there, or they might be testing something. (The case that prompted this post was someone getting weird whitespace issues and trying to see if they could get rid of it by saving a blank entry and then repasting in the text, but when they saved the blank entry, the entire post was deleted without warning.)

Now that a delete button exists, there's not really a good reason why deleting the text should delete the entry. If someone wants to delete an entry, there's a much more intuitive way of doing so: just click the delete button! So my suggestion is that if you delete the text, it should not delete the entry.

However, if that's not possible, at the very least there should be a warning before deletion just like there is with using the delete button. Users new to DW/LJ may not even know about the old way of deleting, and even long-time users may have forgotten it or assumed it was changed with the implementation of the delete button. There should always be a warning before something is deleted.

Poll #11752 Deleting the text of an entry should not delete the entry or should warn first
Open to: Registered Users, detailed results viewable to: All, participants: 80


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
19 (23.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (6.2%)

(Other: please comment)
0 (0.0%)

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

tim: Tim with short hair, smiling, wearing a black jacket over a white T-shirt (Default)
[personal profile] tim

Title:
Screen comment edits when comments are screened

Area:
comments

Summary:
Right now, if I set comments to screened-if-not-in-my-circles and I unscreen a comment, then the author edits a comment, the edit appears immediately without being screened.

Description:
I have screening enabled by default in my journal for comments from people not on my access list. Suppose "Alice", who's not on my access list, leaves a comment, and I unscreen it. If "Alice" edits the comment afterward, her edit appears immediately -- I don't have to unscreen the new edited version.

This is weird. When I saw this happening, fortunately the edit was just a typo fix. But in general, a commenter could abuse the editing feature to sneak in an edited version of the comment that the journal author wouldn't have unscreened.

I think when someone edits a comment in a context where screening is active, their edit should be like a new screened comment: that is, the old version should appear until the journal owner unscreens the edit (at which point the old version goes away).

Poll #11717 Screen comment edits when comments are screened
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (3.8%)

(I have no opinion)
15 (28.3%)

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

[personal profile] swaldman

Title:
List box on the Manage Tags page should remember position

Area:
Manage Tags page

Summary:
The list box on the Manage Tags page should remember your position when the page is reloaded.

Description:
http://www.dreamwidth.org/manage/tags has a list box with a huge great list of all the tags in my journal. Sometimes I go through merging or renaming to catch spelling errors. (OK, I have done this once. I like to imagine I am more organised). When doing this, when I click Rename, Merge, or whatever, it does the requested operation and then reloads the page with the list of tags back at the top. When the list is long, this is annoying.

I don't care about long-term , but it would be good if it could remember my position in the list within a single session.

Poll #11119 List box on the Manage Tabs page should remember position
Open to: Registered Users, detailed results viewable to: All, participants: 53


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (26.4%)

(Other: please comment)
0 (0.0%)

[personal profile] swaldman

Title:
Tidy up the Edit Profile page

Area:
Edit Profile

Summary:
The Edit Profile page needs a tidy, especially when it comes to controlling who can see what.

Description:
I think that the Edit Profile page is needlessly confusing at present, especially for those not used to LJ-a-likes.
I think it could do with general thinking-through and cleaning up, but here are some specific things that I've noted. Let me know if I should resubmit them as separate suggestions.

* When I want to control who can see which bits on my profile, some things are set here and some are set over in Account Settings -> Privacy (under Contact Info Security and DW Private Messages). Some things are set in Account Settings but then overridden in Edit Profile! I don't know whether this is pure historical legacy, or whether it's because the stuff that's in Account Settings applies more widely than just the profile, but I think it's confusing.

* I can't exercise any control over who can see website URLs that I enter. This is already covered by another suggestion (http://dw-suggestions.dreamwidth.org/404239.html), I'm just mentioning it here for completeness.

* There is a line that reads "DW Private Messages: OBSOLETE: This option has been moved to Account Settings". Why is this here at all?

* There is no granular control over who can see IM usernames. The access level for all contact info (email, Yahoo, Etsy, Gtalk, Jabber, Skype, Twitter, etc etc etc) is set in Account Settings. I think it would be good to be able to control the visibility of each contact method individually.


None of this is important or urgent, but I think giving this page a clean-up at some stage would be a Good Thing :-)

Poll #11118 Tidy up the Edit Profile page
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
7 (15.2%)

(I have no opinion)
22 (47.8%)

(Other: please comment)
2 (4.3%)

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

Title:
Demi-ban: screen all future comments from specific user

Area:
comments, comment screening

Summary:
Force-screen comments from one particular user, when it's just that user whose comments warrant screening.

Description:
Occasionally there is a user who may be commenting in a particular journal or community in such a way that they do not quite warrant a ban, but fully warrant review from the admins/owner just to make sure their comments are productive.

Everybody else is commenting all right, it's just that one person.

Setting [class that includes commenter] to have their comments screened (whether that class be everyone, non-Access/Members, or anonymous) would be overkill for this situation, because they haven't brought along friends, it's just them. Turning on screened comments tends to dampen discussion and can be a lot of work to unscreen.

A demi-ban which makes all that user's future comments screened, but leaves everybody else's alone, would solve this problem on a technical level.

On a social level, this person could then use another account to evade the demi-ban and not be subject to screening. That's something that is likely to be noticed, and then the admins/owner would have to decide how to handle it. (The admins/owner may well decide that it's time to actually ban both accounts.)

Evading a demi-ban should not be a ToS-able offense. Evading an actual ban still should be.

Poll #10464 Demi-ban: screen all future comments from specific user
Open to: Registered Users, detailed results viewable to: All, participants: 84


This suggestion:

View Answers

Should be implemented as-is.
67 (79.8%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
10 (11.9%)

(Other: please comment)
0 (0.0%)

kaberett: Overlaid Mars & Venus symbols, with Swiss Army knife tools at other positions around the central circle. (Default)
[personal profile] kaberett

Title:
Opt-in access filters

Area:
privacy, circle management, filters

Summary:
Many users have opt-in access filters, allowing their readers to specify which topics interest them. Currently this tends to involve a lot of work for a journal owner in terms of transcribing results from polls or views expressed in comments. An automated system allowing people on given journal owner's access list to opt-in to filters without requiring work on the part of the J.O. would be awesome.

Description:
Journal owners will often decide that they want to filter their posts according to subject - e.g. "knitting" or "offspring" or "local happenings" or "school" or "health"-related posts - so that their readers are not exposed to posts on topics they have no interest in. Currently, this is typically managed by the journal owner asking their access list/readers to leave a comment/respond to a poll indicating what the readers would like to see. The journal owner then needs to transcribe these results onto the circle management page - which typically involves repeatedly switching between browser windows/tabs.

It would be potentially useful if some of this process could be automated to reduce the amount of work the journal owner has to do.

I envisage something like:

1. J.O. creates an access filter, and specifies that it is an opt-in filter.
2. J.O. flags to readers that these opt-in filters exist/new subscribers are informed that these opt-in filters exist as they subscribe.
3. Readers tick some boxes that indicate "if I [have been/am in future] granted access, I wish to be included in this subset of opt-in filters"
4. J.O. receives a notification that Reader X wishes to be added to filters X,Y,Z. Notification includes links "click here to allow all" and "click here to edit" (for those cases where J.O. decides they really don't fancy having their family members on their sex filter, or what have you!)
5. Profit!!!

The main problem I see with this is that it causes many, MANY more options to become available, in ways that might be intimidating - which in turn makes me think that this might be a good feature to roll out as a perk of paid accounts.

Poll #9800 Opt-in access filters
Open to: Registered Users, detailed results viewable to: All, participants: 61


This suggestion:

View Answers

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

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

Shouldn't be implemented.
8 (13.1%)

(I have no opinion)
15 (24.6%)

(Other: please comment)
3 (4.9%)

allchildren: kay eiffel's face meets the typewriter (Default)
[personal profile] allchildren

Title:
move journal title controls back to Edit Profile

Area:
Styles/Profiles

Summary:
Move the editing controls for journal title and subtitle from Edit Journal Style to Edit Profile.

Description:
Once upon a time on LJ, journal titles and subtitles were edited via the Edit Profile page, and everybody was happy. (There was a dark time previously when journal titles and subtitles didn't even exist, but we don't like to talk about those days.) However, one day For Some Reason those controls were moved to the Customize Journal Style page. Much consternation and confusion raged across the land, for the journal title and subtitle and in fact THE FIRST THING one sees on one's profile, so it seems pretty natural to want to edit it there; in fact, some journal styles hide the subtitle completely. WHY IS IT EDITED THERE. WHERE IS THE LOGIC. BUFFY QUOTE.

...cried the people.

Years later, Dreamwidth came to exist and forked off of LJ's existing code, and that was great. Even greater was the fact that DW was hard at work at correcting some of LJ's more questionable coding decisions. Great, great stuff. However, this fork included the illogical switch of title/subtitle control, and thus it still sits in Customize Journal Style, making way less sense than it would to be in Edit Profile.

Sadness, and also it just took me like two minutes to find because seriously, why is it there?!

I propose that Dreamwidth undo this illogical decision and restore title/subtitle to its rightful place under Edit Profile. The only drawback I see is that it may confuse people who have gotten used to it being under Customize; but since Edit Profile is really the natural place to look for it I think that will be the lesser confusion. Plus, there could be a link where that control used to be pointing people in the right direction (or at least that link to Customize could exist under Edit Profile so I never waste two minutes again). Also it might be hard to code or something. But probably it would be awesome and everybody would be happy again, and that's my story and I'm sticking to it.

Poll #9086 move journal title controls back to Edit Profile
Open to: Registered Users, detailed results viewable to: All, participants: 79


This suggestion:

View Answers

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

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

Shouldn't be implemented.
14 (17.7%)

(I have no opinion)
18 (22.8%)

(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:
Useful control links on search page

Area:
search, entries

Summary:
When searching your own entries, get additional useful links, such as edit entry, edit tags. This could possibly also include control links for entries not in your own journal, if you have permission to retag in that journal, or for communities where you are an administrator.

Description:
Sometimes, when you're searching entries, you're searching for the purpose of editing the entry or its tags. In those cases, you have to first open the entry, then go to edit the tags or the entry.

It could be helpful to offer links to edit the entry or tags.

User interface-wise, the links could possibly be fit in without disrupting the flow too much or making it take up any more lines:


Current:

[personal profile] azurelunatic: 53 tweets for 2011-2-7
... , and jdn. Monday, 2015: @mishacollins Who's having problems with their polypodes? Monday, 2017: Pie doesn't have tentacles, but cupcakes do. http://www.etsy.com/listing/61287471/cupcaketapus Monday, 2018: HEAVENS ABOVE, SEX WITHOUT LOVE Monday, 2024: @ ...
Tags: twitter
Posted: 2011-02-07 23:55:00


Proposed:

[personal profile] azurelunatic: 53 tweets for 2011-2-7 (edit)
... , and jdn. Monday, 2015: @mishacollins Who's having problems with their polypodes? Monday, 2017: Pie doesn't have tentacles, but cupcakes do. http://www.etsy.com/listing/61287471/cupcaketapus Monday, 2018: HEAVENS ABOVE, SEX WITHOUT LOVE Monday, 2024: @ ...
Tags: twitter (edit)
Posted: 2011-02-07 23:55:00

Poll #9058 Useful control links on search page
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
21 (40.4%)

(Other: please comment)
0 (0.0%)

sara: S (Default)
[personal profile] sara

Title:
Comment indexing

Area:
commenting

Summary:
Build a thingy that will pull the subject lines and direct links from top-level comments on a post and output them in some kind of useful format (maybe a table or a list?) which can be inserted into the body of the post (hopefully under a cut-tag). Bonus points if it can be set to periodically run an automatic update.

Description:
This suggestion is motivated by my total lack of enthusiasm for spending an evening manually indexing a meme. I don't want to do that, that's a database query. Someone should build a thingy so the server can do this job for me.

Specific thingy-implementation-related issues should be conceptualized by someone with more thingy design and implementation experience than I have.

Poll #8881 Comment indexing
Open to: Registered Users, detailed results viewable to: All, participants: 75


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (4.0%)

(I have no opinion)
24 (32.0%)

(Other: please comment)
0 (0.0%)

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise

Title:
Support instructors/teachers/professors using DW for class-related projects

Area:
posting, communities, using DW to conquer the world

Summary:
We get at least three or four instructors per semester asking for promo codes for account creations for their classes (which we're always happy to give!) Since DW is so well-suited to keeping class journals, submitting writing assignments, or requiring class participation, I'd love to be able to code some more support for academic use.

Description:
Obviously each teacher's use of DW would be different, depending on the type of class they're teaching and the level at which they're teaching it (high school, undergrad, graduate work, adult enrichment, etc). This suggestion is less "we should add this" and more "we should brainstorm what we can add that would actually be most helpful".

I'm basically proposing a new category of accounts: "instructor accounts" or "academic accounts" and "student accounts" or "learner accounts" (names obviously subject to change, yadda). This will allow us to set different capabilities for these accounts.

The "academic package" would consist of:

* one promo code per class/class section;
* one "academic community" account per section, with slight changes to the standard community model to make them more appropriate for teacher/class interaction;
* one (or more if co-taught or if class has a TA) "instructor account" to be the admin of the community (or the instructor could use their standard DW account, but all of the instructors I know don't want their students finding their regular DW account!)
* a number of "student accounts" created via the promo code, where the students can choose their own usernames and migrate the student account to a standard account later if they'd like.

Things I can think of, off the top of my head:

* the ability for the instructor to "clear out" a community's posts and comments, moving them to some form of archive (essentially a community rename?) each semester/quarter/marking period/etc in order to store each semester's classwork separately and start each semester with a blank slate

* ability to force a student account created with a specific promo code to be subscribed to/a member of the community for the project, without having to check the checkbox during account creation

* ability to designate an instructor account for each "academic package" that will automatically subscribe to any account created from the promo code (so the instructor won't 'lose' students or have to get them to submit their username to the instructor through some other method)

* ability for the instructor to subscribe to all posts and comments made in the community (without the comm needing to be a paid community, I mean)

What other things would instructors using DW for academic/teaching purposes want to see, or would find useful?

(Edited to remove poll #7997, since this is more of an information-gathering entry than a suggestion!)
azurelunatic: A glittery black pin badge with a blue holographic star in the middle. (Default)
[personal profile] azurelunatic

Title:
Comment moderation tool: disemvowelling et al

Area:
comment moderation

Summary:
Introduce a reversible "mask" that may be turned on at a comment-by-comment level by a journal owner or community administrator, that initially displays a particular comment slightly obfuscated, serving as a warning that anyone who puzzles out the comment as displayed, or goes through to read the full version, that they do so at their own risk.

Description:
Current comment moderation tools involve leaving any possibly problematic (for any reason) comments in place, adding more comments, deleting the possibly problematic comment(s), screening them so only the journal owner/admins and the comment creator can see it, and disallowing any new responses to a particular comment or thread.

Missing from this toolbox is an option that leaves the comment in place, but in a way that clearly signals to a reader that while they *can* read this comment, they may not *want* to, and in a way that is friendly to the sort of fast reader who can take in a paragraph at a time before their brain has caught up with the idea that they may not want to read that, but also in a way that is friendly to someone who already struggles to read the text as presented.

Unlike similar tactics on self-hosted blogs, this would not involve actually editing the comment left by the other party. It would alter the display of the comment, with a clear notice that the display had been altered, and a control that any reader could use to view the comment as originally written.

This could be used for abusive comments, controversial/flamebait/triggery topics, and probably also spoilers and content warnings, and for comment-space games and other fun uses. (Owners might like the ability to proactively turn this mode on to set every comment this way at posting time, for entries likely to collect heated response, or for games. Commenters might like the option to self-moderate in this fashion for games and potentially triggery content.)

Options for the form of alteration could include:

Disemvowelling, where all vowels detected in the original are removed, making text that can often be puzzled out slowly without reversing the obfuscation. Can be read faster by someone who's used to it, makes hash of most HTML included. Popularized & I believe invented on Making Light, where I believe it's done by hand. Suitable for English; not so suitable for languages where vowels are implied rather than stated already; can be trivially defeated by writing in 1337 and other character-substitution methods; would need to have non-Roman vowels identified also.

ROT13, where all characters are moved around 13 places in their alphabet. (This is most useful for alphabets with 26 letters.) This makes text that most readers have to work through character by character, but some very experienced readers can read through at speed. Many existing ROT13 functions leave punctuation and non-English characters intact.

Display of a warning message without context derived from original text. No chance of something leaking through due to algorithmic shortcomings, because nothing would show; 100% chance that anyone wanting to read the comment would would have to request its display, causing a certain amount of potential extra server load.

Display of a warning message with optional context (similar to a comment edit message) to be provided by the journal owner/community admin. For screenreader users, the context should probably appear before the control to reveal the original comment.

Poll #7753 Comment moderation tool: disemvowelling et al
Open to: Registered Users, detailed results viewable to: All, participants: 67


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
14 (20.9%)

Shouldn't be implemented.
15 (22.4%)

(I have no opinion)
14 (20.9%)

(Other: please comment)
1 (1.5%)

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