kaberett: Overlaid Mars & Venus symbols, 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: 40


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (10.0%)

(I have no opinion)
14 (35.0%)

(Other: please comment)
3 (7.5%)

teaotter: a dark haired woman in sunlight (Default)
[personal profile] teaotter

Title:
Add an "are you sure?" dialog to the ban user process

Area:
comments

Summary:
Right now, it is easy to hit "Ban User" unintentionally and not know it. A dialog asking if you're sure would be helpful.

Description:
Right now, "Ban user" is one of the options that appears when you hover your cursor over a user's icon. The option is right above "View Journal," which makes it easy to hit accidentally.

If you click "Ban user," the option changes to "Unban user" -- but no other changes happen on the screen. It is easy to assume you just missed the "View Journal" button and click again without noticing the dialog change.

Right now, it is way too easy to ban someone unintentionally and never find out. If the banned person is polite about the ban and leaves you alone -- you'll never know why they unfriended you and went away.

An "are you sure?" dialog would make sure you didn't leave a user banned by accident. It would only add one step to banning people, so hopefully it wouldn't impair the usefulness of the feature for people who actually want to ban someone.

I think the extra dialog would be easier than sending a notification that you've banned so-and-so, although that's another option. I just don't want to ban someone and not know about it.

Poll #12915 Add an "are you sure?" dialog to the ban user process
Open to: Registered Users, detailed results viewable to: All, participants: 80


This suggestion:

View Answers

Should be implemented as-is.
68 (85.0%)

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

Shouldn't be implemented.
1 (1.2%)

(I have no opinion)
10 (12.5%)

(Other: please comment)
0 (0.0%)

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

Title:
Tweak file management area

Area:
files, hosting, user interface

Summary:
Include server-time upload dates on http://www.dreamwidth.org/file/edit

Description:
Dreamwidth image hosting is a work in progress and will have major improvements down the road.

I think the file management area could stand a little bit of (I hope) low-developer-impact improvement to make it more usable before the major overhaul happens.

Currently the images are shown with just the image and some controls. It would be awesome to include details like a link to the entry that the image was originally posted into (and even more awesome to include links to the places the image has subsequently been into, for the use case where you upload the image in one entry and then create a second entry to actually share it), but failing that, I hope it would be easier to grab the time that the image was uploaded, to then be able to hunt it down manually.

Times should be in server time, and one can figure out from there what local date it would have landed on.

Poll #12912 Tweak file management area
Open to: Registered Users, detailed results viewable to: All, participants: 37


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
18 (48.6%)

(Other: please comment)
0 (0.0%)

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

Title:
Link to polls from Latest Things

Area:
Latest Things, entries, polls

Summary:
If polls can't be displayed in full from the Latest Things page, provide a link

Description:
Last time I looked, the display of polls on the Latest Things page was lacking.

It would be lovely to show either the voting form (for a public poll) or otherwise the results so far. However, since polls can be long, that could be a bit funky for the page. Failing the ability to display the poll in an appropriate format, show a link in a similar format to the poll links on crossposts.

Poll #12625 Link to polls from Latest Things
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
2 (4.3%)

(I have no opinion)
17 (36.2%)

(Other: please comment)
0 (0.0%)

holyschist: Image of a medieval crocodile from Herodotus, eating a person, with the caption "om nom nom" (Default)
[personal profile] holyschist

Title:
Crossposting while logged out

Area:
Crossposting

Summary:
Create a setting so that if a particular journal is set to crosspost by default, posting while logged out or logged in as another account will still cause the journal to crosspost.

Description:
Currently, when posting while logged out or while logged in to a different account, journals set to crosspost to another service will not crosspost automatically. If the user then wants to crosspost, they have to log out, log into the other account, and manually edit the post to crosspost. This reduces the utility of the post-while-logged-out option, since the user has to log out and back in in order to crosspost.

For example:

1. birdaccount is set to automatically crosspost to an LJ mirror

2. user is logged into dogaccount, but posts to birdaccount using the "switch accounts" feature on the update page

3. birdaccount does not automatically crosspost

4. user has to log out of dogaccount and then into birdaccount to manually edit the post to crosspost to LJ, defeating the point of posting while logged out

