Separate a few colour settings in Boxes and Borders

[cesy]

Title:
Separate a few colour settings in Boxes and Borders

Area:
styles

Summary:
Separate a couple of colour settings in more intuitive ways for Boxes and Borders, so people can customise more easily.

Add new settings for Navigation module background and for the background of days without entries in the calendar module. Make these the same as entry border colour and page border colour respectively by default, but allow people to change them.

Description:
In Boxes and Borders styles:

Entry border colour is apparently also used as the background for the navigation module at the top. I'd suggest that these settings be made separate, so people can make colour themes and other customisations more easily.

The background for days without entries in the calendar module in the sidebar is apparently the same as the page border colour. I'd suggest that these settings are also separated, as it's unintuitive.

Poll #1305 Separate a few colour settings in Boxes and Borders

Open to: Registered Users, detailed results viewable to: All, participants: 28

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (42.9%)

(Other: please comment)
0 (0.0%)

Create tag sorting for calendar view.

[distractionary]

Title:
Create tag sorting for calendar view.

Area:
entries, tags, calendar

Summary:
Allow users to browse their tags by calendar view.

Description:
I had the thought the other night that it would be very nice to have a clearer view of how often and when I use certain tags. When I got to the computer, I tried going to my calendar and adding ?tag=exampletag to the end of the url, and while the calendar loaded it didn't accurately load the calendar showing only those entries that were tagged "exampletag". (Obviously the tag in question wasn't "exampletag", but that's not really the point.)

I have no idea what the technical requirements or limitations would be for this, but if it's possible to create the option to view all entries tagged by a particular tag in a calendar view, I think that people would like to use it.

Benefits: Overview of tag usage; easier to find entries, if you're looking for a specific entry in a journal without remembering any significant phrases (so that Search isn't as useful, if it's available in that journal), but you know one of the tags that was used, and approximately when it was posted, as the journal might have a vast number of entries so searching by calendar view alone or tag view alone would be time-intensive, confusing, and frustrating.

Downsides: Whatever the technical load is; I don't think this is prone to abuse, or at least I can't imagine any real way to abuse it. If someone else knows how much effort would be required, I hope s/he can comment here. Similarly, I don't know how much bandwidth would be required to actually load the page.

Poll #1314 Create tag sorting for calendar view.

Open to: Registered Users, detailed results viewable to: All, participants: 29

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (37.9%)

(Other: please comment)
0 (0.0%)

Bulk-screen all comments by exampleusername

[cesy]

Title:
Bulk-screen all comments by exampleusername

Area:
banning, screening, comments

Summary:
An option to automatically screen all comments made in a journal under my control (personal journal or community) by any given user.

