Aug. 13th, 2010

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

Title:
Do not show poll results to logged out users without user action

Area:
Polls

Summary:
If a user is not logged in, they should see the 'Fill Out Poll' display, with the 'submit' box marked unavailable, with a prompt to login in order to be able to vote.

Description:
Currently, if the reader of an entry is logged out, they see the results of a poll, without seeing the option to take part in any way. This leads to many users to assume they can't vote or the poll is closed; this is especially true of readers from other, non-LJ derived sites.

This is leading less off-site readers to take part in polls, and creates a bad usability experience and poor workflow, especially for users who have not logged in with OpenID before.

Instead of showing the current poll results to logged out users, they should see by default the fill out poll display, with a clickable option to see the results instead. In addition, a clear link to the login page, with a returnto keyed in, makes it much more likely an individual user will actually take part.

Ideally, of course, the logging in bit can be AJAXified alongside the other plans for polls.

I have mocked up a partial example of this using some CSS:
http://matgb.dreamwidth.org/376612.html the poll is from Miss_S_B's journal (this suggestion is at her request), and the returnto link takes you there. Unfortunately, a logged in user using style=mine will see the box intended for logged out users, but that's the best I can do without a change in the base code.

Thinking through for drawbacks of this, none spring to mind, logged out users, even DW account holders not knowing they're logged out, shouldn't see the results immediately before they've voted, logged in users don't, and it improves both interop and usability.

Poll #4089 Do not show poll results to logged out users without user action
Open to: Registered Users, detailed results viewable to: All, participants: 35


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
10 (28.6%)

Shouldn't be implemented.
7 (20.0%)

(I have no opinion)
3 (8.6%)

(Other: please comment)
0 (0.0%)

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

Title:
Make returnto work from the OpenID login page

Area:
Logging in, OpenID

Summary:
If redirected to the login page, a DW user will get returned to their original position after logging in, OpenID users won't. They should be treated in the same way as normal users as much as is possible.

Description:
If someone logs in from the OpenID page with a returnto URL, they'll get redirected to that locale if they're a DW user. But if they use the OpenID login box, they'll instead get directed to the 'welcome back' page.

This is, in normal circumstances, good, as we want to ensure OpenID users get the full site experience. But it's bad if they've been directed there for a reason, such as inadvertent logging out or for a poll. If you've not encountered returnto working properly, and want to see it, logout, then follow this link:
http://www.dreamwidth.org/openid/?returnto=/users/miss_s_b/1087048.html (that's the link I'm working on, it can work on any site site page). It's a useful feature that improves workflow, and should work for OpenID users.

Drawbacks: New openID users won't see the welcome message, or get prompted to validate their email, this could be fixed by an interstitial, a popup, or similar if considered important enough. Advantage: improved UX for new users, makes site less offputting and encourages engagement.

If comment boxes and polls can have an OpenID AJAX login that keeps the user on the page itself, this suggestion might be considered redundant, but given OpenID users can use many site functions, I think it's still useful.

Poll #4090 Make returnto work from the OpenID login page
Open to: Registered Users, detailed results viewable to: All, participants: 34


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
5 (14.7%)

(Other: please comment)
1 (2.9%)

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

Title:
Have a run-off option for polls

Area:
polls

Summary:
It should be possible to have polls where users ranks options in order of preference (instant runoff or preferential voting).

Description:
Currently we allow for simple plurality voting (radio buttons) and approval voting (checkboxes), but not for preferential voting. As a polling theory geek (involved in the UK campaign for reform) this makes me sad.

We should be able to have polls where a list of options is given, and voters can rank them in order of preference. When the poll is closed, a counting algorithm can be run to reveal which option wins after losing preferences are reassigned.

The code, I think, partially exists for this on LJ as they used it for the advisorty board elections. I don't think it was a good implementation, but it was workable and could probably be improved.