I would love it if automatic crossposting settings for an account were respected no matter how the post to the account is made, so that

1. birdaccount is set to automatically crosspost to an LJ mirror

2. user is logged into dogaccount, or not logged in at all, but posts to birdaccount

3. birdaccount automatically crossposts to the LJ mirror

This would make it far easier to switch between DW journals while maintaining mirrors to other sites, without having to set up two browsers or constantly log in and out.

Poll #12624 Crossposting while logged out
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

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

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

Shouldn't be implemented.
4 (9.1%)

(I have no opinion)
15 (34.1%)

(Other: please comment)
0 (0.0%)

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

[personal profile] alexbayleaf

Title:
Notifications to detect spoofing if posting by email

Area:
email, posts

Summary:
It's possible, though unlikely, for someone to spoof posts from you by email. Notifications would help people recognise if/when this happens.

Description:
This one's a bit out there, but it came up in discussion about replying to comments by email, so I'm posting it as a suggestion.

Currently you can post by email from any of a list of registered email addresses. You also need to use a PIN to post. However, if someone knew your email address and could guess your PIN, it would be possible for them to spoof your email and post as you.

I therefore propose a notification setting: "notify me when I post by email". This should go to your primary registered address and basically just say, "We received an email post from address blah@blah.com, here's a link to it."

As well as being a warning if someone's spoofing you, it could also just be a good diagnostic to make sure your posts are getting through, if you don't have web access. Which after all could be a big part of why you're posting by email in the first place.

(You could make the setting be a bit cleverer, if you wanted to, by offering options like: "Notify me when I post by email: always, if spoofing is suspected, never". The "if spoofing is suspected" could be based on various things, but the obvious one that comes to me is <a href="http://en.wikipedia.org/wiki/Sender_Policy_Framework">SPF</a> records. But this is not a core part of the suggestion, just an idea for further work if someone were that way inclined.)

Poll #12344 Notifications to detect spoofing if posting by email
Open to: Registered Users, detailed results viewable to: All, participants: 49


This suggestion:

View Answers

