cesy: "Cesy" - An old-fashioned quill and ink (Default)
[personal profile] cesy

Title:
Send error if you try to email post from the wrong address

Area:
email posting

Summary:
Don't fail silently on email posting - show an error message somewhere with an explanation.

Description:
If you try to email a post to your journal, there is a setting that lists the email addresses that are allowed to do this. If you have multiple email addresses, and accidentally send it from one that's not one of the three on http://www.dreamwidth.org/manage/settings/?cat=mobile, it fails silently.

Instead of failing silently with no clues, you should get a notification of some sort to let you know it happened and give you a clue why. This should include appropriate caveats about telling Support or improving your security if it wasn't you that did it, and could go either to your Inbox, to your main email, or to the email you tried from, whichever is considered to be most secure.

Poll #13461 Send error if you try to email post from the wrong address
Open to: Registered Users, detailed results viewable to: All, participants: 31


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
15 (48.4%)

(Other: please comment)
0 (0.0%)

tree: a figure clothed in or emerging from bark (Default)
[personal profile] tree

Title:
Change wording of error message re: exceeding max number of tags

Area:
tags

Summary:
The error you get if you try to add new tags when you've reached the tag limit for your account type doesn't make sense.

Description:
The community het_reccers was just imported from LJ, with its 1800+ tags. Prior to upgrading to a premium paid account, I tried to add new tags (forgetting about the tag number limit for free accounts) and got an error.

Here's a screenshot of the error message: http://i.imgur.com/95L5j.jpg. It reads as follows:

Error
Adding this tag would exceed your maximum of 1000 tags. Please remove at least 814 of the following new tags: [2 tags are listed]

I understand the meaning of the message, but obviously it's not possible to subtract 814 from 2 in this situation. I think a better message would be something like, "Adding this tag would exceed your maximum of n tags. You will not be able to add new tags until you delete n existing tags or upgrade your account." And then have a link to the FAQ about paid accounts and/or the Shop.

This might need to be a new suggestion, but I also thought of the possibility of being able to pay for a la carte tag bundles. Like being able to purchasing 100 extra tags for n points. I can see that being useful for communities like het_reccers. We're not that far from our 2000 limit now. Egads.

Poll #12342 Change wording of error message re: exceeding max number of tags
Open to: Registered Users, detailed results viewable to: All, participants: 52


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (13.5%)

(Other: please comment)
0 (0.0%)

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

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

Area:
comments

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

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

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


This suggestion:

View Answers

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

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

Shouldn't be implemented.
6 (9.5%)

(I have no opinion)
11 (17.5%)

(Other: please comment)
0 (0.0%)

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:
Better explanation when demanding a CAPTCHA for an HTML comment

Area:
Commenting

Summary:
It is possible for a commeter to be shown a CAPTCHA even when the journal owner has set "Show CAPTCHA to nobody". It would be good if the reason for this was explained somewhere.

Description:
This is pretty obscure (only discovered due to bugfix-testing), but bear with me...

- Users set in account settings -> Privacy who will be shown captchas when they try to comment.

- In addition to this, and entirely independent of this setting, there is a site-wide configuration setting that causes captchas to be shown to people who use HTML in comments (by default on Dreamwidth this is shown only to anonymous commenters who use HTML. There is an option to enable it for all HTML commenters, which other sites using the code could turn on).

- It is thus possible for somebody making a comment (which includes HTML) to be shown a captcha even though the journal owner has set that captcha will be shown to "nobody". The text with the captcha doesn't indicate the reason that it is being requested, but simply says "Please fill out the CAPTCHA as an anti-spam measure".

I don't think it's actually a bug, hence I'm putting it in dw_suggestions, but I think that some journal owners might feel aggrieved about this - for instance if they have assured readers with accessibility needs that they will not need to complete a captcha to comment.
I imagine that there are good reasons for preventing robots from using HTML in comments, but I think that the text shown to the commenter when they are presented with the captcha should be amended to explain why it is happening.
An alternative (or additional) solution would be to add text to the Account Settings page to explain that setting "nobody" may still be overridden - but I think this would add unnecessary complexity to Account Settings for something that few will encounter or be bothered by.

Poll #11557 Better explanation when demanding a CAPTCHA for an HTML comment
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