Description:
(Original LJ Suggestion: http://community.livejournal.com/suggestions/884592.html)

There are times when there is someone who has either provided so much grief in a journal or community over however long that they need to be completely gone from it, or they have had a falling-out with the journal owner or community maintainer and their presence is vigorously no longer desired. Screening their comments in one fell swoop would be really spiffy. Sometimes this person has also been suspended if a spammer, but sometimes it is just a conflict between two or more users in which Abuse really can't take a side other than to say that there should really be no contact.

This springs from discussion on a suggestion to delete all comments from a single user (http://community.livejournal.com/suggestions/881181.html), as a friendlier, more easy to reverse alternative.

This would be presented as a banning option, but I see no reason that it should not also be available separately. It would also be nice to have a quick reversal (in case of bulk-screening by accident), but not necessary.

An ordered list of benefits

* Unwanted comments being removed from view
* Not needing to search each comment down and screen it manually
* Screened comments can be unscreened if really needed after all; deleted comments cannot
* Peace of mind for someone who does not want comments from exampleusername visible on their journal or community
* Comments would still be able to be deleted by the original poster of the comments
* Comments would still be viewable by the journal owner/maintainer, entry owner (if community), and original poster

An ordered list of problems/issues involved

* Could be seen as a drama-enablement tool
* Developer time to actual user benefit ratio if this is not of use to a wide range of users
* Could be easy to do accidentally and difficult to reverse if no undo option is present
* (if an undo option is present) A tool to unscreen all screened comments by exampleusername could result in manually-screened comments becoming available
* Comments would still be able to be deleted by the original poster of the comments
* Comments would still be viewable by the journal owner/maintainer, entry owner (if community), and original poster

Personally, I would also suggest this as a paid feature.

Poll #1306 Bulk-screen all comments by exampleusername

Open to: Registered Users, detailed results viewable to: All, participants: 32

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
11 (34.4%)

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

Shouldn't be implemented.
6 (18.8%)

(I have no opinion)
12 (37.5%)

(Other: please comment)
0 (0.0%)

Manage Comments page: toolbar in Latest Posted

[cesy]

Title:
Manage Comments page: toolbar in Latest Posted

Area:
manage comments tool, recent comments page

Summary:
On http://www.dreamwidth.org/tools/recent_comments, put the Manage Comments toolbar (Latest Received... View 10 25 50 100) in the Latest Posted section too.

Description:
(Original LJ Suggestion: http://community.livejournal.com/suggestions/901772.html)

Sometimes people forget to click View before clicking on Latest Posted, so they have to go back to the top all the time. If the toolbar was copied to show in this section, too, they wouldn't have to do that.

Poll #1307 Manage Comments page: toolbar in Latest Posted

Open to: Registered Users, detailed results viewable to: All, participants: 26

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
12 (46.2%)

(Other: please comment)
0 (0.0%)

Extend search to allow you to search your own journal for comments by a particular user

[cesy]

Title:
Extend search to allow you to search your own journal for comments by a particular user

Area:
search

Summary:
Extend search to allow you to search your own journal for comments by a particular user.

Description:
I'd recommend making this a tick-box or something similar, so that you can still search for entries in which you mention a user without the results getting flooded with everywhere they've commented.

This might also be useful for communities, though there may be privacy concerns around the communities part.

Poll #1309 Extend search to allow you to search your own journal for comments by a particular user

Open to: Registered Users, detailed results viewable to: All, participants: 40

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (12.5%)

(Other: please comment)
0 (0.0%)

Preserve journal style/app style preference

[allchildren]

Title:
Preserve journal style/app style preference

Area:
Styles

Summary:
When user changes journal themes, the journal style checkbox "Show entry pages in my journal style rather than the app style" is reset, with the app style defaulting into place. I propose that the user's previously stated preference be preserved throughout theme changes.

Description:
DW users choose styles: Tropospherical, Celerity, etc. They also choose whether to view those styles on entry/comment pages or to view comment pages in the style of the journal theme, aka app style, by checking or not checking the box marked "Show entry pages in my journal style rather than the app style." (I find this language very vague and confusing since everywhere else on the site "theme" is prevalent over the term "app style," but that's probably another suggestion.) However, every time the user changes journal theme, that box resets itself and site display defaults back to entry/comment pages in the app style.

My philosophy is that once a user has checked a box to state a preference, that preference should remain unless specifically changed. Particularly during the current development of new themes, I am interested in trying out new themes, and to have my preference for entry pages displaying in Celerity undone is incredibly annoying. Since journal style and theme are different things that are controlled on different areas of the site, it makes no sense that this single style preference should be tied to theme changes. At the very least, the journal/app box should be made more obvious in relation to theme changes, if it must be reset every time the user changes their theme.

The main drawback I can think of is that users changing theme may expect their entry pages to follow suit regardless of their previous preference. I think many users may not be aware of the journal/app style checkbox at all, so possibly that needs some better publicity or language. My alternate suggestion is to move the journal/app style checkbox to the theme page so it is more convenient for the user to re-check the box rather than go to a different page entirely.

Poll #1316 Preserve journal style/app style preference

Open to: Registered Users, detailed results viewable to: All, participants: 25

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (4.0%)

(I have no opinion)
1 (4.0%)

(Other: please comment)
1 (4.0%)

ADMIN: Lifecycle of a suggestion & what the Bugzilla tags mean

[denise]

So, now that we've been running dw_suggestions for a while, and have gotten (and implemented!) some great suggestions out of it, I thought I'd post an admin entry to explain the life cycle of a suggestion, plus what all the tags starting with "bugzilla:" mean.

( Life cycle of a suggestion )

( What the tags mean )

Collapse repeats of edited comments in inbox

[susanreads]

Title:
Collapse repeats of edited comments in inbox

Area:
inbox, notifications, comments

Summary:
When a comment is edited, collapse the notifications so that there are not multiple identical copies in the inbox

Description:
When someone edited a comment on a post I was tracking, the notification that I hadn't read yet was changed to show the edited version, and a new notification was added, so that there were two identical entries starting "Edited comment". I assume that if someone edited their comment several times, more notifications would accumulate. I found this confusing.

I assume people would not want the previous version(s) of their comment sitting in people's inboxes and that this is why the original notification is updated. I would prefer not to have the multiple copies, though, which don't seem to serve any purpose.

Drawback: in case someone has already read or deleted the original notification, the code would need to check whether the original was still there, but there must be a link to it in order to update the contents (to say "Edited comment" instead of "New comment").

Poll #1315 Collapse repeats of edited comments in inbox

Open to: Registered Users, detailed results viewable to: All, participants: 31

View Respondents

This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (12.9%)

(I have no opinion)
10 (32.3%)

(Other: please comment)
1 (3.2%)