Should be implemented as-is.
34 (69.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (30.6%)

(Other: please comment)
0 (0.0%)

peoppenheimer: A photo of Paul Oppenheimer at the Australasian Association of Philosophy meeting. (Default)
[personal profile] peoppenheimer

Title:
Support MathJax in Entries

Area:
MathJax JavaScript support at site level

Summary:
I suggest that (in due time!) dw support MathJax <a href="http://www.mathjax.org/">MathJax</a> for mathematical/technical formatting in dw entries.

Description:
This suggestion is intended to make it easy for dw people to write beautiful and useful mathematical/technical content in our entries. MathJax is now a mature and well-supported FOSS extension of html via javascript, with healthy user and developer communities. We've been experimenting with MathJax for the Stanford Encyclopedia of Philosophy, and we've been very pleased with it so far. (This is not an official SEP endorsement.) Code can be written or displayed rendered or in TeX or MathML. This makes it useful also for gacking and modifying, and even for learning more about those markup languages. Anyone who has tried to do serious mathematical or technical typesetting in html will agree, I think, that html is *not* a typesetting language. MathJax goes a long way toward allowing decent technical typesetting in an html context.

If MathJax can be permitted as a tightly controlled JavaScript layer at the dw site level, which I think it can, then users will be able to write mathematical and technical fragments into their journal entries as easily as any other html. I don't envision putting MathJax support into the rich text editor -- I anticipate that anyone who wants to use MathJax will be comfortable editing their own markup. This is rather an extension of html markup into a wider domain.

It is possible that I'm overestimating the ease of implementing this suggestion, but I've experimented with MathJax support in my personal webpages and at the SEP site, and it looks as though MathJax makes this as easy as possible. Furthermore, the social/political aspects look promising, insofar as the MathJax user and developer communities look like just the sorts of folks dw wants to make alliance with, as far as I can tell.

Poll #12341 Support MathJax in Entries
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
3 (6.5%)

(I have no opinion)
26 (56.5%)

(Other: please comment)
2 (4.3%)

metawidget: A platypus looking pensive. (Default)
[personal profile] metawidget

Title:
Somewhat confusing message confirmation page title

Area:
Messaging

Summary:
The title of the page confirming that a message has been sent is "Compose Message", which when I see a tab with that, makes me think I have unfinished message business. Maybe, if the page (http://www.dreamwidth.org/inbox/compose) is confirming a sent message, the page title and header could read "Message Sent Successfully" or something similar.

Description:
This would make the site more usable for heavy tab-flipping types, and I suspect for people who get their pages in a very linear manner, e.g. screen-reader users or people using very large type — they would know immediately what has happened with their message right away.

Ideally, if the message failed to send for some reason, the title and heading could indicate that too — I've never had a message fail to send, but while you're in there, it might be nice to change that.

I suspect the solution wouldn't make anyone's life harder — it'd be another few entries in the English-stripping file and some more logic in building the page, but from the user perspective I can't think of a drawback, so long as the new titles all included the word "message" to cue people as to what process is succeeding or failing.

Poll #12203 Somewhat confusing message confirmation page title
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

Should be implemented as-is.
46 (80.7%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
11 (19.3%)

(Other: please comment)
0 (0.0%)

bulma: A four star dragon ball png (Default)
[personal profile] bulma

Title:
Import entries from Scribbld.com

Area:
import

Summary:
There is no option to import from scibbld.com

Description:
I have several accounts on Scribbld.com that I would like to import content from, but Dreamwidth doesn't seem to allow for this option (only livejournal and insanejournal). I could go through every entry and repost it to another account on dreamwidth, but that would be a tedious task. LJarchive doesn't work on my mac, and I've tried using it on someone else's PC, but for some reason it isn't functioning on there either because there's some component missing in the operating system or something.

In short, please see if you guys can find a way for us to import content from accounts on scribbld.com to dreamwidth.org. Thanks!

Poll #12202 Import entries from Scribbld.com
Open to: Registered Users, detailed results viewable to: All, participants: 57


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
29 (50.9%)

(Other: please comment)
1 (1.8%)

larissa: (Default)
[personal profile] larissa

Title:
Put plurk.com on the whitelist for embeds

Area:
Entries

Summary:
Allow embeds from plurk.com on entries and/or profiles.

Description:
I run a roleplaying game here on Dreamwidth, but much of my playerbase uses <a href="http://plurk.com">Plurk</a> for OOC contact. As such, we have a mod account on Plurk to supplement posts in our OOC community for player information. However, not all players have or use Plurk. While we strive to put everything on the OOC community, occasionally things are posted on Plurk that they might not see. Plurk has a built-in widget for iframe embeds; if these are added to the whitelist we could post it here on Dreamwidth.

Poll #12198 Put plurk.com on the whitelist for embeds
Open to: Registered Users, detailed results viewable to: All, participants: 74


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.4%)

(I have no opinion)
26 (35.1%)

(Other: please comment)
0 (0.0%)

whipcracks: (Default)
[personal profile] whipcracks

Title:
Sort Icon Page by Active/Inactive Status

Area:
icons

Summary:
On the View Icons page (and possibly the Upload Icon page) allow a sort option which will group Active/Inactive icons (preferably Active on the top/first page) together for ease of finding them.

Description:
Since there are already sorting options for Keyword and Upload Order, having this additional sorting option would be beneficial for accounts which have had paid or premium status previously and are expired, etc. particularly now that there are permanent icon slots available which increase the overall capacity of an account's icon slots.

I believe the method dictating which icons are left active go by most-used in journals followed by most recently uploaded? (I could be wrong on this, it's just what I've observed). However these options both leave active icons scattered through the overall icon page(s). Although the icon browser does only load active icons IF the user still has a paid, it doesn't help free accounts who may be trying to search out 15 active icons from 100, 250, or even more.

I'm not foreseeing any immediate problems if this were implemented due to the fact that there are other existing sort options, but if anyone spots something I've missed...?

Poll #12197 Sort Icon Page by Active/Inactive Status
Open to: Registered Users, detailed results viewable to: All, participants: 67


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (1.5%)

(I have no opinion)
7 (10.4%)

(Other: please comment)
1 (1.5%)

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

sircaliban: (Default)
[personal profile] sircaliban

Title:
2 factor authentication

Area:
improvement to login

Summary:
Create a 2 factor authentication option. The user would login with the password, and then the server would sent a code to a cell phone. The user would then enter the code to verify that they are trying to log in and it's not someone trying to hack into the account.

Description:
This would of course only be necessary for when users are connecting from unknown networks or networks they have not connected to from before. Once logging in, the user would have the option to 'trust this computer', so subsequent authentication requests would not have to got through this option.

Yahoo, Google and Facebook all off similiar functionality.

ETA: I see this option as being 'opt-in', if you opt-in, then the system will ask you for an additional code. The code is generated via something you have (cell phone, hard token, soft token).

Poll #11749 2 factor authentication
Open to: Registered Users, detailed results viewable to: All, participants: 69


This suggestion:

View Answers

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

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

Shouldn't be implemented.
35 (50.7%)

(I have no opinion)
10 (14.5%)

(Other: please comment)
2 (2.9%)

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

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

Title:
Sitewide antispam capability: comment CAPTCHAs for inactive accounts

Area:
comments, anonymous users, inactive users, antispam

Summary:
When an account becomes inactive (discussion of what constitutes "inactive" for the purposes of this concept to follow), require any anonymous comments to fill out a CAPTCHA. If/when the account becomes active again, revert to the user's settings. This would not delete anything already in the journal, would not stop logged-in users from commenting, and would allow anonymous users who could solve the CAPTCHA to comment.

Description:
Spun off the comments on http://dw-suggestions.dreamwidth.org/1374810.html --

Spam comments are a woe that should be discouraged, while not discouraging comments of legitimate discourse from real sentient beings.

Most comment spam on Dreamwidth is anonymous. One of the places that spammers strike is the accounts of people who have become inactive. If someone's not around for any particular reason, they generally can't get rid of any spam that shows up in their journal. Emboldened by the way their first overtures have not been repelled or cleaned up, the spammer strikes again, and again, and again.

Anonymous spam is present until cleaned up by the journal owner (or someone logged in as them). Registered user/OpenID spam is only present until someone (someone else hit by the spammer, or a good neighbor) reports the spammer and the spammer is suspended; all of the spam comments left by that user will then go away across the site.

For this reason, it is more important to attempt to repel anonymous spam in the event that the journal owner is not around and therefore not able to take action.

When the journal owner becomes inactive, and the journal allows anonymous comments, and the journal owner does not already present anonymous comments with a CAPTCHA, and anonymous comments are not screened by default (screening leaves the anonymous comments invisible to search engines unless the journal owner comes through and unscreens them, and by that time first the owner is active, and second, the owner is hardly going to unscreen spam on purpose unless there's a bigger problem) then there should be a sitewide setting to put up a CAPTCHA upon the attempted anonymous comments to those journals.

Now the definition of "inactive" for the purposes of probably not actively gardening journal comments. This should be something that can be adjusted on the administrative end of things should it not be got right on the first try. As a first attempt:

No new or edited entries in personal journal
No new or edited community entries? (Can we track this?)
No new or edited comments (from the journal, not to the journal, either in their own journal or abroad) (can we track this?)
No active login sessions

... for at least 60 days? Doing anything that touches one of the above things would start the clock over again. If someone logs in, leaves a comment in a community, deletes the comment, and logs out, that would restart the clock. If someone leaves themselves logged in after doing that, they would have until that login automatically expires before the clock starts.

Poll #11570 Sitewide antispam capability: comment CAPTCHAs for inactive accounts
Open to: Registered Users, detailed results viewable to: All, participants: 54


This suggestion:

View Answers

Should be implemented as-is.
39 (72.2%)

Should be implemented with changes. (please comment)
8 (14.8%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (13.0%)

(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:
Include poster's username on "edit tags on an entry" page

Area:
tagging, community features

Summary:
Provide more information - specifically, the original poster's username - on the "Edit Tags on an Entry" page.

Description:
The "Edit Tags on an Entry" page currently has the fields:

* subject
* current tags
* [journal]'s tags
* entry text

This is fine if you're tagging within your own journal. However, when I'm tagging in a community, and especially tagging dw_suggestion's posts, I sometimes get curious about Who Submitted This, & it would be lovely to be able to see that information at the same time as tagging, rather than having to click about (which disrupts my concentration).

I can also see this being useful for batch-tagging in communities where posts are routinely tagged with the name of the poster.

Possible solutions include:

(1) always showing the username of the poster on the Edit Tags on an Entry page
(2) show the username of the poster only when editing tags on an entry posted to a community

Downsides: you end up with one extra uneditable line on the Edit Tags on an Entry page. Personally I can't get too worked up about that. ;)

Poll #11569 Include poster's username on "edit tags on an entry" page
Open to: Registered Users, detailed results viewable to: All, participants: 47


This suggestion:

View Answers

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

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

Shouldn't be implemented.
1 (2.1%)

(I have no opinion)
14 (29.8%)

(Other: please comment)
1 (2.1%)

msilverstar: (Default)
[personal profile] msilverstar

Title:
cut expander should show error when accessing protected post

Area:
page: reading, cut tags

Summary:
Right now, if a reader had access to an entry but doesn't any more, clicking on the cut expander doesn't open the cut -- correct behavior -- but also doesn't display an error message. It's very confusing. Clicking on the cut itself takes the reader to an error page where all is made clear, so a little JavaScript error on the reading would be nice.

Description:
Granted corner case, having opened a reading page when one had access but no longer, due to the poster changing the security, the reader logging out in another tab or window, or the system logging the reader out.

In that case, clicking the disclosure triangle to expand the cut flickers but doesn't expand, and doesn't explain why. It seems like the features is broken. Better error handling would be good.

Poll #11556 cut expander should show error when accessing protected post
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (9.6%)

(Other: please comment)
0 (0.0%)

ladyasul: A picture of the back of a fairy, with their red-and-gold wings spread out. (Default)
[personal profile] ladyasul

Title:
Long ECHI could stand to get broken up

Area:
comments, comment display

Summary:
When the ECHI (Explicit Comment Hierarchy Indicator) gets very, very long, like in a 100+ comment-deep thread, it can do odd and ugly things to the layout. Perhaps it could be broken up with spaces, every so many levels, to avoid mauling page formatting and allow it to wrap and improve ease of reading/understanding?

Description:
On comment pages, when a thread of comments gets very long (as often happens in some conversations, but mostly happens in roleplay threads, in my experience) the ECHI (Explicit Comment Hierarchy Indicator) can get VERY long. As in, absolutely ridiculous. It stretches comment headers and collapsed comments alike, and tends to make the layouts I've tried, including the site-schemed pages, behave poorly because of it.

Plus, after a while, it simply seems to blur into one long trail of characters, to try to read it. Phone numbers are broken up into groups of usually 3 and 4 digits for readability (and ease of remembering.) It would be great if the ECHI output could be broken up as well (by spaces every so many characters?) so that it could be made more human-readable and wrap within comment headers, too.

For example, one actual ECHI from an RP thread I was trying to read is 326 characters long (counting the period at the end.) It would be far nicer if it could be displayed more like this instead:


86a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a1a1 a1a1a1a.


My default font size is fairly normal (14-15px) so I can only imagine how badly the page layouts would break for someone who has their font sizes set much higher for eyesight reasons.

I've tried mucking about with Stylish to make the comments' headers and the collapsed comments simply scroll sideways when this happened, but couldn't find CSS which would do this to my satisfaction and still let the comments stretch horizontally with the page how I wanted them to.

As it is, I switched accounts just so I could read that thread without scrolling horizontally to read each comment's text.

I'm not sure what drawbacks such a fix would have. Maybe there would be disagreements over where to add the spaces so that the ECHI can be wrapped, or it would be difficult to implement? I know that long ECHI strings aren't an issue for most people, but it would be nice for something like this to be implemented for those times where it does become an issue.

Poll #11554 Long ECHI could stand to get broken up
Open to: Registered Users, detailed results viewable to: All, participants: 43


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
13 (30.2%)

(Other: please comment)
1 (2.3%)

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