Drawbacks are mostly coding and processing time, as calculating a result will require backened work, especially true if the current result is showing. The LJ implementation is poor and would need improving.

Advantages are that polling geeks like me are very happy, and users can use polls in a more expressive manner. Prefential voting is a good way to organise outings and similar, so good for a journalling site; eg ten people plan a meal together, do they want pizza, burger or that new veggie place, etc...

Poll #4091 Have a run-off option for polls
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (13.0%)

(Other: please comment)
1 (2.2%)

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

Title:
Poll admins should be able to discount votes

Area:
polls

Summary:
Every account you have can vote in every poll. Polls can thus be rigged. As admins can see who has voted, they should be able to discount votes from tallied display if they can see abuse.

Description:
Those of us with multiple OpenIDs and/or multiple accounts know that we can login many times in order to push a poll in the right direction. For most polls, they're just fun and not a problem, but for some it can be annoying and/or abusive.

The original poster of a poll should be able to look at the respondents, and discount any that they know to be duplicate accounts and/or whose opinion they don't really need to see.

Disadvantage: poll admins can use the power to rig results by discounting those that vote the way they dislike. This could be counterbalanced by listing clearly all those whose votes have been discounted. Overall, I think the ability to abuse a poll with multiple accounts and/or dogpiling is greater than the ability to discount individual votes, but if discounting is done it should be done transparently, and with the potential to add the votes back in.

Alternate solution would be to friends lock a poll, but that's not a good solution for, for example, open competitions and similar; you want comm members to vote, you want to use the poll to promote the competition, but you don't want individuals to cheat. I think this is a more refined option.

Poll #4092 Poll admins should be able to discount votes
Open to: Registered Users, detailed results viewable to: All, participants: 44


This suggestion:

View Answers

Should be implemented as-is.
12 (27.3%)

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

Shouldn't be implemented.
15 (34.1%)

(I have no opinion)
9 (20.5%)

(Other: please comment)
3 (6.8%)

ninetydegrees: Art & Text: heart with aroace colors, "you are loved" (Default)
[personal profile] ninetydegrees

Title:
Site Scheme: scheme with neutral colors

Area:
site schemes

Summary:
Create a new scheme using more neutral and/or less contrasting colors.

Description:
When you're uncomfortable with bright colors, you don't have much choice. Both Tropos have very bright colors, Celerity isn't so bad but only exists as a vertical layout and is mostly white (so bright too) and Gradation is also a high contrast scheme. I think it would be nice to have a scheme with more neutral colors and/or less contrast.

Poll #4236 Site Scheme: scheme with neutral colors
Open to: Registered Users, detailed results viewable to: All, participants: 41


This suggestion:

View Answers

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

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

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
8 (19.5%)

(Other: please comment)
0 (0.0%)

azurelunatic: Vivid pink Alaskan wild rose. (Default)
[personal profile] azurelunatic

Title:
Push notification of new reading list entries

Area:
reading page, this is the future

Summary:
A notice informing you when you have new entries on your reading list so you know when to refresh it. This could be at the top of the page, in the page title, or wherever else the creator of your style wants to put it.

Description:
Like Gmail, Twitter, and probably more of the flock of post-web-2.0 services out there, it would be nifty to be able to have a push notification to your reading page that would tell you when you needed to refresh.

It would obviously cost some are-we-there-yet from the reading page, and would require scripting, so it wouldn't be useful to all users. However, it could save on needless refreshing of the reading page, and thus might be a net savings for both the user and Dreamwidth.

Poll #4237 Push notification of new reading list entries
Open to: Registered Users, detailed results viewable to: All, participants: 46


This suggestion:

View Answers

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

Should be implemented with changes. (please comment)
13 (28.3%)

Shouldn't be implemented.
4 (8.7%)

(I have no opinion)
7 (15.2%)

(Other: please comment)
2 (4.3%)

Profile

Dreamwidth Suggestions

December 2018

S M T W T F S
      1
23 45678
9101112131415
16171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags