Plugin: Feature voting separated from Likes

Continuing the discussion from Feature to allow uservoice/getsatisfaction suggestions and voting:

“Post likes” and “Feature likes” don’t overlap well. If a company makes a popular Android app, the first person to type up a 70-character long “Make an iOS port” topic could quickly garner 1000 Likes. In this case the number of likes does not accurately reflect the quality of the post nor the user’s community participation. The flip side of this is that users might reserve their likes.

The motivation behind this plugin is to separate “votes on a feature” from “liking a post”.

Votes as an archetype of Likes

Votes could piggyback the Like design, but the two would be treated as completely separate entities, so that votes on features don’t count towards Trust Levels and such. So while the average post can have “Likes”, a special category could allow “Votes" as an additional metric, applied to the topic as a whole.

Topic view:

Topic view, scrolled down:

  • Votes are displayed above the topic creator’s post, distinguishing the title as a separate thing that you can vote on. You’re voting on the proposal, not the person.

  • Below, the forum works as normal. OP’s post can be Liked, just like everyone else’s.

  • Votes are per-topic only, not per-post as the way Likes work.

  • Votes should be revokable at any point in time

  • Votes would be anonymous to everyone except admins (configurable)

  • The plugin would be activated per-category, just like Solved.

  • Individual topics could still be unflagged as a feature request, to remove the votes counter and use it purely as a discussion (alternative workaround is to have a sub-category for feature discussions).

  • A user should only be allowed to have 10 active Votes (configurable)

  • Closing a topic would disallow further voting and return active votes (while retaining vote count).

As a result of such a plugin, the average like count on the first post in a feature request would almost certainly take a hit, but I don’t see that as a bad thing.

Stretch Goals

Show vote count in topic list

Similar to this:

“Planned” & “Done” buttons integrated with tags

The plugin would add “planned” and “done” buttons for moderators to click on, which would do a combination of actions like "close topic + apply ‘done’ tag + return active votes.

Votes by unregistered users

  • The Votes button should be viewable and clickable by unregistered users (want to vote without registration? just attach your email to your vote and we’ll keep a staged account for you, no fuss)

Status notifications

When the status of a feature is changed to “Planned” or “Done”, an email notification will be sent out to all voters.

Super Votes

Users have 3 “Super Votes” as a way to differentiate between popular wishlist items and MUST-HAVEs. Both types of votes would count towards the same grand total of “Votes” (so technically the Super Vote is just an ordinary Vote with a special flag attached) but say;

If one feature has 50 Votes and 3 Super Votes, while another feature has 10 votes and 6 Super Votes, that’s interesting data.

Furthermore, only fully registered users (perhaps even limited to a TL or custom group like Customers, but this could be tweaked per community) get Super Votes, so it could work as an added incentive to participate as a real member of the community.

37 Likes

Isn’t this already what New Relic built for their site and is active right now…?

Can’t say I’m a fan of the approach, personally, but as a plugin, sure.

Also you’d need to define mobile behaviors; a spec without mobile is a non-starter.

Nope, very different to newrelic. They have a Q&A type plugin, everything can be up and downvoted, no limits on voting.

I am a huge fan of forcing users to pick the 3 most important things for them. There is though tons of mechanics around that very simple concept.

I wonder if “Limit likes on OPs in a particular category” is a good enough first pass at this without needing tons of work. You miss out on “supervote” but still, very easy first pass.

10 Likes

Some clarifications here :slight_smile: I was wondering why voting on the title would equate to voting on the proposal when OP’s post === Proposal in most cases. I personally don’t think the title is sufficient to represent a good proposal… it is usually a combination of the title and the use case described in OP’s post. :grin:

That’s just a visual hint, it does not mean the only thing people are voting on is literally the title :wink:

1 Like

I know this says configurable, just want to confirm that admins means staff (admins + mods), not just admins.

Hmm I know they are not just voting on the title but I was wondering why placing the call to action button at the title would represent a vote on the proposal. :smile:

Here is a screenshot of UserVoice