Should be implemented as-is.
37 (74.0%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (16.0%)

(Other: please comment)
1 (2.0%)

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

screening

Jun. 19th, 2012 08:07 pm
lumpyspaceprincess: (Default)
[personal profile] lumpyspaceprincess

Title:
screening

Area:
entries

Summary:
take you back to the post after commenting in a screened post

Description:
when a post is being screened, if you comment in it currently, after posting it takes you to a page that says "successfully posted!". to get back to the post you have to hit the back button twice.

this is real obnoxious in large communities when you want to reply to several different comments and there is constant activity

it would be great if it would just take you back to the post automatically, or have a button on the successfully posted page that returns you to the post (and the page you were on)

thank you!

Poll #11023 screening
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
12 (24.0%)

Shouldn't be implemented.
1 (2.0%)

(I have no opinion)
13 (26.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:
Clearly flag tagging permissions for posts to communities

Area:
tagging, community administration, posting, error messages

Summary:
For many communities, creation of tags is limited to administrators-only, to prevent an ever-growing list of subcategories, misspellings, etc. For some communities, it's also the case that only administrators are able to apply tags to posts. It should be clear on the Post an Entry page whether either of these settings is in force for any given community.

Description:
When managing tag settings as a community, there are the options:

Who can create new tags and add or remove tags from entries? Anyone/Members only/Administrators only

Who can add existing tags to entries? Anyone/Members only/Administrators only/Entry author and administrators


On the Post An Entry page, it is not [as far as I know!] made clear which of these settings have been chosen for any given community, which can lead to confusion when e.g. someone is trying to be helpful by tagging their entry but adding tags to entries is restricted to administrators only. (The major use-case I've seen of this is in the LJ community vaginapagina, where administrators choose entries that are particularly well-framed and have particularly useful discussions in comments to tag, in order to build up a "resource library" of past posts, which would be less information-dense and useful if all entries relating to a topic were tagged.)

Suggested solution: when somebody selects a community from the "post to..." drop-down, or clicks "post to [community]" in the navstrip, the "tags" area of the Post An Entry page should automatically update with a useful legend. One way I envisage this working:

* if only administrators can /tag/ entries, the tag box should be greyed out with a brief legend to the tune of "only administrators can tag entries in this community". The full list of tags could perfectly well remain accessible, with a similar legend top & bottom and all the tick-boxes greyed out.

* if only administrators can /create/ tags, the tag box should have a brief explanation along the lines of "please choose from existing tags", and typing into the box should result in searching the community's current list of tags.

Poll #10449 Clearly flag tagging permissions for posts to communities
Open to: Registered Users, detailed results viewable to: All, participants: 68


This suggestion:

View Answers

Should be implemented as-is.
63 (92.6%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (7.4%)

(Other: please comment)
0 (0.0%)

montuos: cartoon portrait of myself (Default)
[personal profile] montuos

Title:
Importer error pages need buttons for the next step

Area:
Importer

Summary:
If you omit any information when starting the importer, the error page drops the ball on guiding you to the next step of the process.

Description:
When using the importer [https://www.dreamwidth.org/tools/importer], I forgot to click the site I wanted to import from before I filled in my userid and password and then automatically hit enter. The error page that comes up when you do that [https://picasaweb.google.com/lh/photo/6s-ph1Nbgfxy0p3zwIqYi9MTjNZETYmyPJy0liipFm0?feat=directlink] drops the ball on what to do next. It says "Please select a service to import data from." but the options for that are not displayed, and there is no further guidance for what the user should do. Further testing reveals that you get "Please provide a username and password for the service that you selected." if you forget either of those, but again, there is no further guidance for what the user should do.

In a perfect world, the error page should remember all the information already provided, including the password, and repeat the "Choose a service to import from:" or "Username on other service"/"Password on other service" item that was missed, and have a Continue button to proceed forward.

My secondary preference would be to have a button to go back to the missing step. This would be a more versatile fix since you get the exact same error not just from failing to select a site but also when you fail to fill in any of the information. However, I would prefer not to have to go back because although the username is remembered, I have to re-enter my password for the other site.

At the very least, even if no buttons are added to the error page, there should be an instruction to use the browser's Back button. Again, I would prefer not to have to go back because I have to re-enter my password for the other site even when I already did that.

Poll #10446 Importer error pages need buttons for the next step
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.
0 (0.0%)

(I have no opinion)
16 (34.0%)

(Other: please comment)
0 (0.0%)

reziac: (Default)
[personal profile] reziac

Title:
Unlabeled search box

Area:
Confusing the user, especially the novice

Summary:
The search box in the upper right needs its own label, NOT just the mouseover label.

Description:
The search box in the upper right needs its own label, NOT just the mouseover label. If someone doesn't realise what it is, the dropdown appears to *go* to "Interest" (etc.) with an expectation of some general page appearing, compounded by the button saying "GO" (normally that's an indication that a *dropdown box* will work without javascript) rather than "Search". It got *me* that way, having not run my mouse far enough over and not being a fan of intrasite search so I just didn't think of it (if anything, I'd vaguely wondered what the blank box to the left was for, but didn't investigate as I was distracted by the dropdown).

Anyway, I'm sure the words "search Dreamwidth" wouldn't be too much to squeeze in, perhaps immediately below the box. ;)

You really do have to specify WHAT such a form searches (not just "Search"), because user expectation is that ANY search box searches the whole dang world a la Google. There was a good article recently on this, somewhere on Jacob Nielsen's mondo excellent Usability site, http://www.useit.com/alertbox/

As to my previous poor rejected suggestions, which proved redundant to DW's Master Plan, great minds think in similar... what's that noise?? <g>

Poll #9493 Unlabeled search box
Open to: Registered Users, detailed results viewable to: All, participants: 50


This suggestion:

View Answers

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

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

Shouldn't be implemented.
5 (10.0%)

(I have no opinion)
19 (38.0%)

(Other: please comment)
0 (0.0%)

sincere: DGM: Lenalee's back to the viewer (Default)
[personal profile] sincere

Title:
Making circle changes from the hover menu should be less easy

Area:
entries

Summary:
It is currently too easy to accidentally make circle changes through the hover menu, accidental or otherwise. I propose changing the current <i>two</i> links that require no confirmation before acting to <i>one</i> link that will redirect to the Add to Circle or Manage Subscription page with full text options.

Description:
Several times in the last two weeks alone my mouse has passed, either purposefully or accidentally on the way to clicking something else, over someone's usericon. The hover menu doesn't open until the instant I am attempting to click somewhere else, and now I have clicked on one of the many links in the hover menu. <i>Immediately</i> I have subscribed to someone's journal, unsubscribed from someone's journal, granted someone access to my personal entries, or removed someone's existing access to my personal entries. This simple misclick can result in as many as two email notifications to let someone know that I changed their status -- when I had no intention of doing anything like that.

It's embarrassing to accidentally grant access to someone you're just talking to casually on a community, and even more embarrassing to then go "Uh, sorry, never mind" and take it away again.

I don't see why the hover menu makes this so easy. This requires only a single click and it's just done, but when I do it on the profile page, where I am <i>much</i> less likely to click on those links accidentally, it takes me to a separate page going "Are you sure?" first.

In addition, the hover menu has a lot of text on it, and it appears and disappears very quickly. Once I misclick, I usually have to hover over the icon again 3-4 times to see what I changed, and then to get my mouse to the link to change back again.

My solution to these problems: Replace the "Subscribe/Unsubscribe" and "Grant access/Remove access" links with just one link, which will redirect users to the existing Add to Circle or Manage Subscription pages (depending on their current status in your circle). This both removes the accidental adding problem, and makes it easier to use.


<b>Potential pros:</b>
+ No more accidental circle changes. Big pro for me.
+ Fewer links means less chance for misclicking in general.
+ Users won't have to sort through as much text to find the link they want.
+ Seems more accessible for readers who have reading or clicking difficulty than providing so many options on the tiny, there-and-gone-again hover menu.


<b>Potential cons:</b>
+ Some ease of use removed, requiring an extra page load to change circle status.
+ If there is any accessibility reason for the pile of links and text on the hover menu, that should be taken into account.
+ If you were hoping to meet your future spouse via a misclick granting them access and them falling in love with you while reading your private meanderings, this may reduce the odds of that happening.

Poll #9258 Making circle changes from the hover menu should be less easy
Open to: Registered Users, detailed results viewable to: All, participants: 69


This suggestion:

View Answers

Should be implemented as-is.
9 (13.0%)

Should be implemented with changes. (please comment)
16 (23.2%)

Shouldn't be implemented.
23 (33.3%)

(I have no opinion)
18 (26.1%)

(Other: please comment)
3 (4.3%)

pocketmouse: pocketmouse default icon: abstract blue (Default)
[personal profile] pocketmouse

Title:
Error notification character limit in post title

Area:
Entries

Summary:
Add an error notification that title text goes over character limit.

Description:
I didn't notice for three days that my title text got cut off on a post I made. If there could be either a popup after you hit post, or on the post complete page, or even if there was a lathing character limit in the actual entry box, some way I can know when I post that my entry title is too long would be great.

Poll #8939 Error notification character limit in post title
Open to: Registered Users, detailed results viewable to: All, participants: 66


This suggestion:

View Answers

Should be implemented as-is.
53 (80.3%)

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

Shouldn't be implemented.
2 (3.0%)

(I have no opinion)
5 (7.6%)

(Other: please comment)
2 (3.0%)

garden_hoe21: (Default)
[personal profile] garden_hoe21

Title:
Automatically redirect .htm to .html

Area:
entries

Summary:
I don't know how much bandwidth or work it would take, but maybe you could consider changing or redirecting .htm urls on dreamwidth to .html, bypassing the 404 page. Or, maybe on the 404 page include a note that if the user got there following a url that ends in .htm, they should change it to .html.

Description:
That's pretty much it.

Poll #8904 Automatically redirect .htm to .html
Open to: Registered Users, detailed results viewable to: All, participants: 93


This suggestion:

View Answers

Should be implemented as-is.
73 (78.5%)

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

Shouldn't be implemented.
1 (1.1%)

(I have no opinion)
16 (17.2%)

(Other: please comment)
0 (0.0%)

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

Title:
Comment length warning in preview

Area:
commenting

Summary:
It would be nice if the comment preview screen told you whether you'd reached the character comment limit, without you needing to actually press "post" to find out.

Description:
Sometimes people post prompt memes where other people leave really long stories in comments! Sometimes these stories overflow even DW's very generous comment character limits.

Right now, if you try to post a comment that goes over the limit, you get an error message that tells you your comment is too long, how many characters are allowed, and how many characters your comment is.

It would be great if that error message appeared on the comment preview, as well as when trying to post - that way people wouldn't have to guess about whether their comment will fit, and how many comments they will need total.

(Or they could look up what the comment limit is, and then use an external character counter, but that's <I>hard</i> :P)

It would be even cooler if the error message did the math for you and told you how many comments you would need, total, in order to fit the whole thing!

Poll #8839 Comment length warning in preview
Open to: Registered Users, detailed results viewable to: All, participants: 90


This suggestion:

View Answers

Should be implemented as-is.
71 (78.9%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (5.6%)

(Other: please comment)
0 (0.0%)

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

Title:
do not silently truncate text fields when uploading or editing icons

Area:
profile

Summary:
When uploading or editing icons, if the text entered into the keyword, comment, or description field is too long, it is silently truncated despite the "success" message. As a result, the text attached to icons of wordy users with no memory for, or sense of, the character limits on these fields may be incomplete or incomprehensible.

Description:
If the text entered into these fields is too long, the user should be notified before the text is truncated, advised of the relevant character limit, and presented with their original text to edit.

It would be really awesome if the user could be told how many characters over they were, too.

Poll #8410 do not silently truncate text fields when uploading or editing icons
Open to: Registered Users, detailed results viewable to: All, participants: 70


This suggestion:

View Answers

Should be implemented as-is.
57 (81.4%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
4 (5.7%)

(Other: please comment)
0 (0.0%)

matgb: Artwork of 19th century upper class anarchist, text: MatGB (Default)
[personal profile] matgb

Title:
Validate HTML and warn of errors on posting

Area:
posting, crossposting

Summary:
Currently it's possible to break a layout completely by putting in extra DIV or /DIV html elements, we should validate on posting to prevent this

Description:
It should be possible to have posts validated on arrival to check for extra HTML open/close elements that aren't sorted correctly and deal with them in some way.

A friend this morning had his Delicious crosspost hit my reading page, something I normally appreciate, however there was an extra /div at the end of the list and it completely broke my reading page--it utterly destroyed his entry page.

We should be able to check entries on posting, and if on the update page warn the poster of the issue, if posted from a client we could possibly insert the 'invalid markup in entry, raw contents below' warning and not parse the HTML for display.

Ultimately, the solution matters not, so alternative solutions are welcome, but we should definitely look to fix the problem, and the invalid markup with warning seems to be a practical solution.

Poll #8391 Validate HTML and warn of errors on posting
Open to: Registered Users, detailed results viewable to: All, participants: 60


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
14 (23.3%)

(Other: please comment)
0 (0.0%)

msilverstar: (Default)
[personal profile] msilverstar

Title:
better error message for link to private list while logged out

Area:
user interface

Summary:
I sometimes get logged out by accident, that's fine, I understand. But the error message is user-hostile and very likely to fluster less experienced users.

Description:
I have a named reading filter named "v" that I generally use to avoid big feeds and such. When I get logged out and try to reload the page, I get the following error message:

Forbidden

You don't have permission to access /read/v on this server.
Apache/2.2.11 (Ubuntu) mod_apreq2-20051231/2.6.0 mod_perl/2.0.4 Perl/v5.10.0 Server at msilverstar.dreamwidth.org Port 80

It would be eversomuch nicer to see something like this:

Error: you can't see filters because you aren't the logged user for this account

(with an option to log in)

Poll #8380 better error message for link to private list while logged out
Open to: Registered Users, detailed results viewable to: All, participants: 56


This suggestion:

View Answers

Should be implemented as-is.
49 (87.5%)

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
7 (12.5%)

(Other: please comment)
0 (0.0%)

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

Title:
Feeds: provide link to feed account when account already exists

Area:
rss, site interface

Summary:
When creating a feed account with a name which is already in use, link users to the account so that they can check whether the account is for the same feed or something else.

Description:
So here's what happened: I tried to create a feed which already existed except I didn't know that and because the URL I entered was a bit different the feed wasn't recognized as a duplicate. I therefore was asked to enter an account name as if it was a new feed. The name I entered was actually the same one as the one of the existing feed account (yay universe!) so I got this error message:

That account name is already in use.

That account name is already in use.

(Yeah, twice).

Oh cool, I thought, this probably means the feed account already exists. And then I exclaimed: "But why not link me to it?!" and made a sad face. No more sad face, please?

Poll #7087 Feeds: provide link to feed account when account already exists
Open to: Registered Users, detailed results viewable to: All, participants: 83


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (9.6%)

(Other: please comment)
0 (0.0%)

vass: A sepia-toned line-drawing of a man in naval uniform dancing a hornpipe, his crotch prominent (Default)
[personal profile] vass

Title:
confirm edited post with error

Area:
communities

Summary:
If you edit a community post, and there's an error but the entry still posts, it should say that the post completed.

Description:
I just tried to edit a community entry, and got the error "Tags error: You are not allowed to create new tags for this journal; the entry was not tagged with [tag1, tag2]"

Since my edited entry had other new content apart from the tags, the edit entries page should (as well as stating the error) confirm that (apart from the error) the entry was successfully edited.

Poll #5608 confirm edited post with error
Open to: Registered Users, detailed results viewable to: All, participants: 48


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
12 (25.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (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:
Send errors on failed comment expansion

Area:
comments, making things make sense

Summary:
When a comment cannot be expanded for any reason, give an error instead of failing silently.

Description:
Sometimes you're trying to expand a comment thread, and for whatever reason, it does not work. Currently, the page stays the same as it was, and does not give a clue as to what the problem is; the user tends to have to open the thread in a new tab, or refresh the page.

Instead, an informative error message should expand where the comment should have been. Thus the only time there is no action should be when there are problems in communication between site and browser. This would be less frustrating, make more sense, and follow good programming principles to boot. It's likely to be slightly more expensive to serve an error instead of nothing, but this could well trade off in fewer needless thread and page loads. This might even be a good thing for Weird Client Stuff of the future, and possibly even the current download-comments thing.


Some of the reasons a comment might not expand:
Comment is deleted. (Although this should be pretty apparent.)
Comment has been deleted since the time of page load.
User has deleted themselves and taken their comments with them. (Also sometimes since time of page load.) [Edit: I wrote this up for LJ suggestions first; DW users don't currently have the ability to do that.]
User has been suspended. (Also sometimes since time of page load.)
Comment has been screened and you cannot see it.
Entry owner has disabled comments and you cannot see them. (In this case, to avoid giving away too much information that only the entry owner would know, any comment that exists or doesn't exist on a comments-disabled entry should return the sort of error where the only information is that comments have since been disabled.)
Whole entry has been locked since time of page load.
Whole entry has been suspended since time of page load.
Whole entry has been deleted since time of page load.


It could feed drama-llamas by alerting people to when something's disappeared so they have time to get screencaps before refreshing, but if something's already got drama-llamas in it, they're likely already making screencaps, and experienced drama-llamas already know that you open it in a new tab. In any case, this does not seem like the sort of improvement where "But users might behave worse than they already do!" should be reason enough to not do this.

Poll #4506 Send errors on failed comment expansion
This poll is closed.
Open to: Registered Users, detailed results viewable to: All, participants: 42


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
3 (7.1%)

(Other: please comment)
0 (0.0%)

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