Feature to allow uservoice/getsatisfaction suggestions and voting

(Patrick Klug) #1

I’m mostly after the use-case where users can make feature requests and vote on them. I would rather not split my community into two different systems and discourse seems to be a great fit for this.

The way think it could work is to enable voting on a whole discourse category (or sub-category) turning every post in that category into a votable feature. The category view would then sort these topics by votes.

Updated with mockup, 10. January 2016:

Collecting user feedback and ideas like UserVoice/ UserReport
Plugin: Feature voting separated from Likes
(Paul Yoder) #2

I’m looking for a plugin like this as well.

(Daniel) #3

I’m pretty sure the topic list used to have a likes column which was sortable.

If there was an option to switch this back on and then set a default sort order for a category this could provide a quick solution.

(Rikki Tooley) #4

The likes column displayed total likes for the topic, not just the OP. So it would only be an approximate.

Better solution imo is to extend the archetype system so this can be done in a plugin (iirc voting is possible by creating a custom archetype, but changing the sorting on these topics isn’t)

(Sam Saffron) #5

The sorting thing is trivial. There are a few less trivial changes needed for this plugin to work.

  1. Custom view for specific category topic listing
  2. Token concept (you only have N feature reqs you can vote for)
  3. Custom view for topic

I would like us to support this level of extensiblity but we don’t have time slotted for it yet.

(Caue Rego) #6

What you mean by either or both those “custom views”?

From my weak perspective, sorting is all we need. Token isn’t necessarily a good idea.

On a similar note, I’m thinking about using discourse as it is for ticket support (one of the other 2 aspects from uservoice):

(Patrick Klug) #7

I think a token-mechanic is crucial for this.

(Caue Rego) #8

From my point of view, token differs in 2 things from the current “likening” mechanic:

  • limit of votes
  • weightening

None of which I see as crucial.

To me, this means simply adding a “like” button beside each topic which would like the first post there. Why would you need to add vote limits and weight there? I understand that’s how uservoice works, but I never saw any point to it. Maybe that’s just me being dumb, though! :wink:

Also, why not “splitting” the community into two different systems, if you can have the same login for them?

(Caue Rego) #9

Actually, now I think most crucial things would be:

  • Client contact information
  • Client history
  • Grouped PM

But you could also go with zendesk instead.

(Patrick Klug) #10

just as a data-point for the discourse team: If I could vote for features here, I’d put all my votes on this feature :wink:

(Jeff Atwood) #11

But you can already do this. Post in a “feature voting” category, then people like the first post to indicate support, and sort the category by likes via query string. See the “bug” and “feature” home page links that @sam set up here as examples.

(Patrick Klug) #12

@codinghorror is a ‘feature voting’ category a setting or is that just a concept you apply yourself?

I agree with @sam’s initial assessment that this feature requires at least three things:

Without this, this is of limited use.

(Kane York) #13

@pakl, that link does order the bugs by the number of likes. I just added the word “Voted” in front to make that more obvious. (Anyone got suggestions for a better word?)

(Patrick Klug) #14

I’m surprised that this isn’t much of a priority and that you guys seem to be happy with your ‘order by likes’ custom headers. I doubt that this system is very transparent to the average user.

(Sam Saffron) #15

We will get to some of this but for now our biggest priority is billing and onboarding customers which is key to our survival as a company.

We will get to some extensibility stuff for the next release.

(Patrick Klug) #16

makes sense. good to hear and good luck!

(Erlend Sogge Heggen) #17

A lightweight solution for that would be:

  • Only allow a total of 10 likes in open threads for the /c/uservoiceclone category.
  • When a thread is closed (because accepted or dismissed), that Like no longer counts towards your limit.

[quote=“sam, post:5, topic:19812”]
Custom view for specific category topic listing
Custom view for topic[/quote]
Really looking forward to this kind of thing being possible.

Doing it as a plugin will usually be the way to go of course, but in a pinch one could always make a separate app as well. One could point a category to an URL like features.discourse.org which would take users to a stand-alone app built on the Discourse API.

People have done a lot of really cool things with the GitHub API. Among them are completely new interfaces for GitHub Issues, e.g. with a greater focus on project management.

It’d require considerably more work than a plugin, but on the plus side developers can work with the toolbox of their choice, and there are no restrictions whatsoever on layout.

(Eytan) #18

Bumping this topic - we are evaluating using Discourse, and would like to allow each user to have a limited number of votes in a given time period, e.g. 5 votes per day.

(Patrick Klug) #19

Given the price of alternative solutions out there, I’m surprised that there isn’t more interest in this. Surely having a well integrated uservoice/getsatisfaction-like service would be a major selling point for discourse?

(Erlend Sogge Heggen) #20

Indeed, I’m quite surprised myself that no one has made a bet on this type of (premium) plugin for Discourse yet. Literally hundreds if not thousands of Discourse forums are product-centric, and most of these would benefit from a more formalised platform for feature requests.

I suppose one major detractor for prospective developers is that how to implement it is not abundantly clear. There are different roads you could go down:

Repurpose the native Likes for feature requests

Likes could be selectively stylised as “Votes” for a given category.

Problem: “Post likes” and “Feature likes” don’t always overlap well. If a company makes a popular Android app, the first person to type up a 70-character long “Make an iOS port” feature request 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, which bothers me.

Make a separate, custom voting system

Would allow a more tailored solution, e.g. something that closely mimics UserVoice’s more flexible rating system.

Problem: Yet another points system is added, which can get confusing. There’s also the matter of whether Likes should remain, alongside the custom points system, as a way to acknowledge high quality posts.

Create a Likes archetype

Piggyback the same system, but treat them as 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" instead. Maybe that’s what @strager had in mind in the first place but I thought it important to point out these subtle but important differences.

Problem: There’s still the issue of “how do I acknowledge a post of high quality?”, but…

In conclusion, I favour the last option, the “Likes archetype”. It is conceptually close to what Discourse users are already familiar with, it shouldn’t be as complicated to do as a completely custom rating system and when it comes to post quality I’ve realised that, as far as boosting your community rep goes, it’s actually kind of cool if the way to play the “feature game” is to make valuable additions to other people’s feature requests, as replies would receive Likes instead of Votes.

Also, it would still allow for some important customisations:

  • Votes should be revokable at any point in time
  • 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 (see below).
  • 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 (while retaining vote count)”.
  • 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)

Super Votes

I’ll keep this separate from the rest of the list since this one might not be as straight forward to implement, but I’d love it if users could also 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, but this could be tweakable per community) get Super Votes, so it could work as an added incentive to participate as a real member of the community.

Is "liking" a post too intimidating?