Then you have Reddit (which is both up/down voting

Shifting the title over for the votes to be located seems far easier than shifting the title and first post (to match UserVoice), it also seems better visually than shifting the first post inwards or trying to put the vote box inside the first post.

I think if you could shrink down that box to be the size of an avatar (by width), it would make the visual a lot better. However, that may mean you might have to sacrifice the word Vote for an icon (especially in foreign languages).

2 Likes

Because it’s up there with the title and category, which are global elements as far as the topic is concerned. If you move around in the topic, they’ll come with you (sticky header), because they’re essential to the context of the entire discussion.

By default it’s also neatly separated from the post body & author by an <hr>, which I always liked, because while the body of your post is pretty much yours to do as you like with, trusted users reserve the right to change your category and even your title.

And lastly and maybe most importantly, what @cpradio just ninja’d me with. It’s in line with the industry standard of feature voting, UserVoice.

3 Likes

I couldn’t find the answer to this above so I’ll pose the question. What happens if I reopen a topic? Or is that not allowed? I don’t think you can reclaim the active votes from a user since they’ll likely already be placed elsewhere. Maybe allow them to go over the limit since it would have to be a user with authority who caused it by reopening the topic?

1 Like

Good question! I think what should happen is:

  • Say you have 0 active votes left.
  • A moderator reopens an idea you voted on
  • Now you have -1 active vote left.

Meaning, to vote on something else, you’ll now have to withdraw 2 active votes. So technically it’s possible to exceed your limit, but it can’t be used to your advantage.

[quote=“jomaxro, post:6, topic:38772”]
I know this says configurable, just want to confirm that admins means staff (admins + mods), not just admins.
[/quote]Admins means admins, but configurable means you could expand it to staff. Many big communities will appoint moderators that aren’t actually hired employees of the company. Best to default to the privacy setting of least surprise and let people tweak it from there.

(Though if it turns out it’s technically easier for all staff users to have access, I have no objection to that).

3 Likes

No argument there. I just think it is important to ensure that the permission set is expandable.

Is there an archetype of likes currently or is that an add that this plugin would have to handle?

No, there’s no concept of the archetype in existence yet. Whether it’d be up to the plugin to do all of the heavy lifting remains to be seen though. It’s not unusual that sensible extensions of the core make it in as PRs.

[quote=“sam, post:3, topic:38772”]
I wonder if “Limit likes on OPs in a particular category” is a good enough first pass at this without needing tons of work. You miss out on “supervote” but still, very easy first pass.
[/quote]I’m not so sure. My gut says this works best as an all-or-nothing proposition. “A Like is a Like, except in the #feature category; there it’s something slightly different” – that’s confusing, and it dilutes the meaning of a Like as an acknowledgement of good content.

You could simply rename stuff for first post

Both liking and voting on a feature is equally confusing.

I wondered about that. It would be a lot faster and easier to pull the like button off the first post and reuse it at the top for votes. Then you’d just need to add a custom field on the user that holds the number of available votes, but can we do custom fields on a user-topic relationship? That would make it possible to know which topics they’ve voted for. Maybe there’s an easier and better way.

This doesn’t help with “super votes” but I can’t say I’m a big fan of that anyway.

As you already said this would be a killer-plugin for every community product based
I have the same problem as matter of fact I don’t use likes to sort my features but the top view (filtered by category), which is more truthful but even that does not accurately reflect the quality of the proposal.
Othewrise, how can you consider the features weight without this plugin?

@erlend_sh Are there any outstanding questions here from your view? I’m curious about this for a future community and may be able to find time to help out with it.

1 Like

Not really. I should just reiterate the fact that I’ve no clue how feasible it is to create “an archetype of Likes” so that you can piggyback on its existing functionality. For that you’ll have to dig into the code and start asking questions when you hit roadblocks.

That’s been one of my bigger concerns with it. I wondered about hijacking the like count on the original post like Sam mentioned.

I have a feeling that would be a better approach at the onset. I couldn’t find this in the source so I assume it doesn’t exist, but is there a custom field option available on the Topic-User relationship? We could use that to hold a flag for the user to show whether they’ve voted or not.

Do you have plans to start a GitHub repo for this?

1